Debug.MessageBox displaying out of order?

[kefka95]

I'm having an odd issue. My mod displays several Debug.MessageBox objects in a specific order. However, the game is displaying them in a completely different order than what's specified in the code. For example, when I run the code below:

Event OnInit()
	debug.messagebox("1")
	debug.messagebox("2")
	debug.messagebox("3")
	debug.messagebox("4")
	debug.messagebox("5")
	debug.messagebox("6")
	debug.messagebox("7")
	debug.messagebox("8")
	debug.messagebox("9")
	debug.messagebox("10")
EndEvent

The game displays the messages in the following order: 1, 2, 3, 5, 7, 9, 10, 8, 6, 4. It's almost as if the game continues executing code while the message is displayed, and "stacks up" the messages in the background (although even that doesn't make sense based on the order they display).

 

Has anyone seen this before? Is there any way to get it to display in the same order as the code?

 

EDIT: I was able to get them to display in order by inserting a "Utility.Wait(1)" in between each message. The 1 second pause in between the messages is kind of annoying (there are times when you just want to quickly flip through the messages without waiting), but it's better than nothing.

 

EDIT 2: Actually, I realized I can use 0.1 for the timer instead of 1 (for some reason I thought Wait() took an integer). The 0.1 time works just as well but causes a much less noticeable "pause" in the messages.

Edited April 29, 2016 by kefka95

[EmissaryOfWind]

Maybe add a timer in between displays?

[kefka95]

Maybe add a timer in between displays?

 

Thanks, I just tried that and it worked. Not an ideal solution, but not a showstopper either. I still don't quite understand what the game is doing to cause the issue in the first place, but at least I can work around it if needed!

[RustyXXL]

Because without the wait these messages are supposed to happen at the same time, as quickly as it can. Each of those message boxes you open is a thread on it's own and not aware of the others. Depending on when each of them managed to get resources to execute from the engine they will show up.

 

Edit: I explained that badly, let me explain again.

Of course your calls are executed sequentially from top to bottom, but each of those calls basically tell the game engine: Hey Engine, show a message box with these properties as quickly as possible. And the engine Puts them in a outbox for the next part of the engine to grab them. It puts them from bottom to top, so the newest message is always on top. The output part of the engine grabs the first one from the top and does all the stuffthat is necessary to show it, and for the most part it takes the same time to put one in, as it takes to take one out, but every now and then the engine manages to put 2 items in the inbox in the time it takes to take one out.

The outbox sequence now looks the following:

 

Left of colon are the operations, right of the colon is the content of the outbox. > means a number gets put in the box, < means a number gets taken out of the box.

 

>1:1

<1:-

>2:2

<2:-

>3:3

<3:-

>4:4

>5:4,5

<5:4

>6:4,6

>7:4,6,7

<7:4,6

>8:4,6,8

>9:4,6,8,9

<9:4,6,8

>10:4,6,8,10

<10:4,6,8

<8:4,6

<6:4

<4:-

 

The outbox in this example is called a LIFO-Buffer (Last In First Out), the problem itself is known as race conditions, in case you want to look that up.

 

By Putting a ever so small wait time between both operations, the input task has to wait long enough so the output task has always enough time to get the last message, so this race condition won't happen anymore.

 

Edit 2:

To understand a bit more why this is happening, it might be helpful to understand that the "put into output" task from your script and "get from the output and show on screen" task are not connected. While your script was written to put the messages in as fast as it could, the other task is probably setup to run every/every n-th frame/fraction of a second/Clock tick...whatever. They work completly independent, and don't knw what each other does, and don't care what each other does.

 

Also the race condition doesn't happen with the buffer, but between the 2 independent tasks accessing the same buffer, just if that wasn't clear.

Edited April 29, 2016 by RustyXXL