Owner-code for decorate

[FDARI]

Feature 1: Execute a code pointer with its owner as caller, overriding the current owner.
Applies to: Custom inventory objects and weapons, and any other object types capable of having their states executed by another actor.
Implementation: Put the keyword "OWNER" in the state definition, along with such keywords as "BRIGHT", modifying the state to always use the owner as caller.

Feature 2: Create a custom relation between the caller of a state and the owner of that state
Applies to: Custom inventory objects and weapons, and any other object types capable of having their states executed by another actor.
Applied to: Inventory-class with subclasses.

Implementation: A_OwnerCallerLink(int saveCallerTo, int saveOwnerTo = AAPTR_DEFAULT, int flags = PTROP_NOSAFEGUARDS);

saveCallerTo: Save caller (monster, player, thing) to a pointer in owner (target, master, tracer).
saveOwnerTo: Save owner (inventory) to a pointer in caller (target, master, tracer).
* AAPTR_DEFAULT: Do not save
* AAPTR_MASTER|AAPTR_TARGET|AAPTR_TRACER: Save as Master, Target or Tracer.
flags: I thought they were on the wiki, but it seems not to be true. (I first said: See [wiki]A_RearrangePointers[/wiki])
* Default: PTROP_NOSAFEGUARDS; it is unlikely that a use of this function will ever require that sort of protection.

This function has no effect if owner and caller are the same, and it is only defined for the inventory-class.
Using this function with the "owner" keyword has no effect ("owner" keyword forces caller to the same as "owner").

This function has effect when it is triggered by a CustomInventory state-chain or an active weapon.


Demo: The feature I wanted to demonstrate also requires at least the parameterless version of ClassID() from the String/Name features of http://forum.zdoom.org/viewtopic.php?f=34&t=31493

The demo replaces HealthBonuses with 3 pickups that have 3 effects. The pickups have generic names, and 3 distinct appearances, but it is not predetermined which pickup will have which effect. The first time a pickup is activated, its effect is resolved. The resolution applies only within the map scope, so when a new map is loaded, the effects are randomised again. ClassID() causes the system to be highly reliable and easily extended. Just make sure ACS defines at least as many effects as there are different decorate classes inheriting from "RandomEffectBase" or one of its subclasses.

Contents of decorateOwner.zip:
decorateOwner.zdoom.diff: Patch for the above features.
pkupfx.zdoom.diff: Patch for the demo to work.
pkupfx_dev.pk3: Demo.


Non-demonstrated benefits:

---

Using A_OwnerCallerLink you can establish a relation between inventory-object and creature/whatever that is usable by ACS. Normally I'd make the inventory-object store the caller, and not the other way around (you can do both).
Then you can call an ACS-script (specify the "owner" keyword if you need to start with owner; the link I suggested would require it) and access both actors in a single ACS-script, possibly working with user-variables in both actors.

Code: Select all

/* custom inventory pickup state */
TNT1 A 0 A_OwnerCallerLink(AAPTR_MASTER)
TNT1 A 0 ACS_ExecuteWithResult(ACSS_STUFF, AAPTR_MASTER)
stop

/* ACS code */
#define ACSS_STUFF 1
#define ACSS_SETUSERVAR 2
#define ACSS_GETUSERVAR 3

function int PtrGetUserVar(int ptr_selector, int varstring) // Helper function to make code neater elsewhere
{
    return ACS_ExecuteWithResult(ACSS_GETUSERVAR, ptr_selector, varstring);
}

function void PtrSetUserVar(int ptr_selector, int varstring, int value) // Helper function to make code neater elsewhere
{
    ACS_ExecuteWithResult(ACSS_SETUSERVAR, ptr_selector, varstring, value);
}

script ACSS_STUFF(int ptr_selector)
{
    int joint_info = GetUserVariable(0, "user_aboutme") + PtrGetUserVar(ptr_selector, "user_aboutthat");
    PtrSetUserVar(ptr_selector, "user_set_this_variable", FixedMul(FixedMul(joint_info, GetUserVariable(0, "user_factor")), PtrGetUserVar(ptr_selector, "user_factor")));
}

