Jump to content
The Dark Mod Forums

Combining Xml Trees


Recommended Posts

I doubt there is any reasonable solution to reorganisation. Imagine if the Windows registry were suddely reorganised -- loads of things would break. The important thing is to make sure that additions into the default user.xml can be merged with the user's own additions without one set overriding the other.

Link to comment
Share on other sites

  • Replies 60
  • Created
  • Last Reply

Top Posters In This Topic

I was wondering to what extent the upgrade problem could be simplified by splitting user.xml into several XML files. As the file gets larger, it may be worth doing this particularly if some aspects need to be upgraded whilst others don't.

 

For example, it is unlikely that the colour schemes will ever need to be upgraded as part of a new release, so these could go in a separate colours.xml file, whilst UI state could go into state.xml which is often upgraded as new features are added.

 

Would this make the upgrade system any easier?

Link to comment
Share on other sites

Yes, it definitely would make it easier. I think I suggested this before, but we agreed on having everything in one user.xml file, but I'm not sure, perhaps I only thought about it.

 

However, I believe it would be quite easy to export/import things to and from separate files and I will happily implement this, if we think this helps. We can add this to the ToDo-List.

Link to comment
Share on other sites

Yes, it definitely would make it easier. I think I suggested this before, but we agreed on having everything in one user.xml file, but I'm not sure, perhaps I only thought about it.

 

I think you did suggest it actually -- at the time it seemed reasonable to keep everything in one file but that was before it got as large as it is now.

 

However, I believe it would be quite easy to export/import things to and from separate files and I will happily implement this, if we think this helps. We can add this to the ToDo-List.

 

I was thinking it ought to be reasonably easy too, because the XML registry has methods to import additional files.

Link to comment
Share on other sites

Just added three new colours for the light center, and the upgrade paths are growing already, so I will have to come up with something to make the upgrading a bit easier. I think this will be the next thing after the light center, but should hopefully be done this weekend.

 

edit: Another possiblity would be to have the light center inherit the colours from the patch vertices, but somehow I would prefer that being customisable.

Link to comment
Share on other sites

I split the user.xml file into parts: the default colourschemes went into colours.xml and the upgradepaths into another xml file. This should at least make maintaining of the files a bit easier.

 

Memo to ourselves: We have to increase the version tag in the user.xml before we release the next version, otherwise the upgrade won't be triggered.

Link to comment
Share on other sites

Now that the colours are split, can we do away with upgradepaths entirely just by deploying a new version of user.xml but not touching colours.xml?

 

The key behind splitting is to split things into files that are likely to be upgraded but NOT heavily customised by the user (user.xml), and those that will be heavily customised and hence should not be upgraded (colours.xml).

Link to comment
Share on other sites

I'm pretty sure that we will need (smaller) upgradepaths in the future for importing user defined things like "Show Size Info" and so on, unless the positions of the settings within the xml are not changed in any way. In that case it's possible to leave the user.xml alone.

 

At the moment some registry structures are not quite done, but they should be "stable" at the time DR 1.0 is ready for release. Beyond this point, we probably have defined every possible colour in the xml files and all the other things have settled in - then we could do away with the upgrade paths.

 

I just have to take care of some smaller logistics, i.e. which part of the user tree gets saved into the custom user.xml and which part not. Which will also take some restructuring, I'm afraid.

 

The question is, how important is it for us to safely upgrade pre-1.0 Darkradiant releases. If the priority is low, we could now mess around with the structure until it fits our needs, but the users may have to delete their user.xml on upgrading (or DR would delete it on upgrading).

 

(I hope my post makes sense...)

 

At least I can promise that I will look into it and take care that, by the time 1.0 is released, everything is in order.

Link to comment
Share on other sites

  • 3 weeks later...

I've committed some changes to the XMLRegistry upgrade and export code. The colour schemes and the input definitions are now saved into and imported from separated xml files in the user settings folder. Hopefully this will mean less work for us during future upgrades.

 

If any of our beta-mappers using the latest released version of DarkRadiant could send me his or her user.xml file (the one in C:\Documents and Settings\user\Application Data\DarkRadiant\user.xml) this would be really helpful.

Link to comment
Share on other sites

  • 4 weeks later...

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

    • taffernicus

      i am so euphoric to see new FMs keep coming out and I am keen to try it out in my leisure time, then suddenly my PC is spouting a couple of S.M.A.R.T errors...
      tbf i cannot afford myself to miss my network emulator image file&progress, important ebooks, hyper-v checkpoint & hyper-v export and the precious thief & TDM gamesaves. Don't fall yourself into & lay your hands on crappy SSD
       
      · 2 replies
    • OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 7 replies
    • Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
×
×
  • Create New...