Home » MODDING HQ 1.13 » v1.13 Coding Talk » (New) Common Attachment Framework (new title; was The NAS Receiver)
(New) Common Attachment Framework (new title; was The NAS Receiver)[message #303876] Wed, 25 April 2012 01:27 Go to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
So messing around with the XML Editor, one of the things that drives me nuts, and I'm sure must really drive Wil473 and Smeagol insane, is the crazy amount of work that's required to add and maintain attachment consistency across an increasing number of guns and other items.

So I have a quick solution: The NAS Receiver. Common Attachment Framework.

Basically, we add 3 UINT64/128 tags to items.xml:
- nasReceiver AvailableAttachmentPoint
- nasAcceptedReceiver AttachmentPoint
- nasAttachReceiverAPCost AttachToPointAPCost

We can use these in a similar fashion (ie: bitwise operations) to the nasAttachmentClass tag, and simply set the nasReceiver AvailableAttachmentPoint tag on the weapon/base item, and the nasAcceptedReceiver AttachmentPoint tag on the attachment. Then we can set a common AP cost across all base items with nasAttachReceiverAPCost AttachToPointAPCost.

For example:

Say we have the basic Laser Sight attachment. This thing can be attached to every gun in the game. But what a pain in the ass to have to link it to EVERY gun in the game. And it's so much worse in AIMNAS or AFS, where the number of weapons is much, much higher. *Whew* I get tired just thinking about it.

First we need to do some once only setup legwork.

We need to define a list of possible receivers. For this example, I'll keep it simple, but with enough meat so you get the idea:

0    None
1    Pistol Small
2    Pistol Medium
4    Pistol Large
8    Revolver
16   Large Revolver
32   Machine pistol
63   Any Handgun
64   Submachinegun
128  Shotgun
256  Rifle
512  Assault Rifle
1024 Sniper Rifle
2048 Light Machinegun
4095 Any Gun


Now we could add on things like GLs, Rail systems and AK receivers, and so on. But I'll leave that to your imagination for now...

Next we set all the nasReceiver AvailableAttachmentPoint tags on our guns in the XML Editor (using edit mode in the grid, so we can do it quickly).

Now back to our Laser Sight. We set the nasAcceptedReceiver AttachmentPoint tag to 4095 = Any gun. And we're done. We can also go ahead and delete that massive list of entries in Attachments.xml now to make the game go faster. (It would work with Launchables.xml as well)

Any thoughts, comments or concerns? I can probably get this implemented in the next day or two.


Re: The NAS Receiver[message #303877] Wed, 25 April 2012 01:45 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
So you're thinking about a receiver/rail system? Nice one. That would really ease up things.

You've already thought about AK-receivers, so you'd obviously need a distinction for ARs between NATO and AK. Perhaps even more (chinese stuff?). Same for sniper rifles (NATO vs. WP bc of scopes (PSO-3) ).

How would you handle new rail system vs. 'unrailed' guns? I mean, there might be attachments that fit on a M16A4 but do not fit on a M16A1.

Magwell adapters only fit for a specific caliber. How would you handle that?

Foregrips wouldn't make sense on single-shot shotguns, but would be useful on automatic shotguns, so you'd need 2 flags there...

SMGs that already have a built-in silencer won't accept a new one, so you'd need new tags there. This is under the assumption that the silencer effect has been calculated into the weapon stats, if its just a inseparable default attachment than your system is ok.

Don't get me wrong, I like your idea. I guess what I'm saying is that once this gets adopted, people will soon find guns that are in some way distinct, and you'll therefore need a lot of new flags. If you add new flags afterwards, you'll have a ton of work.

[Updated on: Wed, 25 April 2012 01:54] by Moderator



Re: The NAS Receiver[message #303880] Wed, 25 April 2012 02:21 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Exceptions are still possible, and Attachments.xml and Launchables.xml will remain in play. In fact I don't see any way around having that per-item level of flexibility.

My hope with this new approach is to catch maybe 80% of the attachments, and especially those that are common across many items.

Quote:

You've already thought about AK-receivers, so you'd obviously need a distinction for ARs between NATO and AK. Perhaps even more (chinese stuff?). Same for sniper rifles (NATO vs. WP bc of scopes (PSO-3) ).


I'm thinking I can get away with just tags for AK / NATO receivers (in different sizes?) and then OR them with the tags for the weapons.

One possible issue is that I'm not sure if there's ever a case where you'd have a reason to limit the number of attachments. If so, then the bitwise approach is less ideal.

Quote:

How would you handle new rail system vs. 'unrailed' guns? I mean, there might be attachments that fit on a M16A4 but do not fit on a M16A1.


Right, so in this case, we'd see that the M16A1 receiver is "Assault Rifle+NATO" or something, and M16A4 is "Assault Rifle+NATO+RIS".

Quote:

Magwell adapters only fit for a specific caliber. How would you handle that?

Foregrips wouldn't make sense on single-shot shotguns, but would be useful on automatic shotguns, so you'd need 2 flags there...


These are some good examples of exceptions that would require keeping the old structure in place at the same time.


Quote:

SMGs that already have a built-in silencer won't accept a new one, so you'd need new tags there. This is under the assumption that the silencer effect has been calculated into the weapon stats, if its just a inseparable default attachment than your system is ok.


Silencers are an interesting wrinkle, in that they apply to many weapons, but also cannot be applied to all weapons. An extra tag doesn't really cut it here either, since the tags are inclusive rather than exclusive. Might be able to do something in combination with nasAttachmentClass...

Perhaps the approach to take here is to implement a list of attachments that are not compatible with a given item?

Quote:

Don't get me wrong, I like your idea. I guess what I'm saying is that once this gets adopted, people will soon find guns that are in some way distinct, and you'll therefore need a lot of new flags. If you add new flags afterwards, you'll have a ton of work.


Yep - hence keeping the old way too Wink But I do agree that we should nail down a list of initial receiver values as best we can first.

If anyone has any good ideas for an initial set of possible receiver values, feel free to post 'em.


Re: The NAS Receiver[message #303881] Wed, 25 April 2012 02:49 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Madd Mugsy
Exceptions are still possible, and Attachments.xml and Launchables.xml will remain in play. In fact I don't see any way around having that per-item level of flexibility.

My hope with this new approach is to catch maybe 80% of the attachments, and especially those that are common across many items.

Quote:

You've already thought about AK-receivers, so you'd obviously need a distinction for ARs between NATO and AK. Perhaps even more (chinese stuff?). Same for sniper rifles (NATO vs. WP bc of scopes (PSO-3) ).


I'm thinking I can get away with just tags for AK / NATO receivers (in different sizes?) and then OR them with the tags for the weapons.


Not sure how you want to do that. If you want to OR, this still means that once the receiver is correct, the attachment applies. This would mean your receiver tag has to be given to a subset of guns where it always applies.

Madd Mugsy
One possible issue is that I'm not sure if there's ever a case where you'd have a reason to limit the number of attachments. If so, then the bitwise approach is less ideal.

Quote:

How would you handle new rail system vs. 'unrailed' guns? I mean, there might be attachments that fit on a M16A4 but do not fit on a M16A1.


Right, so in this case, we'd see that the M16A1 receiver is "Assault Rifle+NATO" or something, and M16A4 is "Assault Rifle+NATO+RIS".

So a rail-only scope would have the tag "Assault Rifle+NATO+RIS"? Ok, that would work.

Madd Mugsy
Quote:

Magwell adapters only fit for a specific caliber. How would you handle that?

Foregrips wouldn't make sense on single-shot shotguns, but would be useful on automatic shotguns, so you'd need 2 flags there...


These are some good examples of exceptions that would require keeping the old structure in place at the same time.


Quote:

SMGs that already have a built-in silencer won't accept a new one, so you'd need new tags there. This is under the assumption that the silencer effect has been calculated into the weapon stats, if its just a inseparable default attachment than your system is ok.


Silencers are an interesting wrinkle, in that they apply to many weapons, but also cannot be applied to all weapons. An extra tag doesn't really cut it here either, since the tags are inclusive rather than exclusive. Might be able to do something in combination with nasAttachmentClass...


Wouldn't it be possible to give, for example, the MP5SSD the values of an unsilenced MP5 and then make a silencer a default and inseparable attachment? Same result, nobody can alter the silencer, and one less exception.

Madd Mugsy
Perhaps the approach to take here is to implement a list of attachments that are not compatible with a given item?


In that case you will end of with 3 xmls: the receiver-xml, which will do most stuff, Attachments.xml which catches most exceptions, and a new xml for a few exceptions. I do not know if that is easier to maintain.


Re: The NAS Receiver[message #303905] Wed, 25 April 2012 18:40 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3809
Registered:July 2009
Somehow, it looks like this goes back into the direction of the original NAS implementation. With the additional layer between item and attachment.


Re: The NAS Receiver[message #303907] Wed, 25 April 2012 18:51 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
A Quad Rail handguard would cover a large chunk of Attachments.XML. Technically I would suggest two: lite and full length (allows RIS launchers). I was toying with the idea of using NAS' attachments-adding-attachment capability to pull this off. No AR-15 would have RIS attachments that fit the hand guard, instead any AR sold with a RIS Quad would include a RIS Quad Rail as a default attachment.

If you want an idea of how many attachment "families" are possible in-game, take a look at AFS/UC's RIS adapter system. I've got receiver adapters (Optics slot) for most major weapon types, as well as hand guard adapters that add RIS quads or tri-rails (G3 & MP5 adapters). Semi-related is the modular stock attachment system (covers 3 attachments).

One idea would be use a bitmask, and the attachment list is built up from whatever number it represents:

0000001 = RIS optics
0000010 = RSA optics
0000100 = Scope Rings
0001000 = RIS Quad Handguard
0010000 = RIS Tri-rail Handguard

0001001 = weapon that could attach all RIS optics and all RIS Handguard attachments
0010001 = weapon that could attach all RIS optics but only RIS Handguard attachments that fit side and bottom rails

EDIT: on rereading the first post, I think this is what Madd Mugsy was suggesting.

My only concern is that this system still allows attachments to add attachments to the base item.

EDIT2: why is this suddenly looking like the NAS Layout Class XML, we couldn't directly use the NAS Layout Class as it defines what slots appears and where, but in my case at least slot location and attachment usually have a strong correlation. Then again, I went out of my way to try and replicate what I did with NAS 0.6 with NAS 0.7 in my projects... adding to DepressivesBrot's impression that we're replicating NAS 0.6.

One of the nice things about NAS 0.6, was the lack of a large Attachments list. Attachments went into slots and slots were then assigned to guns. The old NAS 0.6 slots act sort of like the Receivers being proposed here just with smaller lists of attachments.

EDIT3:

Summary, is the following how the system will work for BR display of attachments and in-game use:

Total Attachment List = Attachments defined by proposed Receiver System + direct to item in Attachments.XML + attachments-added-by-attachments (can attachments make use of the Receiver System?)

If the above is correct, then I do not see a problem with exceptions like the MP5SD5, as there are options:

1) just divide barrel attachments among muzzle "Receiver types" that can be added together as needed
2) all suppressors attach directly in Attachments.XML
3) exceptions like the MP5SD5 does not use the receiver system and just have attachments directly assigned in Attachments.XML

[Updated on: Wed, 25 April 2012 19:35] by Moderator



Re: The NAS Receiver[message #303910] Wed, 25 April 2012 20:21 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Quote:

Summary, is the following how the system will work for BR display of attachments and in-game use:

Total Attachment List = Attachments defined by proposed Receiver System + direct to item in Attachments.XML + attachments-added-by-attachments (can attachments make use of the Receiver System?)


Yep.

And the attachments themselves can have the nasReceiver tag set on them. When the game looks at an object for its nasReceiver tag, it will also add on any nasReceiver tags set by attachments. This is similar to the way the nasLayoutClass tag works now.

You could have a gun with a "NATO + Assault Rifle" receiver, and add an attachment with a "RIS Tri-Rail" receiver to get a gun with all three receivers.

I'm playing around with this now, using NATO, AK and RIS receiver tags, each broken down into Small, Medium, Large and Sniper values. I've also created tags for most sizes and types of weapons.

My test data looks something like this (including all OR'ed tags):

0	None
1	Pistol Small
2	Pistol Medium
4	Pistol Large
7	Any Pistol
8	Revolver
16	Revolver Large
24	Any Revolver
32	Machine Pistol
39	Any Pistol / Machine Pistol
63	Any Handgun
64	Submachinegun
128	Shotgun
256	Hunting Rifle
512	Assault Rifle
576	Assault Rifle / SMG
1024	Sniper Rifle
2048	Light Machinegun
2624	Assault Rifle / SMG / LMG
4096	WWII Rifle
4352	Hunting / WWII Rifle
8000	Guns - Two Handed (Not Shotguns)
8128	Guns - Two Handed
8148	Guns - Medium-Large
8191	Any Gun
8192	NATO Small
8193	NATO Pistol Small
8194	NATO Pistol Medium
8196	NATO Pistol Large
8200	NATO Revolver
8208	NATO Revolver Large
8224	NATO Machine Pistol
8255	NATO Handgun
16384	NATO Medium
16448	NATO Submachinegun
32768	NATO Large
32896	NATO Shotgun
33024	NATO Hunting Rifle
33280	NATO Assault Rifle
34816	NATO Light Machinegun
36864	NATO WWII Rifle
49152	NATO Medium / Large
65536	AK Small
65537	AK Pistol Small
65538	AK Pistol Medium
65540	AK Pistol Large
65568	AK Machine Pistol
65599	AK Handgun
131072	AK Medium
131136	AK Submachinegun
262144	AK Large
262272	AK Shotgun
262400	AK Hunting Rifle
262656	AK Assault Rifle
264192	AK Light Machinegun
266240	AK WWII Rifle
393216	AK Medium / Large
524288	26.5mm GL
1048576	40mm GL
1048704	40mm GL / Shotgun
2097152	40mm VOG GL
4194304	40mm MS GL
8388608	43mm GL
16777216	37mm GL
33554432	30mm GL
67108864	RIS Bottom
134217728	20mm GL
268435456	25mm GL
536870912	RIS Small
536879105	RIS NATO Pistol Small
536879106	RIS NATO Pistol Medium
536879108	RIS NATO Pistol Large
536879136	RIS NATO Machine Pistol
1073741824	RIS Medium
1073758272	RIS NATO Submachinegun
1073872960	RIS AK Submachinegun
2147483648	RIS Large
2147516544	RIS NATO Shotgun
2147516672	RIS NATO Hunting Rifle
2147516928	RIS NATO Assault Rifle
2147518464	RIS NATO Light Machinegun
2147520512	RIS NATO WWII Rifle
2147746304	RIS AK Assault Rifle
2147749888	RIS AK WWII Rifle
3221225472	RIS Medium / Large
4294967296	NATO Sniper
4294968320	NATO Sniper Rifle
4294972416	NATO WWII Sniper Rifle
4295000064	NATO Large / Sniper
4295001600	NATO DMR Rifle
4295016448	NATO Medium / Large / Sniper
4295024640	NATO Any
8589934592	AK Sniper
8589935616	AK Sniper Rifle
8590196736	AK Large / Sniper
8590198272	AK DMR Rifle
8590327808	AK Medium / Large / Sniper
8590393344	AK Any
17179869184	RIS Sniper
19327352832	RIS Large / Sniper
20401094656	RIS Medium / Large / Sniper
20937965568	RIS Any
21474837504	RIS NATO Sniper Rifle
23622354432	RIS NATO DMR Rifle
24696094720	RIS Medium/Large/Sniper or NATO Large/Sniper
25232990208	RIS Any or NATO Any
25769804800	RIS AK Sniper Rifle
27917551104	RIS AK DMR Rifle
33286291456	Any Large/Sniper (or RIS Medium)
34359738368	HK Receiver
34359754816	HK NATO Submachinegun
34359771648	HK NATO Assault Rifle
34359773184	HK NATO Light Machinegun
35433496640	HK RIS NATO Submachinegun
36507255296	HK RIS NATO Assault Rifle
36507256832	HK RIS NATO Light Machinegun
38654706688	HK NATO Sniper Rifle
38654739968	HK NATO DMR Rifle
55834575872	HK RIS NATO Sniper Rifle
57982092800	HK RIS NATO DMR Rifle


It's probably overkill Razz BTW, I set it to use "Decimal" in the editor and UINT128 in the game so that there are lots of possible tags. Also notice the GL tags -- this approach works for launchers too.

I think we could do muzzle attachments with tags as well, but there gets to be a point where this approach becomes more work than its worth Razz

I'm using a lot of AIMNAS attachments in my testing, and I did manage to get the list of attachments from Attachments.xml for a given gun down by around 75%.

More examples, for those interested:

(These are not going to be 100% accurate to real life)

Attachments
ISM-V-IR Aiming Module    RIS Medium / Large / Sniper
Battle Scope, 7x          RIS Medium/Large/Sniper or NATO Large/Sniper
Reflex Sight              RIS Any or NATO Any (I don't allow these on AK weapons in my games)
Old Aimpoint Projector    HK Receiver
Rifle LAM                 RIS Large / Sniper
Bipod                     Any Large/Sniper (or RIS Medium)
PSO-1 Scope               AK Large / Sniper
Laser Sight               Any Gun
Small Scope, 2x           Guns - Medium-Large
Duckbill                  Shotgun


Guns
Glock 18                  NATO Pistol Medium
Colt Anaconda             NATO Revolver Large
AKS-74                    AK Assault Rifle
Barrett M468              RIS NATO Assault Rifle
HK G36                    HK NATO Assault Rifle
HK G36 RAS                HK RIS NATO Assault Rifle
FN SCAR-H SV              RIS NATO DMR Rifle


I'm still working on adding GLs to the NATO/AK/RIS mix. EDIT: Wow, those were pretty easy actually.

In general, I think this system works best for attachments which have a wide variety of possible receivers, and it isn't worth the headache of setting it up if an attachment only works on a few items.

[Updated on: Wed, 25 April 2012 20:30] by Moderator



Re: The NAS Receiver[message #303918] Wed, 25 April 2012 23:41 Go to previous messageGo to next message
dinglehopper

 
Messages:134
Registered:January 2008
I think you are going in the right direction, and I like where you are headed. But please allow a suggestion.

Why not break it up into three seperate bitmasks. It seems to me like by far most items go ontop of the gun, so everything you would expect to go on top should fall under one bitmask maybe called scopes and lasers or top rail or top mount or whatever. Then take the muzzle and underbarrel as a second bitmask. And finally the magwell trigger group and anything not covered by the first two (rod and spring, etc).

You are sort of doing this already, you just have them all jumbled into one large list that is going to get larger and harder to read. This way, when you add it to the xml editor, which I assume you plan to do, you can seperate it into the three areas to make it more mangable for the modders as well.

Also, you seem to be mostly describing the gun for the attachment (pistol small, nato pistol large, ak sniper, etc) but finding yourself aometimes describing the attachment for the gun (40mm gl, RIS bottom, etc). I would probably switch it to trying to describe the attachment for the gun in all cases. It will make it less confusing and you may find allow you to shrink your list because it will make the bit mapping more usable.

So for example I would do your attachments you have done already more like this with a few added to extend the example;

  
Scopes and Lasers
ISM-V-IR Aiming Module    Scope_RIS_Battle, Laser_Scope_Combo, NATO_All, Scope_All
Battle Scope, 7x          Scope_RIS_Battle, Scope_NATO_Large, Scope_Large, NATO_ALL, Scope_All 
Reflex Sight              Reflex_RIS, Reflex_NATO, NATO_All, Scope_All
Old Aimpoint Projector    HK_Only, Laser_All
Rifle LAM                 Laser_RIS_Large, Laser All, NATO_All, WP_All
PSO-1 Scope               Scope_WP_Large, Scope_WP_Sniper, WP_All, Scope_All
Laser Sight               ATTACHES_TO_ALL (have this be zero in each bitmap, and force it)
Small Scope, 2x           Scope_Small, NATO_All, WP_All, Scope_All

Muzzle and underBarrel
Duckbill                  Shotgun
Bipod                     Bipod_Normal, Bipod_All
Grippod                   Forgrip_Grippod, Bipod_Normal, Forgrip_All, Bipod_All

Magwell and Trigger
9mm drum extender         Magwell_9mm


Then let the guns pick the categories they want to subscribe to.



As for the magwell adaptors, you will just have to make an entry for every caliber (see in example above).

I have to run and didn't really get time to flesh out everything i wanted to say, let me know if you have any questions or you think i am wrong (i can handle that no prob, wife tells me it all the time and we still married). Just wanted to offer a suggestion that may help, thanks for doing this though as i think it will be a great help to the modders.

DH

[Updated on: Wed, 25 April 2012 23:44] by Moderator

Re: The NAS Receiver[message #303929] Thu, 26 April 2012 09:44 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Interesting.... What would an assault rifle's tags look like using this approach?

I must admit I'm not exactly thrilled by the ever extending list. The big reason it's so long is that it includes all the possible OR combinations, as they need to be added to the list in order for them to show up in a dropdown in the XML editor.

I've now implemented my 1st list from above as a proof of concept, and I'm working on a new approach to the list, simplifying and extending where needed. I'm adding default attachments along the way -- they really are critical to keeping this approach simple! As a side perk, default inseparable attachments show you a visual overview of the weapon's abilities at a quick glance in the EDB.

One way to cut down on the list of values and OR'd values would be to display all the tags in checkboxes... you could select the valid checkboxes for each item in its detail form. This becomes more difficult and time consuming to implement, however, as the checkboxes need to be created dynamically to correspond to the list. It is also slower to edit the data, since you could no longer do it in the grid. Making it editable in the grid is one of the things I was shooting for, since it dramatically cuts down the time required to apply the concept to an existing set of data.

The idea of using three fields instead of one gave me pause. I like the idea of shortening the list, but why not use five fields? One each for the top, side, bottom, barrel, and magwell. Why not add one more for the stock to make six? Things could get messy quick... Once I go down the road of having more than one field, I find myself anticipating the need to add a whole new child table. And a child table in this case again means that you won't be able to edit the data quickly in the grid.

Quote:

Also, you seem to be mostly describing the gun for the attachment (pistol small, nato pistol large, ak sniper, etc) but finding yourself aometimes describing the attachment for the gun (40mm gl, RIS bottom, etc). I would probably switch it to trying to describe the attachment for the gun in all cases. It will make it less confusing and you may find allow you to shrink your list because it will make the bit mapping more usable.


Actually, I'm trying to describe all the available receivers on the gun, and then which receiver the attachments fits on. The issue I see with taking the reverse approach is that the guns have so many more attributes to consider than the attachments do. The guns ARE the receivers, so it makes sense to describe them in detail, since they will almost always need to hold more than one type of attachment.

For instance, say a rifle LAM only fits on a large RIS side mount. So in its nasAcceptedReceiver tag it should say, in English for clarity, "RIS Side Mount Large". It doesn't fit anywhere else, so it doesn't need any other values.

However, an assault rifle probably has multiple receivers on it, so it can hold more than one thing. It may contain that large RIS side mount, and it may also contain a large RIS top mount, and a bottom mount for GLs, and it may be able to mount other NATO scopes too. So it would need a nasReceiver tag that looked like "RIS Side Mount Large OR RIS Top Mount Large OR RIS Bottom Mount OR NATO Top Mount Large". We could then condense this tag combination to the more readable "RIS NATO Assault Rifle" value to use in the dropdown in the editor.

And it's combinations like that which are making the list crazy large. So now that I've had a first go at this, I have a better idea of which values can be cut from my list and how to minimize the number of values in the next list.


EDIT: Just had a thought... Question to all .NET devs: I wonder if I could put a combobox in the datagridview that has working checkboxes in it? And then somehow I could combine the resulting text to display it in the grid, and the values back into a bitmask for storage.... This would eliminate the need to store any OR'd values in the lookup table.


Re: The NAS Receiver[message #303930] Thu, 26 April 2012 10:05 Go to previous messageGo to next message
dinglehopper

 
Messages:134
Registered:January 2008
You can do that in java, but I have never tried it in .net before. Still, they are close enough that I bet you can. Have you thought about a tree list with checkboxes? That would make it easier to catagorize the items and they could check main branch to get all the sub branches or the trunk if they just want everything.

Dh

Edit: just remembered in .net it is the treeView class, and I am pretty sure it has checkbox functionality built in.

[Updated on: Thu, 26 April 2012 10:12] by Moderator

Re: The NAS Receiver[message #303932] Thu, 26 April 2012 10:07 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
A single bitmask should be able to accomplish taking that list down further. Again this is based on my own project as it already has various families of guns using adapters to add RIS. Basically if a set of three or more attachments are common to a couple of guns it gets a "receiver":

0	None
1	pistol under barrel rail
2	pistol modular sights - Match, Reflex, Compact Holo Sights
4	RIS Optics
8	Russian Small Arms (RSA) Optics
16	SVD Optics
32	Scope Rings
64	HK Clamp Optics - Aim-Point-Projector, Clamp 4x Scope, RIS rail
128	AR-15 Carrying Handle - optics and a RIS rail
256	Modular Tactical Stock - yes I know one bit isn't going going to be enough for AIMNAS and all its stocks
512	Light RIS Hand Guard - RIS Grips, RIS Bipods, LAM
1024	Medium RIS Hand Guard - above + M203QD
2048	Heavy RIS Hand Guard - above + all RIS Launchers
4096	Top RIS Hand Guard - LAM's and RIS Bipod (weapon hangs from bipod)
8192	AK Hand Guard - Bipod, Grip, GP-30, RIS Handguard
16384	MP5 Hand Guard - Bipod, Grip, RIS Tri-Rail
32768	G3 Hand Guard - above + HK79
65536	M16 Hand Guard - Bipod, Grip, M203, three sizes of RIS Quad
131072	M4 Hand Guard - Bipod, Grip, two sizes of RIS Quad incl. the MWS which allows short barrel M203QD to be attached
262144	Pistol Suppressors
524288	Magnum Suppressors
1048576	Intermediate Cartridge Suppressor
2097152	AK Suppressors
4194304	Hi-Power Ammo Suppressor
8388608	40mm NATO Grenades
16777216	40mm Russian Grenades
33554432	37mm Grenades
67108864	Basic Vest Attachments



With bitmasks the above should be able to cover all the most common attachments. Magazine Adapters I'd think would work better on a case by case basis in Attachments.XML.

EDIT: Examples, and it took a while for me to complete the list...

AK-74 = 8 + 8192 = 8200 (RSA optics, AK Handguard)
AK-107 = 8 + 16 + 8192 = 8216 (Russian/Soviet NV optics mount = RSA + SVD optics)
AK-74 Tactical Stock = 8 + 256 + 8192
M16 = 128 + 256 + 65536 = 65920 (early model M16)
M16A4 = 4 + 256 + 65536 = 65796 (Flat Top M16)
REC7 = 4 + 256 + 2048 = 2308 (comes with Quad RIS handguard)
M4A1 = 4 + 256 + 131072 = 131332 (almost like a Flat Top M16, but it will never allow large launchers to be attached)

The above actually now looks more like ChrisL's NAS 0.7 than Warmsteel's NAS 0.6, either way nesting bundles of attachments.

[Updated on: Thu, 26 April 2012 10:29] by Moderator



Re: The NAS Receiver[message #303933] Thu, 26 April 2012 10:16 Go to previous messageGo to next message
dinglehopper

 
Messages:134
Registered:January 2008
Sounds good. While working on this do me a favor and fix all the guns that take forgrip and bipod but not grippod. If it takes forgrip but no bipod (always because mag gets in way). Then ok, but if it takes both it should take the grippod.
Re: The NAS Receiver[message #303934] Thu, 26 April 2012 11:31 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3809
Registered:July 2009
dinglehopper
Sounds good. While working on this do me a favor and fix all the guns that take forgrip and bipod but not grippod. If it takes forgrip but no bipod (always because mag gets in way). Then ok, but if it takes both it should take the grippod.
Starwalker (the guy who made it so) and others explained this numerous times: The bipod and foregrip use a one size fits all universal mount, the grippod relies solely on a MIL-STD-1913 interface limiting it to newer guns with bottom rail on the handguard.


Re: The NAS Receiver[message #303938] Thu, 26 April 2012 16:17 Go to previous messageGo to next message
dinglehopper

 
Messages:134
Registered:January 2008
Then I need to take starwalker to a gunshow. While that was true for the original grippod, there are now several universal mount grippods on the market.

But this is a hijack of the thread, so I am done talking about it.

It does bring up an interesting point though, why can't we just do this be the different attachment systems like the different rails, universal mount, ak side mount, svd side mount (which takes the smaller ak side mount items as well), threaded barrel, etc?

Dh
Re: The NAS Receiver[message #303939] Thu, 26 April 2012 16:48 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
dinglehopper
It does bring up an interesting point though, why can't we just do this be the different attachment systems like the different rails, universal mount, ak side mount, svd side mount (which takes the smaller ak side mount items as well), threaded barrel, etc?


Take a look at one of my projects, that's more or less the impression I'm trying to do with my NAS implementation. EDIT: Now if you're actually talking about attachments based around how they attach, that was accomplished in NAS 0.6, but this method lacked compatibility with OAS. Once again, look at my projects as I tried to carry on the feel of my original NAS 0.6 modifications into the present day. This "receiver" system looks to be compatible with NAS as all we're doing is trying to figure out a more efficient way to copy attachment lists across similar guns and items.

Which brings up issues with the name of the thread:
1) this isn't/shouldn't be NAS only as we are just figuring out a better way to build attachment lists
2) "receiver" is is kind of misleading, as I originally thought this thread was talking about a way for attachments to change a weapon's calibres without converting the item wholesale (it has been asked for before)

[Updated on: Thu, 26 April 2012 17:05] by Moderator



Re: The NAS Receiver[message #303941] Thu, 26 April 2012 18:11 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Quote:

Which brings up issues with the name of the thread:
1) this isn't/shouldn't be NAS only as we are just figuring out a better way to build attachment lists
2) "receiver" is is kind of misleading, as I originally thought this thread was talking about a way for attachments to change a weapon's calibres without converting the item wholesale (it has been asked for before)


1) Not a big deal codewise, I think. I just need to remove a few checks and it should work in OAS as well.

2) I'm open to a better name for it. I was just thinking of the base items as "receiving" attachments.

I like your simple approach to the list as well. I'm not a gun nut by any measure, so I've probably been building in too many unnecessary values again. I'm going to scrap my 2nd list and try yours instead.


Quote:

Have you thought about a tree list with checkboxes? That would make it easier to catagorize the items and they could check main branch to get all the sub branches or the trunk if they just want everything.


But can I put a tree list in a combobox and a datagridviewcombobox? I'd have to build in an extra field to the table to categorize things, but it could work.




Re: The NAS Receiver[message #303943] Thu, 26 April 2012 18:16 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
How about: (New) Common Attachment Framework

Not sure if New is appropriate, but thrown in for sake of tradition.

EDIT: how many bits is NAS using for layouts? There was concern early in NAS 0.7 discussion about it not being big enough, though in the end between Smeagol and myself we couldn't come up with enough layouts to make this a real world issue. I'm thinking that we shouldn't be able to come up with have more common attachments than NAS layouts, especially as with a bitmask we can build up lists. Probably a good rule of thumb for how the tag is defined.

EDIT2: 2 attachment/receiver classes that were missed in my table last night:

SMG suppressors (Smeagol will need this one)
Shotgun muzzle - forgot about the chokes and in the case of mods, shotgun suppressors


I'm surprised that this wasn't planned to be OAS compatible. Both OAS/NAS use the same Attachments.XML, and if that is cut down for only one of the two systems then that raises the XML overhead (ie. need to support both systems which lead to the whole NAS 0.7 winning out over NAS 0.6 in the end).

[Updated on: Thu, 26 April 2012 19:08] by Moderator



Re: The NAS Receiver[message #303961] Fri, 27 April 2012 09:20 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Quote:
How about: (New) Common Attachment Framework

That title will work Smile 1st post edited.

Quote:
how many bits is NAS using for layouts?


NAS looks like it was supposed to be using 64 unsigned bits, but I noticed it is actually only using 32 signed bits (max value = 2,147,483,647). I'm going to change it to use an unsigned 64 bit integer instead (max value = 18,446,744,073,709,551,615). I've just got a few more places to change it in the code. This is pretty much as big as it can get. Any bigger and it would likely be easier to just implement an alternate solution than to add code for special 128/256 bit integers Razz

In the XML Editor, BTW, these fields are using the Decimal data type, which is the biggest type allowed by VB.NET (max value = +/-79,228,162,514,264,337,593,543,950,335). Apart from Byte and Char, VB doesn't appear to have unsigned integers, so we're stuck with Decimal. Technically, this means you can put decimal points in the field. Expect weird things (rounding, at least) if the game picks up any decimal points....

Quote:

I'm surprised that this wasn't planned to be OAS compatible. Both OAS/NAS use the same Attachments.XML, and if that is cut down for only one of the two systems then that raises the XML overhead (ie. need to support both systems which lead to the whole NAS 0.7 winning out over NAS 0.6 in the end).


Good point. I just pegged this thing initially for a NAS addon since that's where all the action is. I've actually already changed the code (very, very minor changes were required) to make it work with OAS as well.


BTW, using your bitmask list above, I had trouble figuring out where sniper rifles fit in. A sniper rifle should be able to have rails to mount a Rifle LAM, but without some additional differentiation, I ended up with foregrips and GLs on my sniper rifles Razz LMGs face a similar issue.


Re: The NAS Receiver[message #303964] Fri, 27 April 2012 10:32 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3809
Registered:July 2009
Madd Mugsy
Technically, this means you can put decimal points in the field. Expect weird things (rounding, at least) if the game picks up any decimal points....
I checked the doc for the string to int function not long ago. It should treat the decimal point as a terminal condition and just ignore everything from there on. Anyway, just don't set a point Wink
Madd Mugsy
BTW, using your bitmask list above, I had trouble figuring out where sniper rifles fit in. A sniper rifle should be able to have rails to mount a Rifle LAM, but without some additional differentiation, I ended up with foregrips and GLs on my sniper rifles Razz LMGs face a similar issue.
As they are standardized rails, there's no compelling technical reason not to allow them. Who knows, maybe you're out of ammo for the DMR but it's the only platform to use the fancy underbarrel grenade launcher on.


Re: The NAS Receiver[message #303968] Fri, 27 April 2012 10:50 Go to previous messageGo to next message
JMich

 
Messages:575
Registered:January 2011
Location: Greece
Madd Mugsy
Apart from Byte and Char, VB doesn't appear to have unsigned integers, so we're stuck with Decimal.

Long or Int64 for 64-bit Integer, UInt 64 or ULong for 64-bit unsigned Integer, Short or Int16 for 16-bit Integer, UShort or UInt16 for unsigned 16-bit integer, Integer or Int32 for 32-bit Integer and finally UInteger or UInt32 for unsigned 32-bit Integer. No need for decimal, VB.net does have most (if not all) of the needed types.
(New) Common Attachment Framework (new title; was The NAS Receiver)[message #303980] Fri, 27 April 2012 18:19 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
Madd Mugsy
BTW, using your bitmask list above, I had trouble figuring out where sniper rifles fit in. A sniper rifle should be able to have rails to mount a Rifle LAM, but without some additional differentiation, I ended up with foregrips and GLs on my sniper rifles Razz LMGs face a similar issue.


Generic Tac Rail covered DMR = 4 + 4096 = 4100 (RIS Optics + Top RIS Hand Guard)

However, the non-RIS bipods in my mod present a bit of a problem for me. I've got three of the things: Bipod(original Ja2), Integral Bipod, and Heavy (Integral) Bipod. They don't always go into the same NAS slot as the integrals are kept out of the way so that underbarrel slot may still take a grip, RIS hand guard, or grenade launcher. For my purposes weapons that don't have a hand guard RIS of some sort, DMR/LAM/rifles, will just have the bipods assigned in Attachments.XML.

In addition to the two Attachment/receiver bundles I added yesterday, though of two more:

FN FAL Hand Guard - Bipod, Grip, FAL RIS Hand Guard
Misc. Classic Rifle Front End - Bipod, Grip, Universal RIS Block

Updated List:

0	None
1	pistol under barrel rail
2	pistol modular sights - Match, Reflex, Compact Holo Sights
4	RIS Optics
8	Russian Small Arms (RSA) Optics
16	SVD Optics
32	Scope Rings
64	HK Clamp Optics - Aim-Point-Projector, Clamp 4x Scope, RIS rail
128	AR-15 Carrying Handle - optics and a RIS rail
256	Modular Tactical Stock - yes I know one bit isn't going going to be enough for AIMNAS and all its stocks
512	Light RIS Hand Guard - RIS Grips, RIS Bipods, LAM
1024	Medium RIS Hand Guard - above + M203QD
2048	Heavy RIS Hand Guard - above + all RIS Launchers
4096	Top RIS Hand Guard - LAM's and RIS Bipod (weapon hangs from bipod)
8192	AK Hand Guard - Bipod, Grip, GP-30, RIS Handguard
16384	MP5 Hand Guard - Bipod, Grip, RIS Tri-Rail
32768	G3 Hand Guard - above + HK79
65536	M16 Hand Guard - Bipod, Grip, M203, three sizes of RIS Quad
131072	M4 Hand Guard - Bipod, Grip, two sizes of RIS Quad incl. the MWS which allows short barrel M203QD to be attached
262144	Pistol Suppressors
524288	Magnum Suppressors
1048576	Intermediate Cartridge Suppressor
2097152	AK Suppressors
4194304	Hi-Power Ammo Suppressor
8388608	40mm NATO Grenades
16777216	40mm Russian Grenades
33554432	37mm Grenades
67108864	Basic Vest Attachments
134217728	SMG suppressors (Smeagol will need this one)
268435456	Shotgun muzzle - forgot about the chokes and in the case of mods, shotgun suppressors
536870912	FN FAL Hand Guard - Bipod, Grip, FAL RIS Hand Guard
1073741824	Misc. Classic Rifle Front End - Bipod, Grip, Universal RIS Block




Modders will be able to adjust what each bit in the bitmask is used for right? I'm only thinking of examples of common attachment/weapon groups. I have not optimized it by sorting it for frequency of use (most common attachments/weapon groups with lower integers). Then again if there is a user-friendly interface in the XML Editor for setting up these lists, sorting the bitmask becomes a moot point.

EDIT: sorry inadvertently renamed the topic back to the old name. Copied new title from the first post. EDIT2: on closer examination, it looks like we just kept the old name after the change to the first post...

[Updated on: Fri, 27 April 2012 18:33] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #303983] Fri, 27 April 2012 19:26 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Quote:

Long or Int64 for 64-bit Integer, UInt 64 or ULong for 64-bit unsigned Integer, Short or Int16 for 16-bit Integer, UShort or UInt16 for unsigned 16-bit integer, Integer or Int32 for 32-bit Integer and finally UInteger or UInt32 for unsigned 32-bit Integer. No need for decimal, VB.net does have most (if not all) of the needed types.


DOh! Forgot about those new .Net types. I'll change the VB code to use UINT64 then.

Quote:

Modders will be able to adjust what each bit in the bitmask is used for right?


Yes. I'll be providing the AttachmentPoint table in the XML editor, so you can edit it there. The game won't care what the values are, as all it does is compare AvailableAttachmentPoint (old: nasReceiver) with AttachmentPoint (old: nasAcceptedReceiver - note I reversed the tag names a bit there).

Default 1.13 will probably just go out with just a "0 (None)" value in the AttachmentPoint table, at least at first.

I'm also working on a code generator tool, and need to look into fiddling with dropdown checkboxes, but those may come later.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #303988] Fri, 27 April 2012 23:54 Go to previous messageGo to next message
Gambigobilla

 
Messages:718
Registered:July 2008
Maybe we need a couple of custom recievers for better mod compatibilty. Maybe for some future tech sci-fi weaponry. AFAIK Kazuya was working on a fallout mod.
Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #303992] Sat, 28 April 2012 02:46 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Quick update:

The XML Editor changes for this have been pushed out to the SVN (& the GameDir folder), along with the new Drug Type stuff from Flugente.

I still want to test the code again after merging in the Drugs changes to make sure everything is ok, but it should be merged in soon as well.

EDIT: Code merged into trunk. There's still a minor issue of the BR gun tooltips show 2 attachments if an attachment uses both the old and the new method, but I'll fix that soon.

[Updated on: Sat, 28 April 2012 11:46] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #304041] Sun, 29 April 2012 21:46 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
After playing around with this some more I'm rethinking dinglehopper's idea about having more than one list. There are so many different possible combinations that the list becomes unwieldy pretty quickly.

I was thinking we could retain the single list, and single AvailableAttachmentPoint tag within the game, but enable the xmls to contain more than one AvailableAttachmentPoint tag. This would work similarly to the DefaultAttachment tag, and yes it means it's ugly, and not great db design practice, adding extra columns like that, but it'd be easy to add in. All the AvailableAttachmentPoint tags in the item would be OR'd together by the game, and we could have several dropdowns in the editor instead of just one.

I don't think we'd need to apply this to the other AttachmentPoint tag though. Attachments tend to connect to just one or a few places, whereas guns have many available connection points.

EDIT: testing this out now with 10 AvailableAttachmentPoint tags. I also think we can cut down the number of DefaultAttachment tags from 20 to 10... any opposed to that?

EDIT:

Sample picture:
http://dl.dropbox.com/u/76356832/JA2/Editor%20-%20Multiple%20Available%20Attachment%20Points.jpg

In this iteration, I'm just using the CAF for RIS and AK stuff so far. But the additional fields should make adding stocks, barrels and magwells much easier.

Example of attachment granting RIS attachment points:

http://dl.dropbox.com/u/76356832/JA2/Editor%20-%20RIS%20Attachment%201.jpg
http://dl.dropbox.com/u/76356832/JA2/Editor%20-%20RIS%20Attachment%202.jpg

The CAF makes these items much easier Very Happy

[Updated on: Sun, 29 April 2012 22:38] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #304047] Sun, 29 April 2012 23:20 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
Looks good, but I'm a little unclear as to how an Attachment is assigned to multiple attachment points. ie. the "Flash Hider" - which unlike sound suppressors we all seem to only have one of, but can/should be bundled with each of the different sound suppressors.

Also may we have this style of interface used for NAS Layout assignment please. Better to let the XML Editor calculate bit masks than me (several bug were the result of me getting the math wrong).


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #304063] Mon, 30 April 2012 06:11 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
For the Flash Hider, you would just OR the records together for the various barrels. For instance:

[Code]
Pistol barrel. 1
Revolver barrel 2
AR barrel. 4
Sniper barrel. 8
Shotgun barrel. 16
Open barrel. 15 (=1+2+4+8, for flash hider and any other item that would work)
[Code]

Having 10 available fields for AvailableAttachmentPoint doesn't eliminate all the manual OR'ing, but it makes things much simpler.

We do have this interface for the bitmask fields, but it's not currently calculating the values for you.

If you look at the latest XML editor in the svn gamedir, there's a prototype (and hidden from the ui) bitmask combiner tool for CAF that can be accessed by pressing ctrl-shift-alt-a. It just groups records as checkboxes into columns by first name, and then calculates the result of selected checkboxes; after that you can type in a name for the new record and add it to the table with a button press.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305549] Sun, 03 June 2012 14:24 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
I find myself having the need to allow a specific item to have as a possible attachment ANY gun there is (it makes sense, trust me).

However I am not looking forward to having to add approximately ~1k or more entries to Attachment.xml.

Would it be possible to tweak your system in that regard, or is such a thing already possible?


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305557] Sun, 03 June 2012 18:14 Go to previous messageGo to next message
Wil473

 
Messages:2843
Registered:September 2004
Location: Canada
Yes, but it means adjusting the (N)CAF scheme. Yesterday, I spent the first free time I've had in a while redoing the AttachmentPoint.XML to make it do what I want it to do. Specific to what you're trying to do I set ID 1 = common; any attachment that I want to appear on the attachment list for a few hundred guns (laser sight) I set 1 or other odd number.

This means for the laser sight to be present, one of the ten is simply an odd number (or 1 which in my book is odd, but I think mathematically is treated differently).

[Updated on: Sun, 03 June 2012 18:18] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305570] Sun, 03 June 2012 21:58 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
All you need to do really is to add one more 2^X number to the Common Attachment Points grid. It doesn't have to be 1, but that would make sense if you're trying to keep things nice and organized.

Then just open up the Guns grid view and set all values in AttachmentPointX to your new value. (Use the context menu option to do this really fast).

If you've got a bunch set up already and don't want to reorganize, just assign the new value to AttachmentPoint10. If you have existing attachment points set up, this won't interfere with them at all, and the #s are both arbitrary and meaningful at the same time. They are arbitrary in the sense that when you reload your data fresh, ie: if XmlWorkingData is toasted with a new version of the editor, then the AttachmentPoint fields will be pushed together, eliminating any empty space between them. However, the numbers are meaningful in that they provide an order for the points to be created.

This same principle applies to DefaultAttachments, and the order of items there is much more important. For instance, it is possible to have a DefaultAttachment add new attachment slots, and then have a subsequent default attachment use one of them. Of course, the other way around wouldn't work, as the attachment wouldn't have any slots to use yet.

Another CAF approach would be to create entries for each gun type and then just add an additional "Any gun" entry that ORs them together. Then add the "Any gun" point to your attachment and the gun types to the various guns.

But I digress... It's doable now and is pretty easy to do.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305577] Mon, 04 June 2012 01:40 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
To be honest I am not sure about how that works, Mugsy - for example the Common Attachment Points grid is empty...

Could you explain that a bit more detailed? I am not that used to the xml editor...

The idea is that I have an item (an explosive) that until now took no attachments at all. This item should now be able to take any gun as an attachment. However, it may only take one gun at a time.

Edit: Ah, i get it mostly. Just how do I get to take a value for all guns? How do I enter this context menu?

Edit: Ah, found that too. WOW. This is cool. I'd would have taken hours to do this the old way... thank you!!!!!

Edit: Except.. It doesn't work ingame. Hmm. And now the editor complains about some 'uiIndex' that should be unique but isn't...

Edit: Even copying the whole GameDir copy into my game folder doesn't resolve that error. Even though the XMLEditor.exe is a new one. Emm..... now what?

Edit: I added this to the AttachmentPoint.xml:


1
Any Gun



and this to the item and its attachment (a gun) in Items.xml:

1
1
20


However, I can't attach neither of the items. What am I missing?

[Updated on: Mon, 04 June 2012 02:56] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305584] Mon, 04 June 2012 03:52 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
AttachmentPoint.xml is fine, but the item tags are a bit off.

On the attachment add:
1
20


(The "Attachment Data" tab on the item detail form is for the attachment.)

On the base items(s) add:
1


(The "Attachments" tab on the item detail form is for the base item.)

There are 10 possible AvailableAttachmentPoint flags.

Think of AvailableAttachmentPoints like hard points or locations on the gun: the stock, the muzzle, the rails, the hand guard, etc. And think of AttachmentPoint like where the attachment fits.

In your case attachment = gun and base item = explosive. This a little different than usual as the gun is normally the base item, and it could end up being a little buggy... You might also need to create a NAS layout for explosives and some slots, along with a new attachment class. It might result in being able to attach things like laser sights to the explosive when the gun is attached, which would be kind of weird.

You can check out the Experimental\Data-Test folder in my branch for some CAF examples.




Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305593] Mon, 04 June 2012 21:08 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
That is exactly what I had before. However, it just doesn't work. I can neither attach the gun to the explosive, nor the explosive to the gun.

However, when I set a specific gun as an attachment of the explosive in Attachment.xml, it works, altough with the wierd behaviour you described, I can now attach laser sights :headbanger:

Do I have to activate something somewhere in order for this to work?

[Updated on: Mon, 04 June 2012 21:18] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305594] Mon, 04 June 2012 21:57 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Oh, also you may need to set the Attachment tag = 1 for all guns.

If the resulting behaviour is too weird, it might be worth thinking about swapping the logic, so the bomb is attached to the gun instead of the other way around.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305596] Mon, 04 June 2012 22:08 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Hmm. The attachment tag was missing, this did it..

Created a new attachmetn slot, this also works...

However, I still have the problem that i can attach attachments that the gun would have to my explosive... how do I solve that?

Edit: GAH! I can attach two guns to the same slot at the same time. Waht am I missing?

Edit: This is really odd... I attach my pistol to the explosive. Okay. Then I take another firearm and replace the attached on the item. Okay. But:
If I attach a Masterkey (which is also UNDERBARREL attachment) at the item, and then try to attach the pistol, they are both in the same slot. I can then take the pistol away, but not the Masterkey.

[Updated on: Mon, 04 June 2012 22:18] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305602] Tue, 05 June 2012 00:25 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
Yeah, this is the sort of weird behaviour I was thinking might happen. NAS basically works off the assumption that the gun / base item won't be attached to something else. Probably need a decent amount of refactoring of the NAS code to make it work as you intended.

Another alternative that might be slightly easier would be to attach the explosive to the gun, but this will probably mean that you have to rework a bunch of your code too.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305603] Tue, 05 June 2012 00:29 Go to previous messageGo to next message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
The alternative you mentioned (attaching the explosive to the gun) is out of the question. The item still has to work like an explosive, and be able to be planted.

As a workaround, I might simply exclude the Masterkey...


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305604] Tue, 05 June 2012 00:34 Go to previous messageGo to next message
Madd_Mugsy

 
Messages:637
Registered:July 2005
Location: Canada
You'll also still have to contend with user made attachable guns, and maybe underslung GLs too.

You could maybe use a merge to create a new item instead of attaching it? This way all the attachments would just get tossed into the merc's inventory.

Also, attachment merges are seriously underused at the moment. If you go the merge route, try using these instead -- you could make the player duct tape their gun to the explosive.

[Updated on: Tue, 05 June 2012 00:42] by Moderator



Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305605] Tue, 05 June 2012 00:36 Go to previous messageGo to next message
DepressivesBrot

 
Messages:3809
Registered:July 2009
That would mean 3-5 hundred merges Madd.


Re: (New) Common Attachment Framework (new title; was The NAS Receiver)[message #305606] Tue, 05 June 2012 00:38 Go to previous messageGo to previous message
Flugente

 
Messages:3422
Registered:April 2009
Location: Germany
Sry also not possible. Might as well outline why:

I am currently working on tripwire gun traps. The idea is to attach a gun to tripwire, and then plant the wire. When the tripwire gets activated, the gun is fired in the direction that the tripwire was planted, and is then placed on the floor.

This already works, apart from some minor issues. However, I do not want to manually set all firearms to be possible attachments for tripwire.


Previous Topic: New Stealth Mechanics
Next Topic: [IDEA] New Magazine System
Goto Forum:
  


Current Time: Wed Nov 14 21:50:55 EET 2018

Total time taken to generate the page: 0.01305 seconds