EDITOR: References get messed up when cutting/pasting.

[Sophia]

I hate to post such a vague bug report, but it's severe enough that I feel like I should say something. Cutting and pasting, especially after the editor has been running for a while, tends to change what objects are pointed to by triggers. Sometimes, it'll even change the targets of completely unrelated triggers.

[George Gilbert]

I appreciate this might be a bit tricky, but if there's any chance of giving a concrete example (e.g. add such-and-such, copy and paste it then look at these parameters) it would greatly help in tracking it down.

[linflas]

not easy to reproduce, as you might have made some enhancements in last versions of RTCeditor. but i guess it comes from the order of targets on a same tile.

[Chaos Awakes]

This happens to me too, and it is really severe, in fact it causes errors.

The effect of the bug, and it seems to happen at random, is that I will cut or copy something from the dungeon and then when I go to paste it a totally unrelated item from a different tile appears instead, usually something I cut or copied earlier. The references then get messed up.

This causes a major bug. After a reference has been messed up in this way, two things may happen. Often, there will suddenly be two references to the same square in the editor with the result that placing an item on one square actually makes it appear on two different squares, overwriting what was on the other square. This seems to be a problem with the editor because saving and reloading the dungeon seems to solve it.

However, and this is where it gets really serious, normally after the cut/paste reference gets messed up any attempt to go File|Save or File|Save As results in a fatal error during save and only half the dungeon is written. Reloading it displays a dungeon with half the levels or items missing. I have had to create about 3 or 4 backups of my dungeon to avoid a catastrophe because this happens so often, when I save I now save to several copies in case one gets messed up.

[Sophia]

It's hard to give an exact procedure how to duplicate it, but I will share my thoughts on it, if any of them help:

Since this is more than likely a pointer-related bug, the problem is probably in the routine that allocates new memory for copied and pasted objects. Is there anything in there that assumes new memory is NULL without specifically initializing it? (I've made this mistake more times in programming than I care to admit)

This is by no means a specific recipe to reproduce the bug, but the best way to bring this bug out that I've found so far is to create an object that is targeted by a lot of other objects, and then delete it, clicking "yes" on all of the boxes that ask if you want to delete things. Then, try to save. Odds are something will screw up.

[George Gilbert]

Finally, I think I've solved this one!

I don't think it's a problem with cutting and pasting per se (although that makes the problem more likely) but with having a series of items pointing at eachother.

Consider a three item setup (a switch that activates a relay that activates a teleporter say). If you delete the teleporter, the editor correctly recognises that the relay no longer is pointing at a valid object and prompts you if you want to delete that too. Even if you say yes though, it doesn't then recursively check the switch. End result is the switch is pointing at the (now deleted) relay and when the program comes to save the dungeon, it crashes.

I've now fixed both the lack of recursion (so in the same scenario you're now prompted to delete the switch if you opt to delete the relay) and fixed the crash so you don't lose your work if there are other similar bugs that havn't been found yet.

The more complex case is cut and paste. Again using the same scenario, if you cut the teleporter and then paste it somewhere else, then you don't want the relay to be deleted. However, if you cut the teleporter and then cut something else the teleporter is automatically deleted - currently this leaves the relay pointing at a duff reference and causes the crash as before. I'm not quite sure what the correct behaviour should be here - should it prompt you when you try to cut a second tile, or should it silently delete the relay and switch? The first is messy, and the second just feels wrong - any other suggestions?

[Sophia]

I would silently change any reference to a bad object to a NULL.

This would leave the relay intact, but pointing at nothing, just as before, only not in a state that will cause a crash

[George Gilbert]

OK - this is now all fixed for V0.35.