Colored hands - hypothetical implementation / food for thought

[Gumba Jonny]

Before I start talking about this I'd like to say that I haven't messed with Torque or modded Blockland in a long time, and that my familiarity with any sort of coding is less than basic.

I was thinking of a simple  hypothetical solution to the foremost classic issue with hands on weapons which is the fact that modeled hands are one static color. The reasoning behind this is simple - the hands are modeled in with the weapon and are just textured with whatever material the modeler chooses.

The solution I thought of is simple but seems sort of inefficient, and has probably been thought of before. You'd have a separate image datablock just for the weapon's hands, and the model has a blank texture with translucency turned off for exporting. When the weapon is equipped and the hands are placed into the player model's actual hands/mount points, whichever way you please, a script would run to shift the color of the hands image.

The way this would work is by obtaining the RGB color values from one of the player's hand nodes and just simply putting those values in a setColorShift function for the hands with the alpha set to 1 (or 0, cant remember which way makes it opaque lol). That way, the hands model will be set to the color of the player's real hands, and all is good.

The actual weapon model itself would just be mounted via a function into the normal point it would be mounted to anyway. The animations of both the weapon and hands would be synced like a normal weapon with hands, as if the hands and weapon were not separate models at all.

I'd like to know whether this'd work or not with this method. The only real problem I see, other than lots of datablocks, is the colorshift value change in the script, because apparently changing datablock values in a script is a bad idea. What do you guys think?

[Ad Bot]

[boodals 2]

There is no good way to change datablock values at runtime. That's the whole point of them, they are static values which are shared between server and client. If you change it on one side, you gotta change it on the other. For simple visual things, this usually doesn't matter, however for values which effect gameplay, it can seriously mess up client-sided prediction stuff.

However, changing the colorshift is a simple visual thing, so in theory we could do it, however it would effect the color of every image (or perhaps just newly created images? Needs experimenting).


There is no good way to do this, else people would be doing it already. One not so terrible solution which was discussed in a topic a while ago is to use playertypes as weapons; you can mount them, change nodes, animate, etc, and with sufficient scripting you can make them shootable. Unfortunately playertypes are much harder to create (afaik) than weapons, so nobody has really done it (which is surprising anyway).

[-Jetz-]

There is no good way to change datablock values at runtime. That's the whole point of them, they are static values which are shared between server and client. If you change it on one side, you gotta change it on the other. For simple visual things, this usually doesn't matter, however for values which effect gameplay, it can seriously mess up client-sided prediction stuff.

However, changing the colorshift is a simple visual thing, so in theory we could do it, however it would effect the color of every image (or perhaps just newly created images? Needs experimenting).

It'd have to be transmitted to all clients, not possible for just one field of one datablock.

There is no good way to do this, else people would be doing it already. One not so terrible solution which was discussed in a topic a while ago is to use playertypes as weapons; you can mount them, change nodes, animate, etc, and with sufficient scripting you can make them shootable. Unfortunately playertypes are much harder to create (afaik) than weapons, so nobody has really done it (which is surprising anyway).

A system like this could theoretically function but I can guarantee the implementation would be a complete mess in one way or another, and it wouldn't play nice with other add-ons.

[Gumba Jonny]

But why is it that you can edit a projectile's damage when it hits the target, like with headshots? Could you do the same with colorShift?
Could you create a local variable out of colorShift, like the way projectiles work with damage changing, and change the color of the hands image that way?
Or is it that image datablocks and projectile datablocks are handled differently in a way that would prevent this?

[Pecon]

But why is it that you can edit a projectile's damage when it hits the target, like with headshots? Could you do the same with colorShift?
Could you create a local variable out of colorShift, like the way projectiles work with damage changing, and change the color of the hands image that way?
Or is it that image datablocks and projectile datablocks are handled differently in a way that would prevent this?

Projectiles technically cannot have their damage modified 'on the fly' either. Modders work around this by simply applying more damage through script when certain parameters are reached. Images do not have any functions or values that simply allow us to change it's color at will.

[-Jetz-]

But why is it that you can edit a projectile's damage when it hits the target, like with headshots? Could you do the same with colorShift?
Could you create a local variable out of colorShift, like the way projectiles work with damage changing, and change the color of the hands image that way?
Or is it that image datablocks and projectile datablocks are handled differently in a way that would prevent this?

Damage is handled mostly through scripts. Color of mounted images is handled entirely in the engine, barring the initial setting of the value in the datablock. It has nothing to do with how the different types of datablocks are handled, just in how the specific properties are used by the game.

[Ladios]

Ideaish,
If you had a support_hands which on server creation generated an array of colored hand objectshape datablocks ,
The weapon which supports this on it has two invisible mount nodes for the right and left hands, and moves and rotates them according to where the hand would appear to be were it there.
At runtime on item load it would create the image of the hands relative to the closest color approximation to the player's hands, and mount them to the invisible moving gun mount points.
Thus dynamic reloading hand movement type things could occur, all with the color being independent of the gun model so you dont have to spam color itteration datablocks  per gun datablock, and just create one big 'ol pool o' hands.

[boodals 2]

At runtime on item load it would create the image of the hands relative to the closest color approximation to the player's hands, and mount them to the invisible moving gun mount points.

You cant mount anything to an image. Again, if you used bots then you could.

[Ladios]

Bots are images. They are images with mountpoints. You mount weapons to the bot image. When a weapon fires, a smoke emitter can be mounted to its muzzlenode.
Why couldnt a colored hand?