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

[The_MártonJános]

The thread title speaks for itself - the command lines say that "Mancubus" is an unknown class and I don't have any other ideas what the hell they could be to be summoned.

[tempun]

Cell said:

The thread title speaks for itself - the command lines say that "Mancubus" is an unknown class and I don't have any other ideas what the hell they could be to be summoned.

IIRC it's called "fatso".

[Phobus]

It is definitely "fatso".

[The_MártonJános]

Phobus said:

It is definitely "fatso".

Heh, that would have been even more obvious than I could imagine... :D I was trying with "fat" and then "fatt", too, because I've seen sprite datas in Slumped which names the images as "Fatt*".

Thanks!

[PRIMEVAL]

Someone call for me?

[skib]

Cell said:

Heh, that would have been even more obvious than I could imagine... :D I was trying with "fat" and then "fatt", too, because I've seen sprite datas in Slumped which names the images as "Fatt*".

Thanks!

Yeah, and the zombieman sprite is "POSS" but it's summon is "zombieman"

[printz]

Eternity has more sensible namings.

[DuckReconMajor]

FYI all of the names are here for your summoning pleasure

[Lila Feuer]

The Mancubus one stumped me too, but yeah, Fatso.

[SaladBadger]

skib said:

Yeah, and the zombieman sprite is "POSS" but it's summon is "zombieman"

Naming the zombieman's summon "POSS" would make absolutely no sense at all -- what if someone else implemented an actor that uses the sprite "POSS"?

[Vermil]

All of ZDoom's summon Doom bad guy commands, other than the Mancubus use the names from the Doom 2 ending, rather than the internal names from the Doom source. For some reason, the Mancubus summon command in Zdoom is the Doom source name for the Mancubus.

[printz]

The collectible artifact and Heretic weapon names are VERY annoying in ZDoom. I hope Eternity calls them sensibly like TomeOfPower or HellStaff.

[Vermil]

They are the source code names for the items. Except the Iron Lich.

[o.O]

you can also use summon on items, e.g. summon berserk

[printz]

printz said:

The collectible artifact and Heretic weapon names are VERY annoying in ZDoom. I hope Eternity calls them sensibly like TomeOfPower or HellStaff.

Well it doesn't. It even has HArti or HWeapon prefixed to them. BLAST.

[skib]

No, heretic weapons summon:
Crossbow = Crossbow
Dragon Claw = Blaster
Hell Staff = Skull Rod

[Graf Zahl]

printz said:

The collectible artifact and Heretic weapon names are VERY annoying in ZDoom. I hope Eternity calls them sensibly like TomeOfPower or HellStaff.

You know, statements like this can drive me up walls.

I have always been an advocate of keeping things compatible if possible and when implementing features this was always one of my major concerns that a feature that was already available in another port would use a compatible implementation in ZDoom so that maps can work on both such ports.

Well, sometimes I think I am the only person to do so. Especially the Eternity devs don't seem to take this into consideration with many things they do, even though this engine would be a prime candidate for sharing a Boom-superset of features.

The 2 biggest stumbling blocks are the line special type which ignored everything else in existence and happily reused their values for other purposes. To even handle maps that could work in both Eternity and ZDoom, ZDoom has do use a special setup because Eternity clashes left and right with previously established types.