script ACSS_SETUSERVAR(int ptr_selector, int varstring, int val)
{
    if (SetActivator(0, ptr_selector)) SetUserVariable(0, varstring, val);
}

script ACSS_GETUSERVAR(int ptr_selector, int varstring)
{
    if (SetActivator(0, ptr_selector)) SetResultValue(GetUserVariable(0, varstring));
}

This submission is fully functional but I have not delved deeply into its destructive potential yet. Most of all I (or the devs) need to verify that performing custom operations on a state-owner during state-chains/weapon activity does not have ill effects. The first question: What happens if the state-owner is removed (Thing_Remove(0)) during execution? The second question: Could that be achieved before? (I think it may have been doable, but less available, and less general.)

Heh. I suddenly remembered: http://forum.zdoom.org/viewtopic.php?f= ... 0&p=523532&

[Major Cooke]

Godsend.

I'm going to try this out tomorrow.

I'm... quite hyped for it.

So... Technically, could we make, say for example, monsters that pick up custominventory items and give them automatically to the master? Or, perhaps, if the monster is damaged, the master takes an equal amount of damage as well or outright transfers it to the master?

[FDARI]

I can't fully parse your question. At least I don't trust the result. How does what you ask compare to what we can already do?

Code: Select all

actor AlreadySupported : CustomInventory
{
    states
    {
        pickup:
            // This simple definition actually fails to damage the actor who picks it up.
            TNT1 A 0 A_DamageMaster(random(2,5)) // damage caller's master
            TNT1 A 0 A_GiveInventory("AlreadySupported", 1, AAPTR_MASTER) // relay to caller's master - just never establish loop of masters, they'll kill eachother or hang/crash trying
            stop
    }
}

While it is not all that significant, you could do:

Code: Select all

actor NonRecursive : Custominventory
{

    var int user_damage;

    states
    {
        pickup:
            TNT1 A 0 OWNER A_SetUserVar("user_damage", random(2,5)); // set the OWNER's user_damage, persistent for all actors damaged on this pickup
            TNT1 A 0 A_OwnerCallerLink(AAPTR_MASTER) // owner (NonRecursive) stores the caller as a MASTER

            goto process+1 // Not required, but I feel like skipping the first A_JumpIfTargetInLOS with its foregone conclusion.

        process:
            TNT1 A 0 OWNER A_JumpIfTargetInLOS(1, JLOSF_CHECKMASTER | JLOSF_NOSIGHT) // jump if state-owner has a MASTER
            stop
            TNT1 A 0 OWNER A_DamageMaster(user_damage) // Damage the OWNER's MASTER using the OWNER's user_damage.
            // apologies already for the capital keywords...
            TNT1 A 0 OWNER A_TransferPointer(AAPTR_MASTER, AAPTR_DEFAULT, AAPTR_MASTER) // copy the owner's master's master to the owner's master.
            // The above in pseudo-code: owner.master = owner.master.master;
            loop
    }
}

You can store some data along the way without requirig the caller to possess a particular user-variable, and you can use the owner's data fields, so that you won't be compelled to abuse the caller's fields. Afterall, the caller might be using those fields, but the owner is under your control. You're writing its code. An advantage of doing this non-recursively is that the infinite-loop protection in CustomInventory will be more effective.

Slight word of warning: Damage functions called directly by the object (OWNER in pickup state) do not point to the default calling actor as source of damage, but to the owner. For maximum flexibility you will probably have to fetch the pointer and write ACS-library-scripts (ACS_ExecuteWithResult recommended for speedy resolution) that use this information to work with both actors. Demonstrated in OP.

[Major Cooke]

Edit: OOOH! Holy crap! I think I see the overall picture now! Let me get this straight...

This allows for custominventory objects to truly call things for themselves, and set code pointers for itself and set itself for other actors inside of their code pointers, right?

