how to adjust (lengthen) the on-screen message for an objective completion?

[Komag]

Is there a way to make the on-screen message stay longer, when you pick up a special loot item?

[Komag]

help??? I'll just release without this if I have to, but it would be nice

[Bikerdude]

Hi dude, I wish i knew myself..

[Fidcal]

Nobody knows. I did a quick browse through some guis but didn't see anything. If this is some special item you want the player to know he has got it then maybe add some fine text to the inventory icon? Need to allow space for the hud text. It will disappear when the next loot item is picked up.

[Komag]

Yeah, it shows in inventory with the name I gave it, so I guess that will just have to be good enough then, thanks

 

-oh, now I think you mean something more than just the name, but now that I've tested it some more I think it's good enough as is.

[rich_is_bored]

The responsible gui is tdm_message.gui right? From what I gather by looking at it, it fades out when it receives a doFadeOut event from the engine.

 

The only way you'd be able to change the duration the message is displayed is if you were able to pass a value to the engine. Looking at the training map I see a few triggers have the key "message_long" along with a numerical value. Perhaps this will do the trick?

[Komag]

That didn't work when put directly on the object. Might have to set up a whole trigger system for it to get the effect, don't want to mess with that right now though

[Fidcal]

I don't think that is the same gui. That message gui is for the special help messages that show in the trainer. I think Komag means the message you see at the bottom of the screen whenever you pick up anything, eg,

 

"Acquired log book"

 

Which shows briefly as the item goes into the inventory. I think there is an option to turn that off. Maybe there is a cvar for the duration it shows?

 

BTW from what you are now saying I wonder is this really a loot item? If it shows in the inventory with a name then it's not loot because loot doesn't show it's individual inventory name - it just shows loot and the values. You mean a special objective item presumably?

[Fidcal]

Browsing again I'm pretty sure it's tdm_inv.gui at the section headed...

 

Inventory Pickup Messages

 

But I wouldn't mess with that because if you customise that then it can conflict with a future update.

 

I can't see any obvious cvar. I think it's just a fade time in the above gui.

[Tels]

If you make a small testmap and put in a tracker enty, I am fairly sure I can add a customize delay spawnarg to achieve what you want.

 

tdm_message.gui is indeed for the onscreen messages. It is however, sadly, not used by the training mission, it uses its own system of scripts (which I always wanted to throw out and replace with the simpler messages but have enough todo already)

[Komag]

that would be for the next version of TDM though, right?

[Tels]

that would be for the next version of TDM though, right?

 

Of course, it is too late for this version since we already released it back in May and my time machine is broken again

[Komag]

Okay, yeah yeah, I thought that, but I just wasn't sure how it worked like maybe it would be something I could include with my mission files or something.

 

I'm not sure how to upload a test map for it, I'll look into how the bug tracker wants that...

[Komag]

Okay, I tracked it, and added the test map "notificationtime.map"

[Tels]

Okay, I tracked it, and added the test map "notificationtime.map"

 

The time to display the message is hardcoded, but unfortunately in a GUI file in tdm_hud.gui:

 

       // greebo: This is used to display notifications like "Game Saved" and such
       // The state int "HasMessage" can be used to check whether a message is currently being processed (== "1")
       windowDef Message
       {
               rect            0,10,640,100
               textalign       1 // center
               text            "gui::MessageText"
               font            "fonts/carleton"
               forecolor       1,1,1,0
               visible         1
               textscale       0.35

               onTime 0 {
                       set "gui::HasMessage" "1";
                       transition "Message::forecolor" "1 1 1 0" "1 1 1 1" 200
               }

               onTime 3000 {
                       transition "Message::forecolor" "1 1 1 1" "1 1 1 0" 200
               }

               onTime 3300 {
                       // Signal that we are done here
                       set "gui::HasMessage" "0";
               }
       }

 

I am not sure it is possible to change the "onTime 3300" to something like "onTime gui::messageTime", if yes, then we can set it from code, if no, we would always have a particulare hard-coded time.

 

The code to display the normal "popup" messages that can be displayed during a mission as hints etc does work differently, it creates a new GUI, then adds the message, then waits for X seconds, then calls fadeout the removes the GUI. That works, but is quite more complicated.

