Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Attachment System Beta
| Re: New Attachment System Beta[message #267846]
|
Sun, 05 December 2010 22:23  
|
|
| Wil473 |
 |
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Found the error, this is a new way to crash the game. During item creation via a merger, if the default attachment is not in Attachments.xml the game will throw an assertion error. Previously, if a default was not actually in the attachments list, it just wouldn't show up. The old error crash (and later fail safe) was if a default didn't have a slot to fit into.
Yeah, right now all basic capabilities needed to re-create UC-1.13NAS have been tested. Since I'm building this on the unfinished v2.9, there are several non-NAS elements (merchant inventories, maps, enemy items) to do before its ready. Based on what RoWa21 announced yesterday, it looks like the work invested in rebuilding OAS (and NAS 0.7) capability was worth it...
XMLEditor Capabilities Request (NAS 0.7):
- It might be useful to have some kind of slot simulator that displays in editor just what has been defined on both a slot by slot basis and a layout basis
- System to warn (but not stop) overlapping slots.
[Updated on: Sun, 05 December 2010 22:24] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #267847]
|
Sun, 05 December 2010 22:27
|
|
 ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
I'll look into the crash when a default attachment isn't in Attachments.xml. Should be able to force the code to simply ignore the default attachment in that event.
I think your XMLEditor requests are a little beyond me. I've been able to update (I think) the current code so that it will handle the new AttachmentSlots.xml, the new NAS fields in Items.xml, and the new AttachmentClass.xml lookup table. I haven't been able to figure out how to add the new NAS fields to the detail window, though. But at least it appears that everything is being saved.
EDIT: I'm not able to recreate the error, wil473. I altered Items.xml so that the SCAR-L SV gets a sniper suppressor as a default attachment (something it normally can't use) then I merged the SCAR-L CQC with the SV barrel item. The resulting merge was an SCAR-L SV with no attachments and the CQC barrel item. Of course, I then changed the default attachment to a flash suppressor and re-tried the merge. Same results. Not sure if I'm doing something wrong or not, but when I create an item through a merge, I'm not getting the default attachments at all, while you seem to be. I'm going to have to play around with this a bit since the default attachment (when valid) does appear if I use GABBI mode and ALT+W to "create" the item.
[Updated on: Sun, 05 December 2010 23:13] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #267865]
|
Mon, 06 December 2010 08:58
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Here's how slot validation is carried out.
1- Take the main item and look through Attachments.xml, Launchables.xml and Merges.xml for references to the item. If any match is found, look at the attachmentClass for the referenced item and add it's bit to a flag. Example: XM-29 OICW can support Rod&Spring, Extender, OICW Grenade Launcher, C-Mag, Flash Suppressor and AR Suppressor. So as we find each of these items in Attachments.xml, Launchables.xml and Merges.xml, we add the attachmentClass for the resulting item: Internal + Barrel + Underbarrel + Ammo + Barrel + Barrel = 5648.
2- Look through AttachmentSlots.xml to find slots that go with our main item. Start by looking for slots that match the main items LayoutClass. If no valid slot is found for each bit in our flag, find a layoutClass 1 slot that will work. Example: In my xml files, the XM-29 is layoutClass 1. So all slots that are pulled from AttachmentSlots.xml must be LayoutClass 1. However, if I had made the XM-29 layoutClass 4, then made a Barrel slot with layoutClass 4, then the code would use the LC=4 slot for the barrel and the LC=1 slot for the other possible attachments.
3- For each attachment on the main item, look through Attachments.xml, Launchables.xml and Merges.xml for references to the attachment. If any match is found, look at the attachmentClass for the referenced item and add it's bit to a flag. Example, the default attached OICW GL on the XM-29 can hold 40mm grenades. So we add "Grenade" to out bitmask resulting in 13840.
4- Take the second flag (created in step 3) and sort through AttachmentSlots.xml for valid slots based on the attachments layout class. As before, we look for the specified layout class first but if no valid slot is found, we then look for a LayoutClass 1 slot. Example: In my xml files, the OICW GL is layoutClass 2 and has ubMagSize of 3. So we pull the first 3 of the LC=2 Grenade slots.
5- Repeat steps 3 & 4 for every attachment on the main item.
6- Onces all slots are polled, we go through the resulting list and take out any duplications leaving a single slot of each type. In the above examples, we have no duplications. But if we had a main item that could fit a sight, plus an attachment that also allowed us to fit a sight, and both called the same index from AttachmentSlots, we wouldn't want both options being valid or we'd be "overlap".
So it was intentional that we sift through Merges.xml for valid slots. If we don't, then some items that only used slots for mergers would not ever get a slot. For example, the problem I originally encountered as Alcohol never got a slot because there are no valid entries in Attachments.xml or Launchables.xml for Alcohol. But we're supposed to be able to merge Alcohol and Rag to get Molotov Cocktail. Because Alcohol got no slots, no merge was ever possible so we could never create a Molotov. One possible way to get around this would be to update Attachments.xml so that all mergers were also listed as attachments. I.E., Spring is a valid attachment (according to Attachments.xml) for Rod. But Rag is not a valid attachment (according to Attachments.xml) for Alcohol. I'm not sure why some "mergers" are valid attachments and others aren't.
However, the only time I could see a merger being a problem is if the merger item used an attachmentClass that didn't "go along with" the rest of a main item. For instance, if for some reason you could merge a AC=1, 2, 4 or 8 (default ACs) item with a gun. Like, if you could merge a spring directly with a gun. In this case, the code would see that a "phantom" slot was allowable.
As for why the slot didn't display the allowable attachments, I just looked at that part of the code and currently I'm only generating the tooltips using valid entries from Attachments.xml and Launchables.xml. I don't have a tooltip display for entries found in Merges.xml. This is an oversight since I added the Merges.xml after the fact. I'll correct that before committing NAS 0.7 to the dev branch.
Also, there is a slight possibility, because of the way I'm searching the xml files, that we could miss an attachment and/or launchable. It's extremely remote since two or more indexes in the three xml files would have to match (i.e., the 10th item in merges and the 10th item in attachments would both have to be valid). It's remote but since there is the possibility, I need to look at altering the code a little.
Anyway, as far as the crash, I'm really interested in what is causing that. I'm still not able to recreate a crash do to the arrangement of slots. That's probably because my AttachmentSlots.xml is pretty simplistic compared to what you're working with. I've tried several setups based on your descriptions and still haven't caused a problem. If you're getting these crashes on items in the first 1376 entries in Items.xml, I might simply be able to use your Items.xml, Attachments.xml, Launchables.xml, Merges.xml and AttachmentSlots.xml to recreate the crash. If I can recreate it, I should be able to figure out what's causing it and fix it. However, without more information to test with, there isn't much I can do to try and resolve this problem.
Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #267916]
|
Tue, 07 December 2010 00:50
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
I managed to kill off one of the unexplained slots by deleting merger definitions. Specifically, the toolkit was used to convert a FLIR Scope into Thermal Imaging Goggles (and vice versa). The existence of this pair of mergers led to the toolbox having the default optics slot from Layout 1 appearing (though nothing could attach to it). Perhaps when a slot is required for a merger only "default" flagged slots may appear.
Also ran into some weirdness with slots not appearing as expected. AttachmentClass = 262144 (2^18) is what I'm using for grenades, and following your example ChrisL I set Mortar Shells to use the grenade attachment class. However when doing so the grenade slots didn't appear for Mortars. 262144 works fine for Grenades and grenade launchers however. Found, out of desperation, that I could get away with setting Mortar Shells to AttachmentClass = 1, which I use to cause the default slots to appear for miscellaneous attachments (merger items and armour attachments).
EDIT: Another way to get around the missing slots for mergers; perhaps the four default slots should appear for any item with no layout class that has no attachments and no launchables. If a modder wants no slots to appear, a non-zero layout index with no slots has to be specified as its layout class. This is sort of what is done with NAS 0.61: no entry in the XML that defines what slots an item has = default four slots, a deliberate entry in that XML with no slots = no slots. Make it the Modder's responsibility to avoid deliberately defining a no-slot layout if there is a merger, instead of having the .exe think for the modder...
Also items by default displaying the four default slots would obscure the mergers (for the benefit of new players, allowing them to make new discoveries on their own, instead of having it signposted by the slots appearing only in special cases).
[Updated on: Tue, 07 December 2010 01:10] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #267987]
|
Wed, 08 December 2010 18:46
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
@DepressiveBrot: That's not true. In "basic 1.13" there is no ItemIsCool function call during the merge process. For that matter, there isn't even an ItemIsLegal function call. We call EvaluateValidMerge which simply looks at the two items we're working with and check Merges.xml to see if they result in a merge of some kind. If they do, the function returns the newly merged item(s). There shouldn't be a problem with merges in the currently released version of 1.13.
In the development branch (which is the version Sandro said he was using) there is a glitch but it has nothing to do with whether the treated armor has a coolness factor or not. NAS 0.6 added an ItemIsLegal check during the EvaluateValidMerge process. The problem is, this ItemIsLegal check is run against both items created from a merge, and both items much evalute as legal for the merge to take place. Unfortunately, a Null item is not a legal item and when you merge armor with compound 18 or royal jelly, the result is a treated armor item and a null item. So in the current development build, any merge that results in a single item (and is only found in merges.xml) will never go through. Rod&Spring can be created because that "merge" is found in both merges.xml and attachments.xml. I'm not really sure why it works this way. I didn't bother looking that far into it. Rest assured that the changes to NAS 0.7 (which, again, should be released to the dev branch sometime today) resolve this glitch. I'm prefectly able to have my mercs create treated and coated armor.
Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #267989]
|
Wed, 08 December 2010 19:10
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I've just committed all the changes for NAS 0.7 to the development branch. There are changes in the gamedir folder as well as the build folder, to account for the updated xml files. There's also a new XMLeditor (labeled 0.46) which >should< work with NAS. I only did limited testing on the new editor, though, so use it cautiously.
I should also point out that while nasLayoutClass is a 128bit value in NAS, the XMLeditor currently only treats it as a 32bit value. So if you use more then 32 layoutclasses, you'll have to manually adjust things after you've used the editor. If I can ever figure out VB.net well enough to fix this, I will.
Also, the editor won't currently allow "mixed" attachment classes. So if you want an attachment slot or an attachment to "fit" in multiple attachment classes, you'll have to edit this manually as well. Again, if I ever figure out VB.net well enough to fix this, I will.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #268086]
|
Fri, 10 December 2010 17:50
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Sorry Wil, I thought I had mentioned that. I'm sure there is a way to setup the Attachment Class list in the xml editor so that it can handle multi-select, but I'm not famailiar enough with VB.net (which is what the editor is written in) to do it. I'm still messing around with that code trying to make it work better, but for now multi-select of attachment classes just isn't possible. The only way I could get around that would be to turn that into a text box and let you set the number manually, without relating the field to the AttachmentClass.xml lookup table.
Also, a "bug" has been reported to me. It appears that the tooltip names for slots is not longer what people expect it to be. This is not a bug. It's working as designed. Attachment slots now display one of two tooltips:
1- The tooltip will display the name of every possible attachment that the slot will support, assuming the attachment isn't listed as hidden in Items.xml.
2- If no valid, non-hidden attachment can be found, then the szSlotName field from AttachmentSlots.xml is displayed instead.
So, as an example, if an item gets no attachments, but can support merges, you'll see 4 slots and they'll be labeled "Default Slot 1-4". If you don't like those names, just go into AttachmentSlots.xml and change the szSlotName field.
Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #268138]
|
Sat, 11 December 2010 01:26
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Minor worry after remembering that I actually have two XML's that use multi-attachment/layout classes, but it turns out the XMLEditor doesn't bother to overwrite values it can't handle unless the item is actually modified.
The only help I can offer regarding the XMLEditor is just opinions on the end user experience; however isn't it just a matter of summing up the selected values?
For instance, one of the "RIS-every-where" rifles in UC-1.13 has its layout made up of 1(Default, includes RIS Bottom slots) + 4 (RIS Top) + 8(RIS Side) = 13
So for an interface, why not a new Tab for an item's NAS settings in the Editor? Borrowing the interface style (perhaps code) for attachments, having lists of layout and attachment classes. So for my example, the Layouts list would have three entries: Default Gun, RIS Top, and RIS Side. Have a running total at the top summing up values for Layouts and Attachments added to the respective lists.
EDIT: may I take the lack of comment over Multiple Default Attachments as a good sign that something is in the works to accommodate these in the XMLEditor?
[Updated on: Sat, 11 December 2010 02:04] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #268139]
|
Sat, 11 December 2010 03:14
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I don't know how to make the list box that appear accept multiple selections. Like I said, my skill with VB.net is extremely basic. I was able to make standard text boxes, check boxes and list boxes appear. I haven't figured out how to do mutli-select boxes yet. Once I do, I intend to update the editor so that attachmentclass fields can all have multiple selections made.
As for multiple default attachmetns, that's a more complicated beast. The JA2 program converts multiple copies of the DefaultAttachment field into an array, up to 20 items in size. But the XML Editor currently requires each field in a table to be unique. So while the game can handle multiple DefaultAttachment entries on an item, the editor will only read 1. Unlike the game, which reads each line of the editor one at a time in a fashion I can track and edit, the editor appears to read the entire xml file all with a single command that I can't alter. So until I can either figure out how to get the editor to read multiple copies of a single field, or rework things so that each default attachment get's it's own, unique name, we're stuck with what we have.
In both of these cases, the answer may be pretty simple. But since I have so little VB.net experience, I'm not having a whole lot of luck.
Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #268333]
|
Wed, 15 December 2010 13:27
|
|
| smeagol |
|
Messages:2705
Registered:June 2008
Location: Bremen, Germany |
|
|
So... I just installed the 0.7 and as far as I can tell, it looks quite nice to be able to add attachments with the editor again. Damn... this will still be so much work....
I also have a few questions about it:
- Layout Class? Any chance to describe in a few words what this is and what the possible settings are? Screenshot of in-game difference would also be nice.
- I'm missing a few slots for some attachments (Flashlight, Trigger Group, Ballistic Computer, Match Trigger... I guess the Mag Adapters use the ammo slot?)
Hmm... that's about it for the moment. I guess if I really am getting deeper into this, more questions will show up.
Edit1:
Well... how do I actually make the attachment slots show up on the items? k, figured it out... still had my old 150kb attachmentslots file instead of the 10kb one.
Edit2:
Uhm... the xml editor automatically replaces the attachmentslots.xml with 10kb with the bigger file upon saving, thus slots dissappear again in-game. Weird...
[Updated on: Wed, 15 December 2010 13:48] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #268360]
|
Wed, 15 December 2010 19:37
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Layout Class is a binary value that tells the system which set of attachment slots you want to use based on the weapon (and it's attachments). Layout class can technically have any value from 0 to whatever an unsigned 128bit variable will hold. However, you normally stay with powers of 2 (0, 1, 2, 4, 8, 16, etc) unless you want items or slots to use multiple classes (which can make setting up slots fairly complicated). Also, while the code can support up to an unsigned 128bit value, currently the xml editor can only support a signed 32bit value. I'm still trying to correct that.
As an example using the default xml files, compare a Milkor multi-shot GL with a Talon underslung GL. Both can hold 40mm rifle grenades which have an attachment class of 8192 but each has a different layout class (2 and 1, respectively). The result is that the Talon displays only a single grenade slot to the left of the UGL slot, and the Milkor displays six grenade slots on the right hand side of the attachment window.
When the code is deciding which slots to display it looks at the layout class of the item and tries to find a slot with the same layout class that supports the appropriate attachment class. If no slot is found, the code defaults to using LayoutClass 1. As an example, assume you create a layout class with a single attachment slot that will support Stock attachments. Further assume that you assign the M4 to your custom layout class. Since the M4 can attach a stock, you'll get your custom stock slot. But the M4 can also support things like barrel, sight and scope attachments which you didn't explicitly setup in your custom layout. Therefore, the M4 would display the default Barrel, Sight and Scope slots along with your custom Stock slot.
Without seeing your AttachmentSlots.xml, I can't say why you would be missing slots. In the default xml files, I made sure that all attachments had an appropriate attachment class based on how I thought they should be grouped. And in the default AttachmentSlots.xml, there is a default layout for every attachment class, plus the multi-shot GL/RL slots (layoutClass 2). If you've changed the nasAttachmentClass values in Items.xml, or changed the nasLayoutClass 1 and 2 setups in AttachmentSlots.xml, then it's possible you've removed a slot. But I'd have to see those two xml files to know for sure.
As for the xml editor, I'm not sure what's causing the result you're seeing. I just tested the current editor (0.46) by adding a line to the AttachmentSlots.xml file and it saved just fine. The only issue I saw was that nasLayoutClass wasn't displayed as a field on the table. I'll see about getting that corrected.
Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #268369]
|
Thu, 16 December 2010 00:05
|
|
| Faithless |
 |
Messages:439
Registered:October 2009
Location: The safe end of the barre... |
|
|
Quote:unless you want items or slots to use multiple classes (which can make setting up slots fairly complicated). While complicated, it might be worth looking into because you could make different kinds of slot layouts *just* for the upper receiver.
Then you can tell guns that they have an AR upper receiver but only a pistol barrel (only layout wise, of course).
Just if someone wants to try and doesn't understand it yet, here's a few examples.
Toggle Spoiler
1 = first bit set (00000001) (Slots from layout 1 will be on the gun)
2 = second bit set (00000010)
3 = first and second bit set (00000011) (Slots from first AND second layout will be on the gun)
4 = third bit set (00000100)
64 = 7th bit set (01000000)
(128+64=192) = 7th and 8th bit set (11000000) (Slots from layout 7 AND layout 8 will be on the gun)
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 16 21:57:15 GMT+3 2024
Total time taken to generate the page: 0.02973 seconds
|
Blog
Search
Help
Members
Register
Login
Home
