Custom variables in DECORATE items

[MartinHowe]

I am doing some custom monster action functions and am having to use global variables to maintain properties of monsters created. What would be really nice would be to be able to declare extra variables inside a monster definition so that the data storage could follow the monster around. For example:

Code: Select all

ACTOR MyTrooper: ZombieMan 666
{
    health 20
    int flies 30  // number of flies on his body when killed
    str deaths[3] {"Game over man","Oh hell","I'm a dead man"}
}

The code in a script could then use, e.g.,

Code: Select all

str undead="I am now undead";
int numflies=GetActorCustomProperty("flies");
printbold(s:GetActorCustomProperty("deaths[2]"));
SetActorCustomProperty("flies",numflies-1);
SetActorCustomProperty("deaths[1]",undead);

(Recall that strings in ACS are actually handles to readonly strings, more or less).

This would also make it possible to create generic actor action functions. ACS is already powerful enough to do this, I've done it, but not having to rely on TIDs and global variables to maintain custom monster properties would have made the scripts a lot cleaner and allow them to be reentrant without lot of complicated locking stuff.

How easy/hard would this be?

[Graf Zahl]

Sorry, that is too complicated.

[MartinHowe]

Sorry, that is too complicated.

What are the reasons for that?

Surely at least each monster could have a couple of permanant variables that are built-in to all THINGS (in the same way as health and so on) that could be free for general use.

For example, if every THING had four integers (for example call them misc1, misc2, misc3 and misc4), for many WADs this would be enough.

For those in which it would not be enough, one of the integers could be used as an index into an array. The array would still have to be global and the programmer would still have to maintain a sort of "tid", but this would at least allow ACS action functions to be generic and not rely on whether a monster has a "normal" TID or not.

In other words, if giving us what we want is too difficult, at least it would be nice to have the hook into the system to do it ourselves. Right now, there is AFAIK no way to store even one user-defined value that is part of a monster or object. There should at least be that.

[Graf Zahl]

Ask Randy for the next version. For the unofficial build it would require too extensive changes.
You can use dummy inventory items as a substitute though.

[MartinHowe]

Ask Randy for the next version. For the unofficial build it would require too extensive changes.
You can use dummy inventory items as a substitute though.

Sure.

This was actually a query to Randy for the official build anyway; of course whether Randy would view this as necessary or not, only he knows

[Sphagne]

Hey, my solution for DECORATE object variables was a lot simpler than this and it was not accepted.

[Graf Zahl]

The problem here is that I don't want to mess around with too much code. Since I have absolutely no idea what Randy is doing it might all be wasted. Sorry, guys, but you have to bug Randy to be a little more informative before I'll consider adding this.

[Sphagne]

Have you ever caught randy as a talkative person? I dont think so. He is always mystrious, like a phantasm.

[Cutmanmike]

Lots of people here are. LWM was the worst for it.

You could however go purchase WoW and somehow find him on there.

[Graf Zahl]

Have you ever caught randy as a talkative person? I dont think so. He is always mystrious, like a phantasm.

Which wouldn't be that bad if it wouldn't stall ZDoom's development as badly as it is doing right now.

[DoomRater]

(twiddles thumbs) Still waiting on notices for bug fixes, ideas, and whatnot.

[MartinHowe]

Am I to understand that Graf is supposed to be the "official" reader of this forum, or is it meant to be for Randy's use on the "real" ZDoom, or both?

Anyway, I have put my money where my mouth is and created a mod to 2.0.96 that has eight extra 32-bit int AActor fields called "user1" to "user8" (ok, so those are boring names, sue me already ). These fields are supported in DECORATE, over savegames and with GetActorProperty() and SetActorProperty().

This is only for discussion and testing; if Randy does eventually do something like this, he may not even use the same names; however, it should give us ideas.

The archive contains a diff to 2.0.96, and example WAD and DECORATE scripts and a compiled zdoom.exe file.

Have fun!

[Graf Zahl]

So thanks to Randy's silence ZDoom is turning more and more into a community project. I wonder whether Randy ever imagined that...

And since you already did it there's nothing that would keep me from adding this to the next unofficial build - with some enhancements. One thing I'd change is to turn the 8 variables into an array because then it would be easier to use them efficiently and create 2 new codepointers to use them directly in DECORATE.

[Graf Zahl]

Added.

This reminded me how old 2.0.96 already is...

[MartinHowe]

EDIT: That was quick, I was composing this message while you did that!!

I wonder whether Randy ever imagined that...

He'd better watch out or we'll be after his job

One thing I'd change is to turn the 8 variables into an array because then it would be easier to use them

Yeah, makes sense to me.

I don't know object-orientated programming/C++ very well; how easy is it to make the size of the array configurable but start at zero? E.g., something like this:

Code: Select all

//
// Get current size of AActor.UserData[] array.
// Works on activator if tid=0.
//
// Return size if success
// Return -1 if failure
//
int ACS_UserDataGetSize(int tid);

//
// Set current size of AActor.UserData[] array.
// Works on activator if tid=0.
// If new data is created, set it to zeros.
// 
// Return -2 if not truncated due to (arg 3==FALSE)
// Return -1 if failure for any other reason
// Return 0 if unchanged
// Return 1 if truncated
// Return 2 if extended
//
int ACS_UserDataSetSize(int tid, int size, bool allow_truncate);

// MemMove for AActor.UserData[] array.
// Works on activator if tid=0.
// Overlapping moves handled correctly.
//
// Return -2 if data would fall off the end.
// Return -1 if failure for any other reason.
// Return 0 if success
//
int ACS_UserDataMemMove(int tid, int oldindex, int newindex, int size);

//
// Locked increment of a word in AActor.UserData[] array.
// Works on activator if tid=0.
//
// Return -1 if failure (including if current value is 0x7FFFFFFF)
// Return new value if success
//
int ACS_UserDataIncLock(int tid, int index);

//
// Locked decrement of a word in AActor.UserData[] array.
// Works on activator if tid=0.
//
// Return -1 if failure (including if current value is zero)
// Return new value if success
//
int ACS_UserDataDecLock(int tid, int index);

Inside the engine it could be an (int[])* and realloc()-able, I guess; but some changes to ACC would be needed then as well.

create 2 new codepointers to use them directly in DECORATE.

How would they work? Prototypes please!