Extra lines in dynamic infocards (Reverse-engineering jflp.dll/plugins)
-
This worked absolutely wonderfully, thank you so much!
May I ask what you’re using to peek inside common.dll in such a manner? I have investigated it with a hex editor, but it’s a bit overwhelming and very difficult to find anything coherent.
-
Opened up common.dll in IDA and I can sort of see what you mean! I’ve found the order of things you referenced, and I can see entries relating to AttachedEquipment ahead of ShieldGenerator at [c]Archetype:: ShieldGenerator::read[/c]. This is all way over my head though. I think I have quite a lot of reading to do before I can get my head around playing with this more. Thankyou again for all your help
One odd thing: The newly compiled jflp.dll doesn’t run in Windows 7. Freelancer fails to call it. I can only assume this is related to the change
*len += vswprintf( buf + *len, 4096 - *len, value_fmt, args );on line 319 you suggested to get it compiling in VS 2019. There’s no spew output other than dacom failing to load the dll and ignoring it. It’s not a big problem though, Win7 users (The few we have) can happily go back to the standard 1.23 dll without any issues.
-
I tried removing /MD (VC2019 defaults to /MT) and got a 110kb(!) DLL. It runs fine in 10, but seems to have the same issue on Windows 7 machines as before. Do you know if there’s a way to see where it’s failing/get some spew output about why it couldn’t be loaded?
-
Both dlls attached! The one that works on 7 is just the unmodified jflp.dll from your website.
-
It’s fine! It’s not the biggest of issues anyway. All the Windows 7 users are missing out on (for now) is the shield stat lines, and we’re listing those out of the game as well.
I’ve had a chat with the guy I’ve been working through this with, and we were both wondering if there was any documentation out there for us to learn from? We don’t want to bother you every time with this stuff. We knew that our error from before had to do with the order in which we called things, but that was where our own insight ended.
My (very limited) understanding of how the plugins work is that they modify specific addresses in common.dll (or another dll) and then execute the code defined further down, but I have absolutely no idea what’s instructing jflp to look into common.dll or even at the addresses it does.
-
[W]e were both wondering if there was any documentation out there for us to learn from?
There’s lots of tutorials on learning assembly/reversing, but I learnt pre-internet (initially Z80 on an Amstrad CPC 464), so can make no recommendations.
[…] I have absolutely no idea what’s instructing jflp to look into common.dll or even at the addresses it does.
Finding the addresses involves analysing the disassembly, where exports and text-based ini prove very useful (which is what makes content.dll so hard, since it has no exports and little text). Then it’s off to the debugger, setting breakpoints on where it reads ini values, then hardware breakpoints to find where it uses those values. Once I have an address I try and find existing calls or jumps to use as a hook point, as that allows reusability with other hooks. That’s what [c]NEWOFS[/c] in a plugin does, replacing an existing call/jump destination with the plugin’s. If there’s no call or jump to hook, then I overwrite code with one, which is what [c]CALL[/c] and [c]JMP[/c] do. (I’m still amazed that with all the plugins out there, there’s only been one conflict, where the first version of EngClass didn’t get along with MultiCruise.)
