Why are there only 26 alterable values?

[Krim]

I'm really curious as to why this issue hasn't been solved yet. There have been many updates since and not one of them fix this artificial limit. It makes no sense to me. What is the reason for just 26 alterable values?

It's pretty lame that I have to come up with ways to get more alterable values attached to the same object. So instead of having 1 object with all the values I could ever want I have 3 objects with the same amount of values. So now if I have 5 enemies in my game it's actually 15 objects for 5 visual enemies. Why hasn't this been addressed? What really pisses me off though is MMF2 just keeps getting features added on top even though the foundation itself is not as good as it could be. It really reminds me of how they quickly build apartments in China and eventually they just topple over because the foundation was poorly thought out.

I'd really like to use nifflas custom movement engine but it takes up over half of the alterable values and just for 1 object. When you start programming ai you quickly start to run out of values. Anyway I can't use it because of that reason. I have to use an engine that is not as good and has less features but it takes up less values.

Is this issue ever going to be fixed? It's mind boggling that it hasn't been fixed or that it wasn't fixed when people originally realized and complained about it.

[oasuke]

I believe the way Alt. values are coded is that all values are loaded into the memory ignoring the fact that they may not even be used. (Open the debugger, you'll always have 26 empty alt.values/10 alt.strings.) With their current code logic, it's probably not possible to have different instances with variable a.values unless they recode the way instances handle their values. I doubt it'll be "upgraded" during MMF2's life, but hopefully in MMF3. It is troublesome using different objects/ValueAdd extension just to get more values though.

[Nifflas]

What really pisses me off though is MMF2 just keeps getting features added on top even though the foundation itself is not as good as it could be.

Don't expect this to change in MMF2, besides, I wouldn't want time to go into trying to patch up MMF2. Most of us advanced users are waiting for MMF3 and hope it'll have a really good foundation.

[nivram]

This is starting to sound like the old MMF1.5 forums. Wait for MMF2. Also, there is such an easy work around for the 26 Alterable Value limitation I want to vomit any time someone complains about. Maybe it is a little frustrating, but it is like hitting a toad on the M4 in the UK or I40 in the US.

Marv

[Alonso]

Have you tried the ValueAdd extension? It has done wonders for me, and using it won't have any repercussions. Except for the small inconvenience of having to reference objects through their fixed values.

[Patrick]

oyeah i remember good ol times. MMF 1.5... i used that more than i used any dev tool. MMF2 rocks as. altough i loved the good ol drag'n'drop between animation frames and sequences in MMF 1.5, its always been broke due to "modal" approuch in MMF2.

But back to alt. values. Ye, if you need to store so many values maybe you could work arround it.
Natively, One particular headacke could be when your unning short on these when using multiple instances of an object, in which case you need to set the id of row or column in a datastorage object (e.g. an array) and link it to all the instances.

[Skyhunter]

I dont see an easy workaround for the 26 values limititation...
I think one of the high point of alt values is that you can name them for instance damage, range... etc... if you run out of them you must store data elsewhere or in a parsed string but then you have 26|7|1200|80... and eventually you forgot what each means, structurally it's bettter to have more alt values because of easy n fast editing, i have over 100+ weapons in my game, when i open the editor i wish to click on one of the weapons and change some values, not go to some external database, or having more objects, or looking at what point in the parsed string is the damage value... etc... it's just loosing time...

I like to precode stuff so i can do stuff easy and fast, so when i want to change or add a new weapon it takes me only a second literrally, not minutes trying to find where is something i wish to change/add... and alt values&strings are the most problematic issue i have to deal with because they are limited on how much they can hold.

This applies to the runtime aswell, it's much easier to reference a unit's alt value for instance valA IsItStunned?, valB HowMuchIsItPoisoned etc... than to crossreference to arrays or parsed strings or other objects... becuase the code looks messier... and it's not an easy workaround oftenly, because now you are looking at the same condition and it looks like this: ValueAtXYZ( "SkillsArray", 114, Alterable Value Z( "Unit" ), 0)
instead of just: Alterable Value E( "Unit" )

I agree it's not a problem to go around the limitation, but it's not that easy esspecially for new users and not very user friendly in general...
And i hope mmf3 will have more alt values because it's needed.

[DistantJ]

I just use a global array...

[Skyhunter]

I find it best to use a unit alt values only for starting stats, such as initial data, if i need more initial data i create for instance weapon objects to reference to a single value of a unit.
During runtime i find it best to use all the values from objects you have anyway on units, such as healthbars, detectors etc.., But i also often resort to additional objects just because i can name their values and it's easier to code/debug than using other means.

Actually in my current project i am using about 8 sets of objects for initial data, and around 6 for the runtime of each unit, but only 2 of those are addiotionall which have no graphical use for that particaluar unit.

There is also a way to use parsed strings more effectively for initial data by doing "Damage|20|Range|10|Shields|80|", but in this case or any other case using a parser you need to reference a large list and it can fill up the values very easily to the point where you need to scroll the properties bar where the string is located which does not work very well in either way. And the arrays, it's not easy to setup initial data using arrays, because you need to do that external which is not that easy or fast as just modifying object values, esspecially when it comes to testing phase of the game when you need to balance out the initial data.

[Nifflas]

This is starting to sound like the old MMF1.5 forums. Wait for MMF2. Also, there is such an easy work around for the 26 Alterable Value limitation I want to vomit any time someone complains about. Maybe it is a little frustrating, but it is like hitting a toad on the M4 in the UK or I40 in the US.

I don't enjoy pairing multiple objects or using workarounds like ValueAdd, not to mention all the extra ForEach iterations every time I need more values than 26 for an object I use multiple instances of (and I know every workaround there is for this). Oh, and I don't appreciate that you want to vomit on me because our opinions differ. I can be too harsh on the forums sometimes, but I'd never say something like that.