Ok so what does that title mean?

Well by using my library modules and a bit of ingenuity I have written a small utility script which you can attach to some entities which can then be called from another script attached to another entity to position the first with respect to the second. If you then move the second entity the first will move with it.

For example there is a ChalkBoard in my library and a BarsGreen decal, combining them gives the result in the attached image, a fake computer monitor.

Obviously this is a simple little demo just to show the principle but this is basically the way I attached jets to nozzles for the moonlander (if you remember that one) and can be extended to all sorts of things.

I've included all the scripts you need to replicate the effect.

Have fun!

Edited to add a second decal entity to make it more interesting:

I forgot to mention, you can attach the scripts to as many entities as you like, for example:

(made the delay between decal switch random for this video)



Attached pic of what the editor view looks like as well.

Cool! I been doing something like that. But this is a way better. Thank you

Btw, the example script I've posted has the entity position being updated every frame regardless of whether it needs to be. If you use this in a game I would suggest that the update call is made conditional when it needs repositioning (i.e. first time through and then only when the entity it is attached to changes position or is rotated).

Also if the 'attached' entity(s) are not simple decals you may have to tweak the parameters to get smooth motion, either 'physics no' or 'physics yes' with 'isimobile yes' usually fixes it depending on what you are using the entity for.

awesome AmenMoses.

but please explain were to use all these scripts, because , my brain has left the body. lol

That's what the examples are for!

In the example case I've attached the dynamic_entity.lua script to the decals and named the decals appropriately, i.e. by the name I want to call them in the script.

Then I've attached the de_ test.lua script to the chalkboard entity, in that script is the control logic to decide which decals to use and when to show them, which is as simple as I could make it!, and finally a call to update the decals.

(So there are 9 entities, 3 chalkboards with the de_test.lua script and 6 decals with the dynamic_entity.lua script attached.)

In the de_test.lua script you will find a DE_Register call, this passes the name of the decal and a list containing it's positional offsets relative to the origin of the chalkboard. Scaling of the entities to fit nicely must be done manually in the editor as currently there is no way to get an objects shape/size parameters from within Lua.

Once set up you can position/rotate the control entities (i.e. the chalkboards) any way you like and the decals will be repositioned/rotated to suit by the Lua scripts.

The functions provided are:

DE_Register( e, name, list )
DE_Show( e, name )
DE_Hide( e, name )
DE_Update( e, x, y, z, q )

In all cases 'name' is the name of the decal and e is the entity id of the controlling entity (iow the same 'e' passed in from GG to the 'main' function). 'list' is a list containing positional info for the entity which takes the form:
{ xo = <value>, yo = <value>, zo = <value>, angQ = <quaternion> }

the <values> are simply the offsets in each axis, angQ is optional and is the rotational difference between the two entities in quaternion form. I'll post another example later today which uses this.

DE_Hide will hide all entities registered that have 'name', DE_Show will show them.

DE_Update simply updates the position/rotation of all registered entities that are currently 'showing'. x, y, z is the position of the control entity and q is the quaternion representation of its rotation (which you get from the quatlib function FromEuler).

DE_Update should be called whenever the controlling entity is repositioned or rotated, for simple examples like this calling it every frame is fine.

I'm not done with this yet, will be expanding this gradually but I thought I'd publish something usable to begin with.

I've modified this slightly so that if you position the decals in the editor first and don't specify a 'list' parameter it will work it out for itself. Look at the attached example, spaceship.lua, to see what I mean.

Bit more of a fun example, not really much different from the other example code wise:

Another example:

This is brilliant. Works really well

I've given up on volumetric particles coming from this next update of GG so this will help me get smoke decals going instead (steampunk without err, steam and smoke isn't quite right ).

Thank you.

@cybernescence: Well if one person around here can make the most of this it's probably you.

The major hurdle for me on this one was making it simple enough for anyone to use, took some effort to do that but I think I've succeeded.

