Creating a "parent weapon" for several weapons

[Kzer-Za]

I'm modifying Brutal Hexen/Heretic RPG for my tastes, in the process I decided to clean up DECORATE files a bit. All the weapons in this mod have states Kicking and KickingLoop, which are the same in all of them (except for the part dealing with lowering and raising the weapon before and after the kick). So I decided to create a parent weapon for all of them (that weapon would be child for HereticWeapon) that would have these states and nothing else, then inherit all weapons from them and remove the kicking from their files.

As far as I understand, everything not changed directly should be inherited. So I thought that this code would give me a proper parent for all other weapons:

Code: Select all

Actor HLWeapon : HereticWeapon
{
	States
	{
	Kicking:
		"----" A 1 Offset(0,42)
		"----" A 1 Offset(0,52)
		"----" A 1 Offset(0,62)
		"----" A 1 Offset(0,72)
		"----" A 1 Offset(0,82)
	KickingLoop:
		TNT1 A 0 A_PlaySound("WHOP")
		CKCK ABCD 2
		TNT1 A 0 A_CustomPunch(25,true,0,"BrutalKickPuff", 104)
		CKCK E 4
		CKCK DCB 2
		CKCK AA 1 A_WeaponReady(WRF_NOSECONDARY)
		TNT1 AAA 1 A_WeaponReady(WRF_NOSECONDARY)
		TNT1 A 0 A_JumpIfInventory("Action1",1,"KickingLoop")
		Goto Select
	}
}

But when I inherited for starters the BrutalGoldWand from it

Code: Select all

ACTOR BrutalGoldWand : HLWeapon replaces GoldWand

I received an error when trying to launch GZDoom. The text of the error in GUI popup is:
Script error, ":decorate.weap_goldwand" line 6:
@property@weapon.selectionorder is an unknown actor property

And the error in the console, if I try to launch GZDoom from the command line, says:
Script error, ":decorate.weap_goldwand" line 3:
Parent type 'HLWeapon' not found in BrutalGoldWand

I thought that an actor inherited from HereticWeapon should have all properties of HereticWeapon, since I didn't change anything, only added kicking. But it seems it does not count as a "parent weapon". Or is something else the problem? What can I do about it?

[Graf Zahl]

This one says it all:

Code: Select all

Parent type 'HLWeapon' not found in BrutalGoldWand

You probably got the order of these mixed up and as a result get more seemingly weird error messages.

[Kzer-Za]

What do you mean? Like "HLWeapon : BrutalGoldWand"? If that's what you meant, then no, the code is above. And if I just change

Code: Select all

ACTOR BrutalGoldWand : HLWeapon replaces GoldWand

back to

Code: Select all

ACTOR BrutalGoldWand : HereticWeapon replaces GoldWand

then GZDoom loads OK. And it can't be a typo because I copy-pasted the name.

[Graf Zahl]

I mean you define the parent class AFTER the child class. In that case the child class cannot find it. The parent class must be defined first.

[Kzer-Za]

I mean you define the parent class AFTER the child class. In that case the child class cannot find it. The parent class must be defined first.

Thanks! And how is this order determined? Are the files just read alphabetically? For now it seems so, because when I renamed the file with the "parent weapon" from "DECORATE.weap_HLWeapon" to "DECORATE.weap_aHLWeapon", GZDoom loaded.

Here I hit enother hitch though. With the states defined in that weapon being only Kicking and KickingLoop, the weapon does not go to ready state after the kicking. I thought "Goto select" would work because I defined it in GoldWand itself, but it seems it attempts to go to the state defined in DECORATE.weap_aHLWeapon itself. So it means I will have to define Kicking again in GoldWand, so that it goes to GoldWand select state. Which means I won't be able to reuse the Kicking code after all. Is there a way around it? A way to define kicking (ot any other action shared by all weapons) in one place and the reuse it?

[ketmar]

please, don't rely on loading order! PLEASE, PLEASE, PLEASE, PLEASE! there is "#include" to include arbitrary named files, so you can create one (and only one) decorate lump, name others accrodingly, and include them. this will not rely on unspecified loading order (and will not be gzdoom-specific too).

[Matt]

please, don't rely on loading order! PLEASE, PLEASE, PLEASE, PLEASE! there is "#include" to include arbitrary named files, so you can create one (and only one) decorate lump, name others accrodingly, and include them. this will not rely on unspecified loading order (and will not be gzdoom-specific too).

In my experience* the result is the same whether I use #include or define everything in the same file, so it's not really a choice whether or not to rely on loading order...

*EDIT: which only included my experience with ZScript, per Arctangent's comment below

[Arctangent]

In my experience the result is the same whether I use #include or define everything in the same file, so it's not really a choice whether or not to rely on loading order...

There is actually a choice, just not one that doesn't come with potential drawbacks: lumping all reliant-on-others stuff in the same lump, or ( iirc ) switching to ZScript. Things can't load out of order if they're all loaded from the same source, and from what I recall reading, ZScript does actually load things in the order that they're #included in, so there's definitely ways to control that sort of stuff.

[ketmar]

>In my experience* the result is the same whether I use #include or define
>everything in the same file
you wrote that you have TWO decorate files, and were relying on their loading order. that is what i am asking not to do: there should be only one highlander decorate lump, and if you want to have your code in several files (for maintainability, for example), they should be named accordingly (NOT «decorate.somext»!), and #include-d in main lump.

if i got you wrong, then sorry. my point about «only one decorate» still stands, but i missed the target. ;-)

[Matt]

Oh, I get it! Sorry, skimmed past that part of the OP's last comment.

Yeah that decorate dot blah method is not reliable.

[ketmar]

and i took you for OP, lol. we're both got it slightly wrong here. ;-)

[Kzer-Za]

Using #include does not work. Maybe it can be used only in zscipt, but not in decorate files?

[ketmar]

it definitely works in decorate. you probably did something wrong.

[Kzer-Za]

I put

Code: Select all

#include "DECORATE.weap_HLParent"

into the first line of DECORATE.weap_GoldWand. Below it I stated

Code: Select all

ACTOR BrutalGoldWand : HLParent replaces GoldWand

.

Still, I get

Code: Select all

Script error, ":decorate.weap_goldwand" line 3:
Parent type 'HLParent' not found in BrutalGoldWand

I copy-pasted the name of the file and the name of the weapon, so it's not a typo. Is there something else I should have done?

[Matt]

Other way around!

You should have:

1. one file named "decorate", which uses "#include" to include the other files
2. the other files, none of them named "decorate", which are referenced by the central decorate file via its #includes

Think of it as a tree with branches.
(Or rather: the "#include" is not meant to suggest that you're including the previous code as a library for the current code, but rather it's a shortcut that puts in a bunch of code from the referenced file.)


Example of 1
Example of 2