And the same thing happens with thing type names. Again a previously estabished naming scheme (ZDoom's) has been in existence and again it was completely ignored and a separate one used. No consideration for cross-port compatibility was taken into account even though there could be features later that could make use of it. But no, it had to be different, for reasons I don't understand. And please don't tell me that it's not relevant because EDF and DECORATE are not compatible. Sure, that's right but what about ACS? What if Eternity decides to implement ZDoom's inventory functions? Any chance of a straightforward implementation has been destroyed by the different set of names.

And now you are advocating to make it worse???

[/rant]

[esselfortium]

An open letter to Graf Zahl:

Source port developers are under no obligation to do things the exact same way ZDoom did them simply because ZDoom did them first. Making it easier for ZDoom to run every wad in existence is likely not on the goal list of any other source port's developers.

ZDoom doing something doesn't always make that the best way to do it, and it's a self-defeating waste of time for them to attempt to emulate whatever you're doing solely because you did it.

[printz]

The worms are free now. Go worms go!

[SoM]

Graf Zahl said:

People aren't doing what I think they should!

... Yep.

The absolute last thing on my mind when I spend what limited free time I have working on doom code would have to be "Is this compatible with zdoom?"

[Quasar]

If there was really a demand or use for compatible thingtype mnemonics between DECORATE and EDF I could always add a zdoomname to thingtypes and give it its own hashtable. A waste of memory no doubt, but it would be simple enough to code.

[John Smith]

esselfortium said:

Source port developers are under no obligation to do things the exact same way ZDoom did them simply because ZDoom did them first. Making it easier for ZDoom to run every wad in existence is likely not on the goal list of any other source port's developers.

I find it absolutely hilarious that it's apparently the job of other source port authors to keep things compatible with zdoom, but zdoom has no obligation to keep anything compatible with doom itself unless there's a giant uproar. It's pretty telling IMO

[DaniJ]

I don't really want to get drawn into this "debate" but com'on Graf, seriously? How many features has ZDoom felt the need to re-invent? Doomsday was using native files, pk3s, models, thing definitions (etc...) long before ZDoom even broached the possibility. Yet did Zdoom do as you claim and attempt to keep things compatible? I think not.

You proclaim support for cross port compatibility but you want it on your own terms.

@Quasar:
I think we'll all (most active ports) end up doing something along those lines eventually, just for the sake of being able to load ZDoom mods as-is. I agree that it shouldn't be a driving influence however.

[Graf Zahl]

DaniJ said:

I don't really want to get drawn into this "debate" but com'on Graf, seriously? How many features has ZDoom felt the need to re-invent? Doomsday was using native files, pk3s, models, thing definitions (etc...) long before ZDoom even broached the possibility. Yet did Zdoom do as you claim and attempt to keep things compatible? I think not.

You can implement a feature differently for various reasons. But that's not the point here. Have you seen me complaining about EDF?

No, having different definition files that can coexist may be a nuisance but it's not a deal breaker.

What I have problems with is to implement something in a way that breaks interoperability with other ports. Like many of Eternity's line specials clashing with any other port that extends Boom is such a case for me. All the other ports doing that (Legacy, ZDoom and EDGE) steered clear of each other's special range so if necessary they can mutually share compatible stuff without causing problems. Eternity can't.

And yes, I know that the thing names at the moment are not a big deal but what if Eternity wants to implement some of ZDoom's ACS features later? All of ZDoom's inventory stuff depends on these names so with the current set of names there'd be 2 choices - give each actor yet another identifier or become incompatible. In my book both are bad design decisions. If the set of names was identical there'd be no need to worry. Future compatibility with any feature using these names would be ensured by design.

Oh, and regarding PK3 directory structure, yes, I investigated Doomsday but I had 2 major problems with it:

1. lack of understandable documentation
2. the feature set was too limited and the design goals too different. I needed something that translates Boom's WAD namespaces properly to a directory structure. Hard to do that when the only existing implementation doesn't even know the concept of Boom namespaces, isn't it?

Also I never, ever received a shred of feedback to ensure better compatibility.

[esselfortium]

Doesn't EDF actually predate DECORATE's thing definitions?

[RjY]

Graf Zahl said:

What I have problems with is to implement something in a way that breaks interoperability with other ports.

What do you think ZDoomisms are?

I never heard anybody say "Eternityism". Or anybody besides myk say "Boomism"

[printz]

RjY said:

I never heard anybody say "Eternityism".

That's because it's much less often used than ZDoom. Face it. Still, I'm pretty sure I was about to mention an Eternityism once, but it doesn't come into my mind right now.

Or anybody besides myk say "Boomism"

That's because myk is a much more perceptive person than most all regulars in this forum, often giving solutions no one thought about. Boomisms are more subtle than ZDoomisms, but happen because Boom also changed lots of things in the Doom engine.

[DaniJ]

Graf Zahl said:

You can implement a feature differently for various reasons. But that's not the point here.

Quite. The point being raised here is that port developers should have the common sense and professional camaraderie to refrain from public exhibitions like your rant about the Eternity team's development practices. Especially when ZDoom has made several similar decisions itself. All I'm saying is that it is in our collective best interest that prominent port developers don't fuel the "port war" mentality. Its ultimately self defeating.

Oh, and regarding PK3 directory structure, yes, I investigated Doomsday but I had 2 major problems with it:

1. lack of understandable documentation
2. the feature set was too limited and the design goals too different. I needed something that translates Boom's WAD namespaces properly to a directory structure. Hard to do that when the only existing implementation doesn't even know the concept of Boom namespaces, isn't it?

#1 Our community seemed to manage just fine, the source is openly available and the developers are too. This sounds more like "I couldn't be bothered to implement it".
#2 If this is what you think then you clearly do not understand the implementation.

Also I never, ever received a shred of feedback to ensure better compatibility.

Rubbish. There are several threads on the ZDoom forums where I did exactly that. However, you can't seriously expect other port developers to monitor anothers implementation. We aren't talking about something that was developed coincidentally. Doomsday was doing this many years before ZDoom decided it would also. How is this not deliberately redefining existing and well-used standards?

[Quasar]

EDF did have support for specifying actors in general (and not just static decor) just before DECORATE added it, but the ability to spawn actors by name had already existed in ZDoom for a long time before that and was in fact partially what drove me toward the same implementation for Eternity.

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 was never aware that there was a deliberate attempt to keep compatible linedef numbers between Legacy and DosDOOM/EDGE but obviously I have never been privy to nor asked to cooperate in any shared standard with those ports.

I'm not entirely sure, to be honest, how this is such a big deal to begin with. I don't really understand how it affects ZDoom other than you want to add the ability to load Eternity in DOOM format maps without having to do any special work to identify them as such. We simply cannot make some of the concessions you'd want us to make and it's not technically justified simply because it would make another port have an easier time loading our maps. We watch out for our own functionality first.

RE: not making sense to add ZDoom names to thingtypes after the fact, what else would you suggest? Throwing out Eternity's existing mnemonics would break EDF compatibility all the way back to when it was first created, which would include breaking De Kerker, one of the only actually released Eternity maps, as well as the Vapordemo, and many of the EDF patches I have uploaded over the years as demos or for fun. In short, that's not viable at all, whereas adopting the ability to have a secondary name lookup for thingtypes is both relatively simple and inexpensive. So which makes the most sense when I put it in that light?

[Ladna]

Isn't it simple to write a conversion tool? I mean, I don't know how many Legacy/DOSDOOM/EDGE WADs there are that people have a reasonable expectation of working in EE, but even if there's a whole lot, I'll host converted versions on totaltrash.org. It's not a big deal. It would be nice if /idgames supported different versions at the same URL though, that would be best.