Jump to content
The Dark Mod Forums

handling two instances of DR with the same map open


Recommended Posts

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. :P 

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 by HMart
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by HMart
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...