View Issue Details

IDProjectCategoryView StatusLast Update
0000416DarkRadiantSaving and loadingpublic03.12.2008 21:38
Reportertels Assigned Togreebo  
Status closedResolutionfixed 
Target Version0.9.5Fixed in Version0.9.5 
Summary0000416: Save causes brief "teleport" of entities
DescriptionWhen 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 :)
TagsNo tags attached.




08.11.2007 21:50

administrator   ~0000844

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.


08.11.2007 21:51

administrator   ~0000845

As for your crash: I have never seen such a thing happening before, do you think you can reproduce that?


08.11.2007 22:26

reporter   ~0000846

Last edited: 08.11.2007 22:28

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.



09.11.2007 15:20

reporter   ~0000851

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 :)


09.11.2007 15:34

administrator   ~0000852

Agreed, I'll implement a block in the Save() method if AutoSave is currently active.


09.11.2007 15:54

administrator   ~0000853

I fixed this by implementing a mutex bool, which prevents the saving process from being entered while another one process is active.


15.11.2007 17:13

reporter   ~0000870

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.


15.11.2007 17:25

administrator   ~0000871



18.11.2007 17:23

reporter   ~0000874

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.

18.11.2007 17:23


entity_warp.jpg (103,128 bytes)   
entity_warp.jpg (103,128 bytes)   


18.11.2007 17:49

administrator   ~0000875

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.


18.11.2007 18:55

reporter   ~0000876

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.


18.11.2007 19:04

administrator   ~0000878

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.


18.11.2007 19:52

reporter   ~0000880

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.

Issue History

Date Modified Username Field Change
08.11.2007 19:23 tels New Issue
08.11.2007 21:50 greebo Note Added: 0000844
08.11.2007 21:50 greebo Status new => acknowledged
08.11.2007 21:50 greebo Severity major => minor
08.11.2007 21:51 greebo Note Added: 0000845
08.11.2007 22:26 tels Note Added: 0000846
08.11.2007 22:28 tels Note Edited: 0000846
09.11.2007 15:20 tels Note Added: 0000851
09.11.2007 15:34 greebo Note Added: 0000852
09.11.2007 15:52 greebo Status acknowledged => assigned
09.11.2007 15:52 greebo Assigned To => greebo
09.11.2007 15:53 greebo Status assigned => resolved
09.11.2007 15:53 greebo Fixed in Version => 0.9.5
09.11.2007 15:53 greebo Resolution open => fixed
09.11.2007 15:53 greebo Build => 2520
09.11.2007 15:53 greebo Target Version => 0.9.5
09.11.2007 15:54 greebo Note Added: 0000853
15.11.2007 17:13 tels Note Added: 0000870
15.11.2007 17:13 tels Status resolved => feedback
15.11.2007 17:13 tels Resolution fixed => reopened
15.11.2007 17:25 greebo Note Added: 0000871
15.11.2007 17:25 greebo Status feedback => resolved
15.11.2007 17:25 greebo Resolution reopened => fixed
18.11.2007 17:23 tels Note Added: 0000874
18.11.2007 17:23 tels Status resolved => feedback
18.11.2007 17:23 tels Resolution fixed => reopened
18.11.2007 17:23 tels File Added: entity_warp.jpg
18.11.2007 17:49 greebo Note Added: 0000875
18.11.2007 18:55 tels Note Added: 0000876
18.11.2007 19:04 greebo Note Added: 0000878
18.11.2007 19:04 greebo Status feedback => resolved
18.11.2007 19:04 greebo Resolution reopened => fixed
18.11.2007 19:52 tels Note Added: 0000880
18.11.2007 19:52 tels Status resolved => feedback
18.11.2007 19:52 tels Resolution fixed => reopened
18.11.2007 19:53 tels Status feedback => resolved
18.11.2007 19:53 tels Resolution reopened => fixed
03.12.2008 21:38 greebo Status resolved => closed