[Posila] [1.1.36] Starting message dialog is darkened in the Sandbox scenario

[curiosity]

To reproduce:
1. Start the Sandbox scenario.
2. See the darkened message dialog (see image).
3. Compare to running the following command:

Code: Select all

/c game.show_message_dialog{text = {"msg-introduction"}}

What I expected:
Both dialogs behaving the same way, remaining undarkened.

[KeepResearchinSpoons]

I've made you a simple "afterburner" to skip the first tick where it scans.
When you show the same message over the second tick (or later) the scan goes off normally (it happens NEXT tick actually but whatever, atomic events).
and then it does show it better.
Or maybe it happens so for a completely different reason.

Well, It does solve your problem. :>
I've just ran it on tick+2 successfully. But it may be safe to go for tick+3 actually, Events arrive in the somewhat tricky random order, so off by one is a general safety margin here for the most cases.


[edit: added this part]
According to feedback, +2 is indeed sometimes darkened.
But the new issue is that it flickers with a whitish light right before getting to show you a good non-darkened message over the dark bg.

Maybe you would want a second or two as fade-out now that it flickers...
Or maybe you would want a gui fix that does not darken in the first place?
Bughunting is fun: you solve the mystery to introduce another one! or two. ... or three.
The suggested solution usually "works". Forces, surfaces, setting up spawn-points and teleport gates... But well, probably not so good this time :>
[/edit]


The "fixed" code you can try yourself is here:

sandbox.lua.zip

(1.71 KiB) Downloaded 159 times

went to 6kb from 5kb and got on_tick handler for "just nothing" :>

Get a copy of a base/scenarios/sandbox to your user-scenarios folder, rename sandbox.lua there to a backup one, unpack downloaded file and place the file there instead of the previous one.
It should work fine. At least for what you need/want to do with it.


However for production code, I would STRONGLY suggest getting a tick_event-removal done better.
I have a number of options on how to do it (the augmented que, the shift all later elements etc).
The problem with those is either licensing (both mews have gpl, can't put gpl to factorio base obviously) or complexity (i have somewhat apache-2.0 ques, but they are overkill by a nuke-fat margin with weights and de-huffman for depack etc).
The real reason is that the table does not shrink in mem and in size when you simply "nil" somewhere in between.
Should be fine though, cuz it only has on_player_joined for 2 ticks, that should not snowball anywhere.

And since we probably do not have mem-"gc" for tables that got "shrink-ed since" in size, you might want a better version to be a bit more fool proof and random-proof.
However, as for these purposes it would be fine :> What can possibly go wrong with an almost impossible and improbable leak, right? We have blups that "leak" way harder and waaaaay more often anyways.

[KeepResearchinSpoons]

While I played with it, I found a "bug" with that that is even more fun though!
Go to map view, scroll to world view,
move aside from the "player" position (like west something)
and then summon that message being in the zoomed-to-world-view.

For me it would stick to the side of the screen where the "player center" would have to be located. Overlaps the map preview, other guis etc.
Well, it is strange and unexpected.
Is it a bug? Probably a minor one. And I have a list of those "Is "it" a problem? Come back again when you would get stuck for real." bugs already.

I don't exactly want this main "gui-bug" to be closed off as minor or something. Those first 5-20 ticks of the game are of some really crazy stuff!
But even if it does get not-a-bugged. We at least do have a general solution for this class of off-by-one-tick bugs already, yay.

[curiosity]

This seems to be more of a z-order issue than anything.

[posila]

Thanks for the report.
Fixed for 1.1.37