Home » MODDING HQ 1.13 » v1.13 Coding Talk » [IDEA] New Magazine System
Re: [IDEA] New Magazine System[message #335489]
||Fri, 05 September 2014 02:36 |
Manual chambering already happens on many shotguns and sniper rifles, so this isn't new (nowadays, might have been in '05).
Ok, i'm not trying to convince you on anything, i am/was just trying to answer your troubled thoughts :
Chambering exists in 1.13, yes, but not exactly in this form, it's a 'between two shots chambering', while in 005 it's a 'reload chambering' (by the way probably flawed cause if you already have a bullet chambered from a previous non-empty mag, you don't need to chamber again). I understand if it's superfluous for you, it's a small detail, but for a gun nuts, it may be enjoyable.
So, just to be clear: You people want a system that adds nothing new, but requires having additional items during reloading, for absolutely no gain? I guess I am asking the same thing over and over, because I just can't grasp it.
The gain (IMO) would be mostly about realism, gun handling, mechanics, you name it.
I personnaly like the idea of having amovible magazines, with different stats (size, weight, reload speed, jam modifier...), that don't appear out of thin air when you deal with the bullets.
It's not an absolute must have feature, but could be nice if reasonnably feasable.
Re: [IDEA] New Magazine System[message #335490]
||Fri, 05 September 2014 02:46 |
Location: Czech Republic
||There is another advantage of NMS I want to point out. With the real guns, you can't just take, for example, M16 magazine, and load it into G36, or... G3 mag into FAL, or others... I guess we can pretend that every merc comes with TactiCool Loading Hammer, that allows you to "fit" the magazine in any gun you want, but it would be really nice if this changed, and every gun would accpet only it's proper mags.
Re: [IDEA] New Magazine System[message #335498]
||Fri, 05 September 2014 10:51 |
||How I see it - raw implementation plan.
For every magazine - define it's type.
Now there are types: normal magazine, ammo box, ammo crate.
Add new type "ammo clip" - it's the magazine that does not go into the gun after loading, but instead it becomes 'empty' and can be put back to inventory.
For every gun - define it's feeding type - list of possible magazine items it can accept and if it can accept ammo firectly from ammo boxes.
Item status data
current chamber state - need to chamber before firing
current loaded magazine item id
should be possible to store zero ammo, or add a flag "empty" that allows magazines with zero ammo (do not destroy this magazine, instead keep it 'empty', just like with canteens)
-Allow empty magazines (like empty canteens)
-When loading magazine into the gun check if this item is allowed
-When loading ammo box check if this gun accepts direct loading, check for RT/turnbased
-Adding ammo to the same type of magazines works as usual
-Add button to "extract" ammo from the magazine/clip
-When the gun is empty, add possibility to "extract" empty magazine of the stored type
-When the magazine loaded into the gun, set the internal "magazine" var to the Id of the loaded magazine
-When the clip loaded into the gun, keep empty clip as a separate item
If the magazine id is already stored in the gun, then "swap" magazines after loading
-Teach AI to chamber rounds before firing (similar to "raising" guns) and maybe more tricks, but generally it should work as usual, as it always starts with loaded magazines. The main difference is that there will be empty magazines in the inventory and some guns require ammo boxes for reloading
-More optional checks and coding tricks
This system should be doable and doesn't seem to be epic work (if compared to other systems like NCTH or NAS/NIV).
I also think this could be made optional and should not break existing things.
Note: this text is mostly guessing, I don't have plans to do such system in near future, and there could be some deep problems I am not aware of.
Note2: this system is limited, it does not support storing (additonal or of different type) round in chamber or things like paired magazines but it should be fine for the most players.
Re: [IDEA] New Magazine System[message #335780]
||Sun, 14 September 2014 20:55 |
Apropos concepts:Well, why not... might remove a bit of confusion. Here it is:
If you don't want to do it, would you at least be willing to write down the concepts for implementation that you indicated you had?
New Magazine System Implementation concept
This concept outlines how to implement a new system that allows to load magazines with single bullets. This also allows mixing ammotypes of the same caliber (without mixing it becomes easier, but even more pointless, so I won't outline that here).
The additional concept to mix different calibers in magazines, and have guns be able to use different calibers without relying on hacky item transformation is outlined in blue.
Barely useful, annoying bullshit that complicates everything but will be asked for by people that want stuff like this is marked in red.
Part 1: Basic Idea
The idea is to have ammo separated from magazines.
A magazine can be stacked with ammo.
A magazine can then be inserted into a gun, where we can see it as an attachment.
[color:#CC0000]There are guns that do not accept a magazine, rather the ammo is transferred to them and then stored in the gun itself (speedloaders).[/color]
The gun then fires the ammo from the magazine, in the order that the ammo was inserted into the magazine.
A gun fires ammo of one caliber.
[color:#3366FF]A gun fires ammo of different calibers.[/color]
A magazine has a maximum number of ammo it can hold.
Different magazines can have different maximum numbers of ammo.
Guns can use different magazines.
A magazine holds ammo of one caliber, but the ammo types (AP, HP, Glaser, Tracer...) can be different for each ammo.
[color:#3366FF]A magazine can hold ammo of different calibers.[/color]
[color:#CC0000]Depending on gun, magazine, tactical/strategic screen, combat/no combat, EDB interface and the cycle of the moon, removing a magazine can leave one bullet in the gun chamber,which the gun can fire.[/color].
Part 2: Magazine and ammo setup
In the current state of JA2 1.13, bullets are always in a magazine (crates and boxes are just magazines that have no fitting gun). Whenever we put a mag in a gun, we then tell the gun 'you have x bullets now'. The mazine object vanishes, but we tell the gun what mag that was. From this it knows the ammotype. When removing the mag, a new object if the same itemnumber as the old mag is created, and we insert the correct number of ammo.
We can no longer do that:
- While the mag is 'in' the gun, we still need to differentiate between ammo in the gun itself and ammo in the mag that is in the gun.
- [color:#CC0000]Magazine modifiers (+/- reliability etc.) require knowing the status of the magazine object.[/color]
- [color:#CC0000]Magazines can have attachments, because let's fuck over the coders or something.[/color]
We create a new structure (pseudocode):
This structure is all that is required to know of a bullet. Having each bullet as an object is a hideous idea. The memory use alone is haunting. If anybody ever advises this, shoot them in the face.
Because of [color:#CC0000]bullets in the gun chamber[/color], both guns and magazines can hold ammo. Strictly speaking, a gun is now simply a magazine that also happens to be able to fire them.
Thus we need to store ammo on objects. Thus OBJECTTYPE need a new member:
Now all objects could store ammo theoretically. We can't use a fixed-size array, as this would blow up all object sizes.
As the size of internalmagazine can vary, OBJECTTYPE saving and loading gets more complicated, so expand these routines accordingly. Reserving space will be especially trickier.
Note that changes to OBJECTTYPE require altering sector loading routines. This also requires different approaches according to map version.
It is very easy to render maps unplayable this way, so be careful in repairing that. Rendering maps permanently unplayable is unacceptable, unless getting your head smashed in with an axe by a guy from Bremen counts as 'acceptable' to you
Upon loading ammo into a mag, create a new MAG_BULLET from the ammo and insert it into internalmagazine.
Upon inserting ammo, check wether there is still room in the magazine, return error if not.
[color:#3366FF]Upon inserting ammo, check wether the caliber fits.[/color]
Magazine items need new data:
UINT16 usCapacity; // how many bullets this magazine can store. Will be 1 for most guns.
[color:#CC0000]BOOLEAN fTransparent; // some mags are see-through[/color]
[color:#3366FF]std::vector<UINT8> possiblecalibers; // calibers this magazine takes[/color]
[color:#CC0000]BOOLEAN fLifo; // FiFo/LiFo extracting of bullets when unloading/chambering[/color]
[color:#CC0000]BOOLEAN speedloader; // if true, magazine contents are transferred to the guns internalmagazine upon loading, the magazine object is not attached[/color]
[color:#CC0000]Modders will come up with guns that take one magazine, but can have other magazines attached to it. You then need to internally store which magazine is decoration and which one you use to take ammo from.[/color]
[color:#CC0000]Modders will come up with guns that feed from multiple magazines at the same time, like some futuristic shotgun that everybody agrees is crap but looks cool. You then need to remove ammo from the mags in an alternating manner, storing which mag you took ammo from last.[/color]
[color:#CC0000]Modders will then come up with the urgent need to have a switch on the gun that toggles which mag ammo is currently taken from. This requires altering the above variable and to create a fuckload of UI for that. Nobody will ever use this, but this will be totally necessary for some reason.[/color]
Calibers need new data:
UINT16 usAPLoadCost; // the cost of loading a single bullet of this caliber into a magazine
UINT16 usWeight; // the weight of a single bullet in grams. Data in Items.xml is in 100g-units, so adjust internal calculations accordingly
BOOLEAN fDirectLoading; // if set to true, a gun#s internalmagazine can also be loaded with bullets by directly loading them into its magazine
[color:#3366FF]UINT16 usPower; // power of the caliber, will be the base of damage calculations[/color]
[color:#3366FF]UINT16 usRange; // base of range calculations[/color]
[color:#3366FF]UINT16 usAccuraccy; // base of accuracy calculations[/color]
Guns need new data:
std::vector<UINT16> acceptedmagazines; // which magazines fit into this gun?
[color:#3366FF]UINT16 usPower; // Combined with the caliber's usPower, calculate bullet damage from this[/color]
[color:#3366FF]UINT16 usRange; // Combined with the caliber's usRange, calculate bullet range from this[/color]
[color:#3366FF]UINT16 usAccuraccy; // Combined with the caliber's usAccuraccy, calculate bullet accuracy from this[/color]
[color:#CC0000]You thought the mag adapters were gone? Silly you Modders will demand more types of adapters:
- Mag adapters on the gun that allow access to other magazines - kinda like the current ones.
- Mag adapters on magazines, that then allow fitting those into guns that previously did not accept them. Have fun solving that, jackass.
- They will demand the ability to attach rubber band, and then a second magazine to that, for quicker reloads. I'm sure you can figure out this one on your own.
Part 3: Loading and firing a gun
Magazines are attachments to guns now. This means there has to be set up in the first place, via Attachments.xml, AttachmentPoints and whatnot. This also means that Old Attachment System people effectively lose one attachment slot. They will complain about that, at which point you say 'F*** you, this requires New Attachment System because I say so' and force this system to require NAS.
Once a mag is attached to the gun, load the first bullet ([color:#CC0000]according to fLifo either from start of end of magazine[/color]) into the guns internal magazine.
[color:#CC0000]Don't do that, instead have the player cycle the gun by firing (similar to shotguns) first. I know, utterly pointless, but people dig that shit.[/color]
Whenever you fire the gun, fire the first bullet from its internalmagazine. If it's empty, and the magazine still has bullets, load from there. Some guns, like shotguns, require a manual cycling.
[color:#3366FF]When firing a bullet, check its caliber and determine damage, range and accuracy.[/color] [color:#6600CC]At this point, nerds would like to add all kinds of NCTH-modifiers to this, but as the only effect to cth calculations is input data, you can easily deflect that.[/color]
[color:#3366FF]Caliber calculation require to come up with the new formulas in the first place, and loads of new data on guns and calibers. Once that is done, one might be able to differentiate caliber types without editing a ton of guns though, so this might be beneficial.[/color]
Part 4: Loading a magazine
Now for the ugly parts. First, we require loose bullets. Create new items - 'a handful of bullets' - for each ammotype and caliber. These serve the same function as crates. But unlike crates, we require them to be very small, so we can store them in our inventory. This is required if you want to load different ammotypes into a mag.
When clicking with a handful on a mag, check wether the ammo would fit the mag. If so, fill up the mag with it (realtime)/ add a single bullet (turnbased), AP cost taken from Caliber data.
Loading different ammotypes works in two ways: Either click on the mag with handfuls and switch them while doing so. You will realize this sucks on your second mag.
What needs to be done is a interface in the magazine's description box. This interface should show you how many bullets, and of what ammotype ([color:#3366FF]and caliber[/color]) are already loaded, and in which order. This has to work for magazine sizes like 200+ too, so add a scrollbar and stuff.
This also needs a huge overview over all fitting ammo in your inventory (or sector inventory). It should list these bullets, and how many there are. Clicking on this deducts one bullet and adds it to the mag. Deducting requires looping over the entire secor inventory in this case to find a bullet object to deduct from, so will be slow if you are not careful.
[color:#CC0000]Of course, we will also want to just grab a bullet from anywhere in the mag and remove it. Have fun setting up that bit with miniature mouse regions and callbacks.[/color]
You need two more buttons on the magazine interface, one for removing one bullet, and one fro removing all bullets. [color:#CC0000]At that point someone will want a button fro 5, 10, 3, 7 etc. bullets.[/color]
Note that magazine weight calculation new depends on the weight of the empty mag and the numbers of bullets and their individual weight, which will vary from caliber to caliber.
Setting up this interface will take a lot more time than everything else combined. Whatever you do, nobody will like how it looks. Nobody will volunteer to draw a replacement.
Clicking with the mag on the gun or the mag attachment slot will replace the magazine item. This is fairly easy. [color:#CC0000]This tedious if you take into account all that multiple-mag nonsense.[/color]
Part 5: Unloading a magazine from a gun
Removing the magazine attachment removes the mag. Clicking on the bullet count does the same. This is fairly easy.
[color:#CC0000]This is very complicated. Players want guns to have a bullet in the chamber. At the same time, they do not want bullets to remain in guns they want to have empty. The question is as to when the chambered bullet should stay, and when it should be removed and added back to the magazine. Use these rules:
- Remove attachment: remove mag, chambered bullet stays.
- Click on gun bullet counter: Remove mag, put mag into inventory, remove chambered bullet, put it into players hand.
- [Shift]+[Alt]+[f]+[whatever key it is today]: Remove mag, put mag into inventory, remove chambered bullet, put it magazine.
- [Some other key combo]: Remove mag, remove bullets from mag, put mag into inventory, put bullets into inventory remove chambered bullet, put it into inventory.
Part 6: What's in a mag?
As magazines now have mixed ammotypes, we have problem indicating their ammo via colour. We could just use the colour of the first bullet, but that changes when firing. Besides, we cannot look into a gun's bullet chamber, can we now?
Solution: All ammo counters are grey now.
New problem: One could look at the magazine description box to find out what loadout you use. How unrealistic! Simply block any indication of ammotype and caliber in that huge interface you created. If players will want to know what a mag has, they have to unload the entire thing, see for themselves, and then load it again. As the ones requesting this are so interested in realism, I am confident they will embrace this mechanic.
Alternatively, use the same mechanic as for the current bullet count: have knowledge depend on wisdom and experience. [color:#CC0000]Transparent mags get a bonus.[/color]
[color:#3366FF]The caliber system allows loading mags with a caliber into a gun that does not accept that caliber. Feel free to add all sorts of catastrophes when one shoots a bullet in this case. Damaging the gun won't be enough, as player's will load the fastest, crappy handgun they can find (PM) with .50 BMG and exploit these powerful one-shot devices. A high chance of injury to the firer shoul put a stop to that.
Provided 2 calibers use the same magazine, you will no longer know which magazine was meant for which gun. Profit![/color]
Part 7: Tend to the AI
Reloading itself shouldn't be a problem to the AI, provided you kept their functions clean. Spawning guns and mags is, however.
AI guns are required to have a magazine (otherwise combat will be kinda dumb). Adjust the object creation functions accordingly - make sure they get one!
Some mags should be standard, others are more advanced and rare to diversify things. Use the first mag a gun can have as the standard for it.
Getting the AI to use different mags requires you altering the drop tables. As there will be more than 50 mags total, increase that table or come up with something smart. Random items might work here, but will likely still have to expand the table once the mods with fucktons of items get their hands on this.
This also requires you to fill the mags with ammo after creating them, so you need to do that too.
[color:#CC0000]People will ask for the AI having less magazines and loading those magazines in combat. Simple.[/color]
You also need to come up with a way to get Bobby Ray and merchants working with this. Just have them sell mags as attachments and ammo as boxes - this won't be hard.
Part 8: Filling out xmls, creating items
After setting up the xmls, you will need to fill them with reasonable data. You will also need those magazines and bullet items, including all those pictures.
Create a post where you explain all this, and give a few examples on how to do this, and ask for volunteers to help you with this. Many people will like this. One or two will volunteer, but will vanish due to real-life issues.
Fill out the data yourself, and create the pictures yourself.
After adding this to the game, people will complain about those values obviously being off. They will offer absurd alternative values which you won't use.
People will not like your pictures. Tell them that these are only placeholders, and you will gladly replace them if they deliver better pictures. This will never happen, and those placeholders will stay in the stock data for the next 5 years.
The only way to get good item pictures is to get a modder interested in this. He will have loads of questions. Explain all this to him. He will draw quality pictures for his mod, which you can then steal for the trunk.
Part 9: Coding
For the love of the dark gods, develop this in a separate branch. NOT in the trunk!!!
Finished features can go into the trunk if they work and are tested.
The trunk is not a code dump.
While coding, comment your code. Explain why you are doing what. Explain the idea of a code bit.
After committing, explain in the pit what this is all about!!!
<font size="]Part 10: Compatibility[/size]
Make this a gamestart option. Switching between old and new system in an ongoing game requires quite a lot of conversions. Not recommended.
[Updated on: Fri, 08 May 2015 20:42]
Re: [IDEA] New Magazine System[message #341971 is a reply to message #341960]
||Wed, 05 August 2015 05:14 |
Location: Oregon, USA
||Flugente wrote on Tue, 04 August 2015 21:11
I have no idea what the russian 005 mod is or what happened there, but there should be enough russians on this forum...
OBJECTTYPE is defined in Item Types.h. Be aware, however, that we don't do a lot of OO code. Also, due to the way we save and load data, creating a new class that inherits from OBJECTTYPE and adds new member variables will create a lot of new, messy problems.
Hrm, well I can probably get away with using the base item class... I will see if I can do without.
As always, you rock, thank you, I haven't looked into the file yet but I am sure it will really help out (though I will need to translate some Russian probably)
Re: [IDEA] New Magazine System[message #342002 is a reply to message #341999]
||Fri, 07 August 2015 11:57 |
Location: Czech Republic
||Before I give you any advice, I want to say that I know pretty much nothing about JA2 code, I only have some C++ knowledge.
ormtnman wrote on Fri, 07 August 2015 06:08
DepressivesBrot wrote on Thu, 06 August 2015 10:34
Taking a quick peek at the lua documentation, tables appear to be their universal, catch-all data structure. Ain't no such thing in C++, you'll have to figure out which functions you need out of your data structure and then pick a fitting one. Though Flug's vectors will probably work.
So no array-like functions with c++? That is surprising...
First of all, they are not functions, functions perform a given task, data are stored in variables, that must have a data type defined. Just to make sure we are talking about the same thing, I don't mean to give you a hard time .
Second of all, that's not what DepressivesBrot said, he said there is no universal data structure, like tables in LUA. There are many data types that can store multiple values at once, each suitable for different purposes. sevenfm already pointed you to the basic one, and I advise you to familiarize yourself with standard template library. Now you have to decide, which data type suits your needs.
Re: [IDEA] New Magazine System[message #342006 is a reply to message #342002]
||Fri, 07 August 2015 15:54 |
Location: Oregon, USA
||Both of you are awesome.
Yeah, I am still stuck in the lua terminology. I did notice what is normally termed "function" under lua was called a boolean. So don't worry about giving me a hard time, I am still new and I am asking obvious questions I could probably google for myself ;)
I'll take a look at that but just to give you all a vague idea of what I am thinking of trying to do is:
Here is the magazine for say an M1911. It is empty. I load a standard ball roumd so now it has a .45ACP round stored as the first round in the mag. I then drop 3 AP rounds, now the mag has 4 stored values: 45ACP AP, 45ACP AP, 45ACP AP, 45ACP. (The left most round would be #1. If you decide to insert this mag into the 1911, it stores the magazine as inserted and copies the stored values for the rounds. However, as a mag fed gun, you need to rack the slide to chamber the round. That action removes the first stored value and moves it to the chamber value. So the chamber would equal 45ACP AP, this would determine the current stats of the gun. The mag now has 45ACP AP, 45ACP AP, 45AP. A round is fired, if it hits it will look at the current stats and deal the damage, then we remove the fired round from the chamber. Because this is auto-chambering when the round is ejected after firing the next in line is inserted. Chamber = 45ACP AP and the mag now has 45ACP AP and 45 ACP. And so on.
Other loading styles like revolvers or others would be handled slightly differently but similarly.
Does this make sense to you more experienced guys?
Re: [IDEA] New Magazine System[message #342009 is a reply to message #342007]
||Fri, 07 August 2015 16:52 |
Location: Oregon, USA
||DepressivesBrot wrote on Fri, 07 August 2015 15:09
ormtnman wrote on Fri, 07 August 2015 14:54
Both of you are awesome.Yeah, I am still stuck in the lua terminology. I did notice what is normally termed "function" under lua was called a boolean. So don't worry about giving me a hard time, I am still new and I am asking obvious questions I could probably google for myself ;)Uhm, no, functions are called functions. What you are talking about is defining a function in the code, for which C++ uses a slightly different syntax than Lua, owing to the fact that Lua is dynamically typed while in the C world you generally have to declare right away what data type a variable holds and which type a function returns.
My words are being taken too literally... I understand how it operates. I'll just get to work now.
Current Time: Mon Jun 25 16:43:54 EEST 2018
Total time taken to generate the page: 0.02396 seconds