Topic, Game "Path 4 Mouse (old)"

  yay, it doesn't crashes!

  Yayzorz! I think I fixed it!
In the blEditLevel() function, I traced the level data to the BL debug console (accessed by pressing D and C at the same time).
I think that the problem was maybe that the debug console could not handle such a large amount of data on one line, and so it crashed. This would explain why it worked with the old data: all the old levels have newlines in them to make them more readable, while the new ones are all crammed onto one line because they are no longer made in a text editor. Sounds reasonable?

  but it's still the compression, the compressed data caused the bug :P
even though it's gone it caused it all and also your level trimming code should ensure array size of 20x20
[edit] I didn't miss your edit my post is 20 minutes after yours...

  No, because I don't use the compression to serialize and unserialize the data any more, and also because the editor displays the level just fine but it still freezes in the same spot (you missed my edit).

Also, I sent you the PM.

  so it is your compression failing then :P

  Wait!!! I think I know what the problem is!!!! Gimme a sec.

[edit]
Okay.... The editor does not freeze on old levels, but it does freeze on GIS's newly created level... That gives us a clue.

[edit2]
Another thing I noticed is that the level loads and displays properly this time, but the editor still freezes in exactly the same place.

  I'm absolutely certain it's nothing to do with the compression, so don't start looking there. I'll PM you the Flash file.

  may I see the fla file it's probably something stupid...and also there could still be compressed code on BL :P

  Okay, the crashing problem is officially nothing to do with the decompression. It's happening again in exactly the same place and way as before, even though I removed the LZW algorithm from the loading and saving functions.

  yeah, stupid float numbers ;)

  @yoshi:
Sorry, but I have a lot of testers at the moment, probably more than I need. Don't worry though, I'm working hard to finish the game as soon as I can!

@marc:
I was doing that, but you're right about the scores being rounded. I'll just increment them by 1 instead of 0.1, which will eliminate both problems.

  is it ok if i be a tester

  GIS, for the float inaccuracy, do this(assuming timer var is 'timer')
timer=Math.round(timer*100)/100
[edit] also BL only accepts integers for score, I tried otherwise but it removes the decimal, like doing Math.floor()

  Nope, still crashes, only crashes when I edit an uploaded level thought, haven,'t tested with local saved.

  Ooooohh! I fixed that, but I forgot to upload the new version. Don't worry!

  Somethings is terribly wrong with the editor...

  Yes, no more crashing (as far as I know)! :D

  Does that means there is no crashing anymore ?

  Great you fixed it, I think it's the same kind of problem that makes the auto levels behave differently when you play it on MacOS or Windows.

  Hey JP, just in time!
I'm having problems with increasing a counter by 0.1 every 10 milliseconds using setInterval, but for some reason the timer ends up with things like 29.9000000000002... Any ideas?

I know I could just round it to 1 decimal place, I think that might slow the game down if it's happening once every 10 milliseconds.

[edit] I think I've fixed it, but not in the most efficient way possible.

  will this game ever be public?

  Yes base64 is not a compression, it's just a way to change a binary suite into readable chars.

  Actually, I'm going to change my compression algorithm altogether. I'll use the same base64 stuff that JP uses. Obviously not for saving levels to the site (that would be stupid, because we already have base64 compression by default), but for testing levels offline it will be very useful.

[edit]
WOOOW! Definitely not Base64. The resulting string was larger than the original string!

[edit2] I'm sticking with LZW, I had a bug, but actually it was unrelated to the compression. Let's just get that working and hurry up with the more important things!

  see I told you it was decompress code ;D

  I've fixed it now. You were right, it was the decompression that was causing the problem. I think that it must have been related to the level data stored on BL, as that would explain why the bug only occurred when you loaded a level from BL, not when testing offline or when creating a blank level.

Now I will still be using the LZW compression, but only for testing levels offline. I'm adding a 'compress' feature to the hidden part of the editor, so I will have smaller data to test offline. Then I'll be testing my levels like this:
BLManager.blEditLvl(LZW.decompress("2,ĀĂāĄăĆąĈćĂ|ĊĉĎčĐāČďĔđĖēĖĕĚĆĘěĞėęġğĝĢĥĉĤğĩĜĦĬħĭįĒİįĨIJěĴĪĪķĵĐĺĸġĽĻĮľŃ2ŀńďņŁċŊğ"));

  may I see the fla file it would really help...

  I commented out the inside of the drawGrid() function, and the problem still happens.

  tell it to output the level data...see if that helps

  Okay. I added a simple output texbox, and this is where the editor froze:


This means that the problem either decides to wait a while before it occurs, or that the problem is happening when I draw the grid.. We'll see.....

  that's my point, I think the code for decompression is bugged, maybe you made the code give the wrong level code to the wrong decompressing code...