|#define BG_CANITEMBEGRABED 0x538F0|
|#define PMOVE 0x57EC0|
|#define CLIENTTHINK_REAL 0x59DF0|
|#define CA_ROUNDSTATETRANSITION 0x5FB00|
|#define CMD_CALLVOTE_F 0x6B160|
|#define TOSSCLIENTITEMS 0x6FC00|
|#define PLAYER_DIE 0x70310|
|#define G_DAMAGE 0x72010|
|#define TOUCH_ITEM 0x787C0|
|#define LAUNCHITEM 0x79AE0|
|#define DROP_ITEM 0x79D10|
|#define TELEPORTPLAYER 0x84EF0|
|#define G_EXPLODEMISSILE 0x859E0|
|#define G_RUNMISSILE 0x86350|
|// #define G_MISSILEIMPACT 0x86350|
|#define FIRE_ROCKET 0x87650|
|#define PICKUP_TEAM 0x96970|
|#define G_USETARGETS 0x97B50|
|#define G_SPAWN 0x97DB0|
|#define G_TEMPENTITY 0x980A0|
|#define KAMIKAZEDAMAGE 0x98C20|
|#define G_STARTKAMIKAZE 0x9BA30|
Maybe "0x86350" is not the address of G_MissileImpact but the address of G_RunMissile.
1. The address of "0x86350" is called when I shoot a missile.
I added the following code into hook.c to check the condition where "0x86350" is called.
Then, I shot a missile and then got the message specified in Com_Printf every frame.
2. "0x86350" is called from G_RunFrame.
This is a part of the code of G_RunFrame (from wolfcamql12.2).
and these are two parts of the assembly code partly corresponding to the right-above code.
You can see a repeat of "cmp" and "jz" instructions in the first assembly code. I think this is the repetation of conditional jump, so it corresponds to the part of G_RunFrame code. Also, "3" in the forth line corresponds to ET_MISSILE.
If "ent->s.eType" is 3(ET_MISSILE), it will jump to "loc_83B4A" in the second assembly code. In this assembly code, you can see "sub_86350" and it corresponds to the address I hooked the "My_G_MissileImpact" function to.
Btw, thank you for replying my question about hooking in minqlx's issue :) maybe I will comment your reply later.
Furthermore, I think the code of G_MissileImpact is included in G_RunMissile.
This is a part of the code in G_MissileImpact (from wolfcamql12.2)
This is a part of the assembly code in "0x86350"(G_RunMissile)
There is "EV_GRENADE_BOUNCE" in G_AddEvent's arguments and this corresponds to "29h" in the assembly code ("mov esi, 29h"in the sixth line) Also, "sub_982F0" is the address of G_AddEvent. ("call sub_982F0" in the eighth line)
I think it is still lack of reasons, but there is a possibility that G_MissileImpact is included in G_RunMissile.
I think you are right.
I have an idea how to hook something inside the function: make CALL opcode (current Hooks are using JMP opcodes). But:
Thank you for suggesting the idea! I still don't have enough experience to modify assembly codes, so I made a roundabout code in a hook on G_MissileImpact. Come to think of it, G_RunMissile triggers G_MissileImpact only when a projectile collides with something, so I made lines of a code doing collision detection with BG_EvaluateTrajectory and SV_Trace, like G_RunMissile does. It may be technically not a hook since It just detects whether G_MissileImpact triggers, but I'm currently fine with it because I wanted a trigger detection of G_MissileImpact.
I'm done with G_MissileImpact for now, and I tried to implement and call G_RadiusDamage, but there's two issues.
1. An argument "float damage" causes segfault.
A hook on G_RadiusDamage works fine when I tried it out the following code.
But it causes segfault when "float damage" argument is given to "a = G_RadiusDamage(...)". I debugged it by outputting what value the argument had.
It had negative value, so I put negative value "-1.23456789" into the place where "float damage" should be, as the above code shows, and then shot a rocket, but it didn't cause any segfault. I wonder what's wrong with the value of "float damage".
Also I wonder why "float radius" doesn't cause any segfault even though it has the same value as "float damage".
2. It causes segfault when G_RadiusDamage is called after Com_Printf.
I found that it caused segfault when I was debugging the arguments with Com_Printf, but it didn't cause any segfault G_RadiusDamage was called before Com_Printf.
What is address of G_RadiusDamage?
I think stack is spoiled there, so Com_Printf can return invalid values up there and even segfault. Another way to get values
#!/bin/bash cd "$(dirname "$0")" export LD_PRELOAD=$LD_PRELOAD:./minqlx/bin/minqlx.x64.so LD_LIBRARY_PATH="./linux64:$LD_LIBRARY_PATH" exec gdb ./qzeroded.x64 "$@"
After this type "r" to run qlds, then try to execute G_RadiusDamage. Game will freeze, so you can return to gdb console, type these to get values:
After this, you can continue executing using "c" command.
I'm sorry. The address of G_RadiusDamage may be 0x739B0.
I attempted to execute the original G_RadiusDamage by calling both of My_G_RadiusDamage code I wrote, but it caused segfault this time.