Reflective Flags

[Nightfall]

(to be clear, I'm not saying they should be removed since, at this point, it's far too late.)

Technically that is untrue because these functions haven't been included in an actual ZDoom release.

[Graf Zahl]

To give examples:

It is more important that:
Functions such as A_DamageTarget, A_DamageTracer, A_DamageSelf are reasonable stable and bug free.
(to be clear, I'm not saying they should be removed since, at this point, it's far too late.)

Rather than:
Seriously considering if the aforementioned functions are in fact redundant/code-bloat and are therefore unnecessary since a generic A_Damage function would be a much better candidate. After all, maintaining one is easier than maintaining three.
(A_DamageMaster in an exception because it's been around for a long time and must be maintained for backwards compatibility.)

I'm just trying (and apparently failing) to understand the policy about what sort of suggested features and/or code submissions are acceptable to implement.

Please stop this as it clearly shows that you do not know what you are talking about. Have a look at the code first!
I think it's perfectly fine to have different but descriptive names that internally map to THE SAME function.

[Fishytza]

Having just one A_Damage function wouldn't really reduce actual code bloat.

Perhaps it's a matter of opinion, but even if we ignored A_DamageMaster (because backwards compatibility), having three very identical functions is a bit too much if you ask me. Of course there's the DoDamage subfunction, but still... Wouldn't something like this be more preferable? It would certainly render *Self, *Target, *Tracer (and obviously *Master) deprecated.

---

Code: Select all

DEFINE_ACTION_FUNCTION_PARAMS(AActor, A_Damage)
{
	ACTION_PARAM_START(4);
	ACTION_PARAM_INT(ptr_victim, 0);
	ACTION_PARAM_INT(amount, 1);
	ACTION_PARAM_NAME(DamageType, 2);
	ACTION_PARAM_INT(flags, 3);

	AActor *victim;
	COPY_AAPTR_NOT_NULL(self, victim, ptr_victim);
	DoDamage(victim, self, amount, DamageType, flags);
}

Technically that is untrue because these functions haven't been included in an actual ZDoom release.

Hah! Go tell that to Major Cooke or the other devs. It's far too late because there's probably some modders who readily make use of these action functions. And I bet said modders would be confused if not out right pissed if their mods were suddenly broken in the next official release.

EDIT: Just read Graf's post.

Calm down. If you want me to go away, I'll go away.

[Major Cooke]

Fishy, these have been in for several weeks if not a month or two now. The MOMENT they are added, at that very nanosecond, they're in for good, until the foreseeable future when this rule changes or when Graf/Randy say.

And now for something completely different!

That said, I think that some cleanup will be in order after this gets added. There's too many reflection-specific things spread out through the main flags now, they better get consolidated into their own ReflectionFlags field, just like it was done for bouncing flags.

I could work on that. Not entirely sure though how best to handle it... I can try though. Is there anything in particular you wish for me to do?

I will say my method for working on THRUREFLECT was... a little weird. The problem with THRUREFLECT in particular is, I just discovered if two actors have THRUREFLECT, passing through both, it'll stop the projectile until one of them is no longer colliding (doesn't stop z movement). I for the life of me cannot find out what the hell is doing this... And, I had to add a piece of the code in p_map because, otherwise, the projectile would "step up/down" based on its current z velocity, making it behave weirdly when "reflected". Any ideas for a still particularly novice coder still trying to sink a bit further into the code?

[Graf Zahl]

Fishy, these have been in for several weeks if not a month or two now. The MOMENT they are added, at that very nanosecond, they're in for good, until the foreseeable future when this rule changes or when Graf/Randy say.

Not really. The normal rule - if ZDoom had anything like a sensible release schedule - would be that everything not in an official release is subject to change without notice.
But since Randy doesn't seem to think that an actual release schedule is needed I have to treat the latest dev build as the last official release.

Besides that, I have done one breaking change to DECORATE but that was done because it was the only way to resolve a conflict that would have haunted DECORATE till the end of days otherwise. (That was when I replaced '.' with '::' as class scope resolution operator for state names, because '.' collided with the sublabel separator and could result in ambiguous state names or feature limitations.)

[Major Cooke]

Split the pull request. Now the reflective flags are by themselves, as I feel it's a bit easier to get the other set of flags accepted if they're by themselves.

I moved the HITTARGET/MASTER/TRACER flag discussion to here.