Next I plan on additions for GraPhix to light a fire under his strange red bloke model. Doing this with decals and blocks is one thing, doing it with animated models adds a whole nuther level of complexity which will be tough to simplify.

Edited to add latest script: Added CollisionOn/CollisionOff to Show/Hide functions.

Your just too cleavererererer rofl

Wow man, just wow. This is something else.
Gonna keep me busy for a while!

Really impressive stuff, thanks for all your hard work dude.

Another fun example:

And another:

(this version has a new function to enable you to get a list of registered entities)

Thanks Amenmoses, I will give it a try with Bods animated trains.

Edit- is the quatlib.lua the same as the one used for the helicopter script or do i have to change it ?

The quatlib has been fixed (cybernescence found a bug) so although it will work with the helicopter it may fly the wrong way!

I need to update the helicopter scripts at some point to use the new modules.

Simply move the old quatlib into a subdirectory and change the helicopter scripts to reference the old one for now, that way if Lee does deliver this one in the final DX11 build it won't overwrite it.

btw, there are 4 dust puffs on top of the stack, each is rotated by 45 degrees to give the illusion of a spherical 'puff', that way no matter what angle you look at it from (except straight down!) it will look ok.

Wow, AmenMoses, thank you! Your wonderful idea simplifies many tasks !
Including the glass cockpit (or weapon or other thing) near the aircraft (or car) as an option.

Slightly different example this time, in this video I've got two trucks, or rather it appears that way. In fact they are the same truck with two sets of attached entities. I simply relocate the truck to a different part of the map, along with it's attachments whilst hiding one set of attached entities and showing the others. As long as the movement is done whilst the player cannot see the truck the illusion is complete. (see what I mean about smoke and mirrors!)

If this technique is paired with my zones scripts you could have the same minimal set of entities following the player around as they move around the map.




Attached piccy showing what it looks like in the editor and the scripts themselves.

The truck_plus.lua script is added to the truck, the truck_position.lua is added to a couple of small entities which are simply positioned where the truck should be moved to, the script could be simply extended to more positions if necessary. All the attached entities are given the dynamic_entity.lua script posted above.

All the attached entities have physics off and the truck is set to be immobile, all entities are also set always active.

You Rock! Fantastic!

Made a small but significant change to the script, the DE_Update function can now take a second quat as a parameter.

Bit of explanation as to how the parameters work:

function DE_Update( entity, x, y, z, quat1, quat2 )

'entity' is the e number of the base entity, in the video this is the 'stealth_ship' model.
'x, y, z' is the new position of the entity that the function uses to reposition the registered entities.
'quat1' is the quaternion representation of the 'entity' rotation.

If that is all you provide then the registered entities, in the video that is the 16 decals, would be positioned and rotated by the values provided on registration (if no rotation was specified then they will be set to the same rotation as the 'entity').

'quat2' is optional and specifies a second rotation to apply *after* the positional rotation, in the video this can be seen as the decals rotating around their 'z' axis.

Cool innit?

Thank you.

I really like this one, got a sort of Matrix vibe going on.

In fact it's hard to believe they are simply 2D decals.

ooooohhh that's so cool can that be attached to GraPhiXMaN's chest plate ????

Any decal or entity can be attached to any other decal or entity, that's the whole point! If you can work out where the attachment point is wrt the base objects origin then this works fine. Unfortunately for animated models working out the attachment point is not possible without some help from the engine.

