ZDoom

It is called 'extension', not 'modification'. I think that says it all.

Is it safe to assume that that same restrictions will apply, i.e. you cannot perform an override on the actor functions in the base class when extending it? Just making sure, I figured it would be.

Yes, that would work.

@Graf: Ah well. Thanks to CheckReplacement in event handlers, it somewhat makes state label overrides a novelty idea at any rate that's entirely unneeded.

@Matt: Yep, pretty much. Also variables.

extend class Actor{
	virtual void A_CustomChase(vector3 goalpos,statelabel meleestate,...
		...
}
class CustomZed:Zombieman replaces Zombieman{
	...
	see:
		POSS ABCD 5 A_CustomChase(...
}

So basically something like this would work?
[code]extend class Actor{
virtual void A_CustomChase(vector3 goalpos,statelabel meleestate,...
...
}
class CustomZed:Zombieman replaces Zombieman{
...
see:
POSS ABCD 5 A_CustomChase(...
}[/code]

No. There can only be one defaults block. This isn't for altering actors but for injecting common code and related data into the base class.
Like, you want some special death state that requires common data and functions. You can now place that stuff in Actor and then inherit from the single monsters and add the new state using that common stuff.

But things like, say, giving cacodemons blue blood without replacing them will be possible? Or changing the maxamount property of an ammo type?

State label overrides won't be possible. That'd be too volatile.

extends class Zombieman
{
States.MyAddonIdentifierHere
{
Spawn:

This sounds like it's eventually paving the way towards being able to inject/override states without needing to replace the actor. Removing the need to replace one actor with another just so it doesn't have to be given some little tweaks would be a godsend.

For example, if an addon modifies a state, it could TRULY replace it -- possibly even affecting the goto -- via some definition like:
[code]extends class Zombieman
{
States.MyAddonIdentifierHere
{
Spawn:[/code]

...which would be in the addon code, replacing the spawn state without replacing the actor. But the actor themselves could still use something like [b]Goto <ClassName>::Spawn[/b] or something to make it use the original.

But then again I am effectively deluding myself into thinking its even possible. [size=85]Feel free to correct me if I'm not deluding though![/size]

[i]heavy breathing[/i]

It means that 'extends' blocks to all actor classes can be done in user code. The reason why this wasn't possible yet is that all the native children would have broken if a base class was extended.

For non-actors this isn't really important because there's little to be gained by extending them.

How will this work when done?

[i]excited incoherent screaming[/i]

Graf you're the best. This'll be a game-changer.

8-)

I'm working on it. I'm almost done exporting PlayerPawn which is the last remaining blocker for allowing user-side extends of class Actor.

[quote="Caligari87"]One potential workaround is to use a static function in a separate thinker/class as a proxy. Matt does this in Hideous Destructor, for example. [code]class NewZombieMan : ZombieMan replaces ZombieMan {
States {
See:
POSS AABBCCDD 4 MyFunctions.EnhancedChase(self);
Loop;
}
}

class MyFunctions {
static void EnhancedChase(actor caller) {
//do fancy movement
caller.vel.x += 15;
}
}[/code]
8-)[/quote]
I'm aware of this method and it's definitely the best one available at the time. But having to prefix with `caller` so often leads to rather clunky syntax.