Damage Overlay - How Do I Link It To Health? Please Help!

#1 TGE has setDamageFlash. Which flashes the screen red for X amount. You would have to schedule it to keep the screen "flashed" and then once health restores allow it to fade.

Quote:So is there anyone out there that is able to help me figure out how to link "Player Health" to a GuiBitmap image opacity/alpha?

These might help:
Colour Filter Effect (Night Vision / Colourization)
Image Effect Scope / Night Vision

#2 In both of those tutorials (Colour Filter/Image Effect) the images are either on or off. I'm looking to link this setDamageFlash property to a value that would effect the opacity of an image.

I'm no programmer by any means... :(

#3 Just a thought but ...

You could try and script it using the OnDamage function in player.cs.

e.g. (beware - psuedoscript) 
if(%delta > 30){
%this.showgui = true;
};
(/beware - psuedoscript)

That might get your overlay on, but you'd have to look at then getting it off with regenerating health.

Or you could just write a script to call the %player.health using a schedule and then modify the "%this.showgui"... but that's not really best.

Anyhow, the call for "setdamageflash" is in there.

#4 So if I can figure out what variable hold the players health...

Then I could write a big if/case statement that would display a certain image at certain values of health. When the health is regen'ed it should update the image as well, seeming that it's based off of that variable, right?

Sounds good on paper. :P

Have any of you guys played COD4? ( Call of Duty 4 ) That's what I'm attempting to imitate.

#5 If you're willing to consider engine changes (as opposed to script-only solutions) to accomplish your ends, there is a fairly easy way to modify TGE to do what you want are asking for.

Look in ShapeBase.cc, and find the method ShapeBase::processTick. You will have scroll down quite some way in this method listing (in an unaltered copy of ShapeBase.cc, I found this around line 982). The very small block of code you want to change begins...

// Update the damage flash and the whiteout
   //
   if (mDamageFlash > 0.0)
   {
      mDamageFlash -= sDamageFlashDec;
      if (mDamageFlash <= 0.0)
         mDamageFlash = 0.0;
   }

