ZDoom

To check if somebody is on your team, use JLOSF_ALLYNOJUMP.
Previously you could also check if neither actor was without friends by adding JLOSF_NOTEAMNOJUMP.

What that check actually did is duplicated by
A_CheckFlag("FRIENDLY", "IHaveATeam")
A_CheckFlag("FRIENDLY", "IHaveATeam", AAPTR_TARGET|AAPTR_PLAYER_GETTARGET)

Checking that either actor is friendly. There may be a more detailed team-check possible, to find out if a friendly monster has not been assigned to a team, but that has not actually existed in any code I have written, and so it is for the better that NOTEAMNOJUMP does not exist. Perhaps when I learn even more of this engine, I can add that feature, or determine that it is not required at all.

I'd say an entirely new thread. Ask for the mods to delete the old ones and start fresh new. Anyway I'm downloading this now and going to implement it on my end.

About teams, I would suggest leaving that in. Due to the fact that there's the DesignatedTeam property, this can radically change things around, so say if you want three factions fighting one another then this would be used to say... heal fellows around them by chance.

If you're not familiar with C++ concepts, I think it might be a little hard to grasp. I think it was my lack of experience at work.

I defined a macro "#define niftyword(param, param2, param3)" and used it almost, but not quite, like a function. What I forgot was that if I use the same symbol for param and param2, they will be [i]exactly[/i] the same, rather than two copies of the same value, or two pointers to the same location. Thus, when I assigned NULL to param2 and then tried to read data contained in the first parameter (param), the first parameter was NULL and could not be used; zdoom.exe crash.

Fixed.

By the way, I have a complete build of all my modifications ready. It only differs from existing suggestions in some A_JumpIfTargetInLOS details:
* JLOSF_NOTEAMNOJUMP is removed. All monsters on teams have FRIENDLY, so you can use A_CheckFlag for that.
* JLOSF_COMBATANTONLY is added. Using this will prevent jump for actors that aren't either players or monsters (ISMONSTER).

I'd post it, but by this time I'm not sure where. It encompasses all 3 suggestions I have made, contains an improvement that depends on all 3 submissions being accepted (excluding NOTEAMNOJUMP) and has a Strife weapons mod for demonstration and entertainment. Only two weapons properly use the new features, though.

Punch dagger
Fire: Regular attack
Altfire: Slow double damage attack. If you manage to stay on a bleeding monster that doesn't catch you in its field of view, you deal 5x damage.
(Damage increase is achieved through multiple 0-tic calls to A_JabDagger)

Missile launcher
Fire: Regular attack
Altfire: Try to find a target within field of view or perfect aim and make adjust course for it after a few tics. Semi-seeking missile. Cool, and not always better than a straight shot, but often much easier to get your target. Reduces the impact of low accuracy early in game.

I'll post the lot here for now, just to let people have a look and feel at it.[spoiler=Weapons overview]Punch dagger and missile launcher are roughly as described above. Many projectiles have increased speed, making them easier to aim and slightly more deadly. Grenades also gain increased range from this speed increase, since gravity tends to bring them down.

Crossbows: Altfire readies the bow for a precise shot; repeat altfire to perform the precise shot. Precision gain only applies at low/very low speeds. Crossbow state is not maintained when moving between maps or changing weapons; if it was ready, it must be readied again.

Assault gun: Altfire fires at reduced rate with full accuracy. Has proven excellent for taking out targets from cover because you can track your puffs shot by shot until you find your target.

Grenade launcher: No longer fires double shots automatically. Alternates barrels as long as you hold fire. Main fire starts with right barrel, altfire starts with left barrel.

