Doomworld Forums - Adding monsters without DECORATE

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Doom Editing > Adding monsters without DECORATE

Author

All times are GMT. The time now is 17:20.

Dad Raulo
Warming Up

Posts: 22
Registered: 04-09

I want some custom monsters in my map, without the use of this DECORATE thing, I saw this in a couple of maps like coopbuild for example, where you can see the green cacodemon.

04-16-09 00:58 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6458
Registered: 07-07

Why don't you want to use decorate?
If you aim for generic Doom compatibility, you'll have to use dehacked, and that means that you can't add anything new -- you can just modify stuff until they're completely different, so a useless monster like the commander keen or the wolf SS can be turned into something else.

04-16-09 01:14 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

StupidBunny
Forum Regular

Posts: 831
Registered: 09-07

Exactly what Gez said. Unless you're using ZDoom or anything that supports DECORATE, you cannot add any new objects, or even new frames of animation. If you look at Scythe II as an example, it does not use DECORATE but introduces both the afrit and the evil marine as characters. If you open the WAD with XWE or whatever, you'll notice that the afrit replaces Commander Keen, and the evil marine replaces the Wolfenstein SS. That's the best demonstration I can think of for "adding" new monsters without DECORATE.

In all honesty, though, DECORATE isn't that hard to use and is a lot more flexible and probably easier in the long run. The only reason not to that I can think of is if you want your WAD to be able to run outside of ZDoom and equivalent source ports.

04-16-09 01:34 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Dad Raulo
Warming Up

Posts: 22
Registered: 04-09

The main reason is because i was messing around with XWE, and the I read about this DECORATE stuff, but it seems I can't get it to work, even though I read the tutorials thousand of times.

I really don't want to ADD new monsters, but to modify some monsters colours, nothing out if this world. Maybe fool around with their speeds and HP.

(Sorry for my english)

04-16-09 01:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

StupidBunny
Forum Regular

Posts: 831
Registered: 09-07

It's quite possible to replace animation frames for existing monsters, and speed and HP (as well as a lot of other aspects) can be altered with DeHacked or something similar. But if you put in a revamped version of a monster, will you want to keep the original version of the monster as well? Because if so, you won't be able to; the new monster will entirely replace the old one. If that's what you want then DECORATE won't be necessary. Otherwise, what is the error you're getting when you try running the WAD with DECORATE?

04-16-09 03:36 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

40oz
And who knows, maybe I'm wrong. But that's extremely unlikely because I'm always right.

Posts: 4850
Registered: 08-07

Gez said:
so a useless monster like the commander keen or the wolf SS can be turned into something else.

Is it true that you can modify decorations and stuff too? You could use one of the many hanging corpse and bloody mess sprites to replace as a new monster too right?

04-16-09 04:14 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

JohnnyRancid said:

Is it true that you can modify decorations and stuff too? You could use one of the many hanging corpse and bloody mess sprites to replace as a new monster too right?

You could, but the frames themselves (i.e. what programs the monster's actual behavior and animations) have to be borrowed from somewhere, too. A monster needs a ton of them, whereas decorations only have something like 1 or maybe 4 if it's a torch or something.

04-16-09 04:22 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Vermil
Senior Member

Posts: 1146
Registered: 03-04

StupidBunny said:
Unless you're using ZDoom or anything that supports DECORATE, you cannot add any new objects, or even new frames of animation.

While Decorate may be the most popular and by far the most powerful, other ports do have the ability to add new objects, frames etc to varying degrees.

Last edited by Vermil on 04-16-09 at 10:37

04-16-09 10:29 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

EarthQuake
9.5 on the Richter!

Posts: 2710
Registered: 05-03

Also note that ZDaemon has DEHSUPP support, so adding new custom monsters built from Heretic/Hexen classes will be possible once the Spawn() ACS is functional in 1.09. Half the work is already done.

And heh, it's funny you mentioned the green cacodemon from coopbuild. I was the one who suggested the idea (the original plan was to use the color translations to turn it into gray, red, and brown cacodemon variants, but toke didn't get the chance to follow through on it ;_;).

04-16-09 10:53 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6129
Registered: 06-06

Keep in mind that for vanilla Doom you can use a replaced sprite and get away with it, with Dehacked (here). And the sprite frame/rotation codes don't have to be exactly like in doom(2).wad -- you can use TROOB0 or POSSA1C3 for instance and it won't bomb. Note that for vanilla Doom compatibility you need to cover all letters in range -- between frames A and N, for example, there can't be a missing L or it will bomb.

__________________
HELL GIVES.

