Page 1 of 1

[level refactor branch v2+3] HUDMessages (ACS) don't display

PostPosted: Wed Feb 06, 2019 6:17 pm
by Lord Misfit
As said in the topic. So running Aetherius works in that it loads up in the v2 branch where it didn't before in v1, but unfortunately, no HUDMessages via ACS show up. Using "ACSProfile" in the console reveals that scripts do SEEM to be running, and I can activate the mod's in-game menu which freezes the player and monsters in place, but I also can't see the menu itself. I also don't know if this is messing with OTHER ACS commands or not. >.>

I was going to wait until I had confirmation others where having the same issue, but I was told I should post the bug immediately for the branch's sake, so I hope it's not just me having the problem. <.<; - link for testing

Re: [level refactor branch v2] HUDMessages (ACS) don't displ

PostPosted: Wed Feb 06, 2019 10:28 pm
by Kinsie
HUDMessages seem to be working fine in my mods, but I'm also not building menus out of 'em.

I quickly checked Xaser's Psychic just to be sure (since that also has an ACS HUDMessage-based menu) and that seems to work fine as well.

Re: [level refactor branch v2] HUDMessages (ACS) don't displ

PostPosted: Thu Feb 07, 2019 2:00 am
by Matt
HUDMessages work fine in HD. (4f0850b)

Misfit, is the relevant script in Aetherius "hudmessageonactor" in ... ELLSRC.acs ?

Re: [level refactor branch v2] HUDMessages (ACS) don't displ

PostPosted: Thu Feb 07, 2019 2:39 am
by Graf Zahl
Please post a CONTAINED runnable example. This simply is not testable.

Re: [level refactor branch v2&3] HUDMessages (ACS) don't dis

PostPosted: Thu Feb 07, 2019 4:48 pm
by Lord Misfit - 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[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 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.

Re: [level refactor branch v2] HUDMessages (ACS) don't displ

PostPosted: Thu Feb 07, 2019 5:28 pm
by Graf Zahl
Why are you even using such times? With single tic durations you are always at risk that the tic expires before anything can be seen.

Re: [level refactor branch v2] HUDMessages (ACS) don't displ

PostPosted: Thu Feb 07, 2019 5:42 pm
by Lord Misfit
Mostly because those hudmessages are in scripts that are "delay(1); + restart; at the end" types, so I figure a delay of just over a tic means they stick around for just the right amount of time, unless a requirement in the script for certain displays isn't met and then it means the affected parts of the code can immediately disappear instead of staying/lingering on screen for too long. I know it sounds like it's a really small time frame, but that's how I did it, and the point here is that the branch still changes something here, regardless of "good" or "bad" use of coding.

I suppose I could try to make it more of a 2-3 tic equalvalent, but I feel like doing that also means I'd have never noticed this issue in the first place. I'm not necessarily saying you're wrong with the delays vanishing too fast, it's just how I found myself coding all of this when I initially did this, and it's only now with the new branch that this issue is showing up, I guess.

Re: [level refactor branch v2+3] HUDMessages (ACS) don't dis

PostPosted: Fri Feb 08, 2019 3:00 am
by Graf Zahl
First things first: Your observation that very small durations make the message last indefinitely is correct. This is intentional, because a value of 0 for the duration means the message won't go away. And these small values get truncated to 0.

The rest is because I had to move the status bar ticker after the gameplay ticker, because otherwise it would receive old game state. This also means that as a result the messages will get ticked once before they even show up. While easily fixable once I knew what was up this is a clear case of desigining a system with no margin for error. The HUD messages will be deleted if a replacement with the same ID is added, so you could easily set them to a longer duration.

(Besides, ACS menus really are something best forgotten due to the shitty UX.)

Re: [level refactor branch v2+3] HUDMessages (ACS) don't dis

PostPosted: Fri Feb 08, 2019 10:51 am
by Lord Misfit
Yeah, I'd love to be able to immediately move the HUD/Menu stuff out of ZScript, but I don't yet have the knowledge for doing that for the menus.

And as for the actual HUD itself (the ACS parts), I'm only basing this next thing on hearsay from a couple of others, but someone had offered to see how well my meters with their 50-200 notches each would convert to a ZScript hud, and while it worked, they noted that even having a couple of filled up meters on the screen had appearantly REALLY bogged down performance, even vs the ACS ones, and I think they said that unless it could be optimized more, it would be better for now to keep the HUD [at least the meters] in ACS for now. Again, I don't know if this is true personally since my ZScript HUD experience is limited to a customized inventory bar (adding visuals for customized/dynamic inventory limits) and nothing else, so I can't currently try making this myself to confirm if they were right or wrong on this one.

Even so my ACS-to-ZScript experiences so far have been more getting the more mechanic aspects of the mod like equations/formulas/background-actions for things and game mechanics moved as opposed to focusing on moving the visual elements [partly also because having those things moved over to ZScript means I can tweak them on the fly without having to restart entire games, as changing ACS effectively breaks any savegame using the old ACS code, as I'm sure you know].

I don't blame any of the developers for this personally, but man I wish ZScript had been available back in the early 2010s when I started the mod. :P I'm pretty sure I'd have been a lot less inclined to rely on ACS for so long, which obviously led to a lot of the hubris of having to convert things over when it came out, but still I'm glad we have ZScript to begin with. :V