Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Attachment System Beta
| Re: New Attachment System Beta[message #266317]
|
Fri, 05 November 2010 04:59  
|
|
| Wil473 |
 |
Messages:2815
Registered:September 2004
Location: Canada |
|
|
The number of grenade slots I have going is largely for aesthetics, different multi-shot launchers have different configurations of slots.
ChrisL, just to clarify what your objective is, as an example, instead of me having a: "RIS scope slot," "Russian Small Arms Scope Slot," "SVD Scope Slot," "Old Fashion Scope Mount Scope Slot," etc... all which occupy the same coordinates in the interface; there is a single "Middle Top Scope Slot," and attachment control by a combination of checking the old Attachments.xml and the new attachment class = scope (for which the scopes are set with, and the slot set to accept only)?
I'm sorry for being a pain about this because while I accept having two systems is not elegant (though I am still arguing there is less data entry once OAS is ignored*), it is a system that seems to be relatively stable (arguably because it is a separate system); and aside from effort already invested in them**, I see nothing wrong with NAS mostly using its own independent set of XML's.*** I want to know what else you have in mind as far as new features for the proposed Integrated New Attachment System?
* Its just not a matter of me being lazy that the OAS Attachments.xml has not been updated. NAS opened up several possibilities with regards to items, which have led to some item definition choices that are incompatible with OAS. You know about the missing ACOG/Reflex Sight combo. I've also dropped most of the "multi-grenade" single items; only one left is the 20mm OICW magazine, where the depletion system works fine as a "pseudo magazine." Also, I have purged most of the stats responsible for "built-in-attachments" in favour of multiple default inseparable attachments (up to three in some cases).
** My projects happen to be using unintended capabilities of the existing NAS framework (see the new Folding Stock system I have going). While Warmsteel has regularly kept me on notice that progress on NAS may well break them, so far they haven't. Also, please keep in mind that changes being discussed here have ramifications for Smeaglo's mod, the ever growing IoV/CosPlay/DBB mod, and possibly others as well.
*** As an aside, adding new flags to existing XML's has been historically risky to existing mod projects. Just recently we had the introduction of the tags to allow mercstartinggear.XML to allow A.I.M. Mercs to have multiple starting gear. In fact the new tag was compulsory for the inventories of any RPC/NPC to show up. While it was not difficult to work in, it was annoying and time consuming. I even made use of it for other projects, but at the time, it interrupted work on the Urban Chaos hybrid/update, where the idea is still to arrive unarmed (and I'm not going to spend a few hours devising multiple sets of LBE kits to outfit A.I.M. mercs with).
[Updated on: Fri, 05 November 2010 05:34] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #266318]
|
Fri, 05 November 2010 08:17
|
|
 ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
