inheriting from hexen actor

[bytor]

ZDoom 2.4.1, Doom2/hex format,

I'm trying to use inheritence to place the firedemon(Hexen) into my map. All the sprites are in my.pk3/Sprites, all sounds in my.pk3/Sounds, and I have the sounds defined in a sndinfo.txt. My Decorate reads:

actor FireBat : FireDemon 890 //tried with "replaces zombieman"
{
Game Doom //i've tried without this and with "Game Hexen"
SpawnID 200 //tried without
}
(In my initial attempts I had eliminated all the 'pod' frames in Decorate so that it spawns already as the firedemon,in the air, bobbing.)

All my attempts yield the same thing: The firedemon is there...looks great, sounds great, attacks and does damage...but takes no damage and 'floats' along the floor with player movement (no not it's straffing the pod does it, too). Like it's not 'attached' to the invironment.

Is this an issue with the fact that I don't see "chase" as a viable State on the Wiki? I don't find these, either: action native A_FiredRocks();, action native A_FiredChase();, action native A_FiredAttack();, action native A_FiredSplotch();. What are these doing? No errors from zdoom unless I put them in MY Decorate (along with rest of firedemon definition) Can I make this actor work properly with inheritance or no?

[Gez]

I don't see any reason this wouldn't work. Unless they're buggy in Hexen as well?

You can also try this:

Actor FireBat : RandomSpawner 890 { DropItem "FireDemon" }

Then it'll place an actual FireDemon in the map when spawn, no need for inheritance if all you want is to give it a Doom-compatible editor number.

[bytor]

Thankyou for responding Gez. I tried it but got the same result.

Sooo...I went to look at the sprites and discovered that when I converted/exported them the offsets all zeroed. I put all the offsets back in and...WHALAA! My "FireBat" now works perfectly inheriting from the FireDemon. Not understanding how this affected it NOT taking damage, though. But I accept!

Now...What about these: action native A_FiredRocks();, action native A_FiredChase();, action native A_FiredAttack();, action native A_FiredSplotch();. What are these doing? I don't find them on the wiki. I >guess< these are 'defining' the strafing, pod death, etc.... but I don't see what it's calling(?) from or...?

[Gez]

bytor said:

Not understanding how this affected it NOT taking damage, though. But I accept!

Simple: they weren't actually were you were shooting! :p

bytor said:

Now...What about these: action native A_FiredRocks();, action native A_FiredChase();, action native A_FiredAttack();, action native A_FiredSplotch();. What are these doing? I don't find them on the wiki. I >guess< these are 'defining' the strafing, pod death, etc.... but I don't see what it's calling(?) from or...?

FiredRocks: I think it spawns little debris when the affrit unfurls.
FiredChase: just a variant of A_Chase
FiredAttack: strafing attack
FiredSplotch: spawns little gibs when it dies and crashes on the ground

There are a fuckton of such restricted codepointers, documenting them all takes a lot of time and of motivation.

[bytor]

Gez said:

Simple: they weren't actually were you were shooting! :p

Man...I had the SSG shootin' all over the place! ;p

"restricted" from what? Where's it at?

"variant of..." is what I'm really wantin', I guess. The 'non-restricted' variant of these codepointers so I can retain it's strafing, missle, death but eliminate the pod and it's little death-turds. The A_FiredRocks is a part of it's See state. Using Inheritance and I leave that out along with A_UnSetInvulnerable (-Invulnerable in properties?), and replace the 'pod' frames. Goto Chase. "Chase" is a State not found on the wiki, either. "Restricted" State? And of course it's Spawn State needs the frames changed, too but how can I duplicate the strafing, etc. without using inheritance?

[Gez]

bytor said:

Goto Chase. "Chase" is a State not found on the wiki, either.

Are you reading the same wiki I am? It's right between the See and Pain state sequences.

bytor said:

And of course it's Spawn State needs the frames changed, too but how can I duplicate the strafing, etc. without using inheritance?

Why, why, why, why, why, why, why? Why "without using inheritance"? Why? Oh god why why why? Why? Why? Why? It makes no sense I mean what is but why but I don't why it system failure critical error


With using inheritance because inheritance is great and it is your friend and you should use it all the time because it is the best thing ever and it is stupid not to use it:

Actor FireBat : FireDemon 890
{
	-INVULNERABLE
	States
	{
	Spawn:
		FDMN ABC 5 Bright A_Look
		Loop
	See:
		Goto Super::Chase
	}
}

That's pretty much all you need to do. It's so simple, so clean, so straightforward that I can't understand why you would want to try otherwise.

[bytor]

Gez said:

Are you reading the same wiki I am? It's right between the See and Pain state sequences.

wtf?
http://zdoom.org/wiki/Actor_states
I don't see that here. What are YOU lookin' at? i want it

Gez said:

That's pretty much all you need to do. It's so simple, so clean, so straightforward that I can't understand why you would want to try otherwise.

Because to learn how this 'Thing' works is to open up a vast horizon for me and the firedemon. I can make it dance! I can make it sing!

[Gez]

bytor said:

wtf?
http://zdoom.org/wiki/Actor_states
I don't see that here. What are YOU lookin' at? i want it

http://zdoom.org/wiki/Classes:FireDemon

[bytor]

:::pounding head on table::: Yes...I know it's used in the actor's definition! It's not listed anywhere as a usable state, though! And neither are A_FiredChase(), etc.(functions). ZDoom won't even let me use them in my own Decorate! Just curious as to how these are workin'. That's all. And I didn't realise you could leave a state blank ("See" in your example)! Thanks for that.

"restricted" he says. :::grumble grumble::: Am I on restriction? Why didn't somebody tell me? I'm just gonna...go...now...

[Gez]

The list of actor states is there for listing hardcoded actor states -- like when something dies, it goes in the death state. Nothing prevents an actor from having custom states. You can have as many custom states as you want, in fact.

Here, the spawn state is used for the curled-up-in-a-ball wait, and the See state (which is entered when A_Look finds something) is used for the transformation sequence. The Chase state is simply used instead of a "normal" See state. Notice how the Pain and Missile state sequences end up with "Goto Chase" instead of the "Goto See" you'd normally see on most actors?

So the code I provided gets rid of the normal sequence by having spawn state sequence use the "flying" sprites from the Chase state. And the See state is directly remapped to the Chase state so it goes there.

Restricted codepointers are codepointers that are declared in an actor that is not Actor or Inventory, and as a result cannot be used freely anywhere. Documenting them is a low priority because there are nearly two hundred of them still undocumented and nobody seems to want to do it. If you're not happy about it, learn C++, read the source code, and write the doc yourself. That's what I do after all...

ZDoom will let you use them if you inherit from the actor that declares them. That is another reason why you should use inheritance. It's there to be used.

[bytor]

Gez, thankyou for your wisdom and patience. While I had found the Thinker in the zdoom.pk3 (actors/actor.txt), it was without the description found in the wiki link you provided and I hadn't stumbled upon it. So in trying to learn how these Actors work I run into this puzzling roadblock concerning the aforementioned (restricted codepointers, Chase as State). I went completely through the zdoom.pk3 lookin' for some kinda "#include" or SOMETHING. So I guess they're 'defined'(?) in the .exe or somewhere that I'm not gonna know what the hell I'm lookin' at anyways. Leaving it at that.

And yes, while I never got into the DEHackiness thing, I DO appreciate how far removed this "Inheritance" really is!

Gez said:

If you're not happy about it, learn C++, read the source code, and write the doc yourself. That's what I do after all...

Keyword is "learn". I know it's obvious. So I log onto Doomworld (as a last resort!) to pick away in my (seemingly?) nonsensicle way.

Again...thanks, Gez. I'm good (for now).