|
Re: New Attachment System Alpha[message #252673]
|
Sun, 30 May 2010 21:36
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
I finally got around to doing a clean install of JA2 v1.13 and applying NAS 0.42a over it, still getting some random CTD's with Old Attachment System (OAS).
In my latest round of testing I was however able to finish the landing map (A9), follow Fatima to A10, go underground, talk to rebels and hire Ira. This was with clean install of JA2/1.13 from latest SVN/NAS 0.42a and stock NAS settings except for turning off OAS. At this point I decided to start a new game with both OAS and Old Inventory System (OIV), this is where today's CTD's were found:
- first CTD was during IMP creation, selecting a portrait, this CTD could not be recreated
- second CTD was on landing, tried to move a throwing knife from Hitman's second hand to inventory during combat turn. In my original OAS testing, there was a a CTD moving a throwing knife from hand into inventory as well, that time NIV was on.
From what I am seeing, there are some stability concerns with NAS, however I am not sure if this is specific to the NAS code. From the lack of complaints, and my own testing earlier on, NAS 0.42a with NAS on seems stable enough, though legacy bugs do show up. Is there anyone else testing NAS with NAS turned off as requested?
EDIT: Tried NAS 0.42a again, this time with NAS flipped on, no problems completing the first map.
[Updated on: Sun, 30 May 2010 21:53] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #254564]
|
Tue, 22 June 2010 17:07
|
|
Sandro |
|
Messages:420
Registered:November 2008 Location: Mars |
|
|
Hell I understand, I am before similar task, but for the whole STOMP code.
I have one suggestion though: (I haven't read the 9 pages here, so sorry if I repeat something already said..)
Items which are not defined in xmls have 4 attachment slots by default although a lot of them (like magazines) will not likely have any possible attachments to accept. You may write a procedure to determine if in the Attachments.xml is any entry for the item being shown. If there is no, you may show no attachment slots then. It seems somehow weird, that a 9mm magazine has 4 slots and kevlar vest only 2. You may also count the number of entries in Attachments.xml for that item, so if 2 entries would be there, you show 2 slots, etc. up to 4 slots, if at least 4 different attachments exist in the game for this item. This would be only for not defined items in your xmls.
Maybe a cosmetical thing, but still.. it would act more intuitive and clean. I can eventually write such code, but you certainly may want to enjoy the fun with it yourself, no..?
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #255993]
|
Mon, 12 July 2010 01:51
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
silversurfer
I would rather work with an array where you can assign fixed positions (slot numbers).
I haven't been able to solve this problem. That's why I'm stuck.
Yes if you look back I ran into the exact same problem. Converting everything to fixed arrays was one idea, but it wouldn't be ideal either (you would have to always define that maximum array length and fill every slot with "null" attachments [or add a check for null objects in every function that uses them{This line needed more parenthesis}]).
The second solution, and the one I used is also one of the points I'm not all happy about, but it's the best solution I could think of (and still is).
What I did was add null objects to all items, according to the maximum items it can possibly have.
Then when you add an attachment, you replace the null attachment with the one you're about to place.
When removing an attachment, you remove it (no shit) and replace it with another null object.
This means the gun will always have the same amount of items, be it some "null" objects.
This means you can step to any (valid) slot number and it will never be empty, but it is easy to forget adding the null object when working with attachments.
Null objects are a waste of space, also it's sort of a workaround and that's why I'm not 100% happy with it.
On a sidenote, my summer holidays have just started and that means I will have some time to spare (for now).
I have no problem sharing the code with individuals, as long as they don't just want to blindly copy it into the main source.
I would like to propose that we discuss each others work, and choose the best of both worlds.
Perhaps on IRC?
[Updated on: Mon, 12 July 2010 01:53] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
Re: New Attachment System Alpha[message #255996]
|
Mon, 12 July 2010 03:58
|
|
silversurfer |
|
Messages:2793
Registered:May 2009 |
|
|
WarmSteel
Yes if you look back I ran into the exact same problem. Converting everything to fixed arrays was one idea, but it wouldn't be ideal either (you would have to always define that maximum array length and fill every slot with "null" attachments [or add a check for null objects in every function that uses them{This line needed more parenthesis}]).
The second solution, and the one I used is also one of the points I'm not all happy about, but it's the best solution I could think of (and still is).
What I did was add null objects to all items, according to the maximum items it can possibly have.
Then when you add an attachment, you replace the null attachment with the one you're about to place.
When removing an attachment, you remove it (no shit) and replace it with another null object.
This means the gun will always have the same amount of items, be it some "null" objects.
This means you can step to any (valid) slot number and it will never be empty, but it is easy to forget adding the null object when working with attachments.
Null objects are a waste of space, also it's sort of a workaround and that's why I'm not 100% happy with it.
Now my head hurts. :crazy:
I think I'm too much of a programming noob to fully understand that. Well, I somewhat understand the theory but practice is another matter.
Meanwhile I tried to solve the problem in a different approach. Before I display an attachment I check for its slot number and set the display area and mouse region according to that. That way it doesn't matter at which position in the list the attachment is located. I'm still working on this and will probably encounter problems later.
WarmSteel
On a sidenote, my summer holidays have just started and that means I will have some time to spare (for now).
Hey that's good to hear! Maybe you can work a bit on the code. Sandro is trying to implement STOMP into SVN at the moment. HAM+STOMP+NAS+WF - all in one package some day - that would be cool!
WarmSteel
I have no problem sharing the code with individuals, as long as they don't just want to blindly copy it into the main source.
I would like to propose that we discuss each others work, and choose the best of both worlds.
Perhaps on IRC?
I never used IRC before. Gotta look how to set it up and download a client.
I still don't understand a few things that you did especially the XMLs:
AttachmentSlotAssign.xml is clear - that's where you assign an attachment to a certain slot. I used "AttachmentInfo.xml" for that as it already has info about what category of item an attachment can go to. It was the most logical place for me to put the slot numbers into.
AttachmentSlots.xml - Looks like you define the slot positions and names there. I only defined the position of a slot once (in Tactical\Interface Enhanced.cpp) and try to create the name dynamically but I still have to finish that.
EnemyItemChoices.xml - It's almost the same as the standard one. Why the change?
ItemSlotAssign.xml - Looks like the file where you define which slots a weapon will have. I was thinking of creating this dynamically. It would be better for future modifications. Lots of XMLs lead to lots of errors.
NASIncompatibleAttachments.xml - I don't really see the need for this file because the game already checks for incompatible attachments. Is there something I am missing?
Gotta get some sleep now...
Report message to a moderator
|
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #256021]
|
Mon, 12 July 2010 15:34
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
And what if an item is weird and excludes multiple things that go in completely different slots?
[Updated on: Mon, 12 July 2010 15:34] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|