[bug/issue] Some maps bugs&issue report screenshoot's

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

 

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 it sounds like an important problem and issue for the coding devs then

 

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.

 

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.

 

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.