Messages:19
Registered:October 2013 Location: Oregon, USA
Hello,
I had an awesome conversation with some guys on another thread and realized how possible this idea is to implement. (With help >.>)
Attaching mods to a gun changes the picture.
There are two ways this could be implemented.
First, the way that Sevenfm revealed to me on another thread where an attached mod will change the picture of the gun. This would require each gun to have multiple pictures for each attachment. Which, when you get into the massive amount of attachments in the mods (and in base 1.13) this can be an incredible amount of pictures (albeit easy to make ones as they would be mostly copies) coupled with the mass of different guns. I'm not sure if there is a game picture limit...
The second way may address the issue stated above but requires more coding and xml work. It is to mark each gun with attachment points on the picture (like x,y coordinates) in the xml. I.E. M4A1 has a muzzle attachment point of 120,50 (this is an example I don't know what the actual coordinate would be.)
Then, each attachment has an attachment coordinate, which would attach to the guns coordinate. With this model, you could get into very detailed attachments (like rails etc) and show them on the picture. It could even go so far as to having custom aesthetic parts for guns like grip panels on 1911s or custom foregrip hoods/receivers on AR-15s.
This would also open up the barrel length changeability for weapons without having to have copies of the gun in different lengths,
I am not a coder (yet as I haven't tried very much) but I am familiar with xml work and am willing to slog through that if someone likes this idea and wants to work with me on it!
(I really hope someone is as excited about this as I am)
Ok, what we have now:
The demonstration of how this could look in game:
About implementation concept (quote from experimental project thread):
Current situation:
There are 3 possible ways of making custom images:
1. Combining images
You just make several pictures with combinations of attachments.
It's rather simple and straightforward, and there are available pictures with such combinations for vanilla items (made for ja2'005 mod).
So the simple task is just mapping those items to ja2 stock items, finding pics in BIGITEMS folder and renaming them.
The serious drawback of this method is that it's not scalable - if you want 10 different attachments, you will need to make 1024 pictures with all combinations =)
2. Overlaying images
This method was used for above demonstrations (HK53, AK, Shotgun).
It uses prepared pictures with only one attachment + base picture, so it allows unlimited number of possible attachments.
The drawback of this method is that it's time consuming and you will need a good knowledge of specialized software, palette editing and other tricky things. This method is also mostly implemented and showed very good results (you can see on the video), but I don't see it as a base for serious modding because of mentioned time consuming things and other inconveniences
3. Mapping images
The idea is to have a set of small images of possible attachments and some way of mapping them to the image using xy coordinates stored somewhere.
Some question should be answered before even starting planning anything:
1. Do we need only big custom pictures or small custom pictures, too?
2. Where do you want to see these pictures - my idea is that they should be shown in tactical team panel, one possible place is a free space between squad of 8 mercenaries and the minimap in any resolution starting from 1024x768.
3. The exact method of mapping. Because making those pictures is a very time-consuming process, it should be optimized as much as possible.
Messages:19
Registered:October 2013 Location: Oregon, USA
The first one seems like it is ripe to be tossed out as unworkable like I thought.
On the second idea, how do you get say a silencer to be on the end of a barrel for different lengths?
I am definitely partial to the 3rd option where it is mapped like I mentioned in my post. Attachments could even add new attachment points (w/ x/y coordinates)
Answers to the questions:
1) To make it easy, I would say stick with the big pictures. Though, if we don't do it now it may never happen with the small pictures. I think with the mapping idea it would be easy to do both(one coordinate for large, one for small), all that would take is minor extra xml work.
2) Ui work is my weakpoint, if you think it could fit there, that is where it could fit. The small pic would still be shown under the portrait obviously.
3) My idea for the mapping is having the normal picture (no need to do drastic edits as far as I know), finding the x/y pixel that would be our attachment point, coding that to the xml of the item. Then when the attachment is added the x/y pixel coordinates are matched and connected.
There could be a tag on the mod to have it overlay over or under the base weapon if need be.
Edit: You did some incredible work btw. You literally made my week with those videos!
[Updated on: Fri, 05 September 2014 22:59] by Moderator
Messages:19
Registered:October 2013 Location: Oregon, USA
As in instead of the clunky STI files we redirect it to use pngs? I would love that! I have absolutely no idea how to make that happen but I have lots of experience making png sprites.
First, we need to be able to change the base picture.
Not all attachment can be shown using overlaying method, also it's good to provide a way for using existing images, for example images with folded/unfolded stock that are used in many mods.
So, we define the following tags in the items.xml
- 32-bit bitmask that defines the modifier value for the base picture. We need to define this tag for every attachment that should change the basic item picture.
- 32-bit bitmask that defines possible basic picture changes. We need to define this for every gun/item for which we make alternate base pictures.
So, how it works?
For example, we have item 1008 (folding stock), item 1012 (ar suppressor) and item 347 (AK-47).
Then we define the following tags
1008 1
...
1012 2
...
347 1
...
Then we attach a folding stock and, for example, ar suppressor (PBS) to AK-47 in game.
The program searches for all attachments and sums all uiBasePicMod values (actually, it's bitmask (logical) sum ), the result is 3 (11 in binary)
Then it checks item 347 for uiBasePicMask value and compares it with our bitmask sum using logical multiplication.
The result is 1, that means that for this item only stock attachment will trigger base picture change, and the AR suppressor pic will be shown using overlay or anything else.
Then, instead of base pic 347.sti we will load and show 347_1.sti that is our gun with folded stock.
If this is ok, then we can continue to (hypothetical) picture overlays implementation.
Messages:19
Registered:October 2013 Location: Oregon, USA
I'm a bit confused,
Could a folding stock not be shown overlaid like a normal attachment like the PBS.
For example the using attachment points method the unfolded sock would have an attachment point on the left side of the attachment where the stock meats the main body of the AK. The folded version would be the same but the part where it meets the AK would be on the right side of the attachment icon instead of the left.
I am not sure of the coding implications of this so correct me if I am wrong but using your item examples:
The x and y attachment points are obvious, the uioverlay designates the icon displaying over the main icon w/ 1 and below with 0.
In my laymanistic understanding this seem like a way to avoid having copies of the same gun picture. One main body picture, one stock picture (two if you could the folded version).
This way if we say have a skeletal folding stock we can put on the AKM, and also the AK-74, We have one picture of the AKM, one picture of the AK-74, one picture of the stock. Instead of one picture of the AKM with folding stock, one picture of AKM with wood stock, etc.
Again, I am a layman and you already have some work into this. I know your way will work and I don't want to reinvent the wheel. So, if you think we should stick with your way, lets go for it, I just am thinking of ways to reduce the work and files size of the project.
I agree, the folding stock example is just a simple demonstration of how xml tags work for changing base picture.
I think there are situations (maybe rare) when you cannot use overlaying pictures, and changing base picture will allow using tons of existing images with attachments.
This system is a basic level of gun picture customization, the next level will use overlaying images and mounting points and will be the main way of picture customization.
You don't need to make several pictures for every gun/item that can accept attachments, you define changing of base picture only when you really need it or when you, for example, need only one picture change and you already have that picture.
The next level, with mounting points and overlaying images, is much more flexible, but it also requires more preparation work and is simply not justified in some cases.
Messages:19
Registered:October 2013 Location: Oregon, USA
Well, as they say, better safe than sorry. It isn't much addition and we might as well implement it in the beginning because it will only get harder later on right?
So yes, we should add in the mod-mask part as well... The xml shouldn't bee too difficult. An example I just though of would be an improved bolt, or it could account for modern part kits on guns (to reduce conversions and combinations), or the changing out of a gun part to add a attachment rail that would normally be inside the base icon parts. Like an underbarrel rail on a pistol.
So, I guess a summation (as it stands now) of the xml entries required would be:
uibasepicmod/uibasepicmask
uioverlay
uix(and y)attachment (There will have to be one for each type of attachment and contingency. IE underbarrel, magazine, upper front, upper back etc... could tedious but I am willing to do it.
There would also have to be a rework of incompatible attachments to try to reduce attachment collisions. Like reflex sights and scopes.
Does this sound like the way we want to go?
If so, do we move this to coding projects released and in progress?
I can get to work on the xmls soonish.
Speaking of which, are we going to stick to the base 1.13 weapons and items for now?
What you suggest I think is making a XML file that will look like:
So if you want to attach small scope to m16 you need to make a file "small scope.sti" and make a record in CustomPics.xml: 632 1029 x y 0 "small scope.sti"
I think it will work, but I also think of a bit more complicated system that will allow more flixibility and will probably save some time.
It may be called a "MountPoint" system, so the main idea is to define "mount points" on the base weapon pic and on each possible attachment pic.
Then you will not need to assign each attachment to each weapon, instead if you make a new weapon you simply define "mount points" and all existing attachments will be shown exactly in place.
So, here's another wall of text "Mount point" concept.
First, we add more tags to items.xml
For each attachment:
- it's the class of this attachment, for example "small scope" or "big scope" or "reflex sight". It's not the same as NAS attachment class or attachment point, because you can define it independently, for example all scopes share the same 16 in stock 1.13, so you can define 1 class for them all or make subgroups, or even make a reflex sight with 8 to use the same "mount point" as the scopes.
- defines the order in which the base item and attachments are drawn
default is 0 that means directly on the base picture
-1 means draw behind the picture
1, 2 .. are possible layers, too, but seldom used
For each item that should have custom pic with attachments:
- you need to make several pictures for some attachments, for example, if you want to show a small scope on pistols and on long shotguns too you will need two different scope pictures because of the size difference or it will look ugly.
Also if you have a "tactical" shotgun in woodland camo, you will want to use camo picture of scope instead of regular dark grey.
So there will be several sets of attachment pictures, for example:
1 - small pic, for long rifles
2 - medium pic, for smgs/short ARs
3 - large pic, for pistols
4 - large camo pic
etc
How it works in game:
Now, you can make a set of small scope pictures, define mount point for each picture, define mount points for each basic weapon pic, and the rest will be done automatically in program:
-Program finds attachment
-It searches for the gun's ubCustomPicSet and finds the appropriate attachment picture using attachmentId and the picture set number.
-It can calculate the exact place of the attachment on the base picture using mounting point on the gun and the point on the attachment from item_mountpoints.xml and attachment_mountpoints.xml
How can we speed the thing up:
Instead of writing coordinates in XML in usual error prone way, we can define attachment points in graphical way, I mean open the picture in paint or sti-editor and directly mark the point with a red/green blue dot depending on it's class.
The same for each attachment pic.
These will be the "map pictures", now for each base picture the program will read corresponding map picture and search for specific dots, the same for attachment picture, and then display the attachment correctly.
This way you can avoid tedious XML work and instead do most of the work in graphical way and with much less errors, because it's visual and graphic.
You even don't need to calculate those mount point in any way, you simply open the base picture, take an attachment with already defined mount point, and place the attachment pic on the base picture, and you will have a ready mount point for this class of attachment.
Note: the mount point on all attachments of the same class should match, then all scopes, for example, will be shown correctly.
---------------------------------
the end of the wall of text
---------------------------------
So that's the basic concept how I see it.
You decide what way you like more. Also, nothing is implemented in the code yet, and noone is working on it currently.
I think this project needs some opinions from modders who have skills with XMLs and items and also from 1.13 coders who can tell if there's something wrong here.
Messages:19
Registered:October 2013 Location: Oregon, USA
Well I agree, from my layman standpoint this all sounds doable.
The overlaylevel idea is awesome, there may need to be more levels below the base picture just in case though. I mean magazines will display under the base, if we duct-taped another magazine to that one, it may have to display under that first magazine... who knows.
Defining the picture set in the way you are describing could also make it easier to transition to .pngs if that ever gets off the ground.
I think your idea for the graphical mount points is awesome! Way to think outside the xml box.
Woul we have to define say a uimappic or something along those lines? We don't want color dots showing up in game inadvertently.
Do you have any ideas how we can entice these people to respond? The NMS thread seems to have died slightly since I made a call to action asking for volunteers. I don't want this to happen here...
Messages:19
Registered:October 2013 Location: Oregon, USA
So, 535 people have looked at this thread and another 130 have looked at the job posting and still no bites... Can we move forward with this another way? It may be slow going with two of us (or one if you quit Sevenfm (please don't)) but it will be done eventually.
Blog
Search
Help
Members
Register
Login
Home