[Tels]

Ok, here is an idea:

 

* Lengthen the default time to 10 seconds (is 10 ok?)

* add

 

       // Restarts the message object
       onNamedEvent DisplayMessageLong {
               resetTime "Message" "0";
               set "Message::visible" "1";
       }

 

Then change:

 

       // Restarts the message object
       onNamedEvent DisplayMessage {
               resetTime "Message" "7000"; // 0 => 7000
               set "Message::visible" "1";
       }

 

e.g. reset the time normally to 7000. E.g. for normal pickup messages, only 3 seconds are left, for "long" messages we have the full 10 seconds.

 

Disadvantages: Still not player controllable, and still no variable time from code.

 

I'll toy abit around with the gui code.

[Tels]

Hm, ok, after thinking here are our options:

 

* optional: make the cvar that contros the HUD messages from bool (0 => off, 1 => on) to a length multiplier (0 => off, 1 => normal length, 0.5 => half, 2.0 twice etc). This way players can tweak the message length on top of what we set for different messages. The in-game HUD messages, the pickup messages as well as the message GUI should use this factor to adjust their times.

* add a "message length" field to all in-game HUD messages, so they can have different length. Init this field from a spawnarg from the object that is picked up

* when displaying a inv pickup message, set the normal length (e.g. 3000 ms) x the cvar factor above

* when displaying a HUD message, set the normal length (e.g. whatever the spawnarg said or the default of 3000 ms) x the cvar factor above

 

Disadvantage of all that is:

 

* a bit of code work

* only works from v1.03 onwards

 

Short term solution for you, Komag:

 

* Use the message gui and just display your own message via a trigger on top of the normal pickup messag that says whatever it should say for however long.

[Komag]

Right now it lasts about one second, three would probably be good

[Tels]

Right now it lasts about one second, three would probably be good

 

Strange, the tdm_hud.gui file has 3000ms (aka 3 seconds) in my SVN version?

[Fidcal]

There is probably some loss somewhere along the line. It is rather fast although I don't really bother about it too much. You can see the acquired item in the inventory. As I recall, greebo asked for testing internally and one or two of us replied it was OK and so it seemed. I think this is harmless except it might annoy anyone who prefers minimal hud. Take the quick fix. Try adding 2 seconds but increase the fade time to 2 seconds (if the fade is part of the 2 seconds) so it is less obtrusive but can still be read. and if the majority are against it then mark it up to reduce it by 1 in the update after that.

[Komag]

Well the messages at the TOP of the screen are about three seconds, it's the one's at the bottom that seem to be one second

[Tels]

Well the messages at the TOP of the screen are about three seconds, it's the one's at the bottom that seem to be one second

 

Ah! Because I was about to code a solution to make the top message (new objective) last longer. So you say we need a way to make both longer.

 

Edit: The solution for both is the same, we need a way to:

 

* store the length for each message (currently the code only stores the message)

* pass that length to the GUI (this does not really work, it seems the GUI canonly read hard-coded strings for the time values, but not variable names, or at least I could not get this to work in almost an hour testing various combinations thereof). So we need to make a GUI that can display a message indefinitely long,then have the code to:

 

** start the message

** wait the desired amount

** stop/hide the message, then proceed

 

That means quite a few code-changes, I'll see that I get to that on the weekend (no promises, tho

[Fidcal]

D'uh? You quote Komag saying effectively "the top one is OK, it's the bottom one is too quick" and you reply "So you say we need a way to make both longer." You need to slow down the time you spend reading and increase thinking time.

[Tels]

D'uh? You quote Komag saying effectively "the top one is OK, it's the bottom one is too quick" and you reply "So you say we need a way to make both longer." You need to slow down the time you spend reading and increase thinking time.

 

I know what he wrote because I read it I am saying we need to make "both" longer because:

 

* both are sep. way how messages are handled (they are on two different GUIs)

* AND he wants the bottom one to be longer, but you can bet next week someone comes and wants the top one to be longer

* making the length adjustable is nearly the same wether I do it on one or two GUIs anyway. The code is basically the same..

 

So there