![]() ![]() (edit: seems P_PlayerThink checks it too to disable automatic view centering if flight powerup has just ran out) This can break demo / netgame sync because information about if useexterndriver was enabled while recording isn't stored in a demo and neither is it a per-player variable which is synced between nodes in a netgame. useexterndriver is checked in P_ZMovement to disable automatic view centering whenever the player has just dropped down from a large height. Really, oldAngle should always be reset whenever players->lookdir is reset (or the code should stick to using lookdir only), but it isn't. The game itself also tracks current view pitch in two different places which can and will get out of sync with each other: local static var oldAngle in G_BuildTiccmd (used by the code which handles input from external control driver) and players->lookdir. Well, now that I looked more at the game code I noticed two more problems besides the external driver's and game's pitch value getting out of sync: Yes, anything you attach to the end of the EXE file should be completely ignored by the loader in DOS4GW (or workalike) unless you make some corresponding LE header edits. I know if I ever return (unlikely any time soon) to tinkering around with this crap I'll just take kgsws' stuff and be done with it. Instead of exploiting the game and putting the loader code in the REJECT lump of a map, just permanently patch the provided loader code into the game binary and adapt it slightly where necessary (as in read the code blob from somewhere other than a PWAD lump). Does Fallout have some stack pushes before pretty much every function call, or just before printf & friends and some other rare exceptions? :P It seems you'll also have to write small asm wrappers for all functions from the main game binary your patch code calls, at least if the binary was built using the fast register-based calling convention (up to 4 args passed via regs, it seems gcc simply cannot be easily told to do this) Watcom offers. Might be worth looking into it, at least if you don't mind using gcc instead of Open Watcom to compile your code and the AT&T syntax for x86 asm GNU tools insist on sticking with. The last linked example patches the game in memory to add (limited) ZDoom DECORATE support to it, but of course you could even replace the whole game in memory if you wanted to, or conversely only do some much smaller changes. Don't know if you've already found out about it, but some time ago a proper hacker going by the name kgsws figured out a way to get code exec from a PWAD at map load time in vanilla Doom (with some suitably corrupted map data), and developed a simple "framework" (if you can call it that) for patching the game with compiled C code so that this exploit could be more easily used to do some interesting and even flashy stuff from a PWAD.Īlso see this github repo and especially this branch
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |