Home » MODDING HQ 1.13 » v1.13 Idea Incubation Lab » New Attachment System Alpha
|
Re: New Attachment System Alpha[message #249164]
|
Mon, 12 April 2010 15:19
|
|
pnmartin |
|
Messages:53
Registered:February 2010 |
|
|
DepressivesBrotI think one of the main drawbacks in real life, besides those you mentioned, is quite simply that you have to carry this gun all day long (especially in the military) and everyone will think twice if he takes this additional, cool attachment if he has a bunch of other stuff to hurl around and from what I heard, every kilogram matters under such conditions. It would be hard to simulate this properly without getting serious protests as some people just like to be prepared and load their mercs to the limit (me to). The weight you can carry in game might be realistic from an isolated perspective, but normally you would also have loads of other, not combat related stuff to carry which basically would restrict your mercs to a rifle and a sidearm.
I could also imagine that the weight would make it harder to keep the rifle readied for extended periods of time. Another thing that can't be simulated in game.
This is why I tend to have my team do drop-in assaults by helicopter - seems more realistic to me. A SWAT officer is actually more heavily armed than a long range patrol soldier because he'll get to take it all off in, worst case scenario, a day or so.
[Updated on: Mon, 12 April 2010 15:20] by Moderator Report message to a moderator
|
Corporal
|
|
|
Re: New Attachment System Alpha[message #249188]
|
Mon, 12 April 2010 17:18
|
|
Czert |
|
Messages:105
Registered:August 2007 |
|
|
with new attachment system I dont see any reason for atachments to remain invisible (we have now enough slots), make them visible , but unseperable from weapon.
And this will remove problem for wil743 with non-defined slot for folding stock (wepons which cant have him added will have unremovable factory stock - or call it whatever you like).
Edit: Jup, with invisible attachmenst I meaned eq. build in grenade launcher, reflex sight and others.
[Updated on: Mon, 12 April 2010 21:35] by Moderator Report message to a moderator
|
Sergeant
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #249209]
|
Mon, 12 April 2010 20:09
|
|
Randok |
|
Messages:321
Registered:March 2004 |
|
|
Sent.Save before entering the sector.
[Updated on: Mon, 12 April 2010 21:34] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
Re: New Attachment System Alpha[message #249226]
|
Tue, 13 April 2010 01:16
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Adding attachment slots is going well. I am mostly cutting and pasting existing combinations and adding notation for which entry is for what. I am running into a problem with defining attachments to add and remove attachment slots.
The first definition works fine: Item 50 (GP-30 Grenade Launcher) when attached to Slot 38 (your original for the GP-30) adds Slot 5 (GL Grenade) and removes Slot 29 (Barrel mount for bipod or foregrip)
However, the next attempt led to either no effect or CTD. This was:
Item 540 (UBAR Bridge) when attached to Slot 25 (UBAR pistol mount) is supposed to add the slot I have for a RIS optics rail (50) and remove the match sight mount (23).
In testing when both the add Slot 50 and remove Slot 23 are in the Item 540 attaches to Slot 25 definition, it CTD's when I attach Item 540 to a gun with Slot 25. When just add Slot 50 is set, the slots don't change but I can attach and remove Item 540 without problem.
I was sucessful in replicating my sucess with the GP-30 Grenade launcher. Item 902 (FN GL) when attached to Slot 41 adds Slot 5 (GL Grenade) just fine. Tried setting up another non-grenade launcher attachment to add and remove slots, and got the same CTD when both the add and remove slot entries were present, and no addition of a slot when just the add entry was defined. Item 208 (PSO-1) when attached to slot 52 (SVD Mount) CTD's when this attachment is defined with the add Slot 59 (Korsak-1 LAM mount) and remove Slot 24 (basic LAM mount). No slot is added when just the add slot 59 is part of the attachment definition for attaching item 208 to Slot 52.
Works Perfectly (it seems):
Does not work:
Aside from the variables, they both look identical in format and intent. I'm at a loss to explain why one works but the other does not, except that I can get it working as long as it is the grenade launcher adding the grenade slot.
If you want I can archive and make available what I have done so far (the four NAS XML's in a seperate VFS Data folder, and VFS .ini), the only problem is it requires having the UC-1.13 Hybrid installed to work.
EDIT: tried having a non-GL attachment add the grenade slot, also gives a CTD on attempt to attach the attachment in-game. Same Item 540 into Slot 25, this time adding Slot 5 and removing 23.
EDIT2: Starting a new game does not fix the CTD or lack of effect.
EDIT3: defining just the removal of Slot 23 when Item 540 is in Slot 25 does not CTD, but Slot 23 remains when the item is attached.
EDIT4: Proceeding with adding simple attachment slots, and underslung Grenade Launcher slots that add the Grenade Slot (5), so far have GP-30, FN EGLM, M203, HK79, and AG36 added and working.
[Updated on: Tue, 13 April 2010 07:01] by Moderator Report message to a moderator
|
|
|
|
Re: New Attachment System Alpha[message #249234]
|
Tue, 13 April 2010 15:08
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
On a sidenote: adding grenade slots that way might cause problems when attaching a loaded UGL, have you tried it? (The grenade not properly attaching).
Will look into it later, I'm just testing a conversion for the savegames, so that old ones will still work.
I need this more than I thought, apparently, because some items seem to have been saved version dependently. This caused problem with AIM, for example.
This should be fixed now, but I need to test it before I release it.
[Updated on: Tue, 13 April 2010 15:08] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
Re: New Attachment System Alpha[message #249243]
|
Tue, 13 April 2010 17:11
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
I am getting a repeatable assertion error when I add a loaded grenade launcher and then remove it while it is still loaded. The launchers have Slot 5 so they can be loaded without being attached.
Assertion Failure [Line 2043 in file .\items.cpp]. Attempting to do a debug save as Savegame97.sav (this may fail)
Other combinations seem to work:
- Empty launcher removes ok
- Loaded launcher can be attached, the grenade unloaded first, and then the launcher removed without problems, however it seems the act of attaching a loaded grenade launcher setups the circumstances of the problem which persists.
- Empty launcher attached, and then loaded can be removed with the grenade attached to the launcher. However when it is later reattached and removed again it will crash as long as the round remains attached. It does not matter if I cycle the grenade off and back on the launcher, or remove and replace both.
Aside from the dynamic slots giving problems, everything else seems to be working just fine. Dynamic slots seem to be the most ambitious part of what you are doing here, but then again, that is why I decided try to set some up after less than two days of playing with the XML's. Once the bugs are worked out, it will be a powerful capability indeed. In the Hybrid, it will eliminate a whole series of mergers used to form combined attachments that will no longer be needed.
I am noticing one thing that I'm not sure is intentional or not: Items that can merge with another item, if set to attach to a particular slot will attach in that slot instead of triggering the merger.
What I did: I though it would be nice for the player if I set aside a slot exclusively for the AR-15 Upper conversion mergers. This slot was defined with all AR-15 uppers as possible attachments. In testing, when the merger was attempted with this attachment slot, the AR-15 upper simply attached to the slot. Take the AR-15 to any of the "invalid" slots such as the one for suppressors, and the merger works just fine. In the end, I removed all the AR-15 Uppers from the possible attachments for this slot, and created a dummy "AR-15 Upper Receiver" item which will never appear in-game, but the slot help text lists as the only possible attachment for that slot.
As I said I'm not sure if this behaviour was intentional. It does give the possibility that NAS becomes a sort of pseudo NIV where attachments (which normally would merge with the item) can be stored on an item as an attachment, until it is moved to an "action" slot where the merger is triggered.
[Updated on: Tue, 13 April 2010 17:33] by Moderator Report message to a moderator
|
|
|
|
Re: New Attachment System Alpha[message #249257]
|
Tue, 13 April 2010 20:49
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
I did not really intend people making their own slots for merges, because merges disappear when you try to attach them.
What happens right now is that the game says, oh ok we can attach this item, so it attaches it and stops the function.
It will not look for any possible merges, except combo merges.
I could look into changing this, but it depends.
As for the crashes with grenades slots, it's an assertion error that I put there to locate bugs like this early rather than later (where they become a pain to trace). All I have to do is make sure the slot index gets inited properly. Shouldn't be a hard fix.
Please note, though, that adding a slot and then putting another slot changing attachment in that slot, may cause problems. (the item might be de-attached the next time it loads, depending on which one of the items gets checked first...)
Also it seems I've got old savegames to work, which also fixes Randok's problem.
This problem was caused by items on the maps in AIM apparently not loading properly because they were still stored in the old save format.
The game thought they were stored in the new format, though, because the savegame was up to date
Savegames from version 0.34a will be broken, though. Sorry, can't help it ^^
All other savegames should work with the next version.
Report message to a moderator
|
Master Sergeant
|
|
|
|
Re: New Attachment System Alpha[message #249260]
|
Tue, 13 April 2010 21:47
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Ok, so the item being a valid attachment taking precidence over the merger is intentional. That is good to know, because it has me thinking that once NAS is part of the main (SVN) 1.13 release, I have a new and seeminly better way to do the folding stock thing I have in my mods. As long as it is not a bug to be fixed/changed, it is something that I can use.
Speaking of which, yes my projects do have a very customized set of items. However, if what I am seeing is a bug, and not specific to the UC-Hybrid's items/graphics, then I should be able to replicate it using the standard Data-1.13 items. I'll post something later when I have a chance to setup some add/remove slot based on the XML's that are part of your release Warmsteel.
[Updated on: Tue, 13 April 2010 21:47] by Moderator Report message to a moderator
|
|
|
|
|
|
Re: New Attachment System Alpha[message #249273]
|
Wed, 14 April 2010 00:20
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Using 0.35a now for the two crash tests below:
1) Attaching a loaded launcher to a rifle and then detaching it while still loaded with a grenade from the rifle still always results in an assertion error. Attaching an unloaded GL, then attaching the grenade, still does not lead to an assertion error when the loaded GL is detached from the rifle.
I've also found that defining Slot 5 to the underslung launcher is unnecessary as the grenade can be attached directly to the launcher (unattached to weapon) when there are no slots defined for the launcher item. This saves me a little bit of work (less than a dozen launchers).
2) Replicated the adding/removing slot when attachment is attached bug with NAS' own XML's for DATA-1.13.
- Started a new game before changing the XML's; used Alt-W cheat code to give merc a Dragonov SVD with attached PSO-1; detached the PSO-1 and then saved the game.
- Made the following changes to AttachmentSlotAssign.xml:
52
999
12
25
24
52
1000
12
25
24
Slot 52 takes PSO-1 and PSO-3 scopes
Slot 24 takes Laser Sight and LAM-200
Slot 25 takes Laser Sight, Rifle LAM, LAM-Flashlight, and LAM-200, same 80 by 37 coordinates
- Reloaded savegame where you have an cleared Dragonov SVD and seperate PSO-1 in inventory; attachment of the PSO-1 results in a CTD
- With the modified XML, the game will CTD when in a new game, you Alt-W to the Dragonov SVD (Gun 19), the first occurance of Slot 52 with a default attachment of 999 or 1000.
Next thing I'm going to try is see if the multiple grenade launchers have any problems. These are either standalone launchers or permanetly attached items so to avoid any weirdness, Slot 5 will be part of the rifle natually instead of added by having the launcher attached.
EDIT: Fact checking of Slots 24 and 25 revealed some errors in original post.
EDIT2: No weirdness with the AICW launcher, three shots from one attached "grenade magazine," as expected.
Edit3: Pseudo hidden attachment for the AICW, created a 2nd grenade slot and gave it the same cooridinates as the AICW launcher. The grenade can be added and removed without problem. The graphic for the AICW launcher is visible, but that is easily fixed by adding a blank graphic set. There is a problem, as the crosshatch indicating an invalid attachment slot is visible, misleading the player.
[Updated on: Wed, 14 April 2010 00:59] by Moderator Report message to a moderator
|
|
|
|
|
Re: New Attachment System Alpha[message #249281]
|
Wed, 14 April 2010 02:33
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Yes, confirmed it is working. Testing regime:
1) I have a Laser Sight only slot (Slot 24), 3 different flavours of Russian side mounting (Slots 52-54), and a KORSAK LAM/Laser Sight mount which is supposed to appear only if an optics is attached to the gun (Slot 60)
2) Dragonov SVD has both slots 24 and 52
3) I was able to mount the PSO-1, causing slot 24 to dissappear and 60 to appear; vice versa when removing the PSO-1
4) Attached a Laser Sight which can be fitted to both 24 and 60, and repeatedly attached and detached the PSO-1 causing the Laser Sight to move as expected to the correct slot as it appears.
The only crash I got was when I tried the Grenade Launcher stuff again (sorry, misread your post there).
This is great, it means that I can remove all Combined Scope and Korsak items, the combined ACOG and Reflex scope and the scope on RIS Bridge Rail items; all the mergers associated with creating them, and all the graphics for these combo items.
Report message to a moderator
|
|
|
|
Re: New Attachment System Alpha[message #249400]
|
Fri, 16 April 2010 00:08
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
New version, adding / removing slots should work alot better now.
You can now add lots of them without expecting weird behaviour.
Grenade slots will work fine too now.
One note though: you can only add or remove slots with attachments that go on the unmodified weapon.
I chose this because otherwise it would be horribly complicated, bug prone, and resource consuming (you guessed it, it won't happen in the future either).
Also it's kind of silly to want to do so anyway, in most cases.
[Updated on: Fri, 16 April 2010 00:08] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
Re: New Attachment System Alpha[message #249417]
|
Fri, 16 April 2010 02:58
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Updated to 0.36a
- Confirmed grenade launchers with attached round can be safely removed in the customized XML's I'm working on for a UC-Hybrid mini-mod.
- It looks like your changes now allow the player to choose which slot to use when there are multiple valid slots on the gun.
- Also the changes made have fixed a problem I noticed yesterday where the add slot would only work in conjunction with a remove slot command (the Reflex Scope in RIS slot now adds the Reflex Sight slot).
Mauser, in my testing EDB seems to be working, I haven't seen any glaring errors in the stats related to attaching attachments in NAS.
Before inclusion in the SVN, I would like to see a NAS beta based on the most current source code from the SVN. Just to make sure it is completely compatible before making it permamnet (we all remember how difficult it is to undo things once they are in SVN).
Balance wise, I have not had too many opportunities to make massively tricked out weapons. In fact, for my purposes, I think NAS has given me the opportunity to reduce the number of attachments for several guns. Then again, I haven't gotten to the H&K 416 yet, that one I am anticipating as being the one with the most attachment points. Managed to produce a 7+ kg Barrett REC7 (former 468). Honestly there are just not enough compatible attachments to justify creating more than one "side" rail for the RIS.
EDIT: Yeah, I don't know how to add screenshot...
Direct Link
Edit: Dieter tried to fix the image, sorry, eSnips direct link not showing as pic on board.
[Updated on: Fri, 16 April 2010 07:46] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #249506]
|
Fri, 16 April 2010 21:06
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Yeah, I am seeing some weirdness (and a possible CTD) when I try to attach a second of an already attached attachment onto a gun. At first it was just a graphical glitch when the second occuance of an attachment would not attach on the attempt, but caused the first occurance and its slot became invisible (and unclickable) till another attachment slot was used (either attach or removal). However on a later test of the same scenario, the game CTD, so I thought it best to stop and think through what I'm doing in the XML's
With RIS I treated each slot like an independent RIS rail with minimum differentiation based on function:
- Full Length Optics RIS rail : all RIS scopes and sights, all RIS LAM's
- Short Optics RIS rail : some RIS scopes, all RIS LAM's
- Forward RIS Rail : all RIS LAM's, old laser sight, RIS bipod
- Side RIS Rail : all RIS LAM's, old laser sight
- Lower RIS Rail : RIS foregrip, RIS Bipod, Gripod, all RIS LAM's, grenade launcher (there are multiple variations of this one to accomodate each, none, and combinations of compatible launchers).
Not counting the lower RIS rail/grenade combinations, that is four RIS slots to cover all real world possibilities.
The LAM's and the RIS bipod cause problems with the multiple slots they can be fitted to in real life.
Possible New System
- (Full and Short) Multi rail RIS Optics : All RIS Scopes and sights
- (Full and Short) Solo rail Optics RIS : all RIS scopes and sights, all RIS LAM's
- RIS LAM rail : all RIS LAM's, old laser sight (replaces the stand alone laser sight slot on these guns); used only in cases where there is an excess of rails to allow you to have everything attached)
- RIS Bipod only Rail : only used if it is conceivable to have a LAM, grenade launcher, and RIS (top rail) bipod attached at the same time
- RIS Top/Forward rail: All RIS LAM's, RIS Bipod; used to represent the top forward rail without side rails
- Multi rail Lower RIS/Grenade launcher : RIS foregrip, Gripod, grenade launcher(s)
- Solo rail Lower RIS/Grenade launcher : RIS foregrip, RIS bipod, Gripod, grenade launchers(s); only used if there are no side or top forward RIS.
Once again not counting the lower RIS rail/grenade combinations, seven RIS slots, and think almost twice as many lower RIS/grenade combinations.
Beyond the extra through and XML work, there is another problem, if a gun only has two RIS (top for optics, and bottom forward) the player will either not have the choice of LAM on the top (as it is optics only) and Grenade launcher on the bottom, or both available slots could take the LAM leaving things open for the glitches mentioned at the top.
EDIT: rOckz99 are you using the .ini file that is included with the NAS download, in that did you overwrite the one from the SVN? NAS is not up to date with the reformatted .ini used by the SVN and therefore must use an older format.
EDIT2: the more I think about it, it would probably be better to just have the game be able to handle multiple valid attachment slots on the same gun without CTD or graphical glitches. It is just too easy to create cases where there are multiple valid attachment slots on the same item. Indeed in original JA2 there were four such slots... The only difference between old JA2 and that suggested here is that when you try to attach the second occrance of the attachment, it should go into the new slot that the player is clicking on, emptying the first occurance out of the other/first slot into the players "hand" without graphical glitches.
[Updated on: Fri, 16 April 2010 23:35] by Moderator Report message to a moderator
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #249535]
|
Sat, 17 April 2010 08:27
|
|
dinglehopper |
|
Messages:134
Registered:January 2008 |
|
|
Just wanted to offer a different perspective on the penalties issue.
I think the added weight should effect ready time, as others have suggested. But added weight actually reduces reacquire time as the heavier the gun the less travel there is with recoil, but it is so insignificant (because the weight does make it slightly harder to reacquire as well) we should say this balances out in the wash.
So what does added attachments add? Well, as an avid shooter there are two things I have noticed.
First and foremost, the more attachments you have on the gun the harder it is to maintain it and repair it. Typically removing all the attachments is the first thing you have to do to repair, which in some cases can be burdensome ("now where did I put that Allen wrench that only fits this screw again?"). Along the same lines, I have noticed that the more attachments you put on the gun the more likely you are to have problems with the gun and or one of the attachments. Even something as simple as a bipod causes immense strain on most rifles with every shot, the closer it is to the muzzle the more strain.
Second, You quickly realize when traipsing through the woods with a new hunter who has a new rifle with way more attachments than he needs, that there is no hiding that thing. It has so much added height, reflective surfaces, parts that make noise with every step, and parts with different colors that even the deer spot them coming from miles out and no to get out of dodge. The most successful sniper in history was a Fin who used a Moisin 91 and refused to put anything on it including a scope, he claimed the scope made him far easier to spot since the gun was bigger and he needed to raise his head higher to use it.
In game terms: Each attachment should have a "repair time" modifier and a "degradation" modifier that are both added to not only the gun but every other attachment on it. This way you do get a huge stacking for having a ton of attachments.
Say for example You have a rifle that takes 100 repair units to repair each point of degradation and it has say a 20% chance to degrade 1 point per shot.
Then you have attachment A (call it a scope) that takes itself 75 repair units (optics are not easy) and also has a 20%, but it also has a 5% repair time modifier and a 2% degradation modifier.
Attachment B (say a bipod) only takes 20 repair units and is durable so only has 5% chance to degrade 1 point, but it swings around and adds huge stresses when the gun is fired so it has a 5% repair time modifier and a 5% degradation modifier.
Attachment C (say a folding stock) takes 30 repair units has 5% chance to degrade, but they can be a pain to remove if you need to repair the gun (not really except on AKs, but lets pretend) so a 10% repair time modifier and a modest 3% degradation modifier.
Spelling it out statistically.
Rifle by self ....... 100 to repair .... 20% chance to degrade per shot for rifle
Rifle with just A ... 180 to repair (105 gun + 75 A)
..................... 22% chance to degrade for rifle, 20% for attach A
Rifle with just B ... 125 to repair (105 gun + 20 B)
..................... 25% chance to degrade for rifle, 5% for attach B
Rifle with just C ... 140 to repair (110 gun + 30 C)
..................... 23% chance to degrade for rifle, 5% for attach C
Rifle with A and B .. 215 to repair (110 gun + 80 A + 25 B)
..................... 27% chance to degrade for rifle, 25% for attach A, 7% for attach B
Rifle with A and C .. 235 to repair (115 gun + 85 A + 35 C)
..................... 25% chance to degrade for rifle, 23% for attach A, 7% for attach C
Rifle with A B and C. 285 to repair (120 gun + 90 A + 35 B + 40 C)
..................... 30% chance to degrade for rifle, 28% for A, 10% for B, and 12% for C
So what the above is about: It is not to show how I think the numbers should be used or anything of the sort, nor does it show how it is currently done in game code, as I don't know how it is currently done. It does show that the more attachments you add the more it is going to cost you in repair time due to faster degradation and harder repairs, it is in fact pretty much exponential in its increase when you count the chance to degrade and extra repair time together. So if something like this were implemented you could put a gazillion attachments on, but you would spend days repairing your guns after each fight if you have 8 attachments on every ones guns. Which is realistic really, and should be enough to make people seriously consider their attachment load outs. Also, as a coder (though mostly Java like warmsteel) I would think this wouldn't be too hard to implement in the code, but would require xml work for each attachment unless you just made a table where 1 attachment has x penatlies 2 attachments has y which is greater than x penalties etc.
I also know there is some pretty serious code around sneak and ability to not be spotted, seems like altering this to make it so more attachments means higher chances to be spotted would not be difficult. This would be minor to most players, but combined with increase ready time and increase repair time it might be just enough to make even the most hard core Swiss army gun enthusiast to reconsider if they really need all 8 attachments.
Also, I really think the enemy should get multiple attachments as well, especially in the higher difficulties and with the higher ranked baddies. If I can have a decked out AKM then the queens elite guard should be able to figure out how to deck their guns out with 8 attachments too in expert or insane difficulty games. That alone would balance it.
DH
Report message to a moderator
|
Sergeant
|
|
|
|
|
|
|
Re: New Attachment System Alpha[message #249559]
|
Sat, 17 April 2010 19:04
|
|
Wil473 |
|
Messages:2815
Registered:September 2004 Location: Canada |
|
|
Quote:...because I think it should be possible to have 2 of the same item attached (not often, but sometimes perhaps)
Grenades?
I know you've already said that the launcher framework is an entirely different (and painful) section of code, but a long time ago, before the source code was released, I remember tricking a hex edited JA2.exe into taking two grenades. The gun already had a true built-in launcher (no attachment necessary due to the specific hex editing), but I set it to take the launcher, which when loaded with a grenade attached a 2nd grenade. That being said, pre-source code, I could also trick the .exe into thinking the Talon underslung launcher was a bayonette, this no longer works. It wasn't much use because it meant loosing the launcher attachment. By the time 1.13 rolled around, something stopped it from working (the launcher acting as a knife I mean). Now if you are allowing 2 (can this mean more of two?) of the same, I'm wondering if the current code base can still be tricked into feeding grenades from a second (or more) slot.
[Updated on: Sat, 17 April 2010 19:04] by Moderator Report message to a moderator
|
|
|
|
Pages (12): [ 7 ] |
|
Goto Forum:
Current Time: Fri Mar 29 09:33:21 GMT+2 2024
Total time taken to generate the page: 0.02924 seconds
|