Home » MODDING HQ 1.13 » v1.13 Coding Talk » New Attachment System Beta
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266950]
|
Tue, 16 November 2010 12:00  
|
|
| Logisteric |
 |
Messages:3199
Registered:December 2008
Location: B |
|
|
there are single grenades for the gm-94 (4 slots)
edith: of course i'm talking about aimNAS as well
[Updated on: Tue, 16 November 2010 12:30] by Moderator Report message to a moderator
|
Captain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266982]
|
Tue, 16 November 2010 21:32
|
|
| Wil473 |
 |
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Sorry, I think I was dancing around the issue; but if I'm reading the last bit correctly, this means at the very least with New New Attachment System I will no longer be able to define "decorative" grenade slots for "special cases."
ie. my case as already in use
1. all single shot grenade launchers use the same slot (bottom most row, immediately below the slot position always used for grenade launcher attachments) = Grenade Slot 1
2. above grenade slot plust 5 more slots for the 6 shot launchers (forming a 2x3 arrangement below the gun image) = Grenade Slots 2-6
3. OICW has its own grenade slot to indicate bullpup magazine feed (to the right of the gun image) = Grenade Slot 7
4. AICW has three more of its own grenade slots along the top, purely for decoration indicating the real world placement of the Metal storm launcher = Grenade slots 8-10
5. STK Squad Support Weapon has one more to the right of last AICW slot = Grenade slot 11
More of, "perhaps Wil is reading too much between the lines," but your technical description of adding slots seems to indicate a finite number of attachments may add slots. Granted I understand the reasoning for wanting to get one attachment adding slots working before worrying about more; but the way I seem to be reading it, its not just "nested" or "recursive" addition of slots, but total number of attachments that add slots that will be finite for technical reasons.
ie. A RIS Hand Guard and a RIS Optics adapter will take up two of the attachments that may add attachments allowance. And these two are independent of each other unlike my earlier example.
This means that my worse case example of attachments adding attachments needs to be bumped up by one. Some future modder may need more.
Note: unlike Smeagol, I am using attachments to add slots to create RIS equipped "oldie" guns. To get the equivalent of some modern "RIS-everywhere-guns" two independent attachments are needed. One for optics, and one for the handguard.
[Updated on: Tue, 16 November 2010 21:59] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266984]
|
Tue, 16 November 2010 21:39
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Thanks Minty, your example is more real, rather than pure decoration like mine. Which also means that yes right now I could get away with only 6 slots, if I had to....
EDIT: for more information of what NAS features are already in place, this is an example of the current worse case scenario I have implemented:
AK-107 base slots
AK RIS Handguard = adding slots to make up a RIS quad up front
RSA Optics to RIS = adding a RIS optics slot
RIS grenade launcher (generic name) = adding a grenade slot, fits one of the slots added by the AK RIS Handguard
RIS Scope rings w/Reflex mount = adding a slot for sniper scope and a slot for a reflex sight, this one is sitting in the RIS Optics slot added by the RSA Optics to RIS attachment.
So four attachments adding slots, some of them sitting in slots added by previous attachments, others independent.
[Updated on: Tue, 16 November 2010 22:13] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266989]
|
Tue, 16 November 2010 22:48
|
|
 ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