Flamethrower: No changes (well, I might have meddled with the flame translucency, but I don't think I achieved much. They still seem damned solid, so those changes might not be worth anything).

Mauler: Reduced ammo consumption for the shitty shot. Added primary weapon altfire that vaguely resembles the assault gun in its performance, although it is not affected by accuracy. Sister weapon recoloured to make the visual distinction more obvious. Added sister weapon altfire that executes very low damage hitscans in rapid succession with perfect aim.

Game balance: This mod makes the game very easy. It needs a counterpart in the monster department.[/spoiler]

EDIT: Files removed. [b]Preferred patch: http://forum.zdoom.org/viewtopic.php?f=34&t=29364[/b]

Oh. Uh, what was the bug?

Patch in first post is updated with fix.

There is a bug in this code presently. (Yes, another one.)
For once, I found it during my own testing. I'll get you a fixed patch shortly.

It appears to be working now. Thanks mate!

I don't like A_JumpIfFlag as much as A_CheckFlag, because "check" is straight to the point and says to me, "Is this flag on them? If so, jump."

The check would simply invert the value it checks for, nothing else. The jump should always fail if another actor is referenced that does not exist, as there's no way to check the flag at all.

The idea was for simplicity of use and more similarity to A_ChangeFlag. (A_JumpIfInventory also lets you check certain values, it just happens that flags only have 2. :P ) If it would only add messy complexity to the code, it's not a big deal to have.

I see you made sure it can accept a state offset instead of a label, as well.

For the record, I like the name "A_JumpIfFlag" better. It more clearly conveys the usage of the function. (Though one could argue that "A_CheckFlag" is grammatically nicer. :P )

Most decorate jumps have jump as either true or false, and not jump as the other, and offer no other way of distinction. If adding a boolean to invert the jump condition is a popular idea, I can do it, but it is neither necessary nor precedented. I'm quite used to weaving a path of jumps and non-jumps to reach a state that is only attainable under a specific set of circumstances.

Inverting the jump condition would be roughly the same as inverting the jump condition for A_JumpIfTargetInLOS ("not" in LOS). The change is easier for A_ChangeFlag, because there are fewer branches in the code, but logically it is similar. The two functions also share the same problem with that particular idea: What if the actor you're checking against does not exist? Both functions can check your target, tracer or master. No jump is executed if the chosen actor does not exist. Should this also be inverted? (A_CheckFlag can also check against "self", the default actor which always exists, no issues there.)

Thoughts?

Nice! I hope it works. :P

Though I think this should have a boolean parameter to check against, so you can also code a jump if a particular flag is off.

I don't think it needs to be dead center. Even if it does, I found the bug. I missed a spot when converting duplicated code from A_ChangeFlag. New diff uploaded; should be fine now.

Okay. So even if aiming at the target, you have to be aiming directly at the center of their radius and height?

Also, here's my current changes in case if you can't reproduce it: http://www.sendspace.com/file/chrfuh

What I'm most interested in at this point, is your decorate; any code relevant to this weapon. I'll test that code in my build and see if it does what it's supposed to, and examine the minutiae if there is something odd.

One thing to be aware of: A player only has a (line)target if it is looking directly at one. This is so certain a fact that standard A_JumpIfTargetInLOS skips fov-checks when called by players. (However, my reverse fov/los versions check fov when testing the other actor.) It means your aim must be nearly perfect for A_CheckFlag to get a valid linetarget.

I'll run your decorate on my build, that's what's next.

Tried it that way too, didn't work. And yeah it's a weapon.

If you want me to, I can upload a diff file showing everything combined into one.

What actor is calling A_CheckFlag? If that is a weapon/player, use AAPTR_TARGET|AAPTR_PLAYER_GETTARGET; I believe I added that to the latest patch. Not having the indicated type of target will give the same result as a flag not being set, and players normally don't have a stored target.

A patch containing absolutely everything I have done so far will also include the adjustments I'd make if I knew that all my submissions would be accepted. JLOSF_NOMONSTERNOJUMP will not be part of it, but JLOSF_COMBATANTONLY will be. Feel free to improve naming ideas. JLOSF_COMBATANTONLY will check that the target is either a monster or a player.

I hope I'm not giving anybody a headache.