by Lord Misfit » Thu Feb 07, 2019 3:48 pm
https://github.com/LordMisfit/TempRepo1/ - OKAY, so I think I got this set up right [this is a new commit, unrelated to the previous bug I reported using this repository]
So from what I'm figuring out here, the issue I'm having with HUDMessage is the "holdtime" parameter, specifically values less than 0.0572205 seconds. So if the value is between
0.028656 and 0.0571289 seconds, HudMessages with either no flags whatsoever or just the "HUDMSG_ALPHA" flags just don't appear AT ALL (it DOES show the hudmessages though if HUDMSG_FADEOUT or HUDMSG_TYPEON are in the flags as a side note), and it just so happens most of the holdtimes I have on Aetherius's HUD fall within said range (~0.028 to 0.030 seconds, or basically about 1 "tic" converted to "seconds", since the holdtime parameter doesn't take tics, but seconds as a value.), so over 90% of them weren't appearing at all. Any Hudmessage with a higher time than
0.0572205 seconds [like damage indicators on hit, the tunnel-vision/death graphics, and the level completion bonuses] still show on screen like they should.
However I also saw when I was making my condensed test case, that if you set a holdtime from
0.0~ to 0.285645 [less than the range where it was just flat out NOT appearing], the hudmessage does appear, but it does not GO AWAY even if the delay on the script running the HUDMessage function
gives enough time that the message SHOULD. I have two main scripts in the example above, one with a 1 tic delay [so those messages should never "disappear"], and one with a 35 tic delay[which gives the messages time to disappear before they reappear again]. The top four messages are from the first script, and the bottom four are from the second script. There are a few messages in these scripts with a fixed holdtime of 0.036 seconds [the time Aetherius was using for most of them, for a flat example], so in the branch, they will always fail to appear if they don't have the HUDMSG_FADEOUT or HUDMSG_TYPEON flags, but should always appear when loading this with a recent DRDTeam SVN like 3.8pre-206.
There are also two debug scripts for altering the "holdtime" of the HUDmessages directly: "HoldTimeDebug" and "HoldTimeDebugInc" which you can alter with "pukename" to set the holdtime [either directly for the first debug script, or to force the holdtime to automatically tic up by a value every tic of game time based on the second debug script]. The way it's looking and I can only guess this, is that something in the refactor branch has changed or altered the way holdtime is calculated [like it subtracts a tic or two's worth of time from the holdtime value before the command is ran] vs the current DRDTeam SVNs like 3.8pre-206-g780b7f23 [which all messages will show no matter what the delay is as long as it's not all a solid 0].
I also just noticed with testing that DRDTeam SVN version with my test repo that any holdtimes of 0.0001 to 0.285645 still don't make the hudmessage disappear after the time "elaspes" [which in itself might be a "bug" with the holdtime in ACS anyways], but it will still show the HUDMessages on screen when the holdtime is between 0.028656 and 0.0571289 seconds unlike in the refactor branch.
Also just minutes ago I tested all of this with the new V3 version of the branch from the Discord server and the issues still presist, so in this reply still goes. o.o
I REALLY hope this does something to help. I was up earlier than I normally am to figure this out because I couldn't get back to sleep after briefly waking up and seeing Graf's request for a condensed repo to test this with, and it was keeping me awake trying to figure out what was going wrong.
https://github.com/LordMisfit/TempRepo1/ - OKAY, so I think I got this set up right [this is a new commit, unrelated to the previous bug I reported using this repository]
So from what I'm figuring out here, the issue I'm having with HUDMessage is the "holdtime" parameter, specifically values less than 0.0572205 seconds. So if the value is between [i]0.028656 and 0.0571289[/i] seconds, HudMessages with either no flags whatsoever or just the "HUDMSG_ALPHA" flags just don't appear AT ALL (it DOES show the hudmessages though if HUDMSG_FADEOUT or HUDMSG_TYPEON are in the flags as a side note), and it just so happens most of the holdtimes I have on Aetherius's HUD fall within said range (~0.028 to 0.030 seconds, or basically about 1 "tic" converted to "seconds", since the holdtime parameter doesn't take tics, but seconds as a value.), so over 90% of them weren't appearing at all. Any Hudmessage with a higher time than [b]0.0572205[/b] seconds [like damage indicators on hit, the tunnel-vision/death graphics, and the level completion bonuses] still show on screen like they should.
However I also saw when I was making my condensed test case, that if you set a holdtime from [i]0.0~ to 0.285645[/i] [less than the range where it was just flat out NOT appearing], the hudmessage does appear, but it does not GO AWAY even if the delay on the script running the HUDMessage function[s] gives enough time that the message SHOULD. I have two main scripts in the example above, one with a 1 tic delay [so those messages should never "disappear"], and one with a 35 tic delay[which gives the messages time to disappear before they reappear again]. The top four messages are from the first script, and the bottom four are from the second script. There are a few messages in these scripts with a fixed holdtime of 0.036 seconds [the time Aetherius was using for most of them, for a flat example], so in the branch, they will always fail to appear if they don't have the HUDMSG_FADEOUT or HUDMSG_TYPEON flags, but should always appear when loading this with a recent DRDTeam SVN like 3.8pre-206.
There are also two debug scripts for altering the "holdtime" of the HUDmessages directly: "HoldTimeDebug" and "HoldTimeDebugInc" which you can alter with "pukename" to set the holdtime [either directly for the first debug script, or to force the holdtime to automatically tic up by a value every tic of game time based on the second debug script]. The way it's looking and I can only guess this, is that something in the refactor branch has changed or altered the way holdtime is calculated [like it subtracts a tic or two's worth of time from the holdtime value before the command is ran] vs the current DRDTeam SVNs like [url=http://devbuilds.drdteam.org/gzdoom/gzdoom-x64-g3.8pre-206-g78c0b7f23.7z]3.8pre-206-g780b7f23[/url] [which all messages will show no matter what the delay is as long as it's not all a solid 0].
I also just noticed with testing that DRDTeam SVN version with my test repo that any holdtimes of 0.0001 to 0.285645 still don't make the hudmessage disappear after the time "elaspes" [which in itself might be a "bug" with the holdtime in ACS anyways], but it will still show the HUDMessages on screen when the holdtime is between 0.028656 and 0.0571289 seconds unlike in the refactor branch.
Also just minutes ago I tested all of this with the new V3 version of the branch from the Discord server and the issues still presist, so in this reply still goes. o.o
I REALLY hope this does something to help. I was up earlier than I normally am to figure this out because I couldn't get back to sleep after briefly waking up and seeing Graf's request for a condensed repo to test this with, and it was keeping me awake trying to figure out what was going wrong.