If so, then this will make code pointer transferring MUCH more fun! And, if I'm still on the right track, it'll let things like A_Explode have proper targets too, so we can finally not hurt the target.

As for the whole monster damage business:
http://forum.zdoom.org/viewtopic.php?f=15&t=31625

EDIT 2: Hmm, out of curiousity, would it be possible with this new function to create a "thorns" effect in which they return damage done to the monster's current target using a custominventory item?

This code, for example, if you have a monster spawn with this (give him like a million hit points and use the buddha cheat), it will affect both the enemy and the player. What I'm trying to do is get it to the point where it measures the health against the stored hit points in user_hp, but I'm doing something wrong here as it's constantly damaging myself and the enemy. Not to mention, I just want the target to basically call A_Explode while still being from the enemy, and to not hurt said enemy in the process.

In short, a Thorns-like effect which damages the last target to hit it. I wish to be able to do this without ACS entirely, too.

Here's my test code:

Code: Select all

Actor FluffyThorns
{
	var int user_fluffy;
	Projectile
	+SEEKERMISSILE
	+NOINTERACTION
	+DONTSPLASH
	States
	{
	Spawn:
		TNT1 A 0
		TNT1 A 0 A_SetUserVar("user_fluffy",ClassID(AAPTR_TARGET))
		TNT1 A 0 A_TransferPointer(AAPTR_TARGET,AAPTR_TARGET,AAPTR_TARGET,AAPTR_TRACER,4)
	Moving:
		TNT1 A 1 A_Warp(AAPTR_TARGET,0,0,32,0,WARPF_NOCHECKPOSITION)
		TNT1 A 0 A_GiveInventory("FluffyThornsEffect",1,AAPTR_TARGET)
		TNT1 A 0 A_JumpIfInventory("FluffyArenaMode",1,"End",AAPTR_TARGET)
		TNT1 A 0 A_JumpIf(ClassID(AAPTR_TARGET)==user_fluffy,"Moving")
	End:
		TNT1 A 0
		Stop
	}
}

Actor FluffyArenaMode : Inventory
{	Inventory.MaxAmount 1	}

Actor FluffyThornsEffect : CustomInventory
{
	var int user_hp;
	var int user_damage;
	//+INVENTORY.ALWAYSPICKUP
	+INVENTORY.AUTOACTIVATE
	+FORCERADIUSDMG
	+EXTREMEDEATH
	+FOILINVUL
	+DONTSPLASH
	+NODAMAGETHRUST
	DamageType "FluffyImmune"
	Inventory.ForbiddenTo "AEoDMarine"
	Inventory.MaxAmount 0
	States
	{
	Use:
		TNT1 A 0 owner A_SetUserVar("user_damage",user_hp-health)
		TNT1 A 0 A_JumpIf(user_hp==health||health<=0,"End")
		TNT1 A 0 owner A_SetUserVar("user_hp",health)
	Perform:
		TNT1 A 0 owner A_OwnerCallerLink(AAPTR_MASTER,AAPTR_TARGET)
		TNT1 A 0 A_JumpIf(user_damage==0,"End")
		TNT1 A 0 owner A_Explode(user_damage,32,0)
		Stop
	End:
		TNT1 A 0
		Stop
	}
}

[Xtyfe]

Anyone else think FDARI should have SVN access? he seems to be the only one actually doing any developing these days.

I mean all the code he has already posted is just sitting here waiting.

[Major Cooke]

Anyone else think FDARI should have SVN access? he seems to be the only one actually doing any developing these days.

I mean all the code he has already posted is just sitting here waiting.

QFT.

And if he has access to the SVN, he could make branches for others to try out as well.

[Edward-san]

Well, IIRC, as Graf said some time ago about Gez's similiar request suggestion from other people, if FDARI wants to access to the SVN, he should try asking Randy directly.

[Xaser]

He's definitely done enough to be granted full Developer status, I believe. I'd recommend asking Randy about it, FDARI. I'm sure he'll agree.

[Major Cooke]

Hell, he's gone above and beyond just enough, or the call of motivation (not duty) as I might put it.

