get/set UNIT_VAR

get/set UNIT_VAR

Requests for features in the spring code.

Moderator: Moderators

Post Reply
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

get/set UNIT_VAR

Post by KDR_11k »

I don't think there's a feature like that in Spring, so here it goes:

New get/set values:
UNIT_VAR(id, num): A variable belonging to the unit with id as its ID (well, duh), num ranges from 0 to 15 so each unit has 16 of these (should be sufficient). All initialize at 0.
TEAM_VAR(id, num): Same but belonging to the team id.
GLOBAL_VAR(num): Again but this time it's one shared set of variables for ALL units. This could use being larger than 16 entries.

Should be easy to implement, adding a fixed size array to the unit, player and some global definition and the corresponding commands to the COB Instance. Not sure how syncing is handled, I hope that doesn't get difficult. UNIT_VAR is the most important one, the other ones can wait.


These commands would make many complex scripts MUCH easier. Currently it's not possible to have different units' scripts interact. With these commands many complex operations would be possible without additional engine changes.

For example, a mod could have each combat unit count its ammunition in its script using a UNIT_VAR and a supply truck that refills all nearby units while depleting the ammunition it carries (stored in another UNIT_VAR). Once the supply truck is empty it must be returned to a supply depot which refills all nearby supply trucks.

Another option would be harvesting like the ED does in Earth 2150: The metal extractor doesn't really extract metal, instead it reads how much metal it would extract and increases a counter by that value, when a transport truck comes nearby the extractor fills that truck up while reducing its own value and when the truck gets near a refinery, that refinery empties the truck and fills up its own buffer, it's active (and producing metal) while the buffer is not empty and decreases the amount every second or so.
User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Post by rattle »

I'll second that.
User avatar
Optimus Prime
Posts: 755
Joined: 03 Oct 2005, 14:31

Post by Optimus Prime »

MTR.
I asked for such a feature at least 2 times and others too. All i know is that its too hard to implement because all of the unit fbi values must be saved for all units seperately (means for every unit there needs to be a space for every variable). Lets say there are 50 different variables like costs, damage, speed and so on and let a game have 1000 units, that would make 50k different variable storages. Dont know how that would slow down spring.
But i would need such a feature as well (probably the feature i need most)
Gnomre
Imperial Winter Developer
Posts: 1754
Joined: 06 Feb 2005, 13:42

Post by Gnomre »

Good job reading, slick.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

I'm not talking about fbi tags or anything, just an array of variables attached to each unit that can be read and written by other units' scripts. The variables would be meaningless by themselves but scripts can interpret them in any way you like so e.g. you could have each unit mirror its veterancy in variable number 5 and have other units "upgrade" (you know, set ARMORED to TRUE, unjam weapons, that kind of stuff) themselves if they have a veteran nearby. Or implement the bonus giver system from SWTA without checking for unit heights by saying that variable nr. 2 is TRUE for all bonus givers and FALSE for everyone else.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

The main problem with get/set is that set only has one argument. Otherwise I'd added a lot of stuff already, but now it needs a change in scriptor, which sucks.
Good news is that lua is finally compiling on linux too, so full lua integration can start to happen sometime.
That's why I (and tobi) rather want to focus on large things such as lua than add small features that have only limited flexibility.
User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

I'd rather get the small changes done now than wait a year or two until LUA support is done. I mean, I don't suppose it's going to be done for the next release, right?

That compiler.cfg bit about get looks freaking nasty... Let's see if I can figure that out.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

@JC, or Tobi, since y'all are planning this...

Question:

When LUA support is available... what are we going to do about backwards compatibility?

I mean... the big issue here, to my mind, is not whether LUA is better... that is completely obvious... but how we're going to make the transition to the LUA world as painless as possible. We really, really, really need to start talking about how we're going to go from BOS to LUA without some really terrible efficiency problems... I think we're going to need a full-blown converter for BOS scripts, frankly. Better to convert than to emulate.

That, and we need to have, I feel, a public discussion about what we'd actually like to work with, and hash out what people are actually willing to work with, how it should function, etc. I have a feeling that many people will quit being so insistent on IK when they see what it's going to cost in terms of speed and additional complexity, but that's just me.

I was going to put off talking about all this stuff until the next interim release of Spring was out, but maybe I'll post a biggie about all this during this week, to help frame debate. If nothing else, since I've made myself incredibly popular lately, it'll keep the lightning bolts coming my way, so I can have a complete week of solid flames ;)
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

Making a big public discussion of things that aren't completed or even started yet doesn't really work for me. (Look at the SM3 threads)

I would like to explain what I'm going to do sometime when time allows me:

* abstract the model system. Every model will have an "animator" and a model. The animator can be a COB script, or a set of animation tracks similar to skeletal animation info of other games.

* abstract the unit system, and create a lua binding for the base unit, and a lua binding for the animator interface. The base unit system should have the collision code and map blocking implemented, but none of the mod dependant stuff (resources,etc). It should not have an FBI.
The C++ unit code (the old stuff with FBI) will call the animator for things such as getting the buildspray origin, and doing animations. The lua code can do the same thing.
Lua will have the ability to force specific positions/rotations to the animator, so you can do scripted animation even with a skeletal animation animator.

* (hopefully together with a modder), implement a basic set of unit functionality in lua (such as resource management and building things).

* other modders can derive new unit classes from the lua base code.

So you see I intend to use lua mostly for something other than animation.

* Maybe also expose some C++ matrix code to lua so general IK can be attempted in lua :)
Last edited by jcnossen on 22 Aug 2006, 18:41, edited 1 time in total.
User avatar
VonGratz
Posts: 471
Joined: 03 May 2005, 05:25

Post by VonGratz »

jcnossen wrote:Making a big public discussion of things that aren't completed or even started yet doesn't really work for me. (Look at the SM3 threads) :)
Very good and wise! :wink:
jcnossen wrote:* other modders can derive new unit classes from the lua base code.
Very interesting.
VonGratz
User avatar
PauloMorfeo
Posts: 2004
Joined: 15 Dec 2004, 20:53

Post by PauloMorfeo »

Argh wrote:... a public discussion about ...
jcnossen wrote:Making a big public discussion of things that aren't completed or even started yet doesn't really work for me. (Look at the SM3 threads)
...
And, in fact, we've already had, at least, one discussion about the Lua integration.

Also, i would like to say that, where once jcnossen was a freshy lead developer, he now is the lead developer for .. more than half year probably more? That from a dude that was suposed to carry the project for only a few months until someone new could take over so he could go back to academic needs (at least it will glue very nicely to his Curriculum Vitae).

I expect that the many concerns expressed by modders in the old discussion have matured in how jcnossen sees that lua integration stuff. He has my confidence, if that matters.

Anyway, i don't see why, if lua integration to mod stuff is made, the old FBI/COB/etc ways would not work?
User avatar
unpossible
Posts: 871
Joined: 10 May 2005, 19:24

Post by unpossible »

wait a second, i haven't followed this properly. looking at the changelog..does this mean that we can change any value spring has pulled from the unit's FBI via .cob now? :shock:
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

nope
Last edited by jcnossen on 23 Aug 2006, 21:42, edited 1 time in total.
User avatar
unpossible
Posts: 871
Joined: 10 May 2005, 19:24

Post by unpossible »

my mistake :oops:
Post Reply

Return to “Feature Requests”