Grouped action specials in DECORATE

[Nash]

I can see the benefits of using #### as Gez proposed. I would Search & Replace that out in all of my mods in a heartbeat if GZDoom Builder supported it like SLADE does... but it's not really a high priority for me at this moment and I can live with it not being implemented in GZDB.

[Fishytza]

Seeing that is possibly gonna happen makes me excited as hell. I can't help but wonder, is the syntax going to be something like this?

Code: Select all

CustomAF A_RebelChase
{
	if( CheckClass("SpectralMonster", AAPTR_TARGET, true) )
	{
		A_ChangeFlag("FRIGHTENED", 1);

		if( random(1,100) <= 10 )
			A_PlaySound("rebel/runforyourlives", CHAN_VOICE);

		A_Chase("", "", CHF_NOPLAYACTIVE);
	}
	else
	{
		A_ChangeFlag("FRIGHTENED", 0);
		A_Chase;
	}
}

Actor NewRebel : Rebel
{
	States
	{
	See:
		HMN1 AABBCCDD 3 A_RebelChase
		Loop
	}
}

[Major Cooke]

That actually looks like something I'd expect too, Fishy.

[Graf Zahl]

You won't get a 'CustomAF', of course, but the long term plan is to be able to add custom code to actors - not just action functions, but also extensions to internal methods.

[Fishytza]

...but also extensions to internal methods.

Could you please elaborate what you mean by 'internal methods'? Does this include being able to, say, decide if an actor should or should not change its target to what's attacking it right now based on certain criteria (what class is the attacker, is it a player, etc) IE kind of like how OkayToSwitchTarget works?

Or am I getting my hopes up for no good reason?

[Snarboo]

You won't get a 'CustomAF', of course, but the long term plan is to be able to add custom code to actors - not just action functions, but also extensions to internal methods.

Does that mean custom functions created for an actor cannot be reused by another without inheritance, or am I reading this wrong?

[MaxED]

I can see the benefits of using #### as Gez proposed. I would Search & Replace that out in all of my mods in a heartbeat if GZDoom Builder supported it like SLADE does...

Will that do, or am I missing something?

Code: Select all

public static bool IsIgnoredSpriteName(string name) 
{
    return (name.StartsWith("TNT1A") || name.StartsWith("NULL") || name.StartsWith("----") || name.Contains("#"));
}

(current implementation only skips a sprite when it's name starts with "TNT1A0").

[Nash]

I guess that'll do? But I don't know too much about programming and what other implications or side effects this may cause... will only be able to find out when I actually run the program. :D

[MaxED]

By "am I missing something?" I meant "are there some other 'special' sprite names, which should be ignored?"

[NeuralStunner]

Will that do, or am I missing something?

With TNT1, the frame letter doesn't matter to the engine. Any frame (A-Z, [, \, ]) works the same, it's TNT1 that does the magic.

Also, NULL has no special meaning to the engine and shouldn't be ignored. Bad practices are not to be encouraged.

[MaxED]

This way then? (some refactoring was applied)

Code: Select all

// Ignore some odd ZDoom things
if (!spritename.StartsWith("TNT1") && !spritename.StartsWith("----") && !spritename.Contains("#")) 
{
    sprites.Add(spritename);
}
 

[NeuralStunner]

Looks good to me.

[MaxED]

OK, fixed in r2163.

[randi]

I wonder if that DDF converter that was promised will make it in?

What DDF converter?

[Snarboo]

From the [wiki=DoomScript]DoomScript[/wiki] article:

A DDF->DoomScript converter will be available so that people can both see how something done in DDF relates to something done in DoomScript, and also so that DDF mods will work with ZDoom. A DeHackEd->DoomScript converter might also be made, although doing anything with DeHackEd outside the original doom.exe is very problematic, and it might not be realistically possible to convert it to DoomScript with an automatic tool.