ZDoom

Major Cooke wrote:

Graf Zahl wrote:The really annoying thing here is that much of the problems could have been avoided, had someone thought of it when DECORATE got its anonymous functions.

Okay, I just wanted to clarify... Is this a problem with calling A_SetUserVar itself, direct assignment or both? If it's just A_SetUserVar, then I wouldn't really have any problem changing it.

Graf Zahl wrote:The really annoying thing here is that much of the problems could have been avoided, had someone thought of it when DECORATE got its anonymous functions.

if (CheckClass("SpecialZombie"))
{
    myZombieVar = 2; //Assuming SpecialZombie has it already
}

Graf Zahl wrote:documented in a sane fashion

Graf Zahl wrote: About swapping the pointers, the problem is not the anonymous or even named functions, for those I fully agree that it can be done like that and if that was all there is I'd have done it like that.

Where I see problems is with direct function invocation on a state, which would basically be broken beyond repair as a feature. How should:

Code: Select all

class w : weapon
{
    states
    {
    ready:
        A_WeaponReady;
        loop
    }
}

be handled then, especially if this is trying to reference member variables? Should this just imply 'caller.' and if so, from what context should it resolve expressions?
And of course there's still the fact that DECORATE works the other way around so the entire code generation process has to be aware of this to avoid further problems.

Graf Zahl wrote:Drawback: Syntax of weapon action functions will be completely messed up, not intuitive for modders

Spoiler:

---

From this

Code: Select all

Class NewPistol : Pistol
{
	int testing;
	States
	{
		Select:
			TNT1 A 0
			{
				invoker.testing = 9;
			}
			Goto Super::Select;
		Fire:
			TNT1 A 0
			{
				A_ChangeVelocity(0, 0, invoker.testing); 
			}
			Goto Super::Fire;
	}
}

To this

Code: Select all

Class NewPistol : Pistol
{
	int testing;
	States
	{
		Select:
			TNT1 A 0
			{
				testing = 9;
			}
			Goto Super::Select;
		Fire:
			TNT1 A 0
			{
				caller.A_ChangeVelocity(0, 0, testing); 
			}
			Goto Super::Fire;
	}
}

Class NewPistol : Pistol
{
	int testing;
	States
	{
		Select:
			TNT1 A 0
			{
				invoker.testing = 9;
			}
			Goto Super::Select;
		Fire:
			TNT1 A 0
			{
				A_ChangeVelocity(0, 0, invoker.GetMyTest());
				A_LogInt(invoker.GetMyTest());
				A_LogInt(GetMyTest()); // This is broken by the way
			}
			Goto Super::Fire;
	}
	int GetMyTest() // non-action
	{
		return testing; // not invoker.testing???
	}
}

Graf Zahl wrote:Which may be necessary anyway if HUD overlays from arbitrary actors become a thing.

Graf Zahl wrote:Is it possible that if actor A defines some states, it can inject them into actor B's overlays

Graf Zahl wrote:Of course that will again open up the old problem of having to add a runtime check for DECORATE based states in StateProvider-derived classes because then the incorrect use cannot be detected at compile time.

Graf Zahl wrote:If all else fails I go back to the beginning and implement different state blocks in ZScript for actors, weapons and items and you'll have to adjust all ZScript code that has already been written. Which may be necessary anyway if HUD overlays from arbitrary actors become a thing.