handling two instances of DR with the same map open

[HMart]

Today something very strange and frustrating happened when using DR, mostly because I use the windows 10 feature, virtual desktop, to simulate more than one monitor.

I forgot that I add DR open in one desktop hidden from view, so I opened another instance of DR, I worked on the map in this instance and tested it ingame, something very strange was happening some times some models would just vanish, thinking that I made something wrong, in the engine code, I closed DR and changed to my second virtual desktop that add Visual Studio Open, behind it was the second instance of DR that I didn't saw, after messing around in the code and not seeing anything wrong, I alt+tab to go to the desktop for some reason and saw the second instance of DR open, instead of closing it straight away, I instinctively clicked ctrl+s, not realizing that this version of the map was outdated and so, it undone all the changes I made to the map on the other DR instance on save, this really made my tension rise when I realized the mistake.  

I know it is my fault for not being more attentive but could DR warn somehow if another instance is open in the same map?

Also could this cause models to disappear in game? 

Edited December 5, 2020 by HMart

[greebo]

I see. I hope you could recover some stuff from the .bak file that is created from before a file is overwritten?

I think there are some ways to add safeguards or warnings to make that less likely to happen. What most text editors are doing is (I assume) adding a file watcher to the target file and/or checking the modification date of the file they're writing to.

Even without modification date comparison or watchers, it'd be possible to introduce something like a version counter in the .darkradiant file, that could be checked by the instance before saving to the map. If the version counter was different to the expected value, DR could issue a warning that it thinks the file has been modified in the meantime. That doesn't cover modifications in a non-DR application like text editors though.

Lastly, it'd be possible to add some platform-dependent code detecting other running instances of DR and checking whether one or more of them are working on the same map. Technically the most difficult option I guess, but not even 100% safe since files could also be modified through the network or other applications.

[grayman]

In the case of "another instance of DR is running the same map", DR should give you the option of continuing or not.

I can't think of an example atm, but it's possible that the author might want to do this on purpose.

[HMart]

10 hours ago, greebo said:

I see. I hope you could recover some stuff from the .bak file that is created from before a file is overwritten?

...

Yes fortunately everything was on the backup file.

But I still think this warning should be considered, just in case. 

I also agree with grayman.

[OrbWeaver]

13 hours ago, greebo said:

I think there are some ways to add safeguards or warnings to make that less likely to happen. What most text editors are doing is (I assume) adding a file watcher to the target file and/or checking the modification date of the file they're writing to.

Vim does check the modification timestamp when you are about to save a file, and if it has changed since the file was read, it by default aborts and asks if you really want to continue. This is probably the easiest thing to do in DR too.

11 hours ago, grayman said:

In the case of "another instance of DR is running the same map", DR should give you the option of continuing or not.

This is considerably more complex to implement. I can think of two ways to achieve it:

1. Write a lock file to the map directory when it is opened, e.g. when opening mymap.map, we also write out mymap.map.lock. If DR is asked to load a map and there is already a .lock file, it could ask if you really want to continue (but it must still give you the option to override, because the lockfile could be left in place by a previous crashed session). I don't know how this would work when loading maps inside PK4s, which I believe Greebo has been implementing.
2. Some kind of IPC to communicate between DR sessions and ask if any other application instances are editing the same map. Honestly this feels like using a sledgehammer to crack a nut, however.

Personally I think the Vim approach of a simple modification timestamp check is the best option in terms of value-for-effort.

[greebo]

20 hours ago, OrbWeaver said:

Vim does check the modification timestamp when you are about to save a file, and if it has changed since the file was read, it by default aborts and asks if you really want to continue. This is probably the easiest thing to do in DR too.

I'd prefer to have this implemented, it should provide enough warnings for a mapper to not overwrite the existing map file with outdated data.

@HMartCould you please open an issue tracker entry with the request to add overwriting protection of newer files?

[HMart]

3 hours ago, greebo said:

...

@HMartCould you please open an issue tracker entry with the request to add overwriting protection of newer files?

Don't know if is a good report but is done.

Edited December 7, 2020 by HMart

[greebo]

Thanks

[HMart]

No problem. 

[HMart]

On 12/5/2020 at 10:31 PM, HMart said:

...

Also could this cause models to disappear in game? 

This was my fault...again, the LOD system i coded, was not unhiding some LOD entities after they where hidden at the distance. In this case it was because I was transporting the player around, instead of walking normally around and my LOD code didn't expected that. 

Edited December 7, 2020 by HMart