It is quite difficult to explain why but I'll try. Imagine that your character is standing upright at frame 1 of it's animation sequence, we can determine the attachment point as simply the x,y,z offsets from the models origin to the centre of the chest plate. Now imagine that we start an animation where the character sits down. At frame 2 the chest plate has moved and we can calculate the new position of the chest plate BUT (and it's a big BUT) what the player sees on screen is not a sudden shift from frame 1 to frame 2 but an interpolated sequence of movements, i.e. the engine creates in between frames on the fly so that the animation looks smooth.

The problem is that these intermediate 'frames' are not part of the model itself, nor does the engine allow Lua access to the data that generates them so we cannot calculate the attachment positions for them.

The result is that the 'attached' entity or decal will appear to move in a jerky fashion compared to the model itself. The reason my examples look so darn good is that the models are static so the attachment points are always the same, I am moving them frame by frame along with the model itself.

If the engine provided a function whereby you could specify the offsets for 'frame 1' and it would return the adjusted offsets for the currently displayed intermediate frame then this would be doable, and extremely powerful! (Over to Lee. )

The alternative is to forego animation completely and, like for the Mech stuff, animate the character parts individually from the scripts, unfortunately that is really really hard!

I hope that one of these threads gets Lee's attention!

Btw, I feel like I'm only scratching the surface of what is actually possible here, I am only human after all and limited by my own imagination so if anyone can see a possible use for this that I haven't please pipe up and I'll implement an example of it!

Hmm you've gone a bit psychic there master

I was going to post how this approach would be great for propellers attached to entities but you have beaten me too it before I asked.

Cheers.

Wondering if we have enough lua commands yet to make this work by the limb data info from the global.lua file.

Limbs work for boned animated objects.

Just a thought.
Then we could attach entities or decals to the limb root of the hand or arm. That should narrow down the coordinates for placement and update position.
Possible making the transition smooth.

Yeah I am thinking along the same lines as Myke what if we created a DECALSPOT much like a firespot we attach weapons to firespot bones can we not have a bone for decals as long as we use the 'onionskin' option in animation software we can see all half frames too and should be enough for the human eye to see it as one animation

Ive just had another thought I am not using the HOLSTER bone what if I move that to the centre of the chest plate could I use that to attach a decal to see if it works there must be some reference in lua for the HOLSTER limb ?

If there is some way of getting the limb position and rotation from within a Lua script then it should work fine.

Doesn't seem to be a way, or at least I can't see anything in global.lua that could do it.

There is a limb index and some commands which suggest you can move limbs:

SetLimbIndex(e,v) -- how many 'limbs' can you have?

RotateLimbX(e,v) -- Umm, without some idea of what v means these are pretty darn useless.
RotateLimbY(e,v) -- Is it a value to rotate by in world Euler axis, or a value to rotate to?
RotateLimbZ(e,v) -- Or is it relative to the character axis? Or is it a joint angle?

Maybe I'll go experiment with these but couldn't find any GetLimbAngle or GetLimbPos style commands.

It might be worth looking at how the FIRESPOT works first may be reverse engineering the firespot may lead to some clues I will have a look too see what I can find, I moved the firespot to graphixmans groin so that he didn't point is hand to shoot lol it seemed to have worked ok

V is just the value isnt it e,g RotateLimbX(e,45) will rotate the limb on the X by 45? for animations such as double guns twisting on the wrist etc

Sounds so simple when you put it like that, assume I want to move your forearm bone, go on hold it out in front of you. Now which axis is 'X', which is 'Y' and which is 'Z'? Is the rotation angle relative to the upper arm? Is the rotation centre at the elbow or the wrist? Or the centre of the bone?

I did some brief experimenting and it works but I haven't figured out the answers to these questions yet. too busy adding jets and stuff to the stealth ship ready for it's New Year delivery.

Couldn't find any mention of firespot commands in global.lua btw.

Please dont forget to fix the helicopter script , my helli fly way up and very slowly

Thanks again for all your brilliant scripts

You can get limb positions but not rotation.
Pretty sure its something like g_Entity[e]['limbx'] (I think you need the limb id though, never actually used it myself)
Its near the top of global.lua anyway but as amen said, without knowing the rotation you still only have half the picture.

Firespot is not handled in any of the lua scripts so we have no access to that data and I've never heard of the holsterspot so I assume this is something from fpsc.