Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Attachment System Beta
Re: New Attachment System Beta[message #267608] Tue, 30 November 2010 20:51 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Ok, I'll leave LayoutClass as a bitmask for the time being. Especially if it seems like it's more functional that way.

Remember, that for an attachment to be able to add a slot, at least one item that can fit the new slot MUST be attachable directly to the attachment. For instance, for your RIS Scope Ring to add a scope slot, you need to updated Attachments.xml so that some scope can attach to the RIS Scope Ring item. If you don't update Attachments.xml correctly, you won't get the results you're looking for.

Also, a word of warning when mixing layout classes. As I mentioned, the code won't allow a slot to be called more then once. So you can never have more then on uiSlotIndex=8 slot on a weapon regardless of what attachments you put on the weapon. This doesn't mean you can't create a new uiSlotIndex with the same AttachmentClass as uiSlotIndex=8. This is where you can possibly run into problems. If your newly created uiSlotIndex uses the same coords as another slot, and both slots display on a weapon/item, you'll get "Overlap". Effectively, the code will render BOTH slots. The problem is, there is no way to control which slot you put an attachment in when there are two or more slots displaying in the same space on the screen. Worse, every time you do anything with attachments, there is a chance that the objects will be re-arranged in the code. Visually you probably won't notice it, but this means that you could put an item in the "top" overlapped slot and the code might re-arrange things and put your newly attachmed item into the "bottom" overlapped slot. The result being you can see the attachment, and your weapon/item will get the bonuses/penalties for the attachment, but you won't be able to remove the attachment because every time you click on the attachment slot, you'll be clicking on the "top" overlapped slot.
And no, this is not a valid way to handle non-removable attachments because there is no way to control which overlapped slot is going to be "top" and which is going to be "bottom". Normally it's weapon slots, followed by attachment slots, all in the order they appear in AttachmentSlots.xml, but there are cases where this order can be altered.

Re: New Attachment System Beta[message #267667] Thu, 02 December 2010 06:33 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
5000+ lines of attachments associations, and I'm still not done rebuilding attachments.xml yet. I'm also finding that the old incompatible attachments XML is blocking a few things. However I have managed to demo one of the capabilities I was worried about, second level slot adding.

HK G3A3 + HK Optics RIS = allows ACOG scope to be attached, including pop-up of add-on scope slot
HK G3A3 + HK Optics RIS + ACOG Scope = pop-up of add-on slot specific for Reflex Sight

Added the Reflex Sight as well just to make sure that worked. (And found initially that the old incompatibles list had the Reflex incompatible with all scopes. Then I found the XMLEditor is useless at clearing incompatible attachment settings, they kept popping back in. Finally cleared them by opening the XML directly in Excel.)


I'm using the spreadsheet, and more or less sticking to a default layout (for now) to avoid slot confliction. This time around, I am keeping pop-up slots to a minimum. Some refinement is needed as the default layout needs to be trimmed down a bit too, whenever the integral grip appears all three possible locations pop-up.


Now I still need to get the grenade launchers setup, and have a question: If I have X number of different grenade launchers, can I have X number of different layouts for attaching grenades? Or do all launchers draw grenade slots from Layout 2 only?

Based on our previous discussions, I've already planned for the minimum layout answer (all is drawn from layout 2); but if I can assign to different launchers completely different layouts, then that mitigates most of the layout flexibility issue we had (until one of us uses up all 128 possible layout building blocks).

[Updated on: Thu, 02 December 2010 06:35] by Moderator



Re: New Attachment System Beta[message #267678] Thu, 02 December 2010 17:58 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I'm not sure why you're having so much work unless you're just having to work hard to convert your test setup back from NAS0.61. When I setup things to work on the NAS0.7 code, all I did was use the version of the xml files that comes from the development branch. Then I just added a couple lines to cover the new entries I needed. I didn't have to mess around much with attachment compatibility or incompatibility.

For now you certainly can't use the xmleditor. It'll cut out values and can't handle NAS0.61 (as far as I know) let alone NAS0.7. I'm still playing around with that code but VB really isn't my strong suit.

By default, single shot grenade launchers use layout 1. Multi-shot grenades launchers use layout 2. The easiest option is to go into Items.xml and added nasLayoutClass=1 for every single shot GL and nasLayoutClass=2 for every multi-shot GL. Then if you have more then a 6 shot GL, update AttachmentSlots.xml, layout 2, to account for the extra rounds.
However, if you want to create a seperate layout for every GL, you certainly can. You just create the layout and assign the GL to that layout. But again, the point of the layoutClass is to give you control over the location, size and attachment compatibility of slots. If two weapons/items would use the same location, size and compatibility, then they should use the same layout. In other words (assuming the unedited file), if the rifle grenade for all your single shot GLs should appear at 18x120, then all your GLs should be assigned to layoutClass 1. If all your multi-shot grenades would use rifle grenade slots as I set them up in layout 2, then all your multi-shot GLs should be assigned to layoutClass 2. Don't bother created a seperate layout just for an individual GL unless that GL needs it's rifle grenade slot(s) to appear in a different location then every other GL.

Re: New Attachment System Beta[message #267682] Thu, 02 December 2010 20:07 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Yes, I am using NAS 0.7 Testing as an opportunity to at least revamp UC-1.13 v2.9 attachments for OAS (despite there being other, non-attachment, complications to direct OAS support). That and I only have a few hours in the evening to work on things so I decided to work on this instead of working with (swearing at) the Map Editor.

Also the needs of my projects have lead to significant divergence from Starwalker's Data-1.13. New NAS or old NAS, it all required starting from a blank page.

Based on your earlier post ChrisL, it looks like I can proceed with some more creative layouts for the multi-shot launchers. However while I was reading your NAS 0.7 release posting, I noticed feature #9 "Multi-shot grenades will automatically be converted to single shot grenades when you attempt to load them into a GL." Does this mean that XM29 (and "vanilla" v1.13 XM25) multi-shot grenades get turned into single rounds under NAS 0.7? Not a big deal, as I already had plans in-place to deal with possibly loosing the old mult-shot grenade system under current NAS, but I would prefer to have these work for some items under new NAS.

So far I'm rather confident in being able to replicate old NAS features, but the following I still need to get around to testing:

- Attachment Combo Merges (Vanilla X-Ray Detector, UC-1.13 Flamethrower items)
- inseparable default attachment appearance and clean removal when items are produced through mergers (G36/G36RAS conversion)
- Multiple Default attachments (last on the list due to me finding it easier to work with items.xml in Excel, which does not like multiple defaults)

After this, there is the matter of what else 0.7 can do. For instance, does this change in framework mean that the Map Editor will be able to reliably create items with multiple defaults?


Re: New Attachment System Beta[message #267684] Thu, 02 December 2010 20:34 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
As of Rev 3940 of the development branch, changes have been made to xml files that would conflict with the files that I included in my previous archive. To cover that, I've setup a new archive which you can get here: http://www.mediafire.com/?cocy4hg512ko63q This new archive should ONLY be used if you've upgraded your game folder to both development rev 3942 AND release rev 1252.

If you're still using game data from release rev 1247 or earlier, or developement rev 3936 or earlier, then you should continue to use the files in this archive: http://www.mediafire.com/?w8ggaedwu14h4by

Also, if you're considering "upgrading" from one archive to another, be aware that the 43mm single shot grenades (and the 43mm 4-shot illum grenade) have moved. If your existing savegame had any of these items, you'll "lose" them in favor of some ammo crates that are now using the same uiIndex as the 43mm grenades had been using.

@wil473: Sorry. I should have been more specific. The code WILL attempt to replace any multi-shot rifle grenade item with an appropriate single shot version, but only if a single shot version actually exists. There are 40mm versions in multi-shot (cylinders) and single shot. And part of the xml files in the NAS archives are single shot versions of the 43mm grenades. Currently I don't have single shot versions of the 20mm or 25mm grenades so these won't get converted.

As for your other tests, I can tell you that NAS 0.7 is handling merges such as converting SCAR-L to SCAR-68 and either SCAR from CQC to SV versions. It's handling Rod + Spring mergers and Pipe + Glue + Tape merges. I can't get Alcohol + Rag merges or Can + String merges to work but I think that may actually be an issue with the xml files and not NAS itself. EDIT: I tested again and merges don't appear to work, or they don't always work. I'm working on fixing this.
I haven't tested either of the default attachment concerns yet. I want to go through and play with that but haven't had a chance to yet.

As for the Map Editor, you need to remember that it never knows what version of the game you're working in. The Map Editor doesn't know if you're NAS, OAS, NIV or OIV. As a matter of fact, I'm pretty sure that it has to assume OIV/OAS just for compatability concerns. However, the multiple default attachment thing isn't really a NAS feature. At least I don't see NAS checks being done when default attachments are being handled (though I may simply have missed it since I haven't looked at default attachments much). So the Map Editor should be able to handle them since all it's going to do is add the attachments that the xml file says to. But like you, I haven't tested that yet.

EDIT2: Okay, I've figured out the problem with Merges. There are two-fold issues.
First, in the current code, both "merged" items must be valid. This is fine in the case of "bloody knife & rag" or "SCAR-L CQC & SV Barrel" since these merges result in two items. But most merges take two items and turn them into one. And there is a condition in the ValidMergeCombo function that requires "both" items to be valid. Since most merges only return one item, the "second" item is never valid.
Second, NAS is currently only looking in Attachments.xml and Launchables.xml to figure out whether to display a slot. But if an item only uses an attachment slot for a merge (like can or string) then no slot will appear and no merge will be possible.
I beleive I've figured out how to resolve both of these problems. I just need to update the code and both builds. I'll have new files ready later today. The links have been updated. Both files should now have the fixes so that merges should work. I no longer have all the correct xml files to thuroughly test the 3936 version but it should work correctly

[Updated on: Fri, 03 December 2010 00:12] by Moderator


Re: New Attachment System Beta[message #267830] Sun, 05 December 2010 18:14 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Right I've updated to the latest .exe and so far testing is proceeding well with simple things like:
- multi-shot grenade launchers
- refining my somewhat complex system of attachments that allow other attachments ("allow" implying both adding attachments to an item's list and adding slots). I think I've managed to accomplish most of what I could do with the NAS 0.6 and have not had to resort to incompatible attachment definitions, using up 3-4 additional attachment classes in the process.

Problems:
- From your last post I am still unclear about the Attachment/Combo mergers. Do the items involved need to be setup in attachments.xml?
- I am getting a lot of unexplained slots popping up. Happens at random to items, launchers in particular that do not have attachments that fit the mystery slots defined. I'm going to try flushing the Launchers.xml, as there seems to be a lot of debris in my XML's.

EDIT:
Filled in the Attachment/Combo Mergers items into attachments.xml, mixed results. My 0 Mechanic skill IMP: crashed the game at first, then failed to attach without comment on later attempts.

Tex (40+ Mec) managed to carry out all mergers, or failures as expected (comments on failures and no crashes).

One thing I noticed is that most of the unexplained slots appearing seem to be the slot (from Layout 1) that the attachment generally fits into.

EDIT2:
Slot Text when all valid attachments are hidden is consistently reading the slots name from AttachmentSlots.xml. This is proving useful in testing, and I'm actually hoping to take advantage of this to give instructions on how to use the folding stock system. ie. rename the lower stock slot to: "Move Stock here to Collapse (lower Draw AP vs. Lower CTH)."

[Updated on: Sun, 05 December 2010 19:53] by Moderator



Re: New Attachment System Beta[message #267832] Sun, 05 December 2010 19:49 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Both of the recent builds I've posted should have the Attachment/Combo mergers problem resolved. The problem was strictly a coding issue and didn't have anything to do with the xml files. The code was simply not looking in Merges.xml when setting up slots, and it was assuming that every merge created two valid items. I corrected the slot setup function so that it looked in Merges.xml as well as Attachments.xml and Launchables.xml. So now all three files are reveiwed to determine the available slots for an item. And I corrected the actual merge function so that a valid merge will result even if the "2nd created item" is not a real item. I.E., if you "merge" a bloody knife and a rag, you get a throwing knife (item 1) and a rag (item 2) as a result. This type of "merge" would work (in the actual merge function) even before my corrections. But if you tried to merge a alcohol and a rag, you get Molotov Cocktail (item 1) and null (item 2). Since null isn't a valid item, the whole merge function would fail because of the condition that existed. So this was corrected.

As for unexplained slots, I'd need to look at the xml files you're using to figure that one out. I originally had similar problems but the result has always turned out to be items with either bad attachmentClass or bad LayoutClass. If you want some help finding the problem, email me the xml files you're using and the specific items you're having trouble with, and I'll see if I can't figure where the problem is.

Re: New Attachment System Beta[message #267843] Sun, 05 December 2010 21:39 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
I think I've taken care of the "deadly" unexplained slot appearances (a mistake I made with controlling which slots one attachment can appear in lead to overlapping slots). Due to the size of the mod, I'll have to make it available online (too big to be an email attachment).

I've set up a few multiple default attachments, mix of inseparable and separable, and have run into a few problems:

Old Crash Condition - Not sure where the XML error is on my side yet, but with the last version of NAS 0.6, if there is a merger that generates an item with attachments that do not fit, the game ignores the creation of the attachment.

EDIT: Successfully demo'd G36 <--> G36RAS conversion

Default attachments:
G36RAS - (Full)Folding Stock
G36 - (Full)Folding Stock, Integral Dual Optics(inseparable)

Merger to create G36RAS from G36 successfully removed the Integral Dual Optics without problems.
Merger to create G36 from G36RAS successfully produced the Integral Dual Optics without problems.

[Updated on: Sun, 05 December 2010 21:53] by Moderator



Re: New Attachment System Beta[message #267845] Sun, 05 December 2010 21:59 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
So it sounds like it's working for you?

Re: New Attachment System Beta[message #267846] Sun, 05 December 2010 22:23 Go to previous messageGo to next message
Wil473

 
Messages:2820
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:607
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:2820
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:607
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:2820
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:607
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:2820
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:607
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:426
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:3471
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:607
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:3788
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:426
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:607
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:607
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:812
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:445
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:607
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:445
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:607
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:445
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:607
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:2820
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:607
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:2820
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:607
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:2820
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:607
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:2820
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:607
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 previous message
Faithless

 
Messages:445
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.
Previous Topic: Experimental Project 7
Next Topic: Code Snippets
Goto Forum:
  


Current Time: Wed Jan 17 03:26:59 EET 2018

Total time taken to generate the page: 0.02580 seconds