Comment out all the stuff shown above about mDamageFlash (the stuff about whiteout which immediately follows this can stay... it's not relevant to this effect). And replace it simply with this...

mDamageFlash = this->getDamageValue() * 0.5;

As you can see, this co-opts the normal damage flash functionality to do what you described. Instead of "flashing" red, then fading away over a couple seconds, it colorizes the screen red in proportion to damage taken. I've tossed in the 0.5 as something that at near-death leaves the red filter still translucent enough to see through on my machine's video card, yet red enough to clearly imply the player ain't feeling too great. You simply need to tweak it to what works for you.

I don't know for sure what kind of performance difference it will make during a busy game (as opposed to a casual test), but it sounds so completely like what you are asking for, it's worth a try.


If you choose to stay strictly in script, then I'd only add the following caveat to what Steve earlier suggested: If using the onDamage callback to monitor when damage changes from script, remember than these callbacks are scoped to the player's datablock rather than the object instance. This matters for what you plan to do because you'll have to test whether the player being damaged/healed is the local client's player before changing the overlay visibility, otherwise damage/healing to any player (including bots) will cause your player's damage overlays to switch. IOW, you have to do something like (assuming a starting point like starter.fps):

// Add this into the Armor::onDamage function in /server/scripts/player.cs
if (%obj== localClientConnection.player) 
{
      if (%obj.getDamageLevel() > 25)
           // Do something to make the first overlay visible...
     else if (%obj.getDamageLevel() > 50)
          // Make the next level of overlay visible instead...
    // and so on for however many variable opacity overlays you wanted to add..

So, it can be done, but not as smooth or simple a solution as co-opting the damage flash functionality, though. The engine change (at least IMO) is far easier to implement.

#6 Is there a way to set the transparency of a GUI specifically? I know you can set the visibility, but what about alpha? If that's present, you could use the Armor::onDamage to send a message to the client with the crrent damage leel, and just use that to set the transparency.
However, I'd have to agree with Charles and say go with the source change. Source code is almost always a better alternative to script.

#7 Hmmm, modding the source code does make a 'red hue' appear when the player takes damage, but the red doesn't go away when the player heals.

I should probably find a better way to regenerate health. O.o"
I haven't seen many resources for that either.

#8 How are you currently regenerating health? If the Player object the engine is aware of has been healed, then the damage flash should go away.

#9 Odd. I tested this before I posted, and both damage and healing worked correctly for me. Diagnostically speaking, it sounds like your player object isn't really being healed. Assuming a script environment not too far removed from starter.fps, you could verify this by using the following line in the console window:

echo(LocalClientConnection.player.getDamageLevel());

... which echoes out the player's current number of points of damage. If healing isn't taking place, here's some things to check based on my own experiences when learning how damage and healing work...

First, did you set the repairRate variable in the player's datablock to something greater than zero? Intuitively, it seems as if repairRate means "I want the player to automatically gain back health at this rate" but that's really not how this datablock property works (this confused me enough I mistook it for a bug originally).

"repairRate" in the PlayerBody datablock sets the speed at which the applyRepair command does its work when you use applyRepair to heal. For example, in starter.fps, when you pick up a health, damage is healed using applyRepair in the background, but notice how the health bar smoothly animates upward rather than just
"ta da! you're healed!"? That's because in the default starter.fps, the PlayerBody datablock has a repair rate of 0.33, which means when you apply, say, 10 units of repair, Torque deducts 0.33 units of damage per game tick until the total cumulative repair equals 10 units.

One side effect of this is that if the repairRate property is set to zero (a common error if you're thinking you don't want auto-healing), then the applyRepair method does... nothing at all. Whoops. No error message, no warning, just no healing. This is what I mistook for a bug, but it was successfully argued to me that it was really my mistaken belief that repairRate had to do with auto-healing (which despite the name, it doesn't).

If you actually DO want the player to automatically heal over time, you need to use the .setRepairRate method on the player object. Despite the similarity of the names, this method has no relation to the datablock property "repairRate", but rather, this method does just what its name sounds like it does: it sets the number of points of damage per game tick to automatically heal.

So, depending on how you want to handle healing. If you...

Want to heal all at once, like picking up a med kit:

1.) Make sure repairRate is set to a positive value in your player's datablock. Set it to some low, fractional number if you want health to smoothly, gradually return upon taking the med kit. Set it to equal maxDamage if you just want instantaneous healing.

2.) When the player actually takes the med kit (/healing potion, whatever), use the applyRepair method. Example (assuming the variable %player contains a reference to the player to be healed...

%player.applyRepair(50); //would heal up to 50 points of damage.

If you instead want players to gradually heal at a slow steady rate through the game, then when you first spawn the player, use the setRepairRate method on the newly spawned player. For example, in starter.fps, in /scripts/game.cs, look for the GameConnection::createPlayer method and right after where it says

// AFTER THIS BLOCK...

   // Create the player object
   %player = new Player() {
      dataBlock = PlayerBody;
      client = %this;
   };
   MissionCleanup.add(%player);

   // ADD THIS LINE...

   %player.setRepairRate(0.1); // this will cause this player object to constantly regenerate 
                                                    // at 0.1 point per game tick. Adjust the argument for  
                                                    // faster (or slower) self healing.

That's the most I can really suggest. Hopefully something in all of that gets you where you want to be...

#10 This is the resource I was using to regen my health.
http://www.garagegames.com/community/resources/view/14877

Note: I am posting this before I read your comment Charles, hopefully I'll have something else to reply shortly.

#11 Wow, just-- Thanks a ton for that! I was going about regenerating the health all wrong. Granted, this gives a red-overlay which is fair enough to what I wanted.

Would a person be able to write a part of source code that says
(pseudocode, i am by no means a programmer :( )

Instead of:
On->DamageTaken Flash(256,0,0) //Instead of flashing red

On->DamageTaken Display(.../path/DamagePicture1.png)

Because if we trade out the color for an image, it should be able to be displayed as a 0%-100% visible image. Or am I just crazy?

#12 Hi,
I wrote this resource some time ago. Its some modifications in the engine in order to allow to set a color modulation in a bitmap control. That way you can create an opaque bitmap and set any transparency level you want (you may even set a color modulation). Set the transparency to 0 in order to make it transparent or to 1 in order to make it opaque or any other value between 0 and 1 to make it semitransparent. As you get more damage you can increase the transparency at will.

http://www.garagegames.com/community/resources/view/11774

I know you said you are not a programmer but hey... I am a programmer and sometimes use Photoshop... you must get wet sometimes...

Luck!
Guimo

#13 Guimo: your resource is excellent! I am delighted to say I learned something new about GUI control rendering by reading through it (which is good, since I need more experience on the rendering side of things!)

I was about to reply that the only way I know of to affect the transparency of a bitmap in a GUI control was to add an alpha layer to the image, but this wouldn't really be good for the purpose described by ITT019GreenBay since it would involve making several images, putting in multiple invisible overlays, and then doing an ugly scripting hack to switch them on or off by damage level. The solution works, but is clunky and limited.

After reading your resource, I can see a better solution. Even if one uses it only to add an alpha property to the GuiBitmapCtrl, one can then do a single overlay that can be linked to damage levels via the onDamage callback quite easily.

ITT019GreenBay: if this is really want to do this instead of a red tint, I can show you how to apply a variation on Guimo's resource and set up the necessary scripting side components to take advantage of it. It's not as easy to do as the simple red tint, but not too hard, either. I'd say it is the sort of thing you can put together in about an hour or less if you can compile Torque and already know the image you want to use.

#14 Aye, I have the images already created. It would be a great thing to do/have. I have compiled the engine multiple times so that's not new to me.

#15 @ Charles Fusner,

hell, I'm really interested in that!
please do tell how.

#16 No problem, then. Heres what you need to do. I just tried this out in a fresh install of Torque and it seemed to work. Hopefully this does what you need.

NOTE: Im running up against a word limit on replies here, so I m going to try splitting engine and scipt changes into two separate replies. I will start with the engine changes. This part is just a simple variation on Guimo's mod.

In guiBitMapCtrl.h, at the very end of the definition for the GuiBitMapCtrl class, we add a new public member variable to hold an alpha mask. Around line 49 (just after the line "void setValue(S32 x,S32,y);") add a new line which reads...

ColorF mMaskColor;

In guiBitmapCtrl.cc, there are three small changes. First, in the constructor for the GuiBitmapCtrl class (GuiBitmapCtrl::GuiBitmapCtrl) add this line at the end to initialize the new color mask we just added. Around line 18, just after the line saying "mWrap=false;" add this line:

mMaskColor.set(1.0f, 1.0f, 1.0f, 1.0f);

This makes our mod backward compatible with pre-existing GuiBitMapCtl objects by making the *default* alpha level for GuiBitMapCtrl objects totally opaque which was their previous behavior. Now, rather than exposing a public field, Im going to add a new console method. Add this new function to the very bottom of the file:

ConsoleMethod(GuiBitmapCtrl, setGlobalAlpha, void, 3, 3, "setGlobalAlpha(alphaLevel);")
{
     F32 alphaValue = dAtof(argv[2]);
     alphaValue = mClampF(alphaValue, 0.0f, 1.0f);
     object->mMaskColor.set(1.0f, 1.0f, 1.0f, alphaValue);
     return;
}

This gives GuiBitmapCtrl a new script method called setGlobalAlpha with which we will use to manipulate the transparency of the overlay. Only problem is, so far, the control ignores the value we set, so lets fix that next. Find the pre-existing method called GuiBitmapCtrl::onRender. Around line 126 there is a line which reads:

dglClearBitmapModulation();

Since this normally sets a bitmap control to totally opaque state, comment this line out and underneath, replace it with the following line instead:

dglSetBitmapModulation(mMaskColor);

Which will instead make our mask color determine the transparency. That is all the engine changes. Compile now and make sure you get an executable. Then its time to move on to the scripting changes.

#17 THE SCRIPTS:

Note: I’m going to talk in terms of starter.fps for the script side instructions.

The first thing to do is to add the overlay to your PlayGui definition. Put the desired image in starter.fps/client/ui. In my example below, I’m calling that image file “overlaytex.png” In this same directory open up the file called playGui.gui. In this file, we see the nested heirarchy of controls that make up a PlayGui. At the very end of this definition (but just inside the final curly brace) add the following new control:

new GuiBitmapCtrl(DamageOverlay) {
       profile = "GuiDefaultProfile";
       bitmap = "./Overlaytex.png";
       position = "0 0";
       extent = "640 480";
       horizSizing = "width";
       vertSizing = "height";
       wrap = "0";
       visible = "1";
    };

This adds your image as a new GuiBitmapCtrl aligned to the upper left corner, stretched across the entire PlayGui on top of everything else (because its at the end). More importantly, the definition NAMES the new element “DamageOverlay” so that we can conveniently reference it from script.

Now, remember above when we left the default transparency totally opaque? We need to fix that for this particular control, or the first thing the player will see is an opague image covering their entire view. Go to the file starter.fps/client/scripts/playGui.cs, and look for the function called PlayGui::onWake. To the end of this function add these lines:

// Initially make the overlay completely transparent
DamageOverlay.setGlobalAlpha(0.0);

At this point, all that remains is to “tie” the overlay to damage levels. Go next to the file starter.fps/server/scripts/player.cs, and find the function Armor::onDamage. As you can see, the default starter kit already does something with this callback. That’s OK, just add this extra code to the top of the function:

if (isObject(%obj.client))
     {
           %damageAlpha = %obj.getDamageLevel() / %this.MaxDamage;
           if (%damageAlpha > 0.75) 
               %damageAlpha = 0.75; 
           commandToClient(%obj.client, 'AdjustOverlay', %damageAlpha);
     }

This computes an alpha value based on the total damage taken to the max damage possible, then “caps” the value (so the screen is never totally opaque even near-death). Lastly, it sends off a message to the affected client to update their screen to this new level. This is the cleanest way to handle it, since the same code will work for both single player and multiplayer games this way.

Of course, this requires us to add a new client command to receive this message. This function simply needs to look like this:

function clientCmdAdjustOverlay(%newAlpha)
{
     DamageOverlay.setGlobalAlpha(%newAlpha);
}

And that should be it for the scripts. If everything was done just do, you should now be able to fire up the game and test your changes by taking then healing some damage.

#18 Yep... thats it. But you should have left the full color value in the console function, that way he can use a white overlay and change transparency and color at will. Maybe he can use red for damage... maybe green for poison, purple for radioactivity and so on.

...or... first just get this one working and then you can move to something more complex.

Luck!
Guimo

#19 that looks wonderful, thanks Charles.
will only be able to try it out in 2 more days,( I'm busy generating a 128000X128000 texture in L3DT for a 131kmX131km terrain, been generating for 2 days already, takes 4 days and my other pc doesnt have torque installed on it)

#20 @ Guimo - That's a good thought!

Using a white overlay and tinting differently for different damage types is a nice extension of the idea, actually. And really, it's very easy to add. One need only add one more console method as follows:

ConsoleMethod(GuiBitmapCtrl, setGlobalMask, void, 3, 3, "setGlobalMask(r g b a)")
{
     dSscanf(argv[2], "%g %g %g %g", 
	                  &object->mMaskColor.red,  &object->mMaskColor.green,
			  &object->mMaskColor.blue,  &object->mMaskColor.alpha);
	 return;

}

Which could be used either like:

DamageOverlay.setGlobalMask("1 0 0 0.5"); // change to a red tinted 50% mask

or:

DamageOverlay.setGlobalMask("0 1 0"); // 3 components changes to green while leaving alpha alone.
// This part surprised me, but I just tried it and it worked.


I'd recommend keeping the other method too, but change it to read as follows...

ConsoleMethod(GuiBitmapCtrl, setGlobalAlpha, void, 3, 3, "setGlobalAlpha(alphaLevel);")
{
     F32 alphaValue = dAtof(argv[2]);
     alphaValue = mClampF(alphaValue, 0.0f, 1.0f);
     object->mMaskColor.alpha = alphaValue; //this line different
     return;
}

...which would allow the one function to change the transparency while leaving the color alone, while the new method allows the whole color to be changed). This combination would give the script writer total flexibility on how to use this new feature.