Spring.GetUnitCOBValue

[Argh]

Spring.GetUnitCOBValue

Ok, how does this work? Yes, yes, I read jk's example, but that didn't work, as written.

To make it clear- I have a COB static-var, n. I want to get its value, x, via LUA.

How do I get that? Do I need to SET the value of a LUA0-9? I can't seem to find any examples of people setting this up, so that they can get a COB value from a LUA script at some later point in time, and I don't want to run a COB script from LUA if I can help it.

[jK]

.. GetUnitCOBValue() which is the cob-get function ..

like: "GET PIECE_XZ(x,z);"

Spring.GetCOBUnitVar() accesses trepan's new custom get-vars, but not local defined variables.

-> it is impossible to access static-var's

Spring.GetCOBUnitVar() read those vars:

* Added global, team, and ally GET/SET variables to COB scripts
1024 - 2047: 1024 global variables
2048 - 2175: 128 variables per team (the COB script unit's team)
2176 - 2303: 128 variables per allyteam (the COB script unit's allyteam)

Code: Select all

  local PIECE_XZ = 7
  local PIECE_Y = 8
  local x,z   = Spring.GetUnitCOBValue(unitID,true,PIECE_XZ,piece)
  local y     = Spring.GetUnitCOBValue(unitID,PIECE_Y,piece)/COBSCALE

this works!

[KDR_11k]

Spring.GetCOBUnitVar() read those vars:

Is that one available in Unsynced?

[Argh]

I was using that in synced code. Problem is, it's not working

it is impossible to access static-var's

First off, thank you very much, for giving me more information about this issue, this is driving me nuts.

Unfortunately, I still don't see the result here.

In my LUA script, I have the following line:

Code: Select all

local Y1     = Spring.GetUnitCOBValue(u,1,piece)/COBSCALE

That means that value 1024 is what we're trying to GET, right? What is "piece", though? That part doesn't make any sense- I'm not trying to get a piece, I'm trying to get a value of a variable. Or, are you saying that this gets a Piece coordinate only? I tried a value of (u,1,1) to test that assumption, and that's obviously not right- it wasn't returning the height value of the relevant Piece, even on ground units.

It always returns a value of 1 for the variable.

So, to test further, in my script, I tried setting value 1024 to a specific value, on the COB side:

Code: Select all

SET 1024 to 10000;

The resulting return from COB was 1 If this is a Piece coordinate, it doesn't make sense.

Moreover, there aren't any other commands in LUA for operating with COB data sending over packed coordinates, which is the real problem here. If I could just send the data as args, and unpack it, I'd be done with this. However, unpacking it in LUA manually is incredibly CPU intensive, I don't want to do that.

All I want to do here is to have LUA fetch some data, unpack it in C++, and then do an operation on it.

I need to do this a lot, if I'm going to do stuff like new special FX that use Piece positions to determine where to put vertices... I got quads drawing with textures just fine, I just need this last part, then I'll happily give User my code, and we'll have quad-based, textured trails that emanate from engines / wingtips, for but that's just a start.

I've been looking over the FX from Dawn of War, and I am certain that if User's code is as good as it looks like, then by combining COB data and LUA's access to OpenGL, we're going to be able to do some amazing stuff, totally changing our FX and making our previous FX look like crap. This is very exciting to me, as I'm pretty much hitting wall after wall, in terms of what I want FX to do- I have a lot of ideas that will use something other than CEG, or CEG-like behavior, and they rely on using COB to pass LUA data to speed stuff up, which is looking very attractive now that I'm getting the hang of working with OpenGL and LUA a little bit.

Hmm... looking here...

Code: Select all

const int result = unit->cob->GetUnitVal(val, p[0], p[1], p[2], p[3]);

Um, that's returning an array, correct? Why? We just want a single value to come back, we're not running a COB script and returning arguments...

[jK]

@KDR

Spring.GetCOBUnitVar() read those vars:

Is that one available in Unsynced?

yup

@Argh
1.
seems as there was a change (svn only?):

static const int UNIT_VAR_COUNT = 8;
static const int TEAM_VAR_COUNT = 64;
static const int ALLY_VAR_COUNT = 64;
static const int GLOBAL_VAR_COUNT = 4096;

static const int UNIT_VAR_START = 1024;
static const int TEAM_VAR_START = 2048;
static const int ALLY_VAR_START = 3072;
static const int GLOBAL_VAR_START = 4096;

2.
like i have said GetUnitCOBValue() is the GET function, so

lua: local y = Spring.GetUnitCOBValue(unitID,PIECE_Y,0)/COBSCALE

is the same as

cob: staticvar_body_y = GET PIECE_Y(body);

(I assume body is the first named piece in the piece list of the cob, there are also some function to enumerate over all pieces and convert them into different systems (modelpiece!=cobpieces))

3.

I need to do this a lot, if I'm going to do stuff like new special FX that use Piece positions to determine where to put vertices... I got quads drawing with textures just fine, I just need this last part, then I'll happily give User my code, and we'll have quad-based, textured trails that emanate from engines / wingtips, for but that's just a start.

he is far away of something like that, but that's a different issue..

4.

Hmm... looking here...

Code: Select all

const int result = unit->cob->GetUnitVal(val, p[0], p[1], p[2], p[3]);

Um, that's returning an array, correct? Why? We just want a single value to come back, we're not running a COB script and returning arguments...

???????? why should that return an array ????????

it says >>const int result<<< that is a single integer!
also the next lines are:

Code: Select all

if (!splitData) {
  lua_pushnumber(L, result);
  return 1;
}
lua_pushnumber(L, UNPACKX(result));
lua_pushnumber(L, UNPACKZ(result));

so it also auto unpacks those values for you (if you want to).

[Argh]

Ah! Making more sense! Thank you! I'll test that immediately...

<tests>

Yay! Now I can finally draw quad trails... lemme make a quick test of functionality, I'll post the code, we'll see if User can get it to run fast enough...

[Argh]

Ahhhhh! So close, yet so far...

The following code, when executed, causes Spring to crash, every time. I have 7 Pieces in my .S3O...

Code: Select all

	 	    local PIECE_XZ = 7
			local PIECE_Y = 8
	 	
			local X1,Z1 = Spring.GetUnitCOBValue(u,true,PIECE_XZ,3)
			local Y1 = Spring.GetUnitCOBValue(u,PIECE_Y,3)/COBSCALE

			local X2,Z2 = Spring.GetUnitCOBValue(u,true,PIECE_XZ,4)
			local Y2 = Spring.GetUnitCOBValue(u,PIECE_Y,4)/COBSCALE

			local X3,Z3 = Spring.GetUnitCOBValue(u,true,PIECE_XZ,5)
			local Y3 = Spring.GetUnitCOBValue(u,PIECE_Y,5)/COBSCALE

			local X4,Z4 = Spring.GetUnitCOBValue(u,true,PIECE_XZ,6)
			local Y4 = Spring.GetUnitCOBValue(u,PIECE_Y,6)/COBSCALE

[Argh]

I think I know what's wrong... any Piece references that are to a point-type object are causing the crash, I think...

[jK]

like i have said: modelpieces are not cobpieces!
(in cob you can only access pieces, which are listed in the piece list (at the top of most cobs)!)

also you can use the following function to convert modelpiece names into the corresponding cobpieceID:
Spring.GetUnitPieceMap(unitID)["piecename"]

PS: it works fine with empty pieces

[Argh]

No, that's not it. What the hell... I had it working, with one single vertex, then it crashed Spring, when I did it with 2, now it's crashing with one...

Spring.GetUnitPieceMap(unitID)["piecename"]

Ah... ok... lemme try that... it'd be better if it worked with empty pieces. The "piecename" is the same as the piecename in the .S3O?

[jK]

there is only 1 piecename

(->even in cob you use the modelpiecename)

[Argh]

OK... vital tip: you can't just refer to the name in the .S3O, it's reading the name string from COB, apparently. So, your Pieces must be named, in COB, for this to work.

I'm still seeing a lot of errors:

First, this keeps spamming to the console:

ScriptError: Invalid piecenumber for get piece_xz outside script execution
ScriptError: Invalid piecenumber for get piece_y outside script execution

Which makes no sense, since I'm not calling a COB script, the Pieces are named there, etc., etc... that just looks like a bug of some kind, but maybe it's because I'm calling GET more than once, on the sync side, or something equally stupid. It only started spamming that when I got all four verts set up correctly...

And something is wrong with the triangle data being returned, or something else is wrong:



I've gotta get some sleep, I have a very busy day ahead of me tomorrow... here's the .LUA script, the modified Scoutcraft model, and the texture (drop it into the Bitmaps directory) so that you can make PURE 0.55 equivalent, if you're feeling like testing this. I'm hoping I just forgot something really stupid, my quad drew just fine until I tied the texture on, but during initial tests, I didn't think about why it was getting screwed up, I just assumed it was getting bad vertex data from somewhere...

In the final model of this, I think it has to use pairs of triangles, not quads, to prevent borked results from twisted verts. But, meh, I'm still having trouble getting it to just render correctly

[user]

he is far away of something like that, but that's a different issue..

wow, i always thought that i was getting close to it, so probably you know how does my script work without even looking at it!, you are awesome... (sarcasm)

i could make my own code for quads, but if your code really works, then
ok, we will use it, i will finish some stuff here, then i will help you with this.

[user]

I need to do this a lot, if I'm going to do stuff like new special FX that use Piece positions to determine where to put vertices... I got quads drawing with textures just fine, I just need this last part, then I'll happily give User my code, and we'll have quad-based, textured trails that emanate from engines / wingtips, for but that's just a start.

we are not far from this, when you finish it, i will probably have finished doing a few adjusts that will make implementing it easy.

I've been looking over the FX from Dawn of War, and I am certain that if User's code is as good as it looks like, then by combining COB data and LUA's access to OpenGL, we're going to be able to do some amazing stuff, totally changing our FX and making our previous FX look like crap. This is very exciting to me, as I'm pretty much hitting wall after wall, in terms of what I want FX to do- I have a lot of ideas that will use something other than CEG, or CEG-like behavior, and they rely on using COB to pass LUA data to speed stuff up, which is looking very attractive now that I'm getting the hang of working with OpenGL and LUA a little bit.

what do you mean with changing the fx?, just the trails, or advanced stuff like lights, projectiles, explosions?

i would want to make such things, it would be really cool.

i will post how this cob to lua for the ribbon effects will work in the Ribbon Effects topic i made, so go there, i first try to understand how
your cob to lua works currently.

(yes, i know someone will post that lua projectiles are impossible, they aren't, the problem is that making them in lua is hard)

[Argh]

Well, for one thing, a trail app. could be re-purposed to do helices, animated columns, and spirals, that is all attached to pieces. "Lights" could be quads, defined from Piece coordinates, showing a texture with alpha channel.

Heck, I could even do windows. I can already do that part... 'cept I don't know how to do lighting yet... damn.

[user]

i think we can make custom reflective textures in lua too, see the stencil buffer(only in svn) .

i will wait you finish what you are doing right now, then implement it.

can't you use the get piece position call?, then on unit defs, name the
pieces with effects attached to it.