My point is that I don't think we can really "ignore" OAS. That system exists and people will expect it to be fully functional (even if I prefer NAS so far). I also prefer NIV and haven't played OIV since it was integrated into the main source but that doesn't mean I'd suggest "ignoring" OIV either. If we accept that OAS will always exist, at least in the main source code, then the new system should really work with the system we have rather then having two seperate systems. Of course, I may well find that having two seperate systems is the only option and if that's the case, so be it. But as WarmSteel said, if we can keep the features of NAS while building it on OAS, then why not at least try?
And, yes, you're understanding the jist of what I'm looking at. Though I would like to throw in a third set of conditions so that it will be possible to have attachments add attachments (like not allowing grenades without a grenade launcher first, or having RIS rails added to a gun that normally doesn't have them).
And I'm aware of the risks involved in adding new xml flags. I experienced it while writting NIV but that at least means I'm prepared for those sorts of problems.
Anyway, it's a bit early to start worrying about what I'm going to try and do. I've barely begun looking at the code so far. 
Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266333]
|
Fri, 05 November 2010 15:23
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Oh no, I'm not suggesting dropping OAS from the main JA2 system. Only that once certain design choices are embarked on in an items mod, OAS compatibility for that item mod rapidly becomes untenable. See Original posting on these thoughts. Also, take a look at Alrulco Folding Stock when you have a chance, as I said I've done a few things to mitigate rampant slot expansion, then added additional slots to squeeze more capability out of mergers and attachments than was intended.
As it is just preliminary talk, I'll go back to trying to get my current slate of projects (UC-1.13NAS v2.8, and DL-1.13NAS v2) out before this .exe becomes completely irrelevant. Right now I am designing for 0.61B due to some issues with the later Base Code and attachment combo mergers (oh and the UC Campaign ending bug in the code from two weeks ago that I'm still waiting for new on from Rowan).
Wolf00 - if you are trying to fix a NAS 0.61B install (for an ongoing game); try to obtain an old magazines.xml. One before the new .38SPC ammotypes were added. Otherwise, the Beta SCI already contains an implementation of the NAS feature, along with a bunch of other new stuff that must be tested (Carmen Quest, X-Ray Device mergers, new AI...)
[Updated on: Fri, 05 November 2010 15:32] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266362]
|
Fri, 05 November 2010 23:04
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Wolf00 - it doesn't hurt to copy over both, though since I'm suspecting the addition of new ammo causing your difficulties, Data-1.13 being the important one.
ChrisL - this might take a while, so in no particular order, stuff I remember using:
- option to have no attachment slots
- multiple default attachments
- - creation of item, from a merger/use operation, automatically adds inseparable (and only inseparable) default attachments
- context based attachments adding attachment slots (based on at the very least item being/not being an item index or item class, probably more but I need to open up the XML)
- multiple slots on the same weapon that can take an attachment
- option to allow multiples of same attachments being attached (not just grenades)
- two sizes of attachment slots
- fine control over placement of attachment slots (up to being able to place attachment slots inside the Big Image graphic)
- This one is unintentional on Warmsteel's part, but that didn't stop me from exploiting it, if an attachment is set to merge with the item, the merger will not occur if it is clicked on a slot that takes the attachment. This is how my folding stock system (v2) works:
- - Two attachment slots, one only takes the folded stock, other only takes the unfolded stock
- - Item has one of the two stocks set as default attachment (so it appears with it already attached when supplied to enemy, or bought)
- - Movement of the "stock item" from the slot it can attach to the other slot triggers the merger where the stock item may change (and if it is a Machine Pistol so will the base weapon)
- - Once the "stock item" has transformed it will fit the other slot (reverse slots to change back)
- - I am suspecting that this "feature" is dependent on the having the attachment associated directly to the slot instead of the base item. Moving an attachment to an invalid slot causes the merger, but the merger function does not happen when the slot is valid. You may want to see how it works with one of my more recent releases. Prior to NAS, the folding stock procedure was much more complicated and involved clicking in and out of the attachment screen.
- - Also used for dual ammunition feed system for FN Minimi's (one slot makes the LMG a 30rd magazine feed, other 200rd belt feed), Groza weapon system to change the form of the attachment, STK Compact Personal Weapon to change between three calibres, and once I get around to it an adjustable shotgun choke
EDIT: Better description to that last "feature." Essentially NAS inadvertently created a system for pseudeo "transforming" attachments. Something that up until recently has always been denied. Headrock did suggest that a proper implementation of "transforming" items (something that would change on command) was in the cards for some HAM version after 4.0 (New Chance-to-Hit), but who knows how long it will take to work the bugs out of his parallel CtH system (still in closed Alpha). Headrock wanted a "transform" item feature to allow for variable power scopes that worked with the new CtH system.
Personal observations:
- intuitive attachment assignment, I found it easier to consider not what attachments a weapon could take, but instead what type of attachment mounts a weapon had. This is where I got the examples of RIS Scope Mount, SVD Scope Mount, horizontal(side) non-optic RIS, vertical non-optic RIS (top and bottom), etc... From this, I didn't have to consider what attachments fit what weapon, but instead what attachment mounts a weapon had (ie. does it have a RIS Quad hand guard? If yes = Forward RIS, Side RIS, and a Bottom RIS). This then lead to a large amount of repetition and consequently why it all seemed so easy. All AK's have the same basic set of slots, same with your 21st century RIS everywhere rifle.
[Updated on: Sat, 06 November 2010 00:22] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266455]
|
Mon, 08 November 2010 02:52
|
|
| rOckz99 |
 |
