ZDoom

As I am not aware of such an issue, I find it unlikely that I have done anything to deal with it.

Question with the code- I had reported a seeming range limit on the original JumpIfinTargetLOS when used on a player weapon. Past a certain point on MAP01 my Smart Rifle was not detecting shootable monsters, and I'm uncertain of the issue involved. Thus a secondary indicator was added (a laser beam) to aid in the detection of invisible monsters. Does this code address any of the issues I had there? I need to look for the thread where I posted about this.

I have discovered an important design issue that must be dealt with before I can go for A_CheckFlag / A_JumpIfFlag:

Sometimes flags become deprecated. There is a special function in the source code that assigns properties to simulate these flags. Some of the properties translate easily back to their flag counterparts (setting that flag would have caused X, so if X, consider the flag set). Also, flags currently deprecated could simply be restricted from the function. However, if one of the current flags is to become deprecated, a translation from its replacement to something backwards-compatible must be added to the code, in my function.

Maintaining backward compatibility for A_CheckFlag requires some planning.

I say go for it, but A_JumpIfFlag aught to potentially be in another thread. That's just me though. My recommendation is to make the new function first, see how well it holds out in the zdoom dev's eyes.

Good call.

The JLOSF_NOTEAMNOJUMP is a little clumsy, both in wording and function. All it does is cancel the jump if neither actor is FRIENDLY. I think its responsibility should be transfered to A_JumpIfFlag if that function exists.

The flag JLOSF_COMBATANTONLY is actually a relevant addition. Checking an actor's monsterflag won't be useful for a player, but JLOSF_COMBATANTONLY should treat players and monsters as combatants.

The following would verify that:
* The target is a combatant
* The target is not an ally to the caller
* Target and caller are not both non-friendly However, we then become dependent on A_JumpIfFlag being accepted and not WFDS'ed.

Still, it is my preference. I've got quite a few changes queued now. Should I just keep piling on?

NUMBER TWO. Definitely. That's something that would be a GOD-SEND.

However I would do A_JumpIfFlag instead though. That way it's not so confusing.

Possible solutions for filtering non-monsters:

1 - New flag: JLOSF_MONSTERONLY.
a) As a late addition to this code submission
b) As a subsequent code submission

2 - New action function in separate code submission: A_JumpIfSet(string FLAG, string|int STATE, int checkactor = AAPTR_DEFAULT)

3 - Making both JLOSF_TEAMNOJUMP and JLOSF_ALLYNOJUMP implicitly verify that the target is a monster.

The second idea has a ring of wfds to it, but is probably quite easy to implement, and covers the requested feature (in an extra line of decorate) and may be applied to other uses. If the second way is viable, I don't think I'll write the first one, but if the second is not viable, I too feel the need for a monster-check.

The third idea is somewhat logical, but quite inflexible.

I haven't checked what players have in their ISMONSTER-setting. The WIKI-decorate does not add the flag, and the engine usually doesn't care, when it already knows it is a player. With JLOSF_MONSTERONLY, the player-designation makes a difference.

If you want it to include players, perhaps it needs to be JLOSF_COMBATANTONLY (ugly word, but you get the gist).

Anyway, I can officially confirm this works!

Now if there's a suggestion that I would like to ask, can you add a flag such as JLOSF_MONSTERONLY? Simply put, this'll prevent acquiring targets on objects that dont have the +ISMONSTER flag.

Give me a moment to upload the spyknife... Just have to tweak it some.

c is a constant, though.

NeuralStunner wrote:(I may be oversimplifying the nature of the lightspeed constant, though.)

Light speed is not a constant, as you so aptly described it.

Anyway, I'm about to finish my ripping of the Spy's Butterfly knife so I can attempt backstabs in Doom. I'll let you know how it turns out...

Graf Zahl wrote:Either something is constant or variable but never both at the same time!

I had the same thought.

Though even the speed of light through vacuum can change depending on gravitational and electromagnetic forces. (I may be oversimplifying the nature of the lightspeed constant, though.)

Gez wrote:to change a "const" variable.

isn't that a contradiction in terms? Either something is constant or variable but never both at the same time!

There are currently no way other way than initialization to assign a value to a global variable. So, wait for Doomscript.

Even if there were, though, you wouldn't be able to change a "const" variable.

Also I was unaware we could do things like this:
Can these be modified at all by actors? Something like a global variable? Potentially checked as user variables by multiple actors and/or manipulated?