well... this is strange!! ..and help please!

Blitz3D Forums/Blitz3D Programming/well... this is strange!! ..and help please!

Erroneouss(Posted 2004) [#1]
i dunno whats wrong... i just had my code for my game all fine and all of a sudden i turn it on the next day and its all messed up!!!!!!! nobody used my computer from the time i shut it off until the time i turned it on the next day to play it... and i didnt touch the source code... im so confused!!! no clue what happened.... its a 3rd person camera and when you hit a wall, the player object moves like 1000000 meters away from where he was.... and i turned off the collision stuff for it too! and it still moves him far away when you hit the wall its really strange and i have no clue what happened so if anyone could help me that would be very nice. thanks in advance!


N(Posted 2004) [#2]
Start lookin' for typos.


puki(Posted 2004) [#3]
It is probably too late - but if ever this happens again - just reinstate one of the auto-created .bak files. One snag is with the default Blitz3D IDE - it can be difficult to see where the cursor is - you can accidently delete something without knowing it and it won't necessarily be a code error - you could delete a '#' off a variable definition for example.

Your next option is to post your code and someone might spot the problem.


Damien Sturdy(Posted 2004) [#4]
The basic blitz IDE's BAK tool is useless- only time i ever need them is when my computer crashes, and then all three, .bb, and .bak files are empty. :P


Sunteam Software(Posted 2004) [#5]
Cygnus: That's odd, I don't think that is entirely possible. I think the IDE only reads in the file but after having read it in the file lock is released, and I'm fairly sure it doesn't have open file locks on the BAK files until the time of saving... which is either manual, at time of code execution or on exit. Just doesn't sound right? ... well not to me anyhoo ;)


Erroneouss(Posted 2004) [#6]
oh well.... ive written the file over again with a little bit different approach... i wasnt too far at all anyways ...and i edited a lot after that day to try to make it work and compiled a lot... so the back ups wouldnt be old enough... maybe it was because i was using a back up of a back up? the file was named "waverace.bb_bak1_bak1"


Damien Sturdy(Posted 2004) [#7]
Explanation:
when you hit f5, it saves the files. this gets put to windows disk buffer.
Computer then crashes- after writing the FAT data, but not the file data, or at least- not writing one or the other correctly.
That leaves all files that were sent to windows' disk buffer to be stored incorrectly.
But no matter what machine im on, the Blitz BAK routine fails because the systems tend to crash very shortly after hitting f5.
This isnt juts with my prijects- other blitz projects to it too- And most of the crashes are because of incompatibility.


Sunteam Software(Posted 2004) [#8]
Maybe check that your BIOS and mobo drivers are all up to date. This shouldn't happen.


Ross C(Posted 2004) [#9]
I wouldn't say it's useless. If you delete a large portion of your code and change parts then run it, and realise you needed some of that code you deleted, just open up on of the prevoius .bak files. :o) Very handy :o)


doctorskully(Posted 2004) [#10]
I had this problem once too... if my character collided with something real early in the game, he'd fly from the collision point.

Idea One: Create a variable that adds 1 to it at the end of the loop. COMPLETELY BYPASS the UpdateWorld command until your counter is >= 5 or >= 10. For some reason this works sometimes. Note that your character MAY have to be put a few fractions of a unit from the floor to keep it from falling through, but 5-10 loops isn't that much time anyway. Also--this problem may have NOT happened before if your computer was on Hibernation Mode, Hibernation really messes stuff up.

Idea Two: If #1 didn't work, try writing some code that keeps your character from straying too far from the coordinates (CollisionX#(), CollisionY#(), CollisionZ#()). For example, create a temporary invisible box at those coordinates & test their EntityDistance#(). If it's too far, have it execute a quick Repeat...Until loop without UpdateWorld/RenderWorld that points your character at the invisible cube and moves your character (MoveEntity my_character, 0, 0, amount) until it is at the correct distance. Please note that your character's regular rotation may need to be assigned to variables and restored at the end of the loop. It sounds complicated but should only take a minute to do.

Idea Three: Narrow it down by using your DebugLog to keep track of variables.

Hope this helps you.


jfk EO-11110(Posted 2004) [#11]
AFAIK the IDE first renames bak2 to bak3, then bak to bak2, then the original bb to bak and then saves the new source as the original bb, then throws it at the compiler. No matter when it crashes, some of the backups should remain intact, unless your Systems FAT handling isn't completely messed up. But you cannot blame Blitz for such a case.

As for the collision problem I'd suggest to hide, then position and then show the player before the game starts, because this will remove "collision tensions".