Spring RTS Engine

I've a problem with command CMD_SET_WANTED_MAX_SPEED. Spring ignores this command. Is it supported?

I havent seen anything save scripts make use of it.

Instead try looking at the parameters your passing to it and checking against the code in spring that makes use of it.

I tried, but Spring doesn't use maxWantedSpeed variable (this is the variable Spring is saving value from GiveOrder to). I checked Spring 0.72b1 and SVN trunk version, both have the same code.

I found that the only ai using CMD_SET_WANTED_MAX_SPEED is OTAI. Although noone knows if it worked. You can look at its source here: http://www.fileuniverse.com/?p=showitem&ID=2993.
It is no longer developed since 0.71b1 so you probably won't be able to compile it.

Also look at Simple Formation AI. It doesn't use CMD_SET_WANTED_MAX_SPEED, but it keeps its units moving together somewhat.

OK, so now I have next question:
What we get in UnitDamaged function call as float3 dir?

it's a normalized direction.

aka instead of giving the actual location from whcih the shot was fired, it instead gives a set of co-ordinates showing what direction it came from, aka a vector.

The location is:

damagedunitlocation + dir*TimeToTravelToTarget

the problem is the time value has to be guessed or approximated/predicted.

It's main use was like in OTAI where it was multiplied by 300 then subtracted from the units position resulting in the unit being told to move in the opposite direction of the shot to run away.

It is a normalized vector that basically should show direction towards location from which the shot was fired, but the way it is implemented means that instead it shows direction toward actual position of the shooter.

AF wrote:The location is:

damagedunitlocation + dir*TimeToTravelToTarget

the problem is the time value has to be guessed or approximated/predicted.

Time, eh??

The enemy location is:
damagedunitlocation + dir * DistanceToEnemy

And the distance is the thing which needs to be guessed/approximated/predicted.

I made a patch on the mailing list (1 line of code) for this command to work and included it with SelectedUnitsAI.cpp so that CTRL-Move makes them move at the same speed, Ctrl-Move-Drag makes them move at same speed and form a front (like drag-move).
The only(BIG) problem I didn't fix is how to make them resume their usual speed after command is finished.
I also changed it so when you move-drag the spacing between units takes into account unit sizes, and if a front is big the units spread to fill the whole front, not gather in the middle like it is now. Non of the developers however answered to my post on the mailing list...(changed files are in the attachment on the mailing list)
Alik

Wouldn't CMD_SET_WANTED_MAX_SPEED with Speed = UnitDef->MaxSpeed resume the original speed?

Also don't send whole modified files, make a patch which contains only modified parts of code and is easier to review. Use "Create Patch" button in your SVN client (if you have one already).

thanks for telling me how to make a patch.

Wouldn't CMD_SET_WANTED_MAX_SPEED with Speed = UnitDef->MaxSpeed resume the original speed?

Yes, it would, but you would need to give this command when units finish moving/or stopped/or given another command. I tried pushing the set_max_speed(original max speed) to the end of the unit's command que (unit->commandAI-commandQue.push_back(command)) but it didn't work, besides it's not a very good solution in case units will be stopped/given another command(stopped again). I was suggesting also making update() function in selectedUnitsAI.cpp which could allow advanced formations(without GroupAI) and could be used to solve the setting-back speed problem...
[/quote]