| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000416 | DarkRadiant | Saving and loading | public | 08.11.2007 19:23 | 03.12.2008 21:38 |
| Reporter | tels | Assigned To | greebo | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.5 | Fixed in Version | 0.9.5 | ||
| Summary | 0000416: Save causes brief "teleport" of entities | ||||
| Description | When DR saves a map, either manually or by autosave, all entities are briefly teleported to some location (origin?), then the camera view is updated, the map saved, then everything pops back to the original position again, then the camera view is updated. There are three issues with that: * the camera view updates take time, making it slower than it could be, esp. on very large maps * when you edit and an autosave happens, everything suddenly flickers in and out , disturbing your work * today DR managed to destroy my map because it got saved with all the entities centered in the same location they briefly take during save. I guess by chance I just must have saved while DR was currently doing an autosave itself or some other mishap happened. Both my map file, the .bak file and the .autosave file had all entities moved around so I had to pull out the backup from a day before :) | ||||
| Tags | No tags attached. | ||||
 |
The teleport is due to child primitives of func_static-like entities being measured relatively to its parent. During DarkRadiant "edit runtime", all the child primitives are in the correct position like the user expects them to be, but for saving they have to be relocated. The short flickering is a minor issue in my opinion (and didn't cause any problems at all even in large maps like bonehoard in months), but I guess we could handle that differenly, by applying an optional transformation matrix to the primitives before the items are passed to the Map Exporter. |
|
|
As for your crash: I have never seen such a thing happening before, do you think you can reproduce that? |
 |
It didn't actually crash. I just added some door to my map, saved the map (while still having the camera centered on the door), then switched to D3, dmapped and tested the map..then I noticed for some reason all entities were "missing". So I re-saved the map, removed the new door etc to pinpoint the cause - but everything was still missing. Only a few minutes later I saw in game that all entities in the map were sticking together and floating in mid-air. So I opened up the .autosave and the .bak and they were exactly the same. Unfortunately, when I loaded my backup map (from a different folder) and re-saved it as the regular map, this overwrote the .bak and later the .autosave, so I do no longer have the corrupted map. |
|
|
Just a quick note in case this wasn't clear: I believe that the problem with all entities sticking together can be replicated by saving in exact the same moment the autosave is going on. This is, however, tricky to replicate as the CTRL-S doesn't save without any change having been actually there. In any event, this race condition shouldn't be there - no matter how rare this condition is, having the ability for the user to destroy his saved copy by pressing CTRL-S in an unfortunate moment shouldn't be possible :) |
|
|
Agreed, I'll implement a block in the Save() method if AutoSave is currently active. |
|
|
I fixed this by implementing a mutex bool, which prevents the saving process from being entered while another one process is active. |
|
|
Thanx for implementing the mutex :) I guess it is not easily fix that the entities get relocated during save - albeit it is hard for me to understand why that would be even nec. :) Anyway, what could be implemented is not updating the camera view during save - this way entities wouldn't flicker in and out when autosave kicks in. |
|
|
Done. |
|
|
This bug reared its head again. After converting a few wordspawn to func_static, D3 showed a few entities moved to the origin. However, in the editor, everything looked all right. Even multiple saving did not help. So I closed DR, and restarted it and reloaded the map, and the entities were warped in the editor, too. |
|
|
What exactly did you do before the brushes were moved to the origin? I've been working a few hours with the editor lately (including several worldspawn<->func_static conversions) and I never saw any problems. |
|
|
I have tried recreating the problem, but I can't :/ Here is what I remember: * selected a few bars * cut them into two pieces with the clipper * converted them to func_static * accidentily pressed "move player start here" (I guess) as the player was suddenly at the front wall where I clipped the bars After the next dmap in D3, the entities were moved As for you not seeing the issue, I guess it is very rare, I have worked countless hours since the first report and I only saw this problem once, today. I am not even sure it is related to this bug. This time I still have the corrupted map, but I am not sure if this will help tracking it down. |
|
|
The buggy map itself won't help much, it's the context, I'm afraid. I'm pretty confident that the saving algorithm is pretty robust (I didn't touch the actual saving algorithm apart from implementing the mutex bools), because this algorithm has been in use by several mappers for nearly a year now. I can't imagine that nobody else would not have run into this since then. |
|
|
Yeah, but have these people also been using Linux, and dual-cores? Having two CPUs amplifies race-conditions like nothing else. :D I close this bug report afterwards, but I will keep an eye out. |
