Spring RTS Engine

Here comes some noobquestions.
1. In some .bos files there is a set/get UNKNOWN_UNIT_VALUE() function what does "UNKNOWN_UNIT_VALUE()" mean?

2. Lets say I select 100 units and then press a button -> AllowCommand is triggert. Is the AllowCommand function triggert once or 100 times?
So if my AllowCommand function looks like this: My question is: will command_triggered become true after the first unit is added to the table or after the 100th unit is added?

thedude wrote:Here comes some noobquestions.
1. In some .bos files there is a set/get UNKNOWN_UNIT_VALUE() function what does "UNKNOWN_UNIT_VALUE()" mean?

Sounds like a decompiled script, probably has a #define UNKNOWN_UNIT_VALUE (some number) in it.

2. Lets say I select 100 units and then press a button -> AllowCommand is triggert. Is the AllowCommand function triggert once or 100 times?
So if my AllowCommand function looks like this:

Code: Select all

function gadget:AllowCommand(u, ud, team, cmd, param, opt)

   if cmd == CMD_MYCOMMAND then
      
      here comes a function which adds u (unitID) to a table 
      command_triggered=true  --set a variable to true
   end

   return true

end

My question is: will command_triggered become true after the first unit is added to the table or after the 100th unit is added?

It's triggered for each unit that is issued the command. So command_triggered would become true after the first unit.

At the moment, I have a unit that fires three lasers like this:



How do I make this unit fire like this?



(The unitdef's at http://pastebin.com/L3AJEyZc , if it helps.)

You'd need a fake weapon which fires when aiming is done but deals no damage. Then in the FireWeaponx() part of the script you put some "emit-fx 2048+x from piece" where the x is the respective weapon number of your lasers. That emit-fx command with 2048+(weapon number) forces the respective weapons to fire at their current direction. So when setting things up you just need the pieces which get used as firing positions for the lasers have the same orientation as the turret (I suggest trial & error where you just try things, look where the laser beam goes and then rotate the pieces in the Create() function so the laser heads in the right direction relative to the turret)...

Remember though that this makes the lasers "dumb". Depending on how you set up things the lasers might even miss their target as they won't aim at the target's center anymore. You also might want to tilt the pieces responsible as laser spawning point up/down during the aiming stuff because otherwise the lasers always will shoot straight ahead being sort of unable to hit anything slightly upwards or below making it useless when hills or slight height differences come into play...

FLOZi wrote: It's triggered for each unit that is issued the command. So command_triggered would become true after the first unit.

Is there a way to make command_triggered become true after the last unit was added to the table? I tried to use "Spring.GetSelectedUnitsCount" to get the amount of all selected units and then increment a variable everytime a unit was added to the table so when the variable gets equal the amount of the selected units command_triggered would become true. After a while I realized that "Spring.GetSelectedUnitsCount" can only be used in unsysnced code . Is there a way to do it in synced code?

I can't help but wonder why you want to do this, (and assume that you're doin' it wrong even attempting to do this)

Quick Question:

I've noticed that in BA, for example, the airports have the Fly/Land Button, and that this button determines if the aircraft made will land or continue flying after they're made.

How would I make an airport do this? MoveState doesn't seem to deal with this, and making the airport able to fly sure doesn't either.

FLOZi wrote:I can't help but wonder why you want to do this, (and assume that you're doin' it wrong even attempting to do this)

I'm trying to make a gadget where you have a button and when pressing all the selected units are send to the nearest repairpad (building with a nanotower) to be repaired. First I was trying to give the movecommand in the AllowCommand function but was told that this does not work (because of recursion) so I tried to save all the ID's to a table and then in GameFrame I would look for the command_triggered variable and when that one would become true all the units from the table are send to the nearest repairpad.

Stupid question: what is the maximum number of Pieces supported by .S3O and Scriptor?

Thedude, if your question hasn't been answered otherwise, I think the cleanest way to do what you mean to is to "split" the functionality into two parts:
Add a customCommand (to the appropriate units) to fly back to next repairpad when the order is given. This will be synced stuff, like you've been doing, and you'll need to save units that are given the order in a table or such and give them the movecommand (or whatever) from gameframe (similiar to as you were describing).

Now for the clicking on a button bit - depending on how you want to do it, you can either just go with your customCommand being inserted to the GUI with other unit commands (which will should let you click it for any number of units selected). Or, if you want to have a little extra GUI element, then you can make that an unsynced part of your gadget, or expand any GUI-widgets you're using (as giving an order is something that is possible in unsynced).

Sorry that got a bit longwound, but wanted to try to be clear :). If I've nevertheless failed at that, do ask more questions!

@Argh - someone else will have to answer you that, sorry.

What files do you need to set up a basic mod? ie all the lua files etc.

What are the rules on making a new mod based on an existing *A mod?

Can i just pick ba or xta, give it some other *a name and call it a new mod?

well to distribute any game's that are based from TA, you have to actually own the game (total annihilation) not the spring mod. also various parts of those TA mods might have some models or art, or code that is not freely distributable so you need to check the mod makers them selves and ask specifically. Games that don't use TA ip are mostly mod=able and you don't need to own TA to play them, but there are a few with restrictions and once again I'd ask the author's first and not just get a sure why not from some random guy on the forum or lobby.

bobthedinosaur wrote:well to distribute any game's that are based from TA, you have to actually own the game

And "own" in this case means owning the copyright, not just a copy.

Is there a way to limit a repair rate that a 'construction unit' can repair certain units and some not repairing at all?

Argh wrote:Stupid question: what is the maximum number of Pieces supported by .S3O and Scriptor?

SeanHeron wrote:@Argh - someone else will have to answer you that, sorry.

In TA the limit was 128. I could have more pieces, neither 3do builder nor Scriptor would complain, but ingame only the first 128 pieces would animate, the extra pieces would show but turn/move commands on them were ignored. I don't know if this was a limitation of Scriptor or of TA, so this is likely to not apply anymore in Spring.

im guess that's a 'lua it yourself'?

I don't know if this was a limitation of Scriptor or of TA, so this is likely to not apply anymore in Spring.

128 should be fine for what I wanted to play with, I think.

Is there a way to limit a repair rate that a 'construction unit' can repair certain units and some not repairing at all?

im guess that's a 'lua it yourself'?

More or less. You can't apply limits to repair without using Lua- stuff can either repair or not, in the engine. For whether or not they're allowed to repair certain things, you can use AllowCommand(), but for different rates of repair depending on the case... maybe AllowUnitBuildStep? IDK whether the repair case falls under that or not.

What about levels of stealth, jam, and radar?

Not possible atm, short of implementing a system for altering the visible / radar mask-states yourself. It can be done- I built a prototype LOS system once- but it's definitely non-trivial.