04-16-09 14:49 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

Vermil said:

While Decorate may be the most popular and by far the most powerful, other ports do have the ability to add new objects, frames etc to varying degrees.

EDF, DDF, and svstrife definitions just to name a few :)

04-16-09 21:05 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

kristus
Megablast!

Posts: 9570
Registered: 07-00

Vermil said:
and by far the most powerful,

What do you base this off?
VavoomC for starters is most likely a lot more versatile than Decorate. But it's also a lot more complex and as such no one is really using it (on top of that hardly anyone is using Vavoom that is).

04-16-09 21:29 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

Decorate is also only marginally "more powerful" than EDF. Both are data specification languages and both define almost the same set of objects (and more or less *will* after the addition of inventory and weapons to EDF, which is upcoming).

Ever since EDF was added to EE, people have been calling DECORATE more powerful, including when EDF was first to be able to define arbitrary thing types including monsters, arbitrary frames, and the first with an inheritance system (only by a matter of a week or two in that case, though). So you can understand why it wears a little thin on me :)

The only reason people aren't aware of what EDF does is because nobody's used it so far. I am hoping that esselfortium is going to fix that problem though ;)

04-17-09 18:17 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Vermil
Senior Member

Posts: 1146
Registered: 03-04

I didn't mean to start anything. Indeed I didn't thoroughly research the abilities of every port in the area of new mobj defining before making a comment about power. My apologies.

I wonder what the very first port to be able to define new actors/frames freely was?

04-17-09 18:45 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

kristus
Megablast!

Posts: 9570
Registered: 07-00

DosDoom (EDGE) IIRC

You may not have intended to start anything, but spreading uneducated assumptions as fact is counter productive.

04-17-09 18:59 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

Yes, to my knowledge EDGE was the first with DDF. I had been planning such for EE since way back in '97, but my programming skills had to catch up dramatically with my goals ;)

04-18-09 00:00 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

Quasar said:
Decorate is also only marginally "more powerful" than EDF. Both are data specification languages and both define almost the same set of objects (and more or less *will* after the addition of inventory and weapons to EDF, which is upcoming).

Ever since EDF was added to EE, people have been calling DECORATE more powerful, including when EDF was first to be able to define arbitrary thing types including monsters, arbitrary frames, and the first with an inheritance system (only by a matter of a week or two in that case, though). So you can understand why it wears a little thin on me :)

The only reason people aren't aware of what EDF does is because nobody's used it so far. I am hoping that esselfortium is going to fix that problem though ;)

Concerning 'more powerful', one important aspect here is how easy it is to define something. But when I look at this I think that many potential users may be put off by the clumsy way in which states are defined. Wasn't there an easier way to do it? I believe I can remember such discussions a few years back.

It was one very important aspect for me not to expose too many engine internals to the user so all states are part of the actor itself and not an external definition block.

04-18-09 07:47 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

It's kind of off-topic to discuss it here, but the main reason that EDF states were defined separate from thingtypes is that they have always been shareable, and EDF has always defined all objects, not just a subset of them. Since all EDF things can be edited through DeHackEd, they needed to be immediately addressable. Making them global objects seemed like the best way to do this at the time.

There are obvious problems with it, and it is less ideal (not less powerful) than DECORATE's state syntax. However, this has been previously discussed with users, and since addition of heredocs to EDF's tokenizer, I may in fact be able to add something similar to DECORATE state syntax, and this has been on my TODO list for a while now.

04-18-09 17:00 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6129
Registered: 06-06

Graf Zahl said:
Concerning 'more powerful', one important aspect here is how easy it is to define something. But when I look at this I think that many potential users may be put off by the clumsy way in which states are defined.

Yeah potential users may be detracted when they lack patience to learn. If you compare the EDF definition syntax then it's not too different from DEH anyway: every object has variables to set, like in Dehacked.

__________________
HELL GIVES.

04-18-09 18:16 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 6458
Registered: 07-07

I'd welcome it. The ZDoom family are still my favorite port, but I follow Eternity's development with interest. EDF looks rather unwieldy as it is now, too low-level and too close to the original C code. Contrasting EDF frame definitions with DECORATE states, there's a lot more "meaningless" characters in EDF. ("Meaningless" in quotes because I know they really have a purpose; and it's also required because the language specs prevent from using newlines or whitespace as delimiters, so more tokens are necessary for correct parsing.)

Still, when comparing DECORATE:

code:  See:
    BMBE AAABBBCCCDDD 2 A_Chase
    BMBE A 0 A_PlaySound("suicide/scream")
    loop

