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 Go to previous messageGo to next message
Wil473

 
Messages:2830
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



Re: New Attachment System Beta[message #267847] Sun, 05 December 2010 22:27 Go to previous messageGo to next message
ctiberious

 
Messages:606
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


Re: New Attachment System Beta[message #267855] Mon, 06 December 2010 01:31 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
My mistake was mixing up the Integral Bipod with the Heavy Bipod. Both are identical except in name (I haven't gotten around to making them different). As soon as I figured out that the AUG HBAR was supposed to have the Integral Bipod, the assertion error went away.


As a quick test to see if it was a missed attachment or launchable definition causing the mystery slots to appear, I removed the Hidden Attachment/Addon tags from items.xml to see if anything item names appeared in the unwanted slots. Nothing.

Once I'm done confirming all defaults work (and don't crash the game); I'm going to take a shot a figuring out these slots popping up unnecessarily. Slots will only pop up if:

1) Bitmask for an item cross referenced with the item's attachments list
2) Bitmask for a launcher item cross referenced with the launchables XML
3) Bitmask of an attached attachment, cross referenced with the combined base item and attachment's attachments list (including Launchables list)
4) Mergers call up slots tagged as default(?)
5) If the defined Bitmask does not give a valid slot for attachment defined in attachments.xml, all slots from Layout 1 that the attachment fits will be added

EDIT: Rather sure this was not the intention, but when the default slots appear to accommodate a merger, they are also added when the item is an attachment.

[Updated on: Mon, 06 December 2010 02:45] by Moderator



