What do I have to type in command line parameters to summon Mancubi?

[Graf Zahl]

Quasar said:

And I will actually admit to, in some cases quite deliberately, choosing different names for the thingtypes in EDF, chiefly for the very reason that was being discussed in this thread. I felt that the names in ZDoom were variously confusing, tangential to the thing's purpose, or just outright bizarre in a few cases.

I felt that preferring names which reflect what end users know the objects as (ex: Mancubus, not Fatso; or BeerStein and not TableShit5 or whatever) would result in a much more user-friendly editing experience.

I agree with the inappropriateness of ZDoom's names - but was that alone really reason enough to create a potential compatibility issue?

You know, I'd gladly rename ZDoom's things if I could but as we all know the names have been accessible for far too long at that time...

Concerning a conversion tool, of course for some stuff it could be done, but what about compiled ACS scripts, should Eternity ever use them?

[Quasar]

Graf Zahl said:

I agree with the inappropriateness of ZDoom's names - but was that alone really reason enough to create a potential compatibility issue?

You know, I'd gladly rename ZDoom's things if I could but as we all know the names have been accessible for far too long at that time...

Concerning a conversion tool, of course for some stuff it could be done, but what about compiled ACS scripts, should Eternity ever use them?

At the time, it wasn't a compatibility issue. There wasn't any plan or "hope" for our features to overlap with those of ZDoom closely enough for it to matter whether or not the names were the same.

I've already found ways to handle DECORATE states on top of the pre-existing EDF state system, and I've managed to allow ACS to start sounds by their SNDINFO-specified names despite EDF having a pre-existing sound definition system. I don't anticipate any serious problems with thingtype mnemonics; a solution will reveal itself.

[Graf Zahl]

Quasar said:

a solution will reveal itself.

Of course, maintaining a list of aliases is no big deal. It's still one more indirection somewhere that might cause problems.

And I won't deny that ZDoom has a few such problems itself from before I started working on it myself.

For example, why was it necessary to make Strife's conversation ID a separate property? Since Strife has no ACS it would have been easily possible to reuse the ACS spawn ID for it.

So right now ZDoom has 4 'official' identifiers to reference an actor: its name, its spawn ID, its conversation ID and its editor number. One doesn't have to do much math when it becomes too many (if it isn't already...)

And in hindsight I think these IDs (except the name, of course) should never have been properties of the actor itself but instead been defined in an external table so that redefining them is less of a problem. The DECORATE 'replaces' workaround is also one of these hideous features that with proper planning should never have been necessary...

Another thing that still gives me headaches is the strange handling of Hexen's Flechette. It's the only item that gives different inventory items, based on which class picks it up - but instead of deciding what to do when the item is used it's done when it is picked up. Too bad that people were already (ab)using this so there never was a chance to properly fix this.


So, in a nutshell, I have seen enough of this and do my research now before I start implementing stuff.


BTW, while we are talking about compatibility issue, can you explain what the ML_BLOCKMONSTERS flag does when combined with ML_3DMIDTEX? It's the one thing I never fully understood and I'd really like to make ZDoom's 3DMIDTEX implementation fully compatible with Eternity's and this flag's handling is still missing.