Messages:5
Registered:February 2010
Location: The Netherlands |
|
|
hey guys,
couple days ago i for a clean install of JA2 and i patched that with: SCI_SVN1241_MPSVN3752_Vanilla113_20101008
so right now i got more attachement slots just as i wanted, but im kinda missing the detailed info on the gun that i had before. like AP costs and silencer thingie. is it gonna work to run nas0.61c over my current version?
[Updated on: Mon, 08 November 2010 03:32] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266783]
|
Fri, 12 November 2010 22:53
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I'm still a few days from having a working beta ready, but I wanted to update where I was and the changes I've been making.
We will no longer need AlteringAttachments.xml or NASIncompatibleAttachments.xml, and AttachmentSlots.xml will no longer track valid attachments. All it holds now is the coords for the graphic, whether we're needing a big slot, and what class of attachment uses the slot. I'm also adding an attachment class field to Items.xml.
Attachment slots will dynamically change based on not only the weapon/item but also what other attachments are already in place. So, for instance, if you have a weapon that can support a GL, but no GL is attached, you won't see the attachment slot for GL ammo. Once you attach a GL, though, the "grenade" slot automatically appears. This also means that if we add attachments that would alter the kinds of attachments we can normally use, slots will update appropriately. Like, if we added picatiny rails (obviously we'd need an item for this first) to an M1 Garand, we would add the ability to mount whatever the rails could mount, along with the M1's normally attachment possibilities.
As for Wil's list:
- option to have no attachment slots
If an item has no valid attachments, it'll have no attachment slots
- multiple default attachments
I've left the DefaultAttachment field in Items.xml and the code will allow up to 20 of those. Though I still need to test to make sure it works correctly
- - creation of item, from a merger/use operation, automatically adds inseparable (and only inseparable) default attachments
Mergers actually change from one item to another, so the new item (when it's "created") should get whatever DefaultAttachment items it comes with, but I'll have to double check that.
- context based attachments adding attachment slots (based on at the very least item being/not being an item index or item class, probably more but I need to open up the XML)
Done
- multiple slots on the same weapon that can take an attachment
- option to allow multiples of same attachments being attached (not just grenades)
I've got 6 Grenade slots though I'm not positive yet how is the best way to make them work. Everything is based on an attachment class which equates attachments to specific slots. So this capability may not work like it used to. Have to continue testing.
- two sizes of attachment slots
done
- fine control over placement of attachment slots (up to being able to place attachment slots inside the Big Image graphic)
You can still control the coords for the slot graphics, so this is still available.
- This one is unintentional on Warmsteel's part, but that didn't stop me from exploiting it, if an attachment is set to merge with the item, the merger will not occur if it is clicked on a slot that takes the attachment. This is how my folding stock system (v2) works:
Not sure about this one
- - Two attachment slots, one only takes the folded stock, other only takes the unfolded stock
Make the folded and unfolded stocks have different attachment classes, then have a slot for each class.
- - Item has one of the two stocks set as default attachment (so it appears with it already attached when supplied to enemy, or bought)
Should be able to use DefaultAttachment in Items.xml for this
- - Movement of the "stock item" from the slot it can attach to the other slot triggers the merger where the stock item may change (and if it is a Machine Pistol so will the base weapon)
Not sure about this one
- - Once the "stock item" has transformed it will fit the other slot (reverse slots to change back)
Not sure about this one
- - I am suspecting that this "feature" is dependent on the having the attachment associated directly to the slot instead of the base item. Moving an attachment to an invalid slot causes the merger, but the merger function does not happen when the slot is valid. You may want to see how it works with one of my more recent releases. Prior to NAS, the folding stock procedure was much more complicated and involved clicking in and out of the attachment screen.
Not sure about this one
- - Also used for dual ammunition feed system for FN Minimi's (one slot makes the LMG a 30rd magazine feed, other 200rd belt feed), Groza weapon system to change the form of the attachment, STK Compact Personal Weapon to change between three calibres, and once I get around to it an adjustable shotgun choke
I want to make "ammo related attachments" (like the c-mag adapter) no longer inseperable. Instead of being inseperable, you'll simply not be allowed to removed them until you unload the weapon. In this way you'd simply need an adapter for the Minimi to switch it between belt and clip. Could even make a default attachment that makes it belt fed. Then you simply have to unload the weapon, remove the adapter, and you can reload as a clip fed weapon. Still have to work on this, though.
Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #266787]
|
Fri, 12 November 2010 23:14
|
|
| Faithless |
 |
Messages:439
Registered:October 2009
Location: The safe end of the barre... |
|
|
About inseperable ammo attachments, they already unload ammo if the gun can't take the right amount of bullets after detaching or attaching.
You shouldn't have to change that at all.
[Updated on: Fri, 12 November 2010 23:14] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
| Re: New Attachment System Beta[message #266788]
|
Fri, 12 November 2010 23:32
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Question about the 20 multiple default attachments, do they all use multiples of the same tag (as is done now) or are they enumerated?
The occurances of "Not sure about this one" is somewhat worring as it primarily affects the exploit I've been using to base my alternative to that "stock-is-folded-1/3rd-of-the-time" compromise that Starwalker is using for the main v1.13 items. However, I seem to be reading that attachment classes are user definable (which takes away one worry).
Perhaps I should be lobbying harder for transformable items (instead of just reviving my old request thread once every two years).
Also to clarify, you've got 6 grenade slots defined for your test XML's working, or does the proposed replacement system only have 6 grenade slots possible?
EDIT: oh and I forgot, since it looks like you've been sucessful in making the attachment's possible independent of the attachment slot. Does the adding of attachment slots also include the adding of possible attachments. ie. I don't want RIS attachments to show up in Bobby Ray's ond in-game lists of possible attachments for oldie gun X, until you add attachment Y (RIS Handguard).
EDIT2: now that I think about it, if attachments are no longer bound to slots, do you have a way of displaying what attachments will fit a particular slot based on the weapon attachment list and attachment class limits of the slot? And how many attachment classes can I assign to a slot?
EDIT3: Another idea, related to my whining, if not transforming items, how about a "dead" slot? Basically it takes an attachment like any other slot, but the attachment doesn't do anything to the base item's stats. Hell, might as well go for broke, is it feasible for use of a slot to produce the effect of an attachment (I think I asked about this before when I wanted different behaviour out of a C-Mag adapter when it was attached to specific guns). Instead or cumulative with the stat changes of the attachment, the slot contributes stats when occupied.
[Updated on: Sat, 13 November 2010 01:10] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #266796]
|
Sat, 13 November 2010 01:14
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
@WarmSteel: Nice. I hadn't gotten far enough to spot that.
@wil472: It's just the value in Items.xml. The INVTYPE structure has UINT16 defaultattachments[MAX_DEFAULT_ATTACHMENTS] as one of it's elements, wehre "MAX_DEFAULT_ATTACHMENTS" is currently hardcoded to 20. So the system will read up to 20 DefaultAttachment values from the xml file. It's going to read them in order but I'm not sure that an issue anyway.
The "Not sure about this one" mostly means I'm not really in a position to test. Most of these were, as you called them, "unintentional exploits". Meaning they were things NAS wasn't originally designed to include. It just included them by chance. The main development branch (which is the code I'm working from) doesn't include things like the stocks you're using, so I don't currently have the ability to test that. And, for the time being, I'm more concerned about updating the developement branch before I look at things like your stock system. That isn't to say I'm against adding the capability. I just want to get the changes I'm doing to work for the current development code before I start "adding features".
I have 6 slots currently setup as "Grenade" slots (though Grenade1 is also used as a mortar slot). I've got a seperate "Rocket" slot which uses the large slot. The values are all in the xml but I haven't had a chance to test their functionality because I don't have any weapons that can use multiple grenade slots. The only "multi-shot" grenade launchers currently use the "HE Cylinder" ammo (like uiIndex 964). To test that, I'm going to have to modify one of the weapons that uses that ammo. I'll get to that once I have the rest of the code working.
I haven't looked at the BR code yet. But when you look at the Item Description Window, the only attachments that display in the tooltips are those that are currently allowed. So if you don't have an RIS attached, you wouldn't see the option for an "RIS Handguard", using your example.
Examlple: Assume that an RIS attachment would allow your weapon to use an ACOG 4x scope, and you've made the RIS a valid attachment for an M1 Garand (which can't use the ACOG). Without the RIS attachment, you'd see options for the Small, No.32 & Battle scopes. Once you added the RIS, you'd see:
Small Scope
No.32 Scope
Battle Scope
ACOG 4x
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266837]
|
Sun, 14 November 2010 01:27
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
As far as the XML editor, I intend to look at that code once I get the NAS updates completed. But I'm not really a VB programmer which is what the editor is written in so I don't really know how much I'll be able to do. That said, if the editor is setup to recognize the defaultattachment value as an array, then I don't see why it would be a problem. That's how the ja2 code looks at that field right now (though I haven't yet had a chance to play around with it).
Currently the code is setup with a maximum attachments value of 20, though the way I'm writting the code, we could technically have up to 32. Beyond that and we'd need to change the variable I'm using to deal with activating slots. But, honestly, 20 is way more then enough. There's only so much space available in the graphic.
Currently I only have 1 "internal" and 1 "external" attachment slot available. Internal being things like Rod&Spring. External being things like trigger group and rails. I could probably add a second "external" attachment slot, but we're back to the lack of room for the graphics.
As for "Nested Attachments", I'm not sure what you mean. I've already written the code so that it calculates the available attachment slots by:
1- The weapons/item
2- By all attachments currently on the weapon/item
So, by default an AK would not be allowed to mount a 10x scope to it's scope attachment point. But if you add your AK/RIS Optics attachment to the "External" attachment point, the code would automatically know to allow your AK to support a 10x scope. I think if you want to have attachments that fit together to make other attachments, you need to work with merges. There are going to be limits to what the code can handle no matter what we do.
Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266840]
|
Sun, 14 November 2010 03:19
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Well, technically yes. The code can handle that kind of thing because it determines what slots to "activate", and what attachments can use each slot, by the weapon/item and ALL attachments that are attached to it. The catch I have right now is I currently only have 1 "external" attachment point. For your example to work, you'll need 2. I'll look at adding a 2nd, which should work just like the extra grenade slots. I just have to get the code to recognize that both slots are valid for certain items. That shouldn't be impossible, though, since I'm using bitwise math to figure out what can go where. If I make two external slots, one with class=2048 and the other with class=4096, then setting an attachment with a class=6144 should allow it to be marked as valid for both slots. You'd just need to be sure and include any attachments that can fit into more then one slot in the IncompatibleAttachments.xml so that you couldn't attach two at the same time.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 08:20:21 GMT+3 2024
Total time taken to generate the page: 0.06732 seconds
|
Blog
Search
Help
Members
Register
Login
Home
