I also included modifiers where collisions against walls stop motion automatically (and shove backwards a few pixels to prevent continuous collisions).
I thought about doing that earlier. It's hard to tell if it would be a good idea or not. It would make motion more predictable, but could make it more difficult to get down some of the narrow passages.
Collision is handled on a 2D plane. In the prototype, you can actually pull this plane up using tilde+3, then tilde+0 (in that order). Marika's collision boundary is a circle of diameter about 64, which is the length/width of a tile. Getting her to walk down a corridor of 1-tile width without a collision is near impossible.
So yeah, I am not understanding how to were able to wait until list is empty to continue on. Is it as simple as it sounds? I am trying to empty a list (36000 items) and it takes about 2 seconds, in which the scene is unresponsive. Can I have it check lines in the scene like (if list item # 30000 exists, display 10%, if list item #20000k exists, display 30%) or am I missing something.
I need the scene to actually refrain from becoming non-responsive while the script is running. The script is successfully running, however it freezes as mentioned above by ETH.
Basically, the contents of the screen aren't going to update until all other instructions have finished. So, if you tell the computer to read through all 30,000 list entries at once, the screen won't refresh until that loop has terminated. You can have hundreds of little loops instead, and increment the starting index as appropriate. In between each loop, the screen will update.
I don't know any way to manually update the screen, so this means using the On Drawing and Always events and keeping track of where to start the next loop.
The task that takes the longest in my setup is called "WallBitMap", which constructs polygons for one tile (row, column). What I did was write an event that processes a single row and column. The drawing loop itself is where the code that increments the counter is housed. So, the flow looks like this.
(on Creation)
set row = 0, col = 0
(on Drawing event)
if row, col < max row, max col
call event to process current row, col
increment col by 1
if col == max
set col to 0 and increment row by 1
end if
I realized our problems might be different in a slight, but important way. You're reading a lot of data, and I'm processing it. I can't think of a way to read just part of a file at a time. You could break your one big file into several little ones, though.
But... 2 seconds doesn't seem like a long delay. Is the problem going to get bigger? The reason I went out of my way to put the progress indicator in is because even for a relatively small map, I'm passing 15 seconds. This is a number I pulled from
Apple's guidelines for app loading times.If two seconds was my worst case scenario, I wouldn't have bothered. Using a loading screen adds a surprising number of complications, because now you have to think twice about what code you put in the 'Created' events. When I installed the loading system, I had a lot of segfaults because code in 'On Created' and 'Always' was executing before the loading process finished.
