ZDoom

And now it's finally done...

Oooh man I really hope this makes it in!

Double posting: I have completed my testing and submitted the final version. First post updated with attachment.

There are some minor issues with A_CheckFlag for deprecated flags.

Inventory.* -flags: The function will never apply to them, because the calling context is never an inventory actor. (Not a problem)
FIRERESIST: ZDoom crashes with an access violation when I try to check this value. I'll probably be able to fix it.

All existing features, deprecated or not, are verified as compatible with previous versions (2.5.0).
All features with the exception of checking a few deprecated flags are working.

Since A_CheckFlag did not exist while the inventory-flags and fireresist were valid flags, it is not really necessary to add support for them. The same goes for all other currently deprecated flags. Support for deprecated flags is only required for flags that are are not deprecated as of the current version.

Still, it is more manageable if checking deprecated flags is a mirror/reverse of setting deprecated flags, so I'll try to fix it instead of removing it.

[edit]I wish I could help on the linux svn-app, but I really have no clue.
[edit]Found the issue with FIRERESIST (DamageFactor collection may be a null reference, needs a check.) Will upload fixed patch.

More news: the patch works iff I do 'dos2unix' to all the trunk files. This suggestion came from http://svn.haxx.se/tsvn/archive-2005-11/0440.shtml and it worked.
Also: http://svn.haxx.se/tsvn/archive-2005-11/0441.shtml .

[edit]At this point I ask: can you suggest me another patcher program for linux?

Patched just fine. Just make sure to watch out for the newer submissions such as the screen fading as of recent.

I can apply mine because I'm using windows, so it's just fine. And yeah I use Tortoise SVN as well. Let me give it a quick spin...

The current patch is generated with Tortoise SVN. Major Cooke, I'd like to know if you're able to apply it, and if you are, I'd like you to put it to some testing as quickly as possible.

Graf: I do believe the code is ready. I keep checking for bugs because I didn't do a good enough job in that regard on my first submission. You could apply it as is, and let any fixes go through the bugfixing system. Otherwise, I'll post again when my tests are complete.

EDIT: Uh... Must I resubmit for r3221?

I tried to patch my trunk directory with the diff in the zip file, but failed every hunk ... Ubuntu 10.10 x86-64...

[spoiler][code]
(Stripping trailing CRs from patch.)
patching file src/thingdef/thingdef.h
Hunk #1 FAILED at 26.
1 out of 1 hunk FAILED -- saving rejects to file src/thingdef/thingdef.h.rej
(Stripping trailing CRs from patch.)
patching file src/thingdef/thingdef_codeptr.cpp
Hunk #1 FAILED at 67.
Hunk #2 FAILED at 159.
Hunk #3 FAILED at 186.
Hunk #4 FAILED at 197.
Hunk #5 FAILED at 214.
Hunk #6 FAILED at 223.
Hunk #7 FAILED at 341.
Hunk #8 FAILED at 409.
Hunk #9 FAILED at 812.
Hunk #10 FAILED at 1669.
Hunk #11 FAILED at 1743.
Hunk #12 FAILED at 2917.
Hunk #13 FAILED at 2929.
Hunk #14 FAILED at 2952.
Hunk #15 FAILED at 3354.
15 out of 15 hunks FAILED -- saving rejects to file src/thingdef/thingdef_codeptr.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/thingdef/thingdef_properties.cpp
Hunk #1 FAILED at 159.
1 out of 1 hunk FAILED -- saving rejects to file src/thingdef/thingdef_properties.cpp.rej
(Stripping trailing CRs from patch.)
patching file wadsrc/static/actors/actor.txt
Hunk #1 FAILED at 197.
Hunk #2 FAILED at 219.
Hunk #3 FAILED at 238.
3 out of 3 hunks FAILED -- saving rejects to file wadsrc/static/actors/actor.txt.rej
(Stripping trailing CRs from patch.)
patching file wadsrc/static/actors/constants.txt
Hunk #1 FAILED at 70.
Hunk #2 FAILED at 212.
2 out of 2 hunks FAILED -- saving rejects to file wadsrc/static/actors/constants.txt.rej
(Stripping trailing CRs from patch.)
patching file zdoom.vcproj
Hunk #1 FAILED at 1090.
1 out of 1 hunk FAILED -- saving rejects to file zdoom.vcproj.rej
[/code][/spoiler]

@FDARI: Understandable.

@Graf: YES!!! :D

Add that feature as a separate submission. I want to get this thread out of the way ASAP.

If the features themselves are acceptable as it is, I'd like to "freeze" it at the current point, run some hard testing and say it is done.

There is one feature I'd be likely to submit later; or add to this submission. I've run it at a separate build with good results. That is the ACS function SetActivator with a second parameter (one of the AAPTR-values). It would work as follows:

SetActivator(int tid[, int selector])

if selector is not specified or default (0): the function behaves as before.
if a non-0 selector is specified: the selected pointer is used, relative to an actor matching the tid. TID 0 will represent the calling actor.

This would allow you to set any present player as the activator without regard to the current caller (static pointer), it would cover the SetActivatorToTarget functionality, SetActivatorToTracer|Master.

[u]What do you think Graf?[/u] Freeze it right now, or add that one feature?

@Major Cooke: The most recent change is primarily in how the code looks. The defines were becoming long and ugly (with backslashes at the end of each line), and were full of duplicate code. However, the new code also contains a formal order of pointer selectors: The more specific the required caller-type is, the higher priority the selector has. (Player, Actor, Anything|Null)

Ok, this has been hanging around for too long and from reading this thread I'm still not sure what the implementation state is. Are you still working on it or is this all complete and done?

Is this purely just for coding change sake or does this have some more affect on things like the commands that use the new pointers? (the categories anyway)

Check out zdoom_pack_r3218M.zip in original post.
Features all the things that were partially implemented in the previous posting.

Please test it viciously.

EDIT: Reuploaded now with improvements to actorptrselect.h. I removed some code duplication and got rid of the bulky #define macros.

Actor pointer selections now have a clearly defined order of priority:

There are three categories of pointer selectors: PLAYER, GENERAL and STATIC.

Whenever a PLAYER pointer is specified and applicable (the source actor is a player), the PLAYER pointer is used.
Otherwise, if a GENERAL pointer is specified and applicable (there is a source actor), the GENERAL pointer is used.
Otherwise, if a static pointer is specified (NULL, or one of the players), the PLAYER pointer is used.
Otherwise, the source actor is returned.

Any of the steps may return NULL. Containing a NULL value does not make a selector unapplicable.

Only one selector can be specified from each category. (use bitwise OR to combine selectors from different categories)

Selectors per category:

[b]Player[/b]
AAPTR_PLAYER_GETTARGET, AAPTR_AAPTR_PLAYER_GETCONVERSATION

[b]General[/b]
AAPTR_TARGET, AAPTR_MASTER, AAPTR_TRACER, AAPTR_FRIENDPLAYER

[b]Static[/b]
AAPTR_PLAYER# (numbers 1 through 8), AAPTR_NULL