with EDF:

code:frame BMBE_SEE_A	{ cmp = "BMBE|A|*|2|Chase|@next" }
frame BMBE_SEE_B	{ cmp = "BMBE|A|*|2|Chase|@next" }
frame BMBE_SEE_C	{ cmp = "BMBE|A|*|2|Chase|@next" }
frame BMBE_SEE_D	{ cmp = "BMBE|B|*|2|Chase|@next" }
frame BMBE_SEE_E	{ cmp = "BMBE|B|*|2|Chase|@next" }
frame BMBE_SEE_F	{ cmp = "BMBE|B|*|2|Chase|@next" }
frame BMBE_SEE_G	{ cmp = "BMBE|C|*|2|Chase|@next" }
frame BMBE_SEE_H	{ cmp = "BMBE|C|*|2|Chase|@next" }
frame BMBE_SEE_I	{ cmp = "BMBE|C|*|2|Chase|@next" }
frame BMBE_SEE_J	{ cmp = "BMBE|D|*|2|Chase|@next" }
frame BMBE_SEE_K	{ cmp = "BMBE|D|*|2|Chase|@next" }
frame BMBE_SEE_L	{ cmp = "BMBE|D|*|0|PlaySound|BMBE_SEE_A" misc1 = sound:suscrm }

There's a lot more redundant information given in the EDF version, which could be factorized somehow I'm sure. Maybe something a bit like this (just for illustration, not an actual proposal):

code:state BMBE_SEE
{
   frames A,B,C : { cmp = "BMBE|A|*|2|Chase|@next" }
   frames D,E,F : { cmp = "BMBE|B|*|2|Chase|@next" }
   frames G,H,I : { cmp = "BMBE|C|*|2|Chase|@next" }
   frames J,K : { cmp = "BMBE|D|*|2|Chase|@next" }
   frames L : { cmp = "BMBE|D|*|0|PlaySound|BMBE_SEE_A" misc1 = sound:suscrm }
}

That would already remove a lot of redundant (for a human) code. Even better would be something like this:

code:state BMBE_SEE
{
   frames A,B,C,D,E,F,G,H,I,J,K : { cmp = "BMBE|AAABBBCCCDD|*|2|Chase|@next" }
   frames L : { cmp = "BMBE|D|*|0|PlaySound|BMBE_SEE_A" misc1 = sound:suscrm }
}

Such a method would still give a unique name to each frame, but it's the engine that would expand frame A from state BMBE_SEE into frame BMBE_SEE_A, and the modder would have a lot less identical stuff to type.

Just my two cents.

04-18-09 18:46 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

I don't understand why a definition format needs to be more machine friendly than human friendly as all your suggestions are.

For example, get rid of @next - and what does the * mean? At least in the listed examples it serves no purpose. I'm taking a guess here but it seems to me that most of EDF's syntax is dictated by the underlying parser's limited capabilities and not by what would be nice to have.

As the DECORATE code shows most of this information does not even need to be specified because it can easily be deduced from the definition without explicitly spelling it out.

04-18-09 21:18 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 6129
Registered: 06-06

Maybe it's because ZDoom is older and Eternity has important things still in development (including other games' support; some things may also change), that the EDF system looks more machine-like than DECORATE, for now.

Don't ignore the dehackednum variable, which is still needed where flexible codepointers are employed. Dehackednum requires to allocate a unique number at least 10000 to each key frame or thing (that are addressed by codepointers) and to every sound. That may add a bit to the difficulty to write :)

Good thing there's cmp and there's copy-paste, and I may write myself an EDF front-end if need be.

Regarding adding monsters without DECORATE, I noticed that in Doom 1, if you define with Dehacked a new monster with an ID # of a Doom 2 monster, no it won't appear in the game if you place it.

EDIT: @next is started by an AT in order to be marked as a symbol, not as a state name, but perhaps you knew it. I agree that it's not a good idea to link frames topographically with markers like this, though.

__________________
HELL GIVES.

Last edited by printz on 04-18-09 at 21:44

04-18-09 21:31 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5152
Registered: 01-02

Don't ignore the dehackednum variable, which is still needed where flexible codepointers are employed. Dehackednum requires to allocate a unique number at least 10000 to each key frame or thing (that are addressed by codepointers) and to every sound. That may add a bit to the difficulty to write :)

What? I've never had any need for this, ever.

04-18-09 22:02 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 4484
Registered: 08-00

Eternity does not require explicit allocation of DeHackEd numbers any longer, and has not for several versions now. If you use an entity's name in a place where it must be translated into a numeric id, and the object in question hasn't been assigned a numeric id, one is assigned to it at that time automatically.