[Graf Zahl]

Anyone else think FDARI should have SVN access? he seems to be the only one actually doing any developing these days.

Sorry, no, I disagree.

I like his enthusiasm but there's a good reason why I so rarely add his features. This one, like all the rest of the pointer copying just gives me headaches. What's the necessity for the new code pointer, for example? Why do we need yet another method to copy around pointers? I'm sorry but this is all just a crutch for the lack of real scripting.

This is all just one new feature heaped onto the last with no real underlying design goal.

[FDARI]

Nearly everything I have submitted has been at least very near WFDS. I feel that the existence of (at least the basic) actor pointer selectors (AAPTR_TARGET) and such is a viable generalisation of such a concept as A_GiveToTarget, because we would otherwise get a growing plethora of such specialised per-pointer duplicates of functions. A_Warp is also very suitable as a highly flexible and decorateable jump method.

The rest... ACS string manipulation (the first take was rejected, the accepted version was a direct response to Graf's technical). Pointer manipulation. And now owner reference. I would find use for these. If I ever complete a project, it will probably involve some of these, even if they're not in zdoom; I can do, and therefore I can barely contain myself.

Graf is more... sober. Occasionally I find him overly restrictive, but there is little I'd put into zdoom without verification from either him or randy even if I were able. Adding properties to players (not this submission) is slightly new to me, adding a new implicit cast for TObjPtr<T> (my suggested solution to maintain const-ness in the VisibilityFilter submission); these are things I find out how to do, but cannot fully verify. Graf occationally says "you cannot do it this way", or "you can not do that". When it is the former, I might find another way. When it is the latter I grumble a bit and put my fancy new thing aside.

I submit everything I do in the spirit of sharing, and in the faint hope that the official zdoom.exe will support my project, should it ever come any further. Oh, and sometimes I submit it because somebody around here really wants it and hopes that it can become part of the engine.

(By the time I get that far, Doomscript may be real though; I'm not sure my overall mapping speed exceeds randy's coding celerity.)

Bottom line: You think you want me among the devs, but you probably have me just where you need me.

One thing though: What's the necessity for the new code pointer?

In my kind of usage it is to have a direct relation between an implementation object (typically a weapon or custominventory) that should contain all its own special features without expecting or modifying anything in particular on the affected object (usually a player). The OWNER keyword only allows you to switch context to state owner, it doesn't allow you to combine information between the two. Storing the related actor in any pointer allows the flexible stable and reliable mechanisms already in place to provide the missing power to use data and implementations from one object on the other, especially through acs library script calls that are capable of changing activators.

Summary: I made it to allow me to keep the special objects generally applicable, with potentially no special requirements to the object they affect.

[Xtyfe]

Well, that was long winded

[FDARI]

I think your remark is even less necessary than mine. I have always been long-winded when communicating in human-language. Conversely, I am more succinct than most programmers I know when writing code. (Fewer intermediate assignments, minimal inclination to make an explicit (X != NULL) condition for an (X) condition, even though the optimiser probably knows how to handle it.)

I can be succinct though, once I've read my words and figured out what they mean: I'm very comfortable not having the final call on what goes into zdoom and exactly how the implementation should look, and I do hope Graf's headaches are relatively benign.

[Major Cooke]

I'm sorry but this is all just a crutch for the lack of real scripting.

Because no one knows the status of doomscript, and what it will be capable of doing. Only Randy really knows what it will be about because it's his baby. It was first announced back in 1999, was it not? So why not allow for alternative options in the mean time?

[Zippy]

Because no one knows the status of doomscript, and what it will be capable of doing. Only Randy really knows what it will be about because it's his baby. It was first announced back in 1999, was it not? So why not allow for alternative options in the mean time?

Because maintenance. Every change made has to be maintained into the future indefinitely. So careful consideration has to be made as to the value of having the feature around, particularly with regard to the complexity of the code to maintain, and especially so if it's known that new features will supersede it in the future. The basic reality is that it's not a thing you can keep adding stuff to without consequence.