is it more logical to "leave a mess" because its 14 custom maps then? because i hate agreeing with trump but ctrl+f is a thing that exists
I will chime in and say that the order you put weapons in the vehicle_weapons script is also how they appear in game in the vf menu. So you do end up with the situation of say adding a new mg and it's completely separate from the rest of the mgs. Those scroll bars are super detrimental to showing people that new weapons exist. That said I have never found it hard to keep track of where things are in the scripts, even after adding in 50 of them. Try adding comments into the script files to help keep track, or put the new ones in the same order they'd be in normally, as in mgs first cannons second and so on. There's a bunch of ways of not getting lost honestly.
The existence of Ctrl+F doesn't justify making a mess. Also it's extremely convenient for me if 2-slot/3-slot weapons are right next to each other. Yeah I didn't even include this reason, and I think this reason alone is enough to tell the maps to fuck off, until we finally implement "weapon id". Don't get me wrong, our current script file is very easy to work with, it does follow the order of MG/CN/Arty/ML/GL.
Well, yes, mapper, coder, creeper. I think it's best for me to not do anything for this issue, there's nothing much I can do anyway.
woa... f***... seriously?! the game/engine (i bet it's the gamecode, who even came to that idea to put them in freaking .txt files instead of propper scripts???) recognizes entry's by order and the item names are just decoration or what? xP makes me really sad, tough that explains why they worked strange... but makes me really unwanted to look back at balancing again if it is really that stupid, hope the devs switch to today's common id/name identifyer system in the "near" future tough i can only talk about that from a modders POV, i'm still learning C++! (i'm not that far in progress to understand how definitions/values get outsourced to other file formats!)
Just giving my 2 cents as a programmer: The fgd currently lists all vehicle data as lists of indices with pretty names for Hammer. You can just change that to using actual strings for all data, and parse the string as an index in the code for backwards compatibility. Something like this: Code: char* pszEnd = nullptr; long iIndex = strtol( pszValue, &pszEnd, 10 ); if( pszEnd != pszValue ) { //pszValue was a number, treat as old index value into list of engines/weapons/whatever } else { //pszValue was an item name, do whatever you do in the game's code with it. } strtol sets pszEnd to pszValue if nothing could be parsed, verified by checking VS2012 implementation of strtol. I looked up the code that deals with the weaponType1 keyvalues using IDA, seems to be a DEFINE_KEYFIELD entry so there wasn't much to see. I'm guessing the code for emp_vehicle internally stores indices to weapons. Efficient, but hard to prevent backward compatibility problems. For examples on how you can use strings to look up indices, you can take a look at this SDK code: https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/shared/weapon_parse.cpp There are several examples, both returning the index of a string in a list and mapping strings to constants that aren't tied to list indices.
Came across this seeing if things are changing, and when I was scripting weapons for Vipers testing, I could not understand why an actual index id wasn't being used, but only inferred from the ordering of the script aka text database, which is what it truly is. So here is my suggestion, and it really should be simple to implement, and would never break any custom map at any time in the future, which is the end goal here. implement a strict index numbering system, a 3 digit number should suffice for any future expansions. Make lets say, MG classes 1xx, Missile classes 2xx, Cannon classes 3xx, and misc aka Grenade classes 4xx. This structure should leave room for 100 weapon types for each class. You could also possibly implement sub class structuring, but this would limit sub classes to only 10 weapons per subclass. like HE type cannons, would be in the range of 31x, i.e. 310 he cannon, 311 he arty shell, etc. Then it wouldn't matter the order of the data entered, only that no index was used more than once. Then, when populating the weapons in the VF arming view, a simple routine to list all 1xx, then 2xx, then 3xx, and finally 4xx. Order would always be maintained from reading the index ids, instead of accidentally moving a position in the file and breaking everything.
@DocRabbit The devs have seriously discussed this, and it's on our to-do list. The problem is.... All the maps follow the current method. So we'll have to recompile every map that has restrictions. And we don't have all the source files available. It's not an easy fix... Adding weapons to the end of the file doesn't affect the current indexes, since each new weapon gets a new index...
You should be able to use Entspy to modify maps that have no source. This version should work: http://gamebanana.com/tools/5876 Not sure if it actually works though.
I think we've looked at that... And we decided it might not work... I think we need to add a new entity or something... @Thexa4 Can probably explain more about this.
Can there be some sort of legacy list? This list will basically hold the current weapon ids and point to the correct weapons in the actual weapon scripts. I mean it's only non commander maps that have use this. So couldn't it be possible to use the normal list if there's a cv on the map? I'm not sure when these lists actually get populated in game, so this might not be possible... but the idea is there.
It does indeed work, it's how I've being fixing maps. Adding a new entity is perfectly possible with entspy, I'm not sure why you think it's not.
@TheCreeper I remember we discussed this a short while ago, but couldn't remember what the verdict was... Obviously I remembered it incorrectly Thanks for clarifying.