Re: New Attachment System Beta[message #267865] Mon, 06 December 2010 08:58 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #267916] Tue, 07 December 2010 00:50 Go to previous messageGo to next message
Wil473

 
Messages:2830
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



Re: New Attachment System Beta[message #267924] Tue, 07 December 2010 02:48 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
The default slots is not a bad idea. And would certainly resolve that problem. I'll fiddle more with the code in that area.

Not sure about the problem with the mortars. I admist that I haven't spent much time testing mortars but they really should work just like grenade launchers. I'll test that and see if I can figure out what might be causing the problem. One thing to check is that your Explosives.xml is setup with the new ubMagSize value for your mortar shells. When you use custom layouts for explosives (whether grenades, rockets or mortars) the program assumes you may want "multi-shot capabilities" so it looks at the ubMagSize of the weapon and the ubMagSize of the "ammo" to figure out how many slots should be included. if you have the ubMagSize in Explosives.xml set to 0 (or not set), I think the result would be no slot appearing. But I need to test that.

Re: New Attachment System Beta[message #267961] Wed, 08 December 2010 00:51 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
Fixed the mortar. It was caused by my "Grenade 1" slot being shared by both Layout 1 and Layout 2. The problem went away as soon as I changed the LayoutClass for the slot from 3 to 2. Oddly, grenade launchers (every one of them from 1 to 6 shots) had no problems with the "Grenade 1" slot being part of Layout 1 and Layout 2. I ended up adding a "Grenade 0" slot with identical specs as "Grenade 1" to be in Layout 1; though I'm not even sure if it is needed at this stage, all my launchers use Layout 2.

If you are planning to proceed with my suggestion to just have the default slots appear when no layout class is defined, and nothing attaches to an item (attachments or launchables), and only have no slots appear if a Layoutclass with no slots is specified; I won't worry about the mystery slots now appearing with UC-1.13NAS and the current version of NAS 0.7. Effectively means I've recreated UC-1.13NAS for NAS 0.7. For me at least only three guns intentionally have no attachments, and as I said, I would prefer that the default slots always appear for non-gun items to not make merger items so obvious.


It looks like within the 128 Layout limit, I could recreate all the custom layouts from the last version of UC-1.13. I'm probably not going to as I want to avoid having to work out slot placements for excessively unique layouts.

[Updated on: Wed, 08 December 2010 00:54] by Moderator



Re: New Attachment System Beta[message #267964] Wed, 08 December 2010 01:38 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
Yes, I'm going to setup the default slots to appear when only merges are available.

Re: New Attachment System Beta[message #267974] Wed, 08 December 2010 15:27 Go to previous messageGo to next message
Lamach_Head

 
Messages:425
Registered:November 2008
Location: Mars
Hi,
I am playing current development version of 1.13 (with the NAS implemented), and I wonder why I cant't merge compound 18 or jelly or anything with armor to upgrade it..? A message that I cannot attach the compound to this slot appears.
I guess it's an issue of NAS, unfortunately my VC++ is not working now, so I can't look into it myself.

I was able to merge rod and spring, but nothing about armor.

Sorry if this was pointed out somewhere already, I just want to know how to solve this problem so I can continue playing.


Re: New Attachment System Beta[message #267975] Wed, 08 December 2010 15:41 Go to previous messageGo to next message
Logisteric

 
Messages:3396
Registered:December 2008
Location: B
aimNAS?

you need c18/20 to repair armour, for upgrades you must use little 'suitcases' called upgrade kits
Re: New Attachment System Beta[message #267979] Wed, 08 December 2010 17:39 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
The version of NAS that's in the current development branch has a glitch when it comes to merges. Merges that result in just a single item (such as C18 + armor) will always fail. This has been corrected in NAS0.7 which I'm hoping to have released to the dev branch sometime today.

Re: New Attachment System Beta[message #267981] Wed, 08 December 2010 17:46 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3801
Registered:July 2009
With a basic 1.13 install, armor merges will fail the 'valid item' check because the upgraded armors have no coolness assigned.


Re: New Attachment System Beta[message #267984] Wed, 08 December 2010 18:18 Go to previous messageGo to next message
Lamach_Head

 
Messages:425
Registered:November 2008
Location: Mars
Haha, thats not a "glitch"... bug like hell.
Well, anyway thanks for help, after some xml editting I am at least able to make the items I want.


Re: New Attachment System Beta[message #267987] Wed, 08 December 2010 18:46 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #267989] Wed, 08 December 2010 19:10 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #267994] Wed, 08 December 2010 20:05 Go to previous messageGo to next message
tais

 
Messages:807
Registered:February 2008
Location: NL
I smell something baking.. oh wait that's my new SCI..


Re: New Attachment System Beta[message #268000] Wed, 08 December 2010 20:41 Go to previous messageGo to next message
Faithless

 
Messages:442
Registered:October 2009
Location: The safe end of the barre...
Quote:
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.
Actually, I just looked. Only if BOTH results are invalid, the merge will fail.

old code:
	if( !ItemIsLegal(Merge[iLoop][2]) && !ItemIsLegal(Merge[iLoop][3]) ){
		return( FALSE );
	}
The problem is only that a few items still have coolness 0, size 0 or something else that makes them invalid.

Re: New Attachment System Beta[message #268006] Wed, 08 December 2010 21:08 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
@Warmsteel: Hmm. You know, you're right. I was looking at this line wrong. Which means I'm apparently bypassing this condition with the way I altered it, because once I altered it, I was able to create treated and coated armor again. Either way, before NAS, creating these coolness 0 merged items was possible. So I'm presuming that it should remain possible. There's no reason NAS should make it no longer possible to create treated armor, after all. Since the ItemIsLegal check was only added during NAS, maybe I should alter the ItemIsLegal function so that when we call it from EvaluateValidMerge, we ignore the coolness of the item. I'd say we could simply alter the coolness values in Items.xml but I believe treated/coated armors (and some other merged items) are set to coolness=0 so that they can never be selected as dropped loot.

Re: New Attachment System Beta[message #268007] Wed, 08 December 2010 21:11 Go to previous messageGo to next message
Faithless

 
Messages:442
Registered:October 2009
Location: The safe end of the barre...
Possibly, I believe most things are handled with separate xml though. Maybe if you use one of the "use the old ways" settings.
It would be no problem for coolness 0 items to still be created through merges though, it was more so that you could not create OAS items such as the combo scope.
Re: New Attachment System Beta[message #268009] Wed, 08 December 2010 21:19 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
*nods* Yeah. I'm testing the addition of a parameter to the ItemIsLegal function. If it's set to true (it's false by default so we don't have to change any other function calls) then we ignore then first coolness condition and just check all the rest to determine if an item is legal or not. This should allow the coolness of an item to be ignored during the merge process but still restrict it so that OAS-only items can't be created. Soon as I finish testing this, and assuming it works as expected, I'll commit the changes.

Re: New Attachment System Beta[message #268010] Wed, 08 December 2010 21:20 Go to previous messageGo to next message
Faithless

 
Messages:442
Registered:October 2009
Location: The safe end of the barre...
Perhaps it would be nice to have parameter that simply says wether it is a strict check or not, instead of wether it is used by the merge function or not.
Re: New Attachment System Beta[message #268011] Wed, 08 December 2010 21:26 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
I just added a paramter "fIgnoreCoolness" o the ItemIsLegal function. In the heady I defined the default value of this paramter as FALSE, meaning if we don't specifically include the paramter in the function call, we're assumed to want to include an items coolness in it's "legality". From the EvaluateValidMerge function, I then restored the condition as you previously had it but added a "TRUE" parameter to both ItemIsLegal function calls. The result worked just fine. I was still able to create treated armor by merging C-18 with a piece of armor. I've just committed this correction.

Re: New Attachment System Beta[message #268032] Thu, 09 December 2010 02:54 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
Ah Chris, is it your intention that when an item is involved with a merger, the default slots always appear (overlapping slots from any specified layouts)? I thought you were only having the defaults appear when the item was involved with a merger and no attachment/layout specified slots were present.

I'm still thinking it would be easier for the defaults to appear when no layoutclass is specified; mergers not even being considered. This way, an item will always have slots, unless someone intentionally sets out to create a layout class with no slots. Any merger/slot bugs (no slots) is purely the modders fault; the .exe shouldn't be babysitting the mod to protect from this...

EDIT: clarification, I downloaded Tais's NAS 0.7 SCI (SCI_SVN1256_MPSVN3949_Vanilla113_20101207_NAS0.7.7z (Updated 7 December 2010)) to keep up to date while working on UC-1.13 v3.0

EDIT2: another oddity related to above, the default slots went away when I attached an item that added a slot (non-default) to the weapon's layout. As a temporary measure, I shoved the defaults off to a corner that is not being used by anything yet.

[Updated on: Thu, 09 December 2010 03:15] by Moderator



Re: New Attachment System Beta[message #268033] Thu, 09 December 2010 03:15 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
Hmm. It was only supposed to display the default slots if no other slots were present. What combination did you use, wil? The tests I ran worked correctly but you've been working with custom layouts alot more then I have been.

I can't get it to only display when no layout is available because the code always goes with the default layout if a slot is missing. Meaning, even if you don't specify a layout, it should still use layout 1. I did that intentionally so you guys wouldn't have to create identical slots for multiple layouts. Why force you to have a stock slot (for example) in every custom layout you create if every custom layout is going to have the stock slot appear in the same location?

But I'll look at the defaults with just mergers thing. Like I said, my tests worked but maybe I missed something.

Re: New Attachment System Beta[message #268034] Thu, 09 December 2010 03:29 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
I had a suspicion that the problem would manifest itself with the "stock" Data-1.13 XML's, and it does. Specifically take a look at the G36 (it merges with the RAS kit), or the M4 (it merges with the AR-57 kits). Both of these guns have the four default slots along with their layout/attachment compliment of slots. Guns that are not involved with mergers look fine as far as attachment slots.

Also, when a grenade launcher is attached (adding the grenade slot); the defaults disappear.

[Updated on: Thu, 09 December 2010 03:32] by Moderator



Re: New Attachment System Beta[message #268052] Thu, 09 December 2010 17:56 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
I figured it out. I referenced the wrong variable. Oops. Fix has been posted.

Re: New Attachment System Beta[message #268062] Fri, 10 December 2010 01:31 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
Confirmed the default slots are no longer appearing unexpectedly.

Also confirmed that the XMLEditor (v0.46) can read my XML's, even updated the lookup file for my attachment slot labels. However, besides not supporting multi-classing items/slots (no problem as only one file in my scheme uses multi-classes), the v0.46 XMLEditor is not supporting multiple default attachments. I didn't notice this until I went off to test the MapEditor (and found that my earlier test drive of the XMLEditor had stripped off the extra defaults).

Just a suggestion for XMLEditor support of multiple defaults: selecting defaults by a check box in Attachments list for an item, externally similar to the check box used to define if a particular attachment is only to be used under NAS right now in v0.46. This should prevent the the assignment of an invalid attachment as a default attachment for an item, via the XML Editor at least. (Actually this would be a rather good idea even without NAS.)

I'll need to rebuild my multiple default attachments before I can test out the Map Editor.

[Updated on: Fri, 10 December 2010 01:32] by Moderator



Re: New Attachment System Beta[message #268086] Fri, 10 December 2010 17:50 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #268138] Sat, 11 December 2010 01:26 Go to previous messageGo to next message
Wil473

 
Messages:2830
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



Re: New Attachment System Beta[message #268139] Sat, 11 December 2010 03:14 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #268144] Sat, 11 December 2010 12:01 Go to previous messageGo to next message
Faithless

 
Messages:442
Registered:October 2009
Location: The safe end of the barre...
You can change the game to just look for the start of the xml string to be DefaultAttachment.
This way, in the xml itself you can add any number to it that you'd like, and the game won't care.
Then old xml will still work, but if you add numbers the editor can have the unique tags it wants.
Re: New Attachment System Beta[message #268166] Sat, 11 December 2010 19:10 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
That might work. I'll be playing around with it over the new few days.

Re: New Attachment System Beta[message #268333] Wed, 15 December 2010 13:27 Go to previous messageGo to next message
smeagol

 
Messages:2710
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



Re: New Attachment System Beta[message #268360] Wed, 15 December 2010 19:37 Go to previous messageGo to next message
ctiberious

 
Messages:606
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.

Re: New Attachment System Beta[message #268366] Wed, 15 December 2010 22:22 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
I've been looking at options for a multi-select list box for the xml editor. So far what I'm reading says that the "ComboBox" style drop down window we currently use has no multi-select option. The only suggestion I've come across so far is to change over to a "ListBox" but that doesn't come with "drop down" capabilities, meaning the listbox would always be displayed. I haven't given up hope yet, but for now we still can't select multiple attachment classes.

That said, I do have a valid work around. The text/value that gets displayed/set when you choose the Attachment Class dropdown is populated by the AttachmentClass.xml file found in the lookup folder. That file gets created by default if it doesn't exist. But you can also edit this file outside of the editor. If you add an entry for whatever combinations you want to use, you'll see the extra options in the drop down list in the editor. For example, if you add the following to your AttachmentClass.xml file, you'll be able to set the attachment class of items to 192 which is a combination of the Sight and Scope classes.:
	
		192
		Sight+Scope
	

Re: New Attachment System Beta[message #268369] Thu, 16 December 2010 00:05 Go to previous messageGo to next message
Faithless

 
Messages:442
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
Re: New Attachment System Beta[message #268371] Thu, 16 December 2010 00:31 Go to previous messageGo to next message
Wil473

 
Messages:2830
Registered:September 2004
Location: Canada
We're going to have to figure out some kind of "best practices" for NAS 0.7. So far what has worked for me is:

- only using multi-class bit masks for slots and layouts; not multi-classing the attachment items
- stuffing layout 1 with as many slots as possible, this involves working out a lot of multi-attachment class slots in advance
- keeping the active copy of attachmentslots.xml away from the XMLEditor (in profiles for instance)

I've used up so far:
22 Attachment Classes (scrapped your default ChrisL in the process, as oddly enough I found some of the default attachment classes to be redundant with each other, then again I do have 5 different flavours of "optics")
18 Layouts, many of which are "add-ons" to layout 1

EDIT: I could have gotten away with using up less layouts and attachment classes, but I found that for "add-on" objects I needed to be more restrictive on what could fit, otherwise I'd end up with a Scope-to-RIS adapter that added a new slot that displayed having the Scope-to-RIS adapter as a valid attachment. Also the addon that was supposed to replace Sniper Scope compatibility with RIS scope compatibility still could accept Sniper Scopes. Yes I know I could use incompatible attachments definitions, but using the more restrictive add-on slots looked cleaner as they didn't advertise unworkable attachments.

[Updated on: Thu, 16 December 2010 00:41] by Moderator



Re: New Attachment System Beta[message #268375] Thu, 16 December 2010 02:07 Go to previous messageGo to next message
ctiberious

 
Messages:606
Registered:March 2007
Keep in mind that just because a slot can support an attachment, doesn't mean the weapon can. If a slot can fit the Sniper Scope, but your weapon can't use that scope, then you can't attach it regardless of the slots you have setup.

And why should you keep your active copy of attachmentslots.xml away from the editor. The mosst recent version of the editor (which I uploaded today) should work just fine.

Re: New Attachment System Beta[message #268508] Sat, 18 December 2010 00:51 Go to previous messageGo to next message
smeagol

 
Messages:2710
Registered:June 2008
Location: Bremen, Germany
Jeez... the attachments.xml gets huge... I now have a file that allows each attachment on each gun (except launchers), that file has more than 500.000 lines and is as big as 12 MB!

Although I'll delete a lot of possible combinations and thus make the file considerably smaller, this still doesn't seem to be very efficent. :/



Re: New Attachment System Beta[message #268520] Sat, 18 December 2010 07:53 Go to previous messageGo to previous message
ctiberious

 
Messages:606
Registered:March 2007
Why would you want to make it so that every attachment could fit on every gun? Shouldn't some attachments not fit on some guns? For example, anything that is supposed to connect to some kind of rail system isn't going to attach to a weapon that doesn't have a rail system. I suppose if you rally have a purpose for making every possible attachment valid on every possible weapon, I could add some INI setting that let you ignore Attachments.xml and automatically return TRUE when we try and attach any item with an attachmentClass. Again, though, I'm not really understanding why you'd want this in the first place.

Previous Topic: Experimental Project 7
Next Topic: Code Snippets
Goto Forum:
  


Current Time: Fri Aug 17 06:28:01 EEST 2018

Total time taken to generate the page: 0.03527 seconds