i noticed some bugs today while making a map...
1. it seems every little bit when putting in TELE and LINKS
the program goes off into a wierd area.
2. all the links stop working and a couple extra boxes
down in the link menu area appear to the right. it
then it appears that all the info i input for linking disappears.
3. when i then try to continue any new TELE or LINK i make
does not show up on the screen anymore.
4. when i try to input new X and Y coordinates for TELE or
LINK it keeps entering the same number no matter
what i type.
5. i keep having to exit the program then come back in.. then all
those tele's and links appear...
i run the latest version of bzedit on WIN 98 256m of ram
800mhz model.
some bugs
I'm haveing similar problems on my machine. Except, this applies to all objects once you pass around the 50th object. The objects appear on screen, but I am unable to edit them, until a certain number of other objects have been created. I estamate this "lag" to be about 10-15 objects. Everything re-appears, and works for a while when you restart the progam.
THe only time I have noticed this is after deleting an item. It might work for a little while after deleting the item, however it will eventually fail.
The best bet => after deleting an item, completely close bzedit and reload
I am looking at the code, and am trying to figure out why. Hopefully a fix will be in soon.
The best bet => after deleting an item, completely close bzedit and reload
I am looking at the code, and am trying to figure out why. Hopefully a fix will be in soon.
.........you kids, get out of my tank...........
renumbering
hmmm interesting idea about the numbering system
it maybe something to do with that...
when you delete a item it renumbers everything over
again which then changes tele numbers and linking numbers
which can make everything go boom!
good catch redtail...!
it maybe something to do with that...
when you delete a item it renumbers everything over
again which then changes tele numbers and linking numbers
which can make everything go boom!
good catch redtail...!
I belive that I have narrowed down the cause of the problem even further, though it is just a guess at this point. What I think It's doing is re-numbering existing objects into the numbering slots opened by the deleation of objects. However, the progam thinks that the object with that ID number doesn't exist, makeing the object unslectable. The "lag" I described coiuld also be accounted for as a result of this. BzEdit simply re-assigns whatever was at the supposedly empty ID number to the next open ID number, to make room for the new object, which is written to the lowest empty ID number. Since BzEdit apperently thinks the ID of the deleted object is propetuially empty, it simpy continues to repeat this proscess.
You are correct, Redtail. Good detail. To add more detail, bzedit doesn't seem to completely forget the object is there. Once you get in this state, the easiest way to fix it is to save, exit, restart. Then the object is there and you can work on it. You don't have the problem with the objects if you only delete the last one you created, either. The attempt at garbage collection / memory reuse seems to be the issue. It doesn't step outside memory bounds, or you'd get an o/s error, so memory allocation, if that's dynamic, must be okay.
I don't have the code, or I could take a look at it. However, I can take an educated guess: I suspect that at least two different data structures are being used to track the objects, one of them an array. The other seems to be a pointer that's being incorrectly set or reset during the deletion process. This seems to be classic symptoms of that kind of programming error. Typically, one would solve this by conversion to linked lists. Then objects don't require numbering at all. And the deletion could occur anywhere, but new objects would only be added at the end of the list. Is the code on sourceforge?
Another odd behaviour: when you select an item and then try to center it with the view control, it can take anywhere from 1 to 5 clicks on that control to center the item in the display (in iso mode). Almost like it's ignoring the event?
I don't have the code, or I could take a look at it. However, I can take an educated guess: I suspect that at least two different data structures are being used to track the objects, one of them an array. The other seems to be a pointer that's being incorrectly set or reset during the deletion process. This seems to be classic symptoms of that kind of programming error. Typically, one would solve this by conversion to linked lists. Then objects don't require numbering at all. And the deletion could occur anywhere, but new objects would only be added at the end of the list. Is the code on sourceforge?
Another odd behaviour: when you select an item and then try to center it with the view control, it can take anywhere from 1 to 5 clicks on that control to center the item in the display (in iso mode). Almost like it's ignoring the event?
-toaster
"So there I was, all alone, facing all of the enemy. I started driving in circles, until I had them surrounded, and then I escaped in the confusion."
"So there I was, all alone, facing all of the enemy. I started driving in circles, until I had them surrounded, and then I escaped in the confusion."
Toaster wrote:
I don't have the code, or I could take a look at it. However, I can take an educated guess: I suspect that at least two different data structures are being used to track the objects, one of them an array.
You can have the code , remember this is a free game/software and you can have the code on Sourceforge.net.
If you have a free time to help the developer will be great, Grumbler s/he working with it.
I don't have the code, or I could take a look at it. However, I can take an educated guess: I suspect that at least two different data structures are being used to track the objects, one of them an array.
You can have the code , remember this is a free game/software and you can have the code on Sourceforge.net.
If you have a free time to help the developer will be great, Grumbler s/he working with it.