First off
If you don’t know how to program you can still help. This can be thought of strictly as a logical problem.
There are dozens of ways to solve this problem. I just thought it would be really interesting to see what you all thought. Just leave a comment here or start a thread if you want to get crazy. I'll hand out keys to everyone when we decide on a solution.
The Problem
Android 42’s dialog text box is a little different than the other Androids. In the game I use overlapping volumes to update Android 42’s text. When he overlaps one of these cubes it sends a message containing what new lines to show (string array). His text box is then closed (destroyed) and rebuilt/resized based on the number of lines he receives and their length. When a text box is updated it is automatically opened. This is to ensure he says things at the right time.
The Delay
When the texbox is updated it is automatically assigned a delay. This is to ensure the player has time to read the text before it disappears. Currently it is set to 6 seconds (6s) per line. In other words, 6s for each element in the array. The length of each line doesn't matter***.
The two ways to update and open the text box are by overlapping one of these boxes or when the player interacts with him (left mouse click).
The problem occurs when you want to send him a new text box but the count down delay has already been activated from a previous box. If he is sent a message with one line (6s delay) and then 5s later he is sent another message with a 6s delay the box will close 1s after the text box for the second message opens. Effectively opening an updated text box for 1s (You might experience this bug in the current game).
This happens most often when the player interacts with Android 42 right before he is triggered by another box.
The Fix
Being the professional Programmer I am, I created a very simple (but temporary) fix for this.
Here's the original delay:
When the Android is triggered you are given a delay time and regardless of what happens you will close your text box.
Now here's the (TEMPORARY) fix:
Scenario 1 (perfect scenario):
A message arrives and is assigned the "delay 1" branch. When that delay is complete it checks to see if another message has arrived before it's done. If not (delay 2 is FALSE), it completes it's task and closes the text box.
Scenario 2 (OMG!!!):
A message is received and is assigned the "delay 1" branch. Before delay 1 is complete another message is received and is assigned the "delay 2" branch. When the first delay branch finishes It checks to see if a second delay was received. If so, it will also take that branch and activate the second delay before ultimately closing the text box. This effectively adds the delays.
Like I said, It isn't pretty but it works for the most part. One bad thing is that the delays are constantly counting down in the background. Eventually they will close the text box and it might not be the best time. You can also only handle 2 delays. You could put another branch or twenty but I'm curious what else you think of.
Rules:
You CANNOT reject or delay a message. When Android receives updates he MUST accept them and immediately display them.
Similarly, You CANNOT "save" messages to display later.
You CANNOT change, add, subtract, pause, or alter a delay in any way once it has been started (you CAN ignore it when its done though).
You CAN close a message early.
You CAN add as many branches as you want.
You CAN break delay times up (e.x. 10 delays of .2 seconds Vs. 1 delay of 2 seconds).
You CAN literally do anything and we can rewrite the code but if we keep these rules it will make it a lot easier to insert .wav (voice acting) later.
Sorry "Signals" isn't done yet.
***
The delay could be based off the number of total characters and you could even add additional time for each '_' to account for complete words. It's actually pretty interesting. That's not the problem though.