[Mauzen]

Continuing this: http://forum.sa-mp.com/showthread.ph...78#post3095178 especially the very last edit-paragraph, I did some further investigation. After all it turned out that the problem seems to come from a abnormal rec file, but I cant find any reason why this happens:

pawn Code:

forward RMove();
public RMove() {
    RNPC_CreateBuild(npcid, PLAYER_RECORDING_TYPE_ONFOOT);
    RNPC_AddMovement(0.0, 0.0, 0.0, 100.0, 100.0, 100.0, RNPC_SPEED_RUN, 1);
    RNPC_FinishBuild(1);
    RNPC_StartBuildPlayback(0);
}

// This one works, checksum is always the same
RMove();

// This one creates a different, not working rec file
// Checksum of that recfile changes every server start
// NPC reports to have started the playback, but does nothing then
SetTimer("RMove", 500, 0);

I used a just slightly modified grandlarc gamemode and RNPC 0.3.4 on Windows. No other includes or plugins, except crashdetect, but effects are the same without that. All used RNPC_* functions are natives. RNPC_CreateBuild invokes GetPlayerFacingAngle and GetPlayerPos to get the starting position, but it isnt used later on in this case. NPC position is the same for both calls anyways. Apart from the invokes the plugin does not access the server in any way, and does not use memory hacking.

Those functions should always do the same, there is no random factor in the generation, and checksums prove that as mentioned above.
Still, calling it in a timer gives a different result, and after hours of testing Ive come to the conclusion that I probably cant find the cause without deeper knowledge of samp/the timer procedure.
I could take a closer look at what the differences between the generated files are, but that would take a while and I need a break. If theres no pawn explanation for this Id do it however.

If needed I can upload the complete server I used for testing this.

Edit: I just had a look at the rec files. The only difference seems to be that the not working version got a z velocity of something around 0x30A19854. Throughout the file its the same, it might differ between different files, but its always about that number. Thats 1.1739716E-9 / 5.2443145E12 depending on endianess. RNPC doesnt use z velocity at all for onfoot recordings, but it also isnt reset to 0 explicitly, but keeps the previous value. I doubt the timer leaks into RNPC memory and changes that value somehow, but still I dont see a logical explanation for this.

Edit2: Okay resetting the velocity in the plugin properly seems to fix this. I guess I forgot how important proper variable initialisation is in c++ at that point, probably the velocity variable just had the same memory address than some relics of the SetTimer call. That might also be the reason for the hooking bug in the linked post.
Anyways, would be nice if someone with better knowledge could confirm/disprove my theory. If it is correct this was purely my own fault and this thread is obsolete.