In addition, as of 3.35.90, it was no longer necessary to explicitly specify namespace qualifiers when doing this as long as the name in question is unambiguous.

That is, where you used to have to do this:

code:
thingtype Foobar { dehackednum = 20000 }
frame blah { ... args = { thing:Foobar } }

You can now simply do this:

code:
thingtype Foobar { ... }
frame blah { ... args = { Foobar } }

Automatic resolution of names to numbers is done amongst the supported namespaces in a predefined order. In short, this wasn't implemented in EDF originally simply because I didn't think of it.

EDF's syntax *is* defined by the abilities of the libConfuse parser - it must be based on a fixed, orthogonal set of tokenization rules, and a finite-state-automaton parser. This means that it is a formally specified language, but also that it has to accept certain limitations. This is why I added heredocs, to enable isolation of embedded languages that can be parsed by submodules.

This will enable this sort of syntax:

code:
thingtype Foobar
{
   states = 
   @"
    See:
      BMBE AAABBBCCCDDD 2 Chase
      BMBE A 0 PlaySoundEx("SuicideScream")
      loop
   "@
}

The only added syntax here over DECORATE are the heredoc string delimiters.

The reason this hasn't been implemented yet is chiefly because Eternity still expects all states to be contained within a cohesive array. There are code segments surviving from DOOM which expect "state - states" to evaluate to an index into the states table, and some of these, particularly in the handling of weapon flash state, are exceptionally difficult to deal with in a backwardly compatible manner.

I am working on it, though.

04-18-09 22:10 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 6962
Registered: 01-03

printz said:
Maybe it's because ZDoom is older and Eternity has important things still in development (including other games' support; some things may also change), that the EDF system looks more machine-like than DECORATE, for now.

I don't think it has anything to do with age. Although DECORATE wasn't added to ZDoom before early 2004 its rules date 3 years further back to a time when I was doing most stuff in private without releasing it. But when I designed the state format it was with the explicit goal to automate any data generation that could be automated.

Admittedly, back then Dehacked considerations did not come into play at all because it was not needed. But since the generated data is 100% the same as the one internally defined by ZDoom was then, when the time came to externalize all actors to DECORATE no additional work was needed. The state map in DEHSUPP can perfectly take care of it.

printz said:

Regarding adding monsters without DECORATE, I noticed that in Doom 1, if you define with Dehacked a new monster with an ID # of a Doom 2 monster, no it won't appear in the game if you place it.

The same logic works both ways: If you give a Doom 2 monster another ID # in Dehacked it can be spawned in Doom 1. The only things that won't ever work are the SSG and the Megasphere.

04-18-09 22:20 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

redcrow
Newbie

Posts: 8
Registered: 09-10

StupidBunny said:
It's quite possible to replace animation frames for existing monsters, and speed and HP (as well as a lot of other aspects) can be altered with DeHacked or something similar. But if you put in a revamped version of a monster, will you want to keep the original version of the monster as well? Because if so, you won't be able to; the new monster will entirely replace the old one. If that's what you want then DECORATE won't be necessary. Otherwise, what is the error you're getting when you try running the WAD with DECORATE?

That is actually what I am trying to do right now, simply replace the monsters, weapons, & HUD with my own sprites, replacing some of the sounds as well.

I've been playing around with slumped & XWE for a few months now and I can't seem to get anywhere, despite all the tutorials and everything I read through.

For the record, I have very little experience with any sort of coding. I spent about half a year trying to learn C & C++ and then school started and I didn't have time to do any of that, forgetting a lot.

In slumped I figured you can't use BMPs or you'll have that annoying white box around your monster. In XWE I can't figure out how to even replace a sprite-which is really frustrating because I did it once a while ago and then I didn't have time to use XWE for too long can't figure out how I did it again.

THEN, in slumped whenever I replace sprites and try to save that into the WAD, it tells me I have to save as, so I try that and it says "saving is disallowed."

I wonder if anyone could help me with either of these programs. For instance, I'm trying to replace "SPOSA1" with my own zombie, so I find that sprite, and then try a gazillion different things, and I cannot figure out how in XWE to import the image. I don't want to mess with all that dehacked decorate stuff, just replace the images in XWE or some other WAD editor.

09-04-10 18:39 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 17:20.

Doomworld Forums > Classic Doom > Doom Editing > Adding monsters without DECORATE

Show Printable Version |

Email this Page |

Subscribe to this Thread

Forum Rules:

You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON

< Contact Us - Doomworld >