Spring RTS Engine

I have three questions this time,

first:
Is it possible to make a unit's weapon(s) not reload unless certain conditions apply? For instance, until the unit is being repaired or loads another unit?

second
Is it possible for a unit to make another unit self destruct, or otherwise cease to exist? For instance if it is loaded into another unit.

and lastly
Is it possible to decrease the amount of metal extracted by a unit when the amount of time a game has been running reaches say, 30 minutes? or some other specified quantity of time.

thanks, also I would appreciate, if the action is possible, a simple explanation of its implementation (I.E. which functions it needs to be in etc.)

thanks again

first: Making it only able to fire when it loads a unit is fairly easy. But I'll leave what scripting is required for another as I don't remember the names of the functions (or which does what...)
Being repaired could be done by comparing the value of "get HEALTH" with a previous, stored value of "get HEALTH". However, gaining xp would also increase health. Not sure how you would account for that in a foolproof way, but you can get xp with "get VETERAN_LEVEL".

second: Hrm... maybe with some fancy scripting you might be able to pull that off, but it would be the unit being destroyed detecting the unit that is supposed to be killing it (unit height reading stuff) then setting its own health to 0 (via "set HEALTH 0", which is in %'s, and probably will trigger unit death). There are some issues, whether it would work for you or not depends on how your wanting to implement it.

third: Not directly. You could simulate it by having the unit deactivate for periods of time. You'd create a new function to control it, started by the Create function, have it sleep 1800000 (30 minutes in 1/1000 seconds), then have a loop that turns it off for some amount of time, then back on for some amount of time. It can only approximate a percent decrease in production, and players will hear each on and off...

I just had the best idea ever... have units able to "eat" units, basically load them quickly and convert them into a small percentage of orriginal metal/energy... it would be an offensive resource gatherer.

Actualy SinBadEV, that would fit one of the sides for my mod quite well

I could just not include a sound file for on/off so that the unit is not anoying towards the late game.

Wouldn't a sleep and then loop like that eat CPU resources if there were very many of them in action?

How about a commander that can capture and cloak etc, but cannot build anything?

A race that would basically capture the units of the enemy?

*is planning to add such a 'race' as a mutator for AA, to see how it would work and the tactics that would arise from it*

Another way of doing it is a commander than can fairly easily destroy enemy units and then ressurect them

actualy its funny you mention that, one of the commanders for my sides will be able to paralize and capture (no other nifty things). still builds other units, so no assimilation only races, but similar idea.

Also, I inted to keep metal extractors low. meaning they will be better but the maps for the mod are going to have fewer metal spots than a tipical AA or OTA game, so there should not be too much drain involved if that indeed eats significant resources.

Archangel, would that script work for game time or the amount of time the unit has existed? I don't want rebuilding the unit to make it go back to normal. Can I have the unit check the amount of time the GAME has been running, so that it only implements that if the game times reaches a certain number, rather than the unit's time?

If the unit keeps track of its time, then rebuilding it increases its resorce output, which adds more micromanagement, and defeats the purpose of putting it in there in the firstplace.

thanks

/me is not a scriptorer
you could have the commander have the timer in him, and have the other units check with him what to set their wait variable to on contruction.

That would just check the unit's time of existence. We can't get game time, or pass variables from one unit to another. Being able to get gametime with the script would be a potentially very hand script function though... It might be fairly easy to add, enough so that I'll be looking into it myself.

Well if you do get time keeping coded, that would be great, always nice to see more options added to the engine ^_^

Is it possible to make part of a unit explode with out dying?

say I wanted an animation were some portion of the unit periodicaly explodes.

thanks

Yah, the explode stuff in the killed scripts work anywhere. You'll have to hide the pieces you explode yourself, and there is also an issue I don't remember the details of, something like even if you don't have EXPLODE_ON_HIT a piece with FALL still does it (or something like that...).

very nifty :D thanks.

I don't know if this is the relevante place to post it, but would it be possible to write an AI for a unit so that after it shoots, and has "run out" of amunition (the unit will have to load up ammo creates between X amount of shots, which will be its own type of unit, and the only one the unit will be able to load) it automaticaly seeks out the closest one and loads it? Similar to how metal makers have AI's to turn on and off depending on E.

Thanks

What parameters can be passed, or monitored by units? Is there a list some were on the WIKI?

For instance, can I pass the number of stored resorces to the unit as part of a conditional action?

thanks

- Go to: http://www.unituniverse.com/tutorials/tadesign/
- Go to the bos section
- Scroll down to the the get/set section. Hmm ok it's actually labelled "BOS System Variables". It lists all the parameters that unit scripts can monitor in TA:

Variable Action/Values Description
ACTIVATION Set or Get: 0/1 Used to indicate whether or not the unit is currently activated. For example, after being attacked, an ARM Solar Collector folds up, deactivates, and does not produce any energy during that time.
ARMORED Set or Get: TRUE/FALSE Used to indicate whether the unit is in a protected (or "armored") state or not. For example, the ARM Solar Collector, when folded up and deactivated, is armored, and therefor able to withstand more damage before being destroyed.
ATAN Get Only: ordinary two-parameter atan
BUGGER_OFF Set or Get: (ask other units to clear the area)
BUILD_PERCENT_LEFT Get Only: 0-100 Returns a measure of how far along the unit is in the build process. Typically used to indicate when the unit is fully constructed and ready to be activated. A value of zero indicates the unit is built and ready
BUSY Set or Get: (used by misc. special case missions like transport ships)
GROUND_HEIGHT Get Only:
HEALTH Get Only:
HYPOT Get Only: ordinary two-parameter hypot
INBULIDSTANCE Set or Get:
PIECE_XZ Get Only:
PIECE_Y Get Only:
STANDINGFIREORDERS Set or Get:
STANDINGMOVEORDERS Set or Get:
UNIT_HEIGHT Get Only:
UNIT_XZ Get Only:
UNIT_Y Get Only:
XZ_ATAN Get Only: atan of packed x,z coords
XZ_HYPOT Get Only: hypot of packed x,z coords
YARD_OPEN Set or Get: (change which plots we occupy when building opens and closes)

- To that you must add all the new get/set value added by Spring. Those are found by reading carefully the Spring changelog. There's actually extremely few unit parameters that can be read, and even fewer "other unit parameters" that can be read. But if you are tricky, you can indirecly gets some more: for instance in TA by counting how long a unit takes between two shots you can gather it's veterancy (but in Spring there's a more direct way). Or by calculating how far from the ground units are in TA I could differentiate between kbots and veh and flying units. Or in my Stargate script I made the script grab another unit, and broadcast any number I want by holding that other unit to a depth equal to that number.


Oh, and don't forget to pay a look to that "exptype.h" file inside your scriptor folder. You'll see most of them listed, and as a bonus you might even understand that get/set argument are actually just numbers and that you must add:
#define MAX_ID 70 //returns maximum number of units - 1
#define MY_ID 71 //returns ID of current unit
#define UNIT_TEAM 72 //returns team of unit given with parameter
#define UNIT_BUILD_PERCENT_LEFT 73 /*basically BUILD_PERCENT_LEFT, but comes with a unit parameter*/
#define UNIT_ALLIED 74
to it to get those new ones to work.


As for the first post:

1) Yes, in the AimPrimary(h,p) function, do your test, and loop endlessly until the proper conditon are met.

Something like:

AimPrimary(h,p)
{
signal ...
set-signal ...
while(get UNIT_HEALTH<100)// get HEALTH is in percent btw
{
sleep 327;
}
turn ...
turn ..
wai..
return(1);
}
Would prevent a unit to fire unless it's fully healed. If you it to fire once, but not reload, it's a bit more tricky, you have to declare a global variable storing the number of shell loaded (static-var shots; at the beginning of the bos for instance), then decrease it (with --shots;) in the FirePrimary(), then reload it in when whatever should reload it happen, for instance:
SetSFXOccupy(bleh)
{
if(bleh==0)//0: unit is being loaded (at least in TA, not sure in Spring)
{shots=2;}
}
then chek if shots is positive in the aiming and not fire if not:
AimPrimary(..,..)
{
...
while(shots<=0)
{sleep 492;}
...
return(1);
}
and of course don't forget to initialise the variable:
Create()
{
shots=2;
...
...
}


2) I noticed that the "explode" command sometimes does deal some damage to the unit that performs it under Spring, and by exploiting that I managed to script a unit to self-D in a show a flame. I'm not sure this will work for loaded unit, maybe this had been fixed in newer Spring version and maybe "explode" don't deal damage ever anymore, and anyway it was messy.

3) Like Archangel of Death said, with something like:

Bleh()
{
sleep 30*60*1000;//Wait 30 mins
while(1)
{
set ACTIVATION to 0;//Turns off
sleep 7500;//Stay off 75% of 10s
set ACTIVATION to 1;//Turns on
sleep 2500;//Stay on 25% of 10s
}
}

Create()
{
...
start-script Bleh();
}

Make sure your mexx has no manual on/off command (onoffable=0; in the FBI)

It's great that we have to search through the changelog to find all the functions Spring offers over TA...

for a resource extarctewr that dies after time, just have it set a counter for every minute and when it reaches the certain time; ie the clicker hits 30 for 30 min have it shutdown?