Let's see if I can answer everything.
You have total control over where each slot will appear. If you don't want them on the bottom row like I have them, you can change the x,y coords in the xml file.
You can't have one arrangement for one gun, and another arrangement for another gun. That is the downside of this setup. The counter to this, however, is that you don't have to build a completely new set of xml entries for every weapon that doesn't exactly conform to one of the setups already in the old system. I know this doesn't worry you guys that already have your mods, but I'm thinking it will be a bonus for people trying to write mods. Plus it takes out the concern of whether to make a mod "NAS-only" or not.
The slots in my above examples dynamically created themselves based on the allowable attachments. So in the case of the M16 graphic, if you said that the ISM-V-IR and Reflex Scope were not valid attachments for that weapon, that slot simply wouldn't appear. If you wanted the AICW to support a folding stock (bare with me, I know that weapon really can't support that  ) then you just add the appropriate entry to Attachments.xml and the system would automatically display the stock slot.
As I mentioned, I currently have 6 Grenade slots available. This is hardcoded because we have to tell the code what each attachment class means. That doesn't mean I can't increase that. Right now there is a 21 attachment limit. Because of how I'm handling attachment classes, we can support up to 32. I will code in the other 11 classes before I'm finished and I will alter the hard coded gl limit (currently set to 6). But there still has to be a hard coded limit so we don't try to use an attachment class that is outside of the 32bit range I'm currently using. That said, if you guys seriously think 32 different attachment classes isn't enough, I can alter the flag to a 64bit value but I figured that would be overkill.
When you attach an item, if that attachment itself can have attachments, then the item you attach to can also use those attachments. In other words, you setup a "RIS Hand Guard" that can take a reflex site and "RIS Optics Adapter", and you setup a "RIS Optics Adapter" that can take an ACOG. Then you say that the M1 Garand can fit the "RIS Hand Guard". Without the hand guard, the M1 can't use a reflex sight, ACOG or RISOA. If you fit the hand guard to the M1, you'll now be able to fit the reflex sight and the RISOA. And if you then fit the RISOA, you can fit the ACOG.
 Without any rails
 With "RIS Hand Guard"
 With "RIS Hand Guard and RIS Optics Adapter"
