Reflective Flags

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Reflective Flags

Re: Reflective Flags

by Major Cooke » Tue Dec 09, 2014 12:36 pm

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.

Re: Reflective and Impact Pointer Flags

by Graf Zahl » Fri Dec 05, 2014 2:25 am

Major Cooke wrote: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.)

Re: Reflective and Impact Pointer Flags

by Major Cooke » Thu Dec 04, 2014 5:57 pm

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!
Graf Zahl wrote: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?

Re: Reflective and Impact Pointer Flags

by Fishytza » Thu Dec 04, 2014 3:53 pm

Gez wrote: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.
Spoiler:
Nightfall wrote: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. :P 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.

Re: Reflective and Impact Pointer Flags

by Graf Zahl » Thu Dec 04, 2014 3:47 pm

FishyClockwork wrote: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.

Re: Reflective and Impact Pointer Flags

by Nightfall » Thu Dec 04, 2014 3:07 pm

FishyClockwork wrote:(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.

Re: Reflective and Impact Pointer Flags

by Gez » Thu Dec 04, 2014 3:03 pm

Yeah I'm not sure either why there are all these variants, but it's not really code redundancy. Behind the hood, they're all the same function.
Spoiler:
See? Only _Siblings and _Children actually have some logic on their own, so as to iterate over the multiple valid targets. Having just one A_Damage function wouldn't really reduce actual code bloat.

Re: Reflective and Impact Pointer Flags

by Fishytza » Thu Dec 04, 2014 2:58 pm

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.

Re: Reflective and Impact Pointer Flags

by Gez » Thu Dec 04, 2014 1:44 pm

Redundancy is mostly incompatible with minimum maintenance. When you have redundant code, it means you have to change two parts of code (or more, depending on level of redundancy) instead of just one when there is some maintenance to do there.

Stability, functionality, and minimum maintenance seem to be good priorities. Don't forget that one man's bloat is another man's dream feature, and vice-versa.

Re: Reflective and Impact Pointer Flags

by Fishytza » Thu Dec 04, 2014 1:39 pm

So to clarify.

Stability, functionality, and minimum maintenance are far more important to you than preventing redundancy and bloating the code?

Re: Reflective and Impact Pointer Flags

by Graf Zahl » Thu Dec 04, 2014 7:15 am

You clearly misunderstand our motivations completely. Code submissions can and will be rejected if they are considered harmful to future stability or require constant maintenance in the future. What Major Cooke is doing here is far from both.

Re: Reflective and Impact Pointer Flags

by Fishytza » Thu Dec 04, 2014 6:15 am

Graf Zahl wrote:What's amusing?
Well, I always thought that one had to argue with the devs (or other 'influential users' who the devs respect) about whether a feature gets to be implemented in the first place. Even if the feature suggester was the one coding-in the feature.

(I remember something about being careful about what feature goes in, making sure it's not redundant and unnecessary because "it could be done much better with scripting", i.e. DoomScript/ZScript.)

But I guess I was totally wrong about that.

A bit tired at this point, but I think I'll say it anyway.
@Major Cooke
Maybe I'm wrong about this but you claim that all the new 'reflective' flags require REFLECTIVE to work.
However, i've noticed that apparently REFLECTIVE isn't needed for THRUREFLECT?
Spoiler: code
It seems to me that missiles will pass through and change their target even if the actor that is being past through lacks REFLECTIVE.
Again, kinda tired. Might have missed something. Apologies in advance.

Re: Reflective and Impact Pointer Flags

by Graf Zahl » Thu Dec 04, 2014 4:53 am

What's amusing? If someone who NEEDS the niche feature and goes out spending his own time implementing and testing it is a whole lot different than having a dev spend their time on it - someone who doesn't have a major interest in this feature.

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.

Re: Reflective and Impact Pointer Flags

by Fishytza » Thu Dec 04, 2014 4:39 am

Gez wrote:Writing the code goes a long way towards making unneeded, niche-specific suggestions get accepted after all.
Apparently. This is why I find it amusing.

Re: Reflective and Impact Pointer Flags

by Gez » Thu Dec 04, 2014 2:13 am

The difference is that what Graf was talking about was a suggestion to make all projectiles unconditionally store the actor they hit in a pointer. This is not the case here, because it's conditional, depending on having one of these flags. It will have no gameplay effects on any existing projectile. What Graf was saying was that unconditional storing would have to be in a new pointer made specifically for that, precisely so as to have no gameplay effect on any existing projectile.

The "write access from DECORATE" thing was that this new pointer would be put outside the reach of functions such as [wiki]A_RearrangePointers[/wiki].
FishyClockwork wrote:I'm not complaining, just a little amused that some things the devs rejected for various reasons such as "Not Needed, Too specific/niche, supports modder laziness" etc, you've managed to implement without much objection.
Writing the code goes a long way towards making unneeded, niche-specific suggestions get accepted after all.

Top