Some new get/set I'd need

Some new get/set I'd need

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7052
Joined: 16 Nov 2004, 13:08

Some new get/set I'd need

Post by zwzsg »

I wish Spring script to support these new set/get:


get MAX_ID;// return the maximum ID that could be used in the game. I was told that currently Spring use ID 0 to 4999, but could allocate more if the (number of player) x (unit per player) required it. And anyway that sort of things is prone to be upped. Or maybe even downed in case you do some optimisation to allocate less if less are needed. I know I could assume a MAX_ID of 16*5000-1, but that is a bit too many ID to check for my script that use "for" on all ID. (Also, to be more TA-like, you could start numbering ID at 1, but it doesn't really matter that much.)


get MY_ID; // return the ID of the unit that is running this script. ID as the 0-4999 number that is given to each new unit. Currently, I can work around by checking which ID verify get UNIT_XZ(id)==get PIECE_XZ(base), but I'd rather have it read cleanly.


get UNIT_TEAM(id);//return the team number of the unit. In TA all player had a reserved id range, so the id itself was enough to determine the ownership of a unit, but it's not the case anymore in Spring, so I'd like a way for me to know if a unit of given ID belongs to which player. I guess it could return something like -1 if there is not unit at this ID. It would be nice to also know if the unit of said Id is allied or not. But maybe it's becoming a bit too hacky to try to load so many information on a single value. Actually, maybe that more than the team number, it would be more interesting to know if it belong to the player, to an ally, or to an enemy.


set UNIT_HEALTH(id) to num;// It's like set HEALTH, but changing health of other units. First argument being the ID of the unit to which to change the health, second argument being the health in % (for instance 100 for max health) to set it to. I guess we could have a get UNIT_HEALTH too, but I see much less use for that one.


set UNIT_HITPOINTS(id) to num;// It's like the previous, but instead of having a second argument in % it takes direcly the number of hitpoint in the unit used in the MaxDamage FBI tag. For instance 29918 for a full health krogoth. Oh, and support a get UNIT_HITPOINTS(id) too.

Yes, those two last are very similar. Probably so similar only one of the two would do, but I figured out it would be quicker to add them both in the same time than only one and find out later the other would have been more useful. Personnaly I prefer the HitPoints one, since it would allow to have scripted pseudo weapon, for instance:
set UNIT_HITPOINTS(id) to get UNIT_HITPOINTS(id) - 40;
to simulate a small blow.
and also things like set UNIT_HITPOINTS(id) to 1; I could turn the unit to "barely living only one more blow and it's gone" etc..

If the UNIT_HEALTH or the UNIT_HITPOINTS is set to below zero, then the unit to which we do that should die. (I'm not not sure its <= or <, but whatever). Killing a unit of given IDvia script would be the most important use of these. However, I think it would be good to allow two ways of killing units.
- One way with the killed unit running its Killed(...) script, leaving wreck, displaying fireworks, and the killer increasing its veterancy and the the killer player increasing its killcount etc..
- One way where the killed unit would be silently erased, without killer veterancy increased, without player killcount increased, without any explosion sequence.
I suggest that setting UNIT_HITPOINTS to zero or below zero, and that setting UNIT_HEALTH to zero, do the regular death, while only setting UNIT_HEALTH to stricly below zero do the silent unit erasure.

About what to do you set them to something higher than the max: I'd suggest that with set UNIT_HIGHTPOINTS, it gets ceiled at the MaxDamage defined in the FBI, while set UNIT_HEALTH allow overboosting the health.

TA use the set get from 1 to 20, TA:K from 21 to at least 34, so for Spring, start using get set from, let's say, 50, or 64.

so let's define use for instance:
#define MAX_ID 71
#define MY_ID 72
#define UNIT_HEALTH 73
#define UNIT_HITPOINTS 73
which will have to be pasted into every script using the new set/get functions, until you get bored and add it in some .h

So, can any dev code me that? please? :cry:
Last edited by zwzsg on 16 Dec 2005, 14:17, edited 2 times in total.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

I have no problem with supporting it in the COB code, if you change the scriptor... it should be easy since the functionality is already avaiable for the other GET/SET values.
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7052
Joined: 16 Nov 2004, 13:08

Post by zwzsg »

Well, nothing needs to be changed in Scriptor, since it's only set/get! All I could have to change is the exptype.h shipped with scriptor, but that would only take me three seconds. Ok a bit more to reupload it to FU.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

I was wrong about the unit ID going above 5000, it will not do that in any case.

This means we can also just put in movement class control through GET/SET!

Also, TAK values seem to end at 34 (ON_ROAD), so I think we can just use 35 instead of 71
This would make it:

#define MAX_ID 35
#define MY_ID 36
#define HITPOINTS 37
#define MOVECLASS 38

However having a UNIT_HEALTH/UNIT_HITPOINTS work in normal HP, mods can't control the unit HP with the FBI file which sounds wrong.

Isnt a UNIT_HITPOINTS enough? I prefer to keep things simple, because other people than you would want to use this too ;)
Let's make UNIT_HITPOINTS (or maybe just HITPOINTS) work with percentages too, but implement the -percentage, which would make the unit explode. Maybe -(MAX INTEGER VALUE) can be used to do a silent erasure, and -value (with value not max integer value) will cause an explosion (Increasing the unit health through FBI would also cause a bigger explosion then)

While I'm at it: Moveclasses:

0: Default movetype (ie: no movement)
1: AirMoveType
2: TAAirMoveType (gunships, transports and constr planes)
3: Groundmovetype (with normal ground math)
4: Groundmovetype (with hover move math)
5: Groundmovetype (with ship move math, yes ships are ground units I think)
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7052
Joined: 16 Nov 2004, 13:08

Post by zwzsg »

I know there are a couple undocumented TAK get/set. For instance the Veruna Lighthouse use a get UNKNOWN_UNIT_VALUE(40)(8);. That is why I wouldn't start right at 35 but much over.

Yes, I know the max hp defined in the FBI can't be changed, but in TA, with negative damage modifier or negative damage acid or negative damage weapon, it was possible to overboost health, with all sort of funny side effect. Oh well, forget about it if the same doesn't apply to Spring.

Yes, just UNIT_HITPOINT is enough, but I figured out that since coding the two doesn't take more work than coding one, since they are so similar.

I don't know what's the max integer value, and it's probably a number hard to remember, like -2147483648. And we can't just use a simple number like -1 because then we risk accidentaly falling on it while substracting a constant number to simulate a weapon. Well, I know we could still make sure to use:

Code: Select all

var hp;
hp=get UNIT_HITPOINTS(id) -40;
if(hp<=0)
{set UNIT_HITPOINTS(id) to 0;}
if(hp>0)
{set UNIT_HITPOINTS(id) to hp;}
instead of just

Code: Select all

set UNIT_HITPOINTS(id) to get UNIT_HITPOINTS(id) - 40;
to hit a unit with a -40 hitpoint blow without risking losing the killcount if the unit has precisely a certain number of hitpoint left, but I'd rather have the simple script be odd-once-in-a-10000-bug-free.

And that's another reason for having two "set" commands.

I think that when modifying other unit values, the constant should be prefixed with UNIT_. Because just HITPOINTS would sound like the hitpoints of the unit that is running the script.
Post Reply

Return to “Engine”