Will the forthcoming changes in the Doomsday engine make the maps produced by software like Doom Builder 2 and DeepSea incompatible with the Doomsday engine?
Our goal is to retain the same level of compatibility or extend it further, for instance with additional Boom feature support. Certainly any WAD that works today should also work in the future, possibly even better.
Doomsday has long had a converter plugin that converts Doom and HeXen format maps (though not UDMF currently) to Dday map format. This is why Dday takes a tiny bit longer loading/unloading maps than other ports; it's converting them, as well as simply loading them.
Once upon a time, Dday use to display a log of text as it was loading maps, that would allow people with a keen eye to catch 'converting' written in it. But Deng team shifted this to debug level.
As Skyjake says, though Dday supports the Doom and HeXen map formats, it doesn't yet support all the feature enhancements various ports have made; Boom features (98% of Boom features), ZDoom features etc etc and currently, following the rewrite, hasn't fully restored it's own XG yet. But that will change.
Now that the DED 2.0 implementation is starting to materialize (in the form of ScriptedInfo), we are approaching the time to address the XG regressions and begin work on XG 2.
There is currently no support in Dday map format for XG's dummy lines;
If an XG def that uses them (which is a big part of XG's functionality) attempts to run, Dday currently shuts down with a debug message saying they are not; "P_AllocDummy: Dummies of type DMU_SIDE not supported."
DaniJ placed that there in the past, to avoid Dday crashing until the time was available to deal with it.
On top of the bugs at Sourceforge, I also don't think the damage class currently works (i.e no damage is dealt); but, as is my understanding, until the above is re-instated, there is little testing possible with XG.
There is currently no support in Dday map format for XG's dummy lines. If an XG def that uses them (which is a big part of XG's functionality) attempts to run, Dday currently shuts down with a debug message saying they are not; "P_AllocDummy: Dummies of type DMU_SIDE not supported."
This is a relatively new regression which is the result of map format changes (one can no longer allocate a side independently of a line). Will fix.
The error you mentioned was actually for something else and I added it to catch an edge case that wasn't being handled.
Edit: Fixed the aforementioned regression for the next unstable build and the upcoming 1.11.2 release.
On top of the bugs at Sourceforge, I also don't think the damage class currently works (i.e no damage is dealt); but, as is my understanding, until the above is re-instated, there is little testing possible with XG.
To correct myself; the damage class appears to be working fine, but it may actually be floor chains that aren't working.
Comments
Once upon a time, Dday use to display a log of text as it was loading maps, that would allow people with a keen eye to catch 'converting' written in it. But Deng team shifted this to debug level.
As Skyjake says, though Dday supports the Doom and HeXen map formats, it doesn't yet support all the feature enhancements various ports have made; Boom features (98% of Boom features), ZDoom features etc etc and currently, following the rewrite, hasn't fully restored it's own XG yet. But that will change.
Now that the DED 2.0 implementation is starting to materialize (in the form of ScriptedInfo), we are approaching the time to address the XG regressions and begin work on XG 2.
If an XG def that uses them (which is a big part of XG's functionality) attempts to run, Dday currently shuts down with a debug message saying they are not; "P_AllocDummy: Dummies of type DMU_SIDE not supported."
DaniJ placed that there in the past, to avoid Dday crashing until the time was available to deal with it.
On top of the bugs at Sourceforge, I also don't think the damage class currently works (i.e no damage is dealt); but, as is my understanding, until the above is re-instated, there is little testing possible with XG.
The error you mentioned was actually for something else and I added it to catch an edge case that wasn't being handled.
Edit: Fixed the aforementioned regression for the next unstable build and the upcoming 1.11.2 release.