Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Attachment System Beta
Re: New Attachment System Beta[message #267013] Wed, 17 November 2010 11:37 Go to previous messageGo to next message
Bever

 
Messages:24
Registered:March 2009
Location: Australia
Been playing around making some attachments and weapons and love the organisation of the xml tables. You've done a great job on this system it's quick and easy to use and has added a whole new dimension to my JA2 tinkering.
Re: New Attachment System Beta[message #267035] Wed, 17 November 2010 16:36 Go to previous messageGo to next message
Bever

 
Messages:24
Registered:March 2009
Location: Australia
Was wondering if any other tags than the ones specified in the NAS_Readme would work for the AlteringAttachments.xml

The tag I would like to use is 0 instead of 0 as WeaponType gives more specific results while still being faster and broader than typing each individual ID.

I've given it a try and it seems to not work... Any suggestions as to why... i.e. is it a limitation of the way the xmls are used when internalising the data when .exe is run? or did I just spell something wrong or define the tag incorrectly?

What I'm trying to do is create a adapter thread for the end of rifles but need different slots to be generated depending on if the rifle is a Sniper Rifle or an Assault Rifle or just an ordinary Rifle. These categories are defined in WeaponType and not WeaponClass.
Re: New Attachment System Beta[message #267037] Wed, 17 November 2010 17:06 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3788
Registered:July 2009
BeVeR
I've given it a try and it seems to not work... Any suggestions as to why... i.e. is it a limitation of the way the xmls are used when internalising the data when .exe is run? or did I just spell something wrong or define the tag incorrectly?


The game will only read and compare what it was told to do in the exe. If ubWeaponType is not defined as a valid tag to be used in AlteringAttachments.xml, it will be ignored. It should be possible to change that in the code though.


Re: New Attachment System Beta[message #267041] Wed, 17 November 2010 19:28 Go to previous messageGo to next message
Bever

 
Messages:24
Registered:March 2009
Location: Australia
K thanks, had a feeling that was the case. Any clues as to where abouts in the code this would be?
Re: New Attachment System Beta[message #267043] Wed, 17 November 2010 19:57 Go to previous messageGo to next message
Bever

 
Messages:24
Registered:March 2009
Location: Australia
Hmm... found where the code is written for passing in the info from the XML. Also found where the ubWeaponClass is checked. Now since it's been forever and a day since I've worked with C++ I'm not too keen on writing some whole new code but I'm wondering if it will cause any issues if i just change all the references to ubWeaponClass to ubWeaponType seeing as I haven't been using ubWeaponClass for any of my AlteringAttachments.xml

Any thoughts on this before I go ahead with it... Think I'll wait till I get up tomorrow before trying any actual coding seeing as it's 0430 and I'd be likely to make mistakes. :sleep:
Re: New Attachment System Beta[message #267044] Wed, 17 November 2010 20:07 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I'll admit that I ran with the modifications I have been working with (which resulted in the lose of fine control over slot placement for various weapons) because it is a fairly expedient method from a development point of view. Right now I'm working with a single "nasAttachmentClass" value which links slot and attachment to determine layout and compatibility. From a development standpoint that means less coding and less updating when someone (possibly me if I can figure out VB) gets around to the xml editor. But that isn't the only option.

One option would be to use the existing "ubWeaponType" in combination with the "nasAttachmentClass" so that different classes of weapons could use different layouts. This option would allow a bit more control of slot placement with a minimum of code work. If we assume that most assault rifles, for example, use pretty much identical layouts, this option would work well. You still wouldn't have the level of slot placement control you currently have, but it would be more then what I'm currently working on and may work well if the assumption is valid.

A second option would be to add a second class variable (nasLayoutClass). Similar to option one, it would grant a bit more control since you could give different weapons of the same ubWeaponType completely different layouts. It would require a 2nd field being added to Items.xml, but it's certainly possible. Again, you wouldn't have quite the level of control you potentially have now since there would still be a finite number of arrangements you could use. But there would be more then what I'm currently working on, more then in option one, and probably about as many as you guys are actually using right now.

And a third option would be to restore ItemSlotAssign.xml. This option is the most involved but would give you the ability to have a completely different layout for every weapon/item in the game. Personally I think this is overkill. There's alot more programming involved (both in the ja2 code and the xml editor) with this option. Plus, would you actually have a different layout for every AK in the system (as an example)?

In all three cases, the way the system determines what a valid attachment is, and where those attachments can be placed, remains unchanged from what I'm currently working on. All these options would change is how the system figures out the way to display the attachment slots. Also, I can't program the system to do all three options, though I am willing to work on one of them since it's apparent the slot placement is a bit more important to the modders then I had originally expected. Of the three, I'd prefer option 1 as it gives you additional control without me having to write too much extra code. Smile But if you guys think options 2 or 3 would be better, I'll try those instead. I just need to know which option you guys think would be best.

As for multiple attachments, most of the functions used to figure out weapon bonuses are designed to look through the attachments until one is found that meets the search criteria. When one is found, the code returns the value. So in the case of laser sights, if you had a standard Laser Sight in a "lower" slot number (from the codes perspective) and a LAM-200 in a "higher" slot, you'd get the bonus from the Laser Sight and the LAM would be ignored. We'd have to re-write most of those functions to search every attachment and then have the code figure out which is the "best" option. This is very problematic, especially when we compare attachments that have bonuses and penalties that counter each other. For example, if you could put an ACOG and a Battle Scope on the same weapon, the code might determine that the Battle Scope gives the best bonuses but it also has the worst penalties so we'd have to let it know to use this attachment for both calculations. Obviously that isn't impossible, but the code currently isn't designed to do this. Ultimately the code (both the original and now NAS) is designed on the assumption that you wouldn't use two similar attachments on the same weapon. Personally, though I know it's feasible that you could go mounting multiple scopes, laser sights and such, there really is no reason you would do so in the game so it's not worth the effort to rewrite functions that work. Not to mention that if we make these functions too complicated, it'll slow the game down.

Finally, for multiple attachment points, that's already possible with the code I'm working on. With or without the above options to give you guys more control over the attachment layout. I may have setup the xml files I'm currently working with so that (for example) laser sights can only go in the "Sight Attachment" slot (nasAttachmentClass = 32) but that doesn't mean you guys can't change that. If you want to make it possible for laser sights to be attached to the "Sight Attachment" or "Underbarrel Attachment" points, you just have to change the "nasAttachmentClass" of the laser sites to be a combination of both (i.e., nasAttachmentClass = 32 + 8192 = 8224) and the code will allow placement in either/both locations.
Alternatively (and probably a better solution with any of the above options) you could change the "nasAttachmentClass" of the "Underbarrel Attachment" slot (or the equivalent for a specific "ubWeaponType", "nasLayoutClass" or "usItem" depending on which layout option we program for) uses class 8224 which would then allow that slot to use both "underbarrel" and "lasersight" class attachments.

Re: New Attachment System Beta[message #267045] Wed, 17 November 2010 20:09 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
BeVeR
Hmm... found where the code is written for passing in the info from the XML. Also found where the ubWeaponClass is checked. Now since it's been forever and a day since I've worked with C++ I'm not too keen on writing some whole new code but I'm wondering if it will cause any issues if i just change all the references to ubWeaponClass to ubWeaponType seeing as I haven't been using ubWeaponClass for any of my AlteringAttachments.xml

Any thoughts on this before I go ahead with it... Think I'll wait till I get up tomorrow before trying any actual coding seeing as it's 0430 and I'd be likely to make mistakes. :sleep:

Just so you're aware, the AlteringAttachments.xml is only used in the current version of NAS. The version that I've been working on (what we've been talking about over the last few days) does away with this xml file in favor of an altering system similar to the way underslung grenade launchers currently work.

Re: New Attachment System Beta[message #267046] Wed, 17 November 2010 20:28 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Depending on how much control and flexibility is made avaialbe to the modder, nasLayoutClass could transform into a substitute for a weapon families variable that so many other ideas require (ie. weapons familarity by Mercs). So the effort to add a new tag to items.xml may find other uses.

EDIT: just off the top of my head I've recycled these slot arrangements

AK
AR-15
Bullpup Rifle
Sniper Rifle
FN FAL
G3
MP5
Oldie Pistol
Pistol w/tac rail
Heavy Revolver (sniper scope)
Heavy LMG
Desert Eagle
G36/80's fixed scope AR

Then again I probably have more examples of custom layouts vs. repeats; though overall the bulk of the weapons fit one of these.

[Updated on: Wed, 17 November 2010 20:50] by Moderator



Re: New Attachment System Beta[message #267048] Wed, 17 November 2010 20:43 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Ok. For the moment I'll start looking at adding a nasLayoutClass option while I'm working the rest of the bugs (those that I can see, anyway) out of what I've written.

Re: New Attachment System Beta[message #267050] Wed, 17 November 2010 21:01 Go to previous messageGo to next message
Faithless

 
Messages:445
Registered:October 2009
Location: The safe end of the barre...
Without a separate xml, I fear there may be problems with future development.

There have been idea's to have attachments actually draw a picture of the attachment over the gun pic.
This makes it possible to change the barrel, and have the gun look differently without it actually being a different gun.

However, you'd have to be able to place these extra images differently on pretty much every gun, because no gun pic is the same.
I don't see how this would be possible with your first two options, while with a separate xml it would just be a matter of adding a new tag.

The xml can probably also be modified to have the XML editor understand it more easily.
It would also not be needed for every weapon, but only if this weapon is different from the default layout.

example with data for the second image added (just to illustrate the idea):
	
		2
		12
		29
		30
		51
		74
	
	
		2
		6
		20
		50
		80
		40
	
Re: New Attachment System Beta[message #267053] Wed, 17 November 2010 21:32 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Actually having an extra xml still wouldn't resolve the problem you're thinking of because each weapon/attachment combination would require a slightly different graphic. A "pistol suppressor" installed on a Berreta M92F is going to look different from a "pistol suppressor" installed on a Browning Highpower which is going to look different then a "pistol suppressor" installed on an FN P90. Most weapon/attachment combinations are going to result in a need for different graphics unless the weapons started off looking fairly simiarl. One xml file wouldn't be able to cover the graphics for all that. At least not an xml file that would work for "option 3" in my post. What you're talking about would probably work best if the existing Attachments.xml was expanded since it already "links" attachment and items on a case by case basis.

Re: New Attachment System Beta[message #267085] Thu, 18 November 2010 22:16 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
@smeagol- I downloaded the WF6.06-AIMNASV14 EN file to try and get the individual 43mm rounds for the GM-94 from your files, as was suggested but I only see the standard 4rnd items plus an entry for a 4rnd Illum version. Did I download the wrong file?

Re: New Attachment System Beta[message #267089] Thu, 18 November 2010 22:42 Go to previous messageGo to next message
Logisteric

 
Messages:3471
Registered:December 2008
Location: B
obviously, you screwed the install somehow - the file is the right one
Re: New Attachment System Beta[message #267102] Fri, 19 November 2010 00:58 Go to previous messageGo to next message
smeagol

 
Messages:2714
Registered:June 2008
Location: Bremen, Germany
ChrisL
@smeagol- I downloaded the WF6.06-AIMNASV14 EN file to try and get the individual 43mm rounds for the GM-94 from your files, as was suggested but I only see the standard 4rnd items plus an entry for a 4rnd Illum version. Did I download the wrong file?


Hmm... the 43mm single grenades should be in there. Don't know what went wrong there.

[Updated on: Fri, 19 November 2010 00:59] by Moderator



Re: New Attachment System Beta[message #267105] Fri, 19 November 2010 01:36 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I figured it out. You replaced the "4-shot" version with the single shot version. Since I still need the "4-shot" version, I had to add new items but I did copy your single shot graphics. I think it's working now.

Re: New Attachment System Beta[message #267150] Fri, 19 November 2010 19:56 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I'm about ready with the NAS, ver 0.7, code. I want to release it for testing with the latest code from the development branch but some of the changes (Rev3903) had an adverse effect on save games so I'm working to get that resolved before I make the NAS updates available. However, from the tests I've been running so far, it looks like everything is working. Including the ability for up to 32 attachment layouts. Right now I have 3 "default" layouts (a default layout, a single shot GL layout and a multi-shot GL layout) which would leave you guys 29 custom layouts. Based on the list wil473 posted, that should be more then enough, but if you think more would be better, I can change to a 64bit layout variable.

What I did with the layout is allow attachments to alter it. So, by default, all weapons use layout 1 but if you attach a GL to a weapon (or if a weapon has a GL by default), then the code would use layout 1 & 2 combined. Also, the way I set things up, you don't have to recreate every slot for a custom layout. If you assign a weapon to a custom layout but don't include a slot that the weapon needs (based on what attachments it's allowed to use) the code should automatically use a default slot. I did this mostly so we didn't risk dropping attachments.

I haven't had a chance to check how the updated code will handle wil's folding stock system because it's not part of the dev branch. For the moment, I would like to make sure that these code updates work for the dev branch. Once we're fairly sure that everything is functioning properly, however, I can look at what adjustments would need to be made for that folding stock system to function (assuming it doesn't with this code).

Re: New Attachment System Beta[message #267196] Sat, 20 November 2010 21:16 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
As far as I can tell, Folding Stock v2 (yeah, I've given it a name) only works due to order of operation:

1) does this attachment fit this slot? - if yes then 2), if no 3)
2) does this attachment trigger a combo merger? if yes then trigger combo merger, if no simply attach with no further action
3) does this attachment merge (simple) with item (in a valid way)? - if yes then carry out merger, if no 4
4) error message attachment does not fit item


Moving on, just to be clear, Attachments adding slots is based on adding valid attachments to an item's list and addind layouts, right? Weapon layout + Attachment 1 layout + Attachment 2 layout + ... + Attachment N layout = layout for the specific occurance of the weapon

Example 1. gun only has one optics slot, attach the ACOG and the Reflex only slot appears above the primary optics slot. The ACOG has a layout defined with the one new slot.
Example 2. gun only has one optics slot, attach fancy scope with triple RIS and Reflex only and RIS LAM slots appear. The scope has a layout defined with the two new slots.


Despite my own redesign to streamline the number of slot layouts in use, I'd say go for as large a number of layouts as feasible, 64bit or more if possible. What I forgot to list are the custom layouts for items (armour, explosives, and those needed for mergers).

Also I have a lot of attachments that add slots. If the layouts are additive, these would account for a large number of layouts:

- RIS Quads handguards (3 slots, no point having 2 "side" slots)
- RIS Triple handguards (2 slots)
- Pistol RIS Bridge Mount (2 slots)
- Desert Eagle specific RIS add-on
- ACOG
- Scope-to-RIS Optics
- RIS Scope Rings
- RIS Scope Rings with Reflex Sight Mount
- Scope with Reflex Sight Mount
- 1.5x Scope with RIS (2 slots)
- Advance Reflex Sight optics addon
- Metal Storm Underslung launcher (3 grenade slots)

Now can you subtract slots?
Also is there a safeguard to prevent adding the same slot twice? Not overlap of two different slots that have the same coordinates, though that is a problem, but one that's on the modder's head.

[Updated on: Sat, 20 November 2010 22:09] by Moderator



Re: New Attachment System Beta[message #267199] Sat, 20 November 2010 22:13 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
First, I wouldn't make a "fancy scope with triple RIS and Reflex only" item. You can, but from my experience the "triple RIS" would be attached to the gun and the scope (and other items) would attach to the RIS. So I'd suggest the "RIS Quads" and "RIS Triple" (and maybe even an "RIS Single"), all with an attachment class of "External" (2048) and an identical layout class. Then assigne each the attachments that it can support. The program will only activate the slots that your valid attachments can use so even if the RIS rails all use the same layout, if one can use Optice and Reflex, and the other can use Optics, Reflex and Laser, the first will only get two slots while the second will get three.

I've already created a default UGL and a Default "Multi-Shot GL" layout. So you'd just assign the Metal Storm UGL to the "Multi-Shot GL" layout (4) and the code will automatically put three slots in the appropriate place. Even though layout 4 currently has 6 available slots, it will only display however many the weapon's magsize allows. So a Metal Storm would get 3 slots while a Milkor would get 6, even though both would use the say layout class.

Remember, regardless of the slots you assign to a particular layout, only those slots that an item can actually make use of will show up. So even though the default item layout (1) has slots for barrel, laser, reflex, scope, stock, ammo, underbarrel, internal, two external and 4 misc slots, a weapon will only get the slots that match up to it's valid attachments. I.E., if an M1 Garand can't support any ammo attachments, it doesn't get the ammo slot even though the ammo slot may be part of the M1s layout class.

Non-weapon items (like armor, explosives and mergers) are all handled the same, though odds are you won't need to assign any of them anything but the default layout (1). Since all those items can only support Misc attachment class items, you'll only get the appropriate items. As an example, there are 4 "Misc attachment classes" available: 1, 2, 4 & 8. All Vision related items (NVGs and Sun Goggles) are currently AttachmentClass 1, while Extended Ears are AttachmentClass 2. Any helmet that can attach NVGs, Sun Goggles and Extended Ears automatically get the first two default misc slots.

I've already worked the code so that you'll get all the slots from the default layout, regardless of the layout class you specify, unless you've specified another layout. As an example, I created a custom layout for the M1911A1 pistol (strictly as a test) that only has a laser slot which is under the barrel. When you pick up an M1911A1, you'll get the default barrel and reflex slots, plus the custom laser slot because it overrides the default laster slot. That said, however, it is up to the mods to make sure their layouts function. Taking my M1911A1 example to an extreme, if I decided that the weapon could support a bipod (silly, but bare with me) then you'd run into a problem because the default underbarrel slot would try to appear in the same location (because of how I setup the custom layout) as my custom laser slot. This would cause issues that the program can't resolve, but technically you can do that kind of thing with NAS 0.61 so you should be able to deal with it.

Remember, you won't always need a custom layout. If an attachment grants more attachment points, you can use the default locations unless you are going for a specific layout design.

Edit: Oh. The code does follow the logic you indicated, wil. So perhaps Folding Stock v2 will work just fine.

[Updated on: Sat, 20 November 2010 22:14] by Moderator


Re: New Attachment System Beta[message #267200] Sat, 20 November 2010 22:33 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Sorry, run-on item description (this is what happens when I do my own proofreading). The "fancy scope with triple RIS and Reflex only" item is just a scope with multiple RIS, similar in concept to the ACOG, but with one more slot added specifically for a LAM device.

I don't seem to remember an answer to this one, how many attachment classes may a slot be given?

Ie. Flat Top M4 with only one RIS slot (old fashion M4 handguard), and I want the following attachment classes to fit:
- Optics
- Reflex Sight (I'm thinking I need a seperate class for this one as while it can be a primary sight, it is also being employed as an addon to mitigate some of the severe scope penalties I have)
- LAMS

...and I don't want the game engine to automatically pop in a LAM only slot on this particular weapon, I just want by default, only one slot that these three attachment classes may fit into. Bascially I'm exercising the point that NAS does not necessarily mean more attachments on a particular gun, indeed this one is meant to reduce the number options, as while scopes and those big RIS LAM's can fit this M4, the player has to pick only one (or find a RIS Quad handguard).


EDIT: actually, this gives me the opportunity to better describe the ACOG and the RIS equipped Scope. Same Flat Top M4, with only the one slot (the optics position) for RIS items.

When the ACOG is attached, it adds a slot that may only fit the Reflex Sight
When the RIS Equipped Scope is attached it adds two slots, one that fits only the Reflex Sight, and a second that only fits those big RIS LAM's

Note, that the Reflex Sight and the big RIS LAM's are already in the M4's attachment list. These examples with the M4 are cases of adding available slots only and not valid attachments.

[Updated on: Sat, 20 November 2010 23:08] by Moderator



Re: New Attachment System Beta[message #267201] Sat, 20 November 2010 23:03 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Technically each nasAttachmentClass flag (whether on an item or an attachment slot) can support up to 32 classes. It's all handled by bitwise calculations in the code. So if you assign an item to nasAttachmentClass 3, then the item would be valid for slots of class 1, 2 or 3 because of the bitwise math:
3 = 00000011 binary so "Item[usItem].nasAttachmentClass & AttachmentSlot[slotNum].nasAttachmentClass" would return true if one is attachment class 3 (0011) and the other is attachment class 1 (0001) or 2 (0010).

That said, for most items you probably want to assign them to a single attachment class and then create custom attachment slots that might allow multiple classes.

And because the code determines whether to use a default or custom slot by the attachment class, if you created a custom slot that was attchment class 3 (0011) then you'd override the default slots for class 1 and 2 with your custom slot. So, I have scopes set to class 128 (10000000), reflex sights set to class 64 (01000000) and laser sights set to class 32 (00100000). So if you create a custom slot of class 224 (11100000) then you get a single slot that can hold all three types of items and which will override all three default slots. At least it's supposed to. I'm still alpha testing everything but that's the general idea. If you wanted to allow two of those three, you could simply create 2 custom slots, both of class 224.

Re: New Attachment System Beta[message #267202] Sat, 20 November 2010 23:15 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Ah, from the modder's standpoint, wouldn't it just be easier to have a list of valid attachment classes for the slot. Yeah I know this is running very close to Warmsteel's NAS, but I'm only suggesting short list of attachment classes instead of the attachments directly for the slot. The way I'm reading your description, I'm envisioning problems with slots accidentally becoming valid due to mistakes in the math done by the modder.

EDIT: no wait, now I think I am reading that an attachment slot will have a list of possible attachment classes in your description there Chris. I'm now slightly more confused...

EDIT2: Yes my example of the M4 Flat Top has a custom slot layout. I think I can get away with using a combination of the default layout and default inseparable attachments to differentiate between the M4 (which will get the C-mag adapter from the default config); and a Barrett REC7 (which differs in having a RIS Quad handguard, but no C-mag option). This should save on layouts:

- default gun
- Basic AR-15
- common RIS Quad handguard

Instead of
- default gun
- Basic AR-15
- RIS everywhere AR-15
- common RIS Quad handguard

EDIT3: Ok, yes or no, am I correct in reading the following:
1) 32 attachment classes
2) attachment slots may have multiple attachment classes assigned

[Updated on: Sat, 20 November 2010 23:33] by Moderator



Re: New Attachment System Beta[message #267208] Sun, 21 November 2010 04:17 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
If you have a list of valid attachments, then you've got redundancy that shouldn't be there. Remember, this is supposed to be useful for everyone.
As a player I shouldn't have to edit two files if I want to add an attachment to a weapon.
As a developer, it's going to be tough enough getting 1 extra table and a couple extra values added to the xml editor. Trying to get the xml editor to deal correctly with two seperate attachment compatibility lists would be murder.
And from a modders pov, sure, you could do the math wrong but you could do a ton of other things wrong as well, and cause problems with your mod. By using the existing attachments.xml, that's one less thing you modders have to worry about. Plus, you don't have to do anything special for your mods to work in both OAS and NAS.

I should point out that I've made it possible for "ammo adapters" (like the C-mag) to be removed. The addattachments and removeattachments functions have been modified so they recognize when ammo capacity is modified so the gun can either be unloaded or the ammo item updated depending on what needs to be done. I.E., stick a C-Mag on an M4 and the game will convert the 30rnd clip into a 100rnd C-Mag (with only 30rnds in it). Take the C-Mag back out and we either unload the weapon (if more then 30 rounds) or convert to a standard 30rnd mag.
I want to add an adapter for the minimi so it can switch between 30rnd mags and 200rnd belts.

For your example, unfortunately I don't have an REC7 in my specs. But hopefully this will help. The following picture are for three different weapons I'm currently using. None of them are using any kind of custom layout, just the default Item layout is being used. Notice that the M16A4 has no valid external attachments so it gets no external slots. The M4 gets externals but no stock, so it has 2 external slots (there are 2 default external slots) and no stock slot. And the A1 doesn't get reflex, internal, external, stock or ammo slots. The code generated all three strictly based on the allowable attachments. if I were to remove the Foregrip from the M16 and install an M203PI, I'd automatically get a GL slot for a single shot UGL.
http://img52.imageshack.us/img52/7655/nasexamples.jpg
The only reason you'll need custom layouts is if you want a slot to acctually appear in a completely different location and/or want a slot that allows multiple attachment classes. You don't need custom layouts to deal with "altering attachments". The following are three examples of the M1 Garand. The only modification I've made to the M1 is to make the existing "G36 Rail-Kit" attachable by the M1. This give the M1 access to the default external slots. To the rail-kit I made it so it could take the existing "G36 Grip/Optics" item and a reflex sight. And I make the grip/optics so it could take the ACOG. By default the M1 can not fit the reflex sight or the ACOG. But when I fit the rail-kit, the "sight slot" is automatically available and I can now mount a Reflex Sight (as seen in the second image). And by mounting the grip/optics (which is only allowable on the M1 because I've got the rail-kit already mounted) I can now attach the ACOG. This all used the default layout. I simply "turn on" slots, and alter what are considered valid attachments based on the other attachments I've installed. If I were to remove the rail-kit, the system would also remove the Reflex Sight, ACOG and grip/optics because none of them are valid attachments for the M1 Garand without the rail-kit installed. Obviously this is just an example to try and show how "altering attachments" function.
http://img189.imageshack.us/img189/7212/nasexamples2.jpg
EDIT: I should also comment that you don't use a special xml file to deal with "altering attachments". You just go into the existing Attachments.xml and make attachments valid for your attachments. In my example, I added an entry for item 1185 (rail-kit) so it could use 1186 (grip/optics) and 1006 (reflex sight). And I added an entry for 1186 (grip/optics) for 1030 (ACOG). Because these attachmens can have attachments, anything I attach them to also can mount these "extra" attachments.

Yes, there are currently 32 attachment classes. I've pre-assigned all of the attachments that exist in the development game branch to the first 15 classes. That means there are still 17 attachment classes available should you come across (or create) an attachment that doesn't fit into one of my "standard" classes. Btw, those "standard classes" are:
Default1 - (NVG, Goggles, armor plates, Detonators, Spring, glue, etc) [1]
Default2 - (Extended ear, Duct tape, camo, etc) [2]
Default3 - (nothing at present) [4]
Default4 - (nothing at present) [8]
Barrel - (Silencers, suppressors, extenders, etc) [16]
Laser - (Laser sights) [32]
Sight - (Reflex, Match, ISM-V-IR, Kobra, etc) [64]
Scope - (Scopes) [128]
Stock - (Folding, Retractable) [256]
Ammo - (C-Mag, 7.62WP) [512]
Internal - (Rod&Spring) [1024]
External - (Trigger group) [2048]
Underbarrel - (Bipod, Foregrip, Gripod, UGL) [4096]
Grenade - (Rifle Grenades) [8192]
Rocket - (RPGs - this is a bigslot) [16384]

Yes, attachment slots may have multiple attachment classes assigned. Remember, we're using bitwise math which means we're looking at the bits that make up the value of our attachment class to determine if an attachment is a fit. 1024 = 10000000000 in Binary. 1040 = 10000010000 in Binary, so if you assign a slot to nasAttachmentGroup 1040, it will be able to use both Internal and Barrel attachments. Want a custom slot that can fight both scopes and sights? Assign it to nasAttachmentClass 192. Want a custom slot that can fit lasers or bipods? Assign it to nasAttachmentClass 4128.
Technically you can also do this with attachments. If you wanted a Sniper Scope (for example) to mount in either a sight or scope slot, you could change it's nasAttachmentClass to 192. I don't suggest making attachments that can fit in multiple slots, though, as there is a risk that attachments will go places you don't intend them. But the option is still there for you.

[Updated on: Sun, 21 November 2010 04:25] by Moderator


Re: New Attachment System Beta[message #267213] Sun, 21 November 2010 08:24 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Ok, Chris, I think I know enough to start planning, and compiling lists of stuff be discussed.

Known:
-32 attachments classes
-32 layouts (3 already set aside for defaults)
-6 Grenade slots only, though coordinates are modder definable

To be Determined:
-Folding Stock exploit
-We forgot to mention that multi-shot rocket launchers have been implemented in both AIM and my projects; differently too, I think Smeagol has four rockets slots, while I use only one and it depletes the round by 25% each shot.

Unclear still:
-Ok, you mentioned that the presence of an underslung grenade launcher results in the code combining the guns layout and the Number 2 layout. Fine, but I am still unclear if this applies to other attachments causing layouts to merge. Your explanation is fine at describing the addition of new attachments (all defined in attachments.xml); however what if it is not new attachments I am after, but additional slots?

Perhaps I was not being clear. In my earlier example, I was describing a M4 Carbine with only one RIS Rail (Flat Top); which on its own, can have only one attachment from any of the following categories: RIS equipped Optic, RIS LAM, RIS Scope Mount Adapter, or a Combination scope and RIS adapter. Given that the player has a RIS LAM, a Battle Scope, and a Reflex Scope, only one of these three may be attached at any one time. This is the start, I understand that with bit masking this slot can be made to accept multiple classes, however the existing slot layout is not the issue:

Case 1 for the M4 Flat Top: ACOG problem
Now if an ACOG is attached to this one slot nothing else can use it. Can the ACOG be defined so that when it is attached, a new slot pops up for the Reflex to be mounted? The reflex is already a valid attachment, with the ACOG already occupying the Flat Top slot, all it needs is an open slot to appear for it, which is what the ACOG is intended to do (unlike the Battle Scope). My original reading was that this could be done by assigning the ACOG a layout, and then adding this layout to the base weapon's layout, but later comments have me not so sure anymore.

Case 2 for the M4 Flat Top: RIS Quad Handguard problem
Without a handguard, the player has to pick between a scope or the RIS LAM, both are valid attachments, but they compete for the same solitary slot on this M4. With a RIS handguard attached, I want to have multiple slots appear, all of which can accept the LAM (among other things). Again, my original reading had me thinking this could be done by adding the layouts of the M4 and the Handguard together.

Please bear in mind that I've already got the effects above in use. I am not simplying using NAS to allow players to have more attachments, in many cases I am constraining their use further. ie. instead of four slots that each can fit a scope or a LAM, there is just one, unless they find something that adds slots.

[Updated on: Sun, 21 November 2010 08:37] by Moderator



Re: New Attachment System Beta[message #267215] Sun, 21 November 2010 09:22 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Currently there are only 6 grenade slots because that's all I've coded in the default "multi-shot GL" layout. The code isn't limited to 6, however. The code will give you a number of slots equal to the weapons "magsize" so long as you define the slots. If you want an 11-shot GL, make sure you have 11 slots defined (just add them to the default multi-shot layout unless you want all 11 in a special layout) and that the ubMagSize value for the weapon is 11.

I wasn't aware anyone had created multi-shot rockets but that's not a problem. I'll update the code so it'll treat rockets just like multi-shot GLs.

A UGL is nothing more then an attachment. Any attachment that has a nasLayoutClass that is different from the weapon/item it's being attached to will add it's layout to the weapon/item. So if the weapon using using Layout 1 (default) and you attach a UGL using layout 2 and an ACOG using layout 8, then all three layouts will be used (though the highest layout takes presedence).

As I understand it, the ACOG is nothing more then a scope. You don't attach things to it. That being said, the code doesn't really care one way or the other. If you go into Attachments.xml and say that attachments can attach to the ACOG, then mounting the ACOG to a weapon will grant that weapon the ability to mount ANYTHING that the ACOG can mount. However, this is item independant meaning if you say the ACOG can mount a Reflex, then any weapon that can take an ACOG will be able to use a Reflex. Not just the M4. Assuming that isn't an issue, then you simply say the Reflex can attach to the ACOG and when you attach the ACOG to a weapon (M4 or otherwise) you'll get a new slot to mount the Reflex to.
The confusion I think is that what we're talking about here has nothing to do with the Layout. The Layout simply determines slot placement and attachment class. For instance, using just the default Layout, I could setup a weapon that can use an ACOG and no other attachments. When looking at the weapon with nothing attached I would see only the scope slot. If I also tell the xml file that a Reflex can attach to the ACOG, then attach an ACOG to my example weapon, the sight slot will automatically appear simply because the ACOG allows it. This has nothing to do with the Layout. This is strictly a concern for the Attachment Class.
Where the layout would come into play is to force the "laser slot", "sight slot" and "scope slot" to only appear as a single slot, thus allowing LAM, Reflex or Battle scope (but no more then one) to be mounted to your example M4. The M4 would be assigned to your custom layout (say Cool and you'd create (at least) one slot with a LayoutClass of 8 and an AttchmentClass of 224. The ACOG in your example, could be left with Default LayoutClass 1 so long as the sight slot didn't overlap your custom slot. By attaching the ACOG to your custom layout slot, you'd still activate the sight slot because attachments always override.

From your second case, your weapon would actually need 2 slots: 1 scope/lam slot and 1 external slot, both in the same custom layout. The scope/lam slot would be allowed to fit your scope or lam as the player chooses. The external slot would be able to hold the handguard. You setup the handguard just like I've described the ACOG above. When you attach the handguard, whether you have anything mounted in your scope/lam slot, a new slot (or slots depending on what the handguard is allowed to attach) will be made available. Again, like the ACOG, you could assign the handguard to Layout 1 unless you wanted it to add custom slots. That really just depends on what you're trying to accomplish.
I suppose you could also create a single slot that was a scope/lam/handguard slot. Then when mounting a handguard, it could override your custom slot, move itself to a new, custom location, and add new slots for individual scope and lam slots. In this case you'd be working with 2 custom layouts. One for the weapon and one for the handguard. And you'd have to make sure that the scope/lam/handguard spot existed in both layouts (just in a different location in each).

Re: New Attachment System Beta[message #267220] Sun, 21 November 2010 17:36 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Ok, that outright confirms that layouts add, takes away one worry.

However this morning I came up with an alternate plan. Since I'm consolidating gun layouts as much as possible into a common design, I was thinking of using "dummy" attachments and attachment classes to cause extended attachment slots to pop-up from a tricked out default layout. This plan was compatible with your earlier examples Chris of needed, undefined slots being drawn from the default.

Classes
-Scope Add-on 1
-Scope Add-on 2
-Scope Add-on 3 (based on furthest nesting level I already have in use)
-RIS Quad Top
-RIS Quad Side
-RIS Quad Lower

Whenever I needed fine control over slot appearance, I'd use a fake attachment (does nothing except appear in items and attachments.xml) to cause the wanted slot to appear. These variable slots are multi-classed so that the "Reflex pedestal"** slot takes both the dummy Scope Add-on 1 item and the Reflex Sight. May still use this plan if I run short on layouts, or if it turns out this is easier (doubt it as it involves more math).

Which brings me back to an earlier point, didn't you say something about using a larger bit count for storing these variables? As we all seem to be expecting some degree of XMLEditor compatibility out of this, I'm hoping the bitmasks math can be done there. If the XMLEditor can do the math for the modder, then why not 64 or more bits?


EDIT:
Both AIM and the FS projects have the M202 FLASH in-game.

**With this NAS, I intend to again dispense with the merger produced combo scope/sights. So instead of the combined ACOG Reflex Scope/Sight, attachment of the ACOG Reflex Scope will cause a slot for the Reflex sight to appear on demand. For my own purposes, I also have two Sniper Scope related attachments that do the same thing (but pop-up two slots, one replaces the in-use optics slot, and a second for the Reflex Sight. To be honest, my current nested slots adding slots is somewhat haphazardly arranged, so a redesign for more commonality between guns is not entirely out of order.

[Updated on: Sun, 21 November 2010 17:57] by Moderator



Re: New Attachment System Beta[message #267222] Sun, 21 November 2010 21:27 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
Yes, I can work on switching the layoutclass to a 64bit variable. I'm not sure I can get a variable larger then 64bit.

The M202 Flash shouldn't be an issue. I'm testing multi-shot rocket launchers now but they should work just the multi-shot grenades.

I'm not sure why you'd need fake attachments. If a slot can hold you fake attachment or a reflex sight, and the weapon/item/attachment can hold a reflex sight, then the slot should appear. I'm testing to make sure layout precedence is going to work correctly, but the end result should be that fake attachments shouldn't be needed.

Re: New Attachment System Beta[message #267261] Tue, 23 November 2010 01:55 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I've updated the layout class so it should support up to 64 layouts. I'm also only using 2 layouts as default layouts so that should leave you guys 62 possible custom layouts to work with.
Default Layout 1 is the default item layout. It has default attachment slots for weapons and items. The code will use this slot to "fill the gaps" in any custom layouts that are created. So, for example, if you want a custom layout that has the laser sight slot in a location other then the default, but you want the "standard" location for all other attachments, your custom layout only has to include a definition for the new laser sight slot. Any weapon/item that requires any of the slots not in your custom layout will automatically use LayoutClass 1 slots so that no attachments get lost. However, as a word of caution, it's possible for you to create an item that has two (or more) attachment slots that overlap. The results will be strange. Any attachment that goes into one of these overlapped slots will effect the weapon/item, but you may not be able to remove them from the weapon.
Default Layout 2 is used by multi-launch grenade and rocket launchers. At present I have 6 GL and 4 RL slots setup. If you want to create a GL or RL with more capacity, just add more slots to the LayoutClass 2 definition, and set the ubMagSize value in Weapons.xml to the appropriate size. I.E., if you want a 6 shot RL, ubMagSize should equal 6 and you'll need to add 2 more Rocket slots to LayoutClass 2.

Because NAS no longer uses "multi-shot grenade" items (like 40mm Cylinders), I've marked them all as OAS-only in the Items.xml I'm using. But I have noticed that (especially in established games), these kinds of items may still exist. So I've added to the attachment code. Any time you try to attach a "multi-shot grenade" item to a multi-shot GL, the code will automatically "take 1" from the multi-shot item, load the slot you clicked on, and leave the remaining multi-shot item in your cursor. So, for example, if you have a 40mm HE Cylinder with 100% status (meaning, all 6 shots available) and you try to load a Milkor with it, an individual 40mm HE grenade will be loaded into the Milkor slot you clicked on and the 40mm HE Cylinder's status will be lowered by the equivalent of 1 round. This works for metal storm and 43mm grenades as well, so long as the code is able to find an idential, single-shot grenade somewhere in the xml files.

@wil473: I've been playing around with some custom layouts that conform to what I think you've been describing for the M4 in previous posts. I'm pretty sure (assuming I'm understanding exactly what you're looking for) that the code is doing what you expect it to do.
I'm going to continue with my test game for a couple more days and see if anything unexpected happens. If everything goes well, I'm hoping to make a beta available for use by Wednesday.

Re: New Attachment System Beta[message #267266] Tue, 23 November 2010 03:07 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
With 64 layouts I don't think I'll be needing to use the dummy attachments, though I think I will be needing some of the attachment classes to control which RIS slots are usable on RIS Quads and Triplets.

About the map placed items, NAS (not this one, yet, but the current one) has aggravated a few issues. This goes beyond the scope of the NAS replacement you've described Chris, but it is bound to come up: with multiple default attachments there is the problem of updating items in-map. Now I'm going through the maps with Warmsteel's implementation of the map editor replacing items in the hope that default attachments show up. I am finding it is not just the 2nd and further attachments that are inconsistently showing up, but now single default attachments are not appearing either for entire item indexes.

Is there some way to:
1) have all items refresh (so that all default attachments appear) when a map is loaded by the exe the first time?
2) have an equivalence list that swaps NAS only items for some preset OAS item when a map is loaded initially. Something that based on a modder defined list, swaps out the 40mm Cylinder for a 40mm grenade.

[Updated on: Tue, 23 November 2010 03:08] by Moderator



Re: New Attachment System Beta[message #267309] Tue, 23 November 2010 21:21 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I'm not sure you'll need special attachment classes for RIS Quads and Triplets. Between the attachmentClass and Attachments.xml, you should be able to control what any particular item can and can't use. Let me see if I can give an example as to how the system works.
You've got items like the following:
Laser Sight (AC=32)
LAM-200 (AC=32)
Rifle LAM (AC=32)
ISM-V-IR (AC=64)
Reflex Sight (AC=64)
Battle Scope (AC=128)
2x Scope (AC=128)
ACOG (AC=128)
Bipod (AC=4096)
Foregrip (AC=4096)
Various UGLs (AC=4096)
RIS Rails (AC=2048)
RIS Triple (AC=2048)
RIS Quad (AC=2048)
Trigger Group (AC=2048)

Without any kind of rail system, maybe a weapon can't support any kind of sight, laser, scope or underbarrel attachments. For simplicity sake, let's also assume we're using the default layout for this weapon. So in Attachments.xml this weapon might have no entries for any of these kinds of items. What Attachments.xml does have, however, is an entry for the "RIS Rails", making that attachment the only valid item for this weapon. When you look at the "clean" weapon in the game, the only attachment slots you'll see are the two External slots (since two are currently in my default layout).
Let's say that the "RIS Rails" are using a custom layout (LC=4) that includes a single "multi-point" attachment point of AC=224. We also say that in Attachments.xml, the "RIS Rails" can attach any of the scopes, sights or lasers I've listed in the above list, along with the "RIS Triple". If you attach the "RIS Rails" to our fictitious weapon, we suddenly have a single "multi-point" attachment point and the two external slots (one of which is occupied by the "RIS Rails").
Let's also say that the "RIS Triple" uses a custom layout (LC=8) that includes a "multi-point" attachment point of AC=224 (offset from the one above) and a third external point of AC=2048. In Attachments.xml we say the "RIS Triple" can attach any ONE scope, sight or laser I've listed above (we need at least one for the slot to appear), along with the "RIS Quad". If you attach the "RIS Triple" in our 2nd external slot, a third external slot appears plus a new "multi-point" slot that can hold ANY of the items allowed by the "RIS Rails" even though the "RIS Triple" can use only a single item.
Finally, let's say the "RIS Quad" also uses custom layout LC=8 (though LC=4 would net the same results). In attachments.xml we say the "RIS Quad" can use a bipod, foregrip, M203PI and sniper scope. If you attach the "RIS Quad" in our 3rd extrnal slot, the default underslung slot (since none of our custom layouts included an entry for AC=4096 items) will appear and the 10x sniper scope will now ALSO be attachable to either of our "multi-point" attachment points.
You can see this progression in the following graphic.
http://img15.imageshack.us/img15/5113/acexample.jpg
The above is a pretty exteme example, but it does show that modders should be able to completely redesign Attachments.xml to have nearly complete control over attachments, assuming they want to do away with OAS in their mod. However, here's a similar example that keeps OAS valid.
In this example, we take the standard Attachments.xml and add an entry so that a sample weapon (the Colt Commando) can use our "RIS Triple", that the "RIS Triple" can use a laser sight and the "RIS Quad", and that the "RIS Quad" can use a sniper scope and FN EGLM. We're also going to assume that our weapon has a "RIS Rail" built in by making it use Layout Class 4 which I'll leave unchanged from my above example.
Without any attachments installed our weapon gets the "multi-point" from the custom layout along with a barrel, underbarrel, internal and two external ports from the default layout.
If we install the "RIS Triple", we get a 2nd "multi-point" attachment port plus a third external port. Just like in the above example, even though the "RIS Triple" has only been setup to use the Laser Sight, both "multi-point" attachment points can fit any scope, sight or laser that our weapon could have used.
Finally, if we install the "RIS Quad", we get no new attachment points because our weapon already got the default underbarrel point. But both of our "multi-point" attachment ports can now fit a sniper scope and our underbarrel will now support either the M203PI (which the Colt Commando can fit by default) or the FN EGLM
http://img101.imageshack.us/img101/6388/acexample2.jpg
So you get the same basic results with the 2nd example while still keeping OAS support intact. You could take it one step further and modify the "default layout" (LC=1) so that it only allowed internal, external, barrel, stock and ammo ports (or any other default design you wanted). If you did this, our Colt Commando from the 2nd example would not have been able to mount any kind of underbarrel attachment until the "RIS Quad" was installed. Though you would need to remember to include an underbarrel port in the custom layout used by the rails (LC=8 from my examples). Below is what you'd get with this modification. Notice that the only real difference is that the underbarrel slot isn't available until the "RIS Quad" is installed.
http://img207.imageshack.us/img207/6013/acexample3.jpg
The point of all this is to try and show some of the capabilities of the system. Even without removing OAS support, you should still have significant control over the attachment points that items can use. And don't forget that just because there are two "default" layouts (one for items and one for multi-launch GLs and RLs) doesn't mean you can't change them. The defaults are simply what the system uses if a custom layout doesn't include a port. The idea being so that you don't have to create multiple, identical ports if you don't want to. After all, if your custom layouts aren't going to mess with the placement or valid attachments usable by the barrel port, why force you to create a barrel port for every attachment "just in case"?

As for the map placed items:
1)I'm not sure. I'm not positive if the game actually knows when a map loads "for the first time" or if it simply loads all the maps from the get go. I'll have to look at that code. If it turns out that the code is aware of when a map is called for the first time, it should be possible to have the code recreate the item which would cause the default attachments to be generated properly. I'll look into it.
2)I'm thinking of an extra Items.xml field that allows you to indicate replacement items. So if the code tried to create an item that isn't legal, it can look at the AlternateItem field and try to create that item. There are some issues with this, however. You can't reliably swap out a single item with a stack of items because there are times when a stack is not a valid option. For instance, if the code was trying to generate an item in an enemies hand, we can't create a stack of such items because the game would have problems. This means we can't have multiple replacement items, like an ACOG Combo being replaced by an ACOG and Reflex Sight. Or replacing a 40mm Cylinder with 6 40mm grenades. But I can still look at the option of the "AlternateItem" field and see if I can do anything with that.

One other things I'd like suggestions about is the way I've setup AttachmentClass and the default LayoutClass. As I believe I've mentioned, I've currently got 15 attachment classes defined:
Default1 - (NVG, Goggles, armor plates, Detonators, Spring, glue, etc) [1]
Default2 - (Extended ear, Duct tape, camo, etc) [2]
Default3 - (nothing at present) [4]
Default4 - (nothing at present) [8]
Barrel - (Silencers, suppressors, extenders, etc) [16]
Laser - (Laser sights) [32]
Sight - (Reflex, Match, ISM-V-IR, Kobra, etc) [64]
Scope - (Scopes) [128]
Stock - (Folding, Retractable) [256]
Ammo - (C-Mag, 7.62WP) [512]
Internal - (Rod&Spring) [1024]
External - (Trigger group) [2048]
Underbarrel - (Bipod, Foregrip, Gripod, UGL) [4096]
Grenade - (Rifle Grenades) [8192]
Rocket - (RPGs - this is a bigslot) [16384]
What I'm not sure about is, do I have items in the right classes. For instance, aftering googling the ISM-V-IR, it seems that this item is kind of a compbination laser sight and reflex sight. So maybe it shouldn't be in the "Sight" class. For that matter, maybe reflex sights shouldn't be in their own class. Or maybe having them like this gives you guys the control you need. Either way, I'd like opinions of how I have organized the attachments so far.

Re: New Attachment System Beta[message #267318] Wed, 24 November 2010 00:40 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Earlier, I did a quick chart of how slots under your NAS will look, and what I'll need to do as far as defining Attachment Classes and bit masks to make sure it "looks" right.

At present, it looks like I can cram most guns into one default scheme. Major variations on the default are:
- Bullpup (if I choose to have the C-Mag Adapter in a different position)
- XM29/K11 to account for the large attachment slot for the FCS, and rear Launcher item position
- AICW to prevent the launcher from conflicting with the Foregrip
- FN F2000 Weapon System to again account for the FCS (I suppose I could just draw a smaller graphic)

The sheer number of attachments that add attachment slots I have will take up many more layouts than "special" guns.


To be honest, I'm going to rename and reshuffle some of your default attachment classes. For instance what I'll be classing as "Scopes" will likely include adapters that fit directly to scope mounts, the Match Sights, and the ISM-V-IR. I'm going to have to do the math to setup so-called "scope" slot for the default layout as it needs to accomodate:
- Scopes (see above)
- Reflex Sight (its its own class for 2nd level attachment purposes)
- 2nd Level Scope Adapters (the two RIS Scope Rings I have)
- RIS LAM's (which so far are the only RIS attachments that can fit all RIS slots)

If you want Chris, I can email you the Excel spreadsheet I'm doing all the planning in.


Based on experience, the game must know that it needs to "read" a map for the first time. In troubleshooting UC-1.13 I could get away with swapping in maps as long as I had not visited the map previously in the save game.

Otherwise, related to my first request, but without intruding on the player's experience, would be a Map Editor option that automatically runs through all the maps, clearing optional attachments to prevent conflicts***, and corrects for all current default attachments defined in the XML's at that moment.



***From the moment we were allowed more items in v1.13, the Map Editor's attachment assignment system has been obsolete as it only gives the original attachments as options.

We need a better system:
1) This one isn't directly in the Map Editor, additional attachments for weapons carried by map mercs (Enemy, civilian, Militia) defined via the MapEditor are drawn from EnemyItemChoices.xml as is done with random gun selection. (By the way, did you replicate WarmSteel's changes to random Enemy Attachment selection?) Right now Map Editor assigned weapons are worse off because they have no opportunity for random assignment of new attachments (and often are missing defaults anyways).

2) Attachments placed in the inventory of Map Editor defined mercs, as long as they fit, are attached to gun in weapon hand. Randomly select a gun if the character is dual-weilding. This one I like, if only because most of the CTD's with the Map Editor last weekend (DL item restocking) were caused by accessing weapon details.

3) New add attachment interface to the Map Editor that takes into account the fact we have so many more attachments.

[Updated on: Wed, 24 November 2010 16:25] by Moderator



Re: New Attachment System Beta[message #267341] Wed, 24 November 2010 13:03 Go to previous messageGo to next message
Faithless

 
Messages:445
Registered:October 2009
Location: The safe end of the barre...
Quote:
I should also comment that you don't use a special xml file to deal with "altering attachments". You just go into the existing Attachments.xml and make attachments valid for your attachments. In my example, I added an entry for item 1185 (rail-kit) so it could use 1186 (grip/optics) and 1006 (reflex sight). And I added an entry for 1186 (grip/optics) for 1030 (ACOG). Because these attachmens can have attachments, anything I attach them to also can mount these "extra" attachments.
That's quite handy, but can you currently remove slots as well? (through incompatible attachments probably)
Quote:
I wasn't aware anyone had created multi-shot rockets but that's not a problem. I'll update the code so it'll treat rockets just like multi-shot GLs.
I fixed a bug to make it kind of possible, and it now works well enough for semi-auto rocket launchers, because the rocket needs to hit *before* you shoot another rocket.
Quote:
I'm not sure I can get a variable larger then 64bit.
Is a "long long" not an option? Better be safe than sorry Smile
Re: New Attachment System Beta[message #267364] Wed, 24 November 2010 18:31 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
@wil473: Keeping in mind that what I'm doing is currently geared toward the non-modded game, I'm happy to see that from my descriptions alone you think this new system is going to work for you. At least I'm going to take your comments that way. Smile Figure you woudln't be putting the effort into a spreadsheet if you didn't think it was going to work. Wink

As for the default layout, I'm mostly concerned about whether I've put things in the right category and whether there should actually be as many default slots as I have generated. Maybe we shouldn't have space for 10 attachments as a "default" in NAS? Then again, from my own test game, I rather like being able to outfit a weapon "realistically".

I'm not sure of a problem with enemies getting a selection of all attachments. In my test game I have "Enemy Drop All" turned on and I've been getting all kinds of attachments. I've found pretty much every scope in the game, every LAM and all but the ISM for "sights". I've found both types of stocks, bipods, foregrips, trigger groups, UGLs , silencers, suppressors, etc. About the only things I haven't found much are standard ACOG (no combos other then what I started the game with) and Reflex Sights but I originally was using a heavily modified EnemyGunChoices.xml file that pretty much restricted the enemy to Warsaw Pact weaponry. I've since reverted to the default xml file (by accident) so I expect I'll start seeing more ACOGs and Reflex Sights in the coming battles.

I'm not really sure what can be done about the map editor. It assumes that you're playing OIV/OAS and I don't know that there is a way to change that which doesn't make OIV/OAS mode invalid. I do have a little experience with that editor, though, so once I get the beta of NAS .7 ready, I'll start looking at the map and map editor in more detail.

@Warmsteel: The only way to "remove" an attachment slot right now is to not have any valid attachments that use the slot. For instance, most non-assault rifles do not have any ammo modification attachments, so they don't get the Ammo slot. If your weapon can't support a stock attachment, you won't see the Stock slot. Like that. But if your weapon can normally attach something to a slot, I don't have a means of removing that slot.

I haven't tested semi-auto rocket launchers since I don't have anything like that in my Items.xml file. But since I've mostly made alterations to the code you originally wrote, my guess is if you made them work, they should still work.

I've never tried a "long long" but I can give it a try I suppose. Personally I would hope 64 possible attachment layouts would be more then enough, and no matter how many I make possible, someone is going to want more. Smile Just have to keep in mind that you really only need differnt layouts if you wnat slots to appear in differnt locations and/or you want slots to have different attachment classes. You don't need a seperate layout for two attachments that use the same placement but have different possible attachments. I.E., a Rail that adds the ability to mount scopes and a rail that adds the ability to mount laser sights don't necessarily need different layouts unless you want the slot they each add to appear in the same location.

Re: New Attachment System Beta[message #267369] Wed, 24 November 2010 21:43 Go to previous messageGo to next message
Faithless

 
Messages:445
Registered:October 2009
Location: The safe end of the barre...
long long works, its 128 bits. And it's not too resource consuming or hard to change, so I'm all for having the max amount of classes with minimum effort Smile
Re: New Attachment System Beta[message #267375] Wed, 24 November 2010 22:53 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
WarmSteel
long long works, its 128 bits. And it's not too resource consuming or hard to change, so I'm all for having the max amount of classes with minimum effort Smile
Alright. I'll look at upgrading it to a 128bit value.

Re: New Attachment System Beta[message #267549] Mon, 29 November 2010 18:15 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
I believe that the changes I've been making to NAS are ready to go. But before I upload all these to the development branch, I'd like to get some further testing done by you all. I've tried to test every situation I can think of, but I'm sure someone out there will come up with some situation I hadn't thought about. Smile If you're interested in trying out NAS 0.7, you can download the files here: http://www.mediafire.com/?w8ggaedwu14h4by

The archive contains the following:
7 graphics for single shot 43mm grenades (BigItems)
An updated MDP1ITEMS.sti for single shot 43mm grenades (Interface)
6 XML files (TableData)
1 executable file
1 patch file

To use this update, you should put the BigItems, Interface and TableData folders into your profile path. You could put them directly into your Data-1.13 folder if you want, but sticking them in Profiles means you don't overwrite your "standard" xml files. Also copy the executable into your game folder. That's really all you should need to do. Just make sure your profile is setup and then run the executable.
The patch file is only needed if you want to look at/work with the actual NAS0.7 code. Just pull the latest development code (rev 3936) and apply this patch to that code.

This version of NAS includes the following:
1) AttachmentSlots.xml is used to generate placement of attachment slots but no longer determines valid attachments.
2) There are 128 possible layouts you can create. 2 layouts are predefined in AttachmentSlots.xml.
3) There are 32 possible attachment classes, with 15 already assigned.
4) The code uses Attachments.xml and Launchables.xml to determine valid attachment slots
5) No longer use NASIncompaibleAttachments.xml or ItemSlotAssign.xml
6) Added ubMagSize to Explosives.xml so the code can determine if UGL ammo is single or multi-shot
7) Added NASOnly field to Attachments.xml so certain attachment options will only be valid in NAS
Cool Added nasAttachmentClass and nasLayoutClass to Items.xml. These fields allow the system to know which slots to make available
9) Multi-shot grenades will automatically be converted to single shot grenades when you attempt to load them into a GL.

I believe that's everything. The xml files I've included are just the basics. You can generate your own custom layouts and assign items to those layouts as you chose. But the system shouldn't require you to create custom layouts to run. I've been playing with this code in my test game for awhile now and it's been working just fine. Hopefully you guys won't encounter any problems, but if you do, please let me know so I can address them.

Edit: To use the executable you need the latest updates from the Gamedir folder of the development branch. Specfically, there are a number of LUA scripts that need to be put into the Data\Scripts and Data-1.13\Scripts folders. If you don't have these scripts, starting the program will result in a black screen that never goes anywhere. This isn't a NAS issue, and is resolved as soon as the LUA scripts are installed correctly.

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


Re: New Attachment System Beta[message #267565] Mon, 29 November 2010 23:53 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
I'm getting only a black screen when I try to run NAS 0.7. Both Windows XP and Windows 7. In the latter OS I went as far as doing a clean install from retail JA2 Gold CD, installed Tais latest Vanilla MP-Beta SCi over than, and finally NAS 0.7. Task Manager is still responsive, so after a few minutes I end just program. Tried both the recommended profile location for the folders and DATA-1.13.

[Updated on: Tue, 30 November 2010 00:02] by Moderator



Re: New Attachment System Beta[message #267566] Tue, 30 November 2010 00:05 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
You need the latest updates from the development branch in order to use the executable. Some of the most recent updates included some new LUA scripts. If those scripts aren't in your Scripts folder, you'll get a black screen but no error messages or anything like that. It's not a NAS issues, though. Just LUA updates. Once you have the latest files from the development gamedir, it should work just fine.

Re: New Attachment System Beta[message #267570] Tue, 30 November 2010 00:46 Go to previous messageGo to next message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
Thanks, got the vanilla game to start. Now to see how my projects can break it (most of my comments prior to NAS 0.7 concerned breaking NAS). So far trying to run an unmodified UC-1.13NAS with the .exe causes a CTD.

EDIT: figured it out, I forgot a folder (my end of things)... Right onwards to a prototype UC-1.13 v3

EDIT2: Merc Starting Gear does not seem to be reading properly from the UC-1.13 folder. Found it, more folders being where they shouldn't be again.

EDIT3: Now that I've had some time to see the implementation of NAS 0.7, I'm going to add user friendliness to the list of concerns. Up until I looked at AttachmentSlots.xml, I was thinking there would be a separate XML for layouts and attachment classes. Now I know why you seemed so preoccupied with bit masking. This one is going to take some planning before I can put 0.7 through its paces. Thankfully I happen to still remember binary math, but not every modder is going to...

EDIT4: Several hours later, I've managed to get a rudimentary default gun system working, still needs quite a bit of tweaking but I should be able to test the Folding Stock System within a few hours.

EDIT5: Folding Stock System works though "dummy" attachments will be needed to make the alternate position slot appear. Noticing some inconsistency with slots sometimes listing the slot name instead of valid attachments.

EDIT6: Question about attachments adding attachments and attachment slots - If there is already a valid slot based on attachment class, an attachment meant to add both attachments and slots won't actually add slots?

IE: RIS Scope Rings - an attachment meant to fit to the RIS scope slot, allowing 6x and 10x scopes, and intended to add the "add-on scope" slot. If I fit this attachment to my default optics slot (with bitmask set to allow both scopes and the RIS Scope Rings), the game isn't going to add the "add-on scope" slot due to there already being a valid slot based on bitmask, right? If yes, then I need to create more "dummy" attachments to force slot appearance, or I need to reconsider my all-signing-all-dancing optics slot's bit mask.

Only when at least one of the new slots accommodates something none of the previous slots could will the new slots appear as expected. Based on this I'm leaning towards using "dummy" attachments to enforce slot addition.

[Updated on: Tue, 30 November 2010 07:39] by Moderator



Re: New Attachment System Beta[message #267599] Tue, 30 November 2010 18:16 Go to previous messageGo to next message
ctiberious

 
Messages:607
Registered:March 2007
wil473
EDIT3: Now that I've had some time to see the implementation of NAS 0.7, I'm going to add user friendliness to the list of concerns. Up until I looked at AttachmentSlots.xml, I was thinking there would be a separate XML for layouts and attachment classes. Now I know why you seemed so preoccupied with bit masking. This one is going to take some planning before I can put 0.7 through its paces. Thankfully I happen to still remember binary math, but not every modder is going to...
I'm still hoping I (or someone with more VB experience) can get the xmlEditor updated to help resolve the binary math concern. I knew that was going to be the one difficult aspect. But it also resolves a number of problems, which is why I went ahead and used it. That said, the main reason for using binary math is to allow multiple types of attachments to use the same slot. Currently you can also have an item use multiple layouts, but that really gets complicated as the order in which slots are selected is based on their appearance in AttachmentSlots.xml (specified layout, then default). It might be better if I removed the binary math issue from the LayoutClass and just used basic integers. Would mean you wouldn't be able to have items fit multiple layouts, but it would reduce some of the complexity.
I should also state that by multiple layouts, I'm refering to a single item fitting directly into two or more layouts (i.e., nasLayoutClass = 6 = 2 & 4). With basic intergers instead of binary math, you could still have a weapon pull slots from multiple layouts depending on the attachments being used. You just wouldn't have a single (sans attachments) item fit into multiple layouts. There is also the added advantage that you could have 255 (or more) possible layouts instead of the current 128 limit.

wil473
EDIT5: Folding Stock System works though "dummy" attachments will be needed to make the alternate position slot appear. Noticing some inconsistency with slots sometimes listing the slot name instead of valid attachments.
If an attachment is "hidden" (like the Rod&Spring) then it won't appear in the list. If hidden attachments are the only valid attachments for a slot, then you just get "Attachments" in the tooltip. In the basic game, the only "internal" attachment right now is the Rod&Spring so it never displays valid attachments. You should be able to test this by setting HiddenAttachment=0 for the Rod&Spring item in Items.xml.

wil473
EDIT6: Question about attachments adding attachments and attachment slots - If there is already a valid slot based on attachment class, an attachment meant to add both attachments and slots won't actually add slots?

IE: RIS Scope Rings - an attachment meant to fit to the RIS scope slot, allowing 6x and 10x scopes, and intended to add the "add-on scope" slot. If I fit this attachment to my default optics slot (with bitmask set to allow both scopes and the RIS Scope Rings), the game isn't going to add the "add-on scope" slot due to there already being a valid slot based on bitmask, right? If yes, then I need to create more "dummy" attachments to force slot appearance, or I need to reconsider my all-signing-all-dancing optics slot's bit mask.

Only when at least one of the new slots accommodates something none of the previous slots could will the new slots appear as expected. Based on this I'm leaning towards using "dummy" attachments to enforce slot addition.

The code won't allow two identically numbered slots to appear because of overlap issues. I.E., if the code would allow two identiccally numbered slots, you could put an item in the slot but might never be able to remove it because it could end up at the "bottom" of the stack. This doesn't mean the code won't let you created "stacked" slots (which will cause you problems). It just means it won't let you have two of uiSlotIndex=5 on the same item. In the case of your RIS Scope Rings, I see two options.
Option 1: Have the RIS Scope Rings fit to an external slot instead of the scope slot.
Option 2: Create a LayoutClass for the RIS Scope Rings which has it's own scope slot.
Either option should work just fine, but I'll run a few tests to make sure that Option 2 is working correctly. Technically, so long as two slots have different uiSlotIndex values, you should have no problems having multiple slots that have the same attachmentClass. That's why the default layout (as I set it up) has two "External" slots.

EDIT: Test verified. I went into Items.xml and created a test item with a nasLayoutClass=8 and nasAttachmentClass = 128. I went into AttachmentSlots.xml and created a new layout with the following:
uiSlotIndex = 27
szSlotName = Test Slot
nasAttachmentClass = 128
nasLayoutClass = 8
usDescPanelPosX = 138
usDescPanelPosY = 10
I went into Attachments.xml and made the sniper scope a valid attachment for my test item and made the test item a valid attachment for the M4. The following image shows the successful test.
http://img576.imageshack.us/img576/6384/addedslots.jpg

[Updated on: Tue, 30 November 2010 18:28] by Moderator


Re: New Attachment System Beta[message #267603] Tue, 30 November 2010 19:23 Go to previous messageGo to previous message
Wil473

 
Messages:2820
Registered:September 2004
Location: Canada
For this system, I'd say keep it all bit based math. While I was unsure at the time, I suspected it was bit based instead of integers, and managed last night to build up from a default gun configuration (layout 1) various RIS handguard configurations (layouts 4 and Cool. ie. 5 gives a weapon with an additional side RIS, 9 a weapon with additional top front RIS, 13 a RIS Quad (the underside RIS I'm so far getting away with as part of the default underslung slot). Ironically I'm treating bits like the slots from Warmsteel's NAS (0.6). Only managed to use up 8 layouts so far (1. default gun, 2. Grenades, rest were for attachments adding slots, till I found that I could just add them directly without attachments).

As far as adding slots, I think I was trying to implement Option 2 last night. Worked just fine for the non-RIS scope ring (that adds the reflex mount slot and add-on scope slot since the non-RIS Scope ring fit the primary optics position). There is a bit of contamination from my pre-NAS Attachments (which is what I'm testing with right now). So I'm sure the underlying system is working, and fully expect it to when I get around to flushing the old attachment associations in favour of a new build.

I'm using MS Excel to caculate BitMasks (instead of adding them manually), as well as directly editing Attachmentslots.xml. Seems to be working well enough, and once I figure out possible loadouts, I'll be using Excel to do mass entry of attachments. Real world data -> Excel Spreadsheet -> attachments.xml I find I get cleaner results than doing this from within the XML Editor. However with the NAS 0.6 it was Real World Data -> Excel Spreadsheet -> system of slots (spread across various XML's).

[Updated on: Tue, 30 November 2010 19:41] by Moderator



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


Current Time: Wed Jan 17 03:25:40 EET 2018

Total time taken to generate the page: 0.02049 seconds