Spring RTS Engine

KDR_11k wrote:Er, why would there be a difference? VETERAN_LEVEL lists the experience value multiplied by 100 (because COB doesn't do decimals).

Aha, well that's what I needed to know then.

Ok, another question:
Can I use lua to get the current value of a variable or constant from a cob script? If so, how would I go about monitoring said value for change?

REVENGE wrote:Ok, another question:
Can I use lua to get the current value of a variable or constant from a cob script? If so, how would I go about monitoring said value for change?

If you want to share a variable between Lua and COB, you will need to use the following COB SET/GETs:

1024-2047 for unit variables
2048-3071 for team variables
3072-4095 for ally variables
4096-5119 for global variables

To get at these from the Lua side use Spring.GetUnitCOBValue and Spring.SetUnitCOBValue. To get notified of a change, you'll need to poll the variable (check it at regular intervals). Alternately, you can pass the data directly using Spring.CallCOBScript or Spring.CallCOBScriptCB going Lua->COB, or call-script lua_FunctionName going COB->Lua. Note that the latter is pretty expensive, so polling may not be as bad as it might seem.

See the wiki for details. Also,
Example of (primarily) first method
Example of second method

Thanks a lot Evil4Zerggin, really informative post.

This forum can be so helpful at times.

Quick question:

What is the feasibility of creating an aircraft factory that doubles as an air repair pad?

Would this work either in a simultaneous capacity (can build and repair/refuel at the same time), or in a boolean capacity (you cannot build and repair at the same time)?

This was not possible in OTA, but perhaps it is possible in Spring.

Warlord Zsinj wrote:What is the feasibility of creating an aircraft factory that doubles as an air repair pad?

The feasibility is "yes". See NOTA. IIRC it does both at the same time.

Gundam's big federation airport does it too AFAIK.

Thanks for the quick responses!

Ok, another question:

I know that we can set features to always render now (agorms tree map). However, I recall there being another issue where features will not display when their origin is not on-screen. This results in very large features suddenly 'appearing' on a map, because while their various parts are within visibility range, their origin is not.

Is this still the case, or has it been resolved?

It's still the case, so far as I'm aware. Meh... I guess I should check, but I could've sworn that it wasn't the center, but a check against the hitsphere itself.

If so, then there are ways around this, albeit hackish. I really wish the hitsphere wasn't used for so much stuff, tbh, it's obnoxious how many things depend on it, its size, position and angles

Well, in that case I'm trying to produce something that sits essentially in the same plane (perhaps slightly above) the the terrain, so that units are able to walk over it, aircraft will change their height for it, etc, but lets me have more detailed control over the texture (especially where vertical surfaces are concerned), and allows me to include a specular map.

It will be over quite a large area of terrain (though not the whole map... I'm talking about a 5*5 area of map size).

Any ideas?

I thought about breaking it up into smaller pieces so you don't have one big thing clipping into and out of view, but making that seamless would be bloody difficult...

Well... hmm. TBH, the amount of pop-in you'll see with a mere 5X5 at typical zoom is small. The only way to force it to draw all the time, period is through OpenGL, and I'd get with PressureLine or Zpock about that, if I were you.

Argh wrote:PressureLine

hmm knew my ears were burning for a reason, and that it wasn't the ear infection I've been battling for the past few weeks.

Talk to me in the lobby Zsinj, im not 100% sure what you are after

Warlord Zsinj wrote:Well, in that case I'm trying to produce something that sits essentially in the same plane (perhaps slightly above) the the terrain, so that units are able to walk over it, aircraft will change their height for it, etc, but lets me have more detailed control over the texture (especially where vertical surfaces are concerned), and allows me to include a specular map.

It will be over quite a large area of terrain (though not the whole map... I'm talking about a 5*5 area of map size).

Any ideas?

I thought about breaking it up into smaller pieces so you don't have one big thing clipping into and out of view, but making that seamless would be bloody difficult...

Don't make it a feature, draw it with Lua.

Just to get some clear answers on a few things:

- Does a feature cull from view on your screen when the centre of its hitsphere is no longer on-screen, or when any part of it's hitsphere is no longer on screen?

- Does the tag that tells features to always render (no distance culling) also counteract the off-screen culling mentioned in the first point? Or is it unrelated?

i cant find the documentation on the cob constant "MAGIC_DEATH 31"? any one know about it, how it works ect?

It's a TAK constant, and is not defined in Spring's source (it was, but is commented out). Click here for details on the constants.

thanks, but i didnt ask for the page on the constants, for it doesnt really explain why that was in there. but you did

i didnt ask for the page on the constants

It's something every modder / game designer should know. It's not black magic, we're just doing function calls through specific #define'd variables, where the value has a specific meaning to Spring if found in our bytecode.

Argh wrote:

i didnt ask for the page on the constants

It's something every modder / game designer should know. It's not black magic, we're just doing function calls through specific #define'd variables, where the value has a specific meaning to Spring if found in our bytecode.

fully trained at dodging the thrust of the argument i see Argh.

He obviously saw it in there, and wondered what the hell it was (ive wondered about MAGIC_DEATH myself before, but never bothered asking) theres no need to tell people to go read the entire COB interpreter source just to see what something does, or if it even works

Oh, come on--that's not fair. He did say that a) it was a TAK thing and b) that it doesn't appear in the source, from which it isn't a long leap to know that it doesn't actually do anything; it's not like he only linked the source and said "go find it yourself". And the source is very useful for any modder who wants to know how things really work--there's a lot of unintuitive/incomplete tag behavior, undocumented features, etc. etc.

how would he have found the MAGIC_DEATH thing without having at leasted glanced at cobinstance?