3 merged submissions (details in post)

[Major Cooke]

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)

[Graf Zahl]

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?

[FDARI]

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.

What do you think Graf? 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)

[Graf Zahl]

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

[Major Cooke]

@FDARI: Understandable.

@Graf: YES!!!

[Edward-san]

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

---

Code: Select all

(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

[FDARI]

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?

[Major Cooke]

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...

[Major Cooke]

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

[Edward-san]

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?

[FDARI]

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.

[FDARI]

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

[Major Cooke]

Oooh man I really hope this makes it in!

[Graf Zahl]

And now it's finally done...