As for removing possible attachments, I haven't figured out a way to do that. Possibly using IncompatibleAttachments.xml would work but I need to test that.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266993]
|
Tue, 16 November 2010 23:18
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Slot layout is generated by the attachments.xml in your NAS? If true, then this is going to force a rethink of how my mod looks at least. Probably going to have to ditch multiple possible slots for an attachment. ie. that refex sight is only going to appear in one slot position on-screen regardless of if it is mounted directly to the weapon, or on a mount built into another scope/sight.
Right now: RIS Handguard - of which there is one for the AK, G3, MP5, FAL and most recently (Mini)Uzi
Adds (generally):
Top RIS slot = accepts all LAMs, RIS bipod
Side RIS slot = accepts all LAMs
Bottom RIS = accepts all LAMs, RIS bipod, RIS Grip, Grippod, FN SCAR grenade launcher, HK AG36 grenade launcher, Metal Storm underslung launcher, bipod(non-RIS), foregrip(non-RIS)
Removes:
non-RIS Grenade launcher slot (HK 79, GP-30)
standalone bipod and foregrip slot(s)
However with how I'm reading things for the new system, the RIS Handguard attachment adds a series of attachments to an items possible attachment list, adding slots as needed. This seems to imply that a standardized system of slots is mandatory.
EDIT:
ChrisL, I know you mean well, but I am still seeing a lot of work for all of us, for questionable return.
EDIT2:
Echoing Smeagol, since inclusion of the existing NAS framework into the Beta-MP code, there has been a bit of "buy-in" with it, especially as it has been very stable (not a slight against Warmsteel, really it is a big comliment that I can say that NAS is very stable, and a statement of my waryiness of "New" features over the years), and has been filled out with extra features. Nesting slots adding slots, wasn't even thought possible till later on in the project, now it is a feature. Same actually with multiple grenades.
[Updated on: Tue, 16 November 2010 23:46] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #266994]
|
Tue, 16 November 2010 23:40
|
|
| Logisteric |
|
Messages:3199
Registered:December 2008
Location: B |
|
|
well, i'm just a stupid maccie, but can anyone (probably the one who wants to change the code) tell me what this is supossed to be good for, besides freeing smeagol and wil 473 from boring weekends?
[Updated on: Tue, 16 November 2010 23:43] by Moderator Report message to a moderator
|
Captain
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #266997]
|
Wed, 17 November 2010 00:48
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Not to talk badly of anything WarmSteel did, but I do like the basics of his code, but the current NAS is overly redundant. As wil said, there are currently two seperate attachment systems in the code. You've got two basially identical IncompatibleAttachments.xml files, each having to be maintained seperately. You have two seperate attachment systems. If you want to add an attachment, you have to either add it to both systems (one place for OAS and potentially dozens of places for NAS) or, like you did, restrict your mod to only a single system. There are seperate functions for each system, because the way we currently look at attachments is completely different.
Yes, for "old timers" it didn't take you too long to setup using the current NAS. But it still took you longer then it should have. You had to adjust the AttachmentSlots.xml and ItemSlotAssign.xml files for each specific weapon. If you add items, you have to go through and make changes to multiple locations unless you choose to ignore one system.
Say I want to add an attachment so the game will allow a Minimi to switch between clips and belts like it should. With the current system I need to add an entry in Items.xml for the item istelf, then I need to add an entry in Attachments.xml so OAS will know which weapons can take this attachment, then I may need to update IncompatibleAttachments.xml if there are any attachments this "adapter" shouldn't go with, then I have to figure out which ItemSlotAssign entries go with the Minimi, make sure those assignments aren't used by any other weapons and possibly create new assignments, then update AttachmentSlots.xml to account for the new "adapter" and update NASIncompatibleAttachments.xml if there are any incompatibilities there. All this could take a significant amount of time, especially if you're a beginner to 1.13.
With the system I'm working on, you simply add the item to Items.xml, then update Attachments.xml and IncompatibleAttachments.xml and you're done. Less then 5 minutes of effort regardless of your experience level.
And that's from a "modders" point of view. From a a developers point of view, any time a change needs to be made to the development system, you have to make twice as many changes. Every change is a risk for a new bug.
And then there's the xml editor which would require significant work to make it compatible with the current version of NAS because we have two completely seperate systems we're trying to work with.
From a modders perspective, the system I'm working on should take less time to setup. Yes, I get it that you guys have already spent the time setting things up but I would hope you aren't the only modders that will every do stuff for 1.13.
From a players perspective, the new system should give more options because modders won't have to choose between OAS, NAS or both when designing their mods. So if a player wants to play UC with OAS, they could. As a player, I don't see why anyone would want to since both NIV and NAS add so much to the game, but the reason we didn't remove OIV (and won't remove OAS) is so that players have an option.
And from a developers standpoint there is less risk of bug fixes causing problems because NAS will sit "on top of" OAS, just like NIV sits "on top of" OIV.
The only real drawback I see so far is that you lose some of the fine control you currently have over how slots appear. I.E., you can't have a completely different layout for every single weapon.
Wil, look at your post. You've got three different "RIS Slots" that "accept all LAMs". Does that mean you'd actually mount 3 LAMs to a gun? Which you actually could do with the system I'm setting up. But other then simply doing it "because you can", would you? I don't think the code would even recognize that you had three attachments that gave the same bonuses.
Anyway, at this point the only thing I can do is finish what I'm doing and let you all look at it. From there I can either "fix" the things you all think are missing or scrap the work I've done and just leave what we currently have in place. Though I would at least hope you'd keep an open mind.
Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #266998]
|
Wed, 17 November 2010 01:05
|
|
| Wil473 |
|
Messages:2815
Registered:September 2004
Location: Canada |
|
|
Nope, at least for LAM's and bipods. One of the reasons for the nearly identical IncompatibleAttachments.xml files, is that the NAS one has definitions making LAM's incompatible with itself as well as other LAM equipped attachments. With OAS there wasn't any reason to worry abut multiples of the same attachment being attached, however with NAS.
Multiple attachments adding together is a recognized feature of Warmsteel's NAS; one that I have yet to use. I was in on the original discussions, because it related to the very example I've noted (all I wanted was multiple legal slots that one could drop a LAM into).
I've already said I will take a look at what you have to offer Chris. To be honest, I've already rebuilt the mod (now mods) to accomodate NAS changes before; however in that last case we had an idea of its benefits (its documented in the thread somewhere, an entire XML was dropped, it had something to do with adding/removing slots I think). I am sorry, but so far it seems we've only discussed loss of capability today.
[Updated on: Wed, 17 November 2010 01:55] by Moderator Report message to a moderator
|
|
|
|
|
| Re: New Attachment System Beta[message #267000]
|
Wed, 17 November 2010 01:57
|
|
| Faithless |
 |
Messages:438
Registered:October 2009
Location: The safe end of the barre... |
|
|
Quote:From a a developers point of view, any time a change needs to be made to the development system, you have to make twice as many changes. Every change is a risk for a new bug. This is something that shouldn't be underestimated, and the main reason I think we should explore this option further.
I also think it fits 1.13 alot more, since it maintains OAS without (too much?) extra effort, ensuring it will always be around.
Your mods have dropped OAS completely, which is fine. But this is unthinkable for 1.13 itself, because it would mean all attachments would have to be defined twice.
I know currently it's a big hassle for the modders that have adapted their mods to NAS, but in the end having a more stable and possibly easier to use system will benefit us all.
It might still not work out the way we had all hoped, but we can always think about merging certain aspect of the two ways Chris and I have tried.
Quote:The only real drawback I see so far is that you lose some of the fine control you currently have over how slots appear. I.E., you can't have a completely different layout for every single weapon. I think this is rather a serious restriction, but maybe it can be fixed by having some xml (probably embedded into some other xml file) to be able to define slots with a different layout than the default based on the item ID (usItem).
I'm also a bit concerned about the limitation of these classes, as while only up to something like 10 will go on one separate item, I could understand there was a need to make "similair" classes for different items.
Quote:Multiple attachments adding together is a recognized feature of Warmsteel's NAS that I have yet to use. Its there, I was in on the original discussions, because it related to the very example I've noted (all I wanted was multiple legal slots that one could go into). Even though NAS does currently support this, it is not perfect by far, mainly because of the same reason Chris mentioned, the game does not *always* know how to handle multiple attachments of the same type.
The reason for this is:Quote:I don't think the code would even recognize that you had three attachments that gave the same bonuses. Some bonuses will take effect, and some won't. It really just depends. This means at the moment it's dangerous to assume everything will work.
I do think this is mainly because the functions that read data from attachments are a bit wacky and are all very specific on how to read certain attachment data.
In this light, they would need an overhaul anyway, but I figured this was another project altogether.
EDIT : one more concern
[Updated on: Wed, 17 November 2010 02:02] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
| Re: New Attachment System Beta[message #267001]
|
Wed, 17 November 2010 02:08
|
|
| smeagol |
|
Messages:2705
Registered:June 2008
Location: Bremen, Germany |
|
|
ChrisLIf you add items, you have to go through and make changes to multiple locations unless you choose to ignore one system.
Well... I ignore OAS, but still have to check several different places when I add new items. I like using the XML editor to add new stuff, but I have to add attachments manually atm. Once you get the hang of it, this isn't such a big deal, though.
Quote:Say I want to add an attachment so the game will allow a Minimi to switch between clips and belts like it should.
Like the idea... now if only more than one default attachment would work with the xml edior ... 
Quote:All this could take a significant amount of time, especially if you're a beginner to 1.13.
Hmm... don't know if the "beginner" argument is really valid. Adding stuff was already difficult when the XML editor was still working properly (item pics spread over three sti files, etc...). For people who want to get into modding it takes quite a bit of time to get used to.
Quote: Less then 5 minutes of effort regardless of your experience level.
Well, for adding one item maybe... but we're talking here about re-configuiring entire item mods with something around 2500 entries to items.xml. I don't say, I disaprove what you intend to do, but I'd like to explain my thoughts on this (though I actually succeeded in chasing away other people by doing this...).
Quote:From a a developers point of view, any time a change needs to be made to the development system, you have to make twice as many changes. Every change is a risk for a new bug.
Yeah, I can see that.
Quote:The only real drawback I see so far is that you lose some of the fine control you currently have over how slots appear. I.E., you can't have a completely different layout for every single weapon.
Exactly. And that fine control was one of the reasons I picked up on NAS rather quickly.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: New Attachment System Beta[message #267044]
|
Wed, 17 November 2010 20:07
|
|
| ctiberious |
|
Messages:605
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. 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.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Nov 30 11:35:46 GMT+2 2024
Total time taken to generate the page: 0.03334 seconds
|
Blog
Search
Help
Members
Register
Login
Home
