[FF7PC] EXE 1.02 "Editing Real Estate"

[nfitc1]

Ya know what? I'm tabling this for now. My XPath tracer isn't tracing enough and it's getting things I don't want. I'll have to make my own tracer at this point. That might take a while. I'll still try to make this list.

 

[Iros]

Are you definitely certain that none of the functions are called indirectly, i.e. through a function pointer (or table of function pointers)? I could not tell whether the way you generated this list, was checking for this or not (and I am not sure how you could be certain of whether a function was called indirectly or not, without examining the indirect calls manually).

 

[DLPB_]

Reunion uses 511d40 to 513000 currently.  Not sure how much I will end up using, but a lot less than I used to because I realize now how to actually code a little in assembly.  Used to be the case that I'd just jump to this area every time, no matter what.

Live and learn, really.  When I am done with Reunion, I will likely go over this again and cut out as much of this nonsense as possible.

 

[nfitc1]

Are you definitely certain that none of the functions are called indirectly, i.e. through a function pointer (or table of function pointers)? I could not tell whether the way you generated this list, was checking for this or not (and I am not sure how you could be certain of whether a function was called indirectly or not, without examining the indirect calls manually).

Looks like it's not accounting for that. XPath's only deal with what's referenced in code, not data. There's actually lots of pointers in data that point to magic/item effects that this doesn't account for. :O

Reunion uses 511d40 to 513000 currently.

Have you tried using a Dragon Fang? 0x511C99 and several other methods in that range are referenced by Dragon Fang directly.

This list needs a little tuning.

 

[paul]

Can't mods just VirtualAlloc their own memory for injected code? Why does it have to take over a "dead" code section?

 

[DLPB_]

There certainly would have been a crash by now if any of the areas I use were used by the game.  I don't use 0x511C99.  My code starts after this point.  Before that is a ton of source code strings.

 

[paul]

Why not create a mod sdk where all mods register with the manager which allocates the ranges for it? Then unless all ranges are exhausted you'd never have to worry about it

I still don't understand why you can't just call VirtualAlloc() and put your code in the returned buffer from that though?

 

[nfitc1]

Can't mods just VirtualAlloc their own memory for injected code? Why does it have to take over a "dead" code section?

If you want to run this through a wrapper or your own drivers, yes. Most don't go that route though.

There certainly would have been a crash by now if any of the areas I use were used by the game.  I don't use 0x511C99.  My code starts after this point.  Before that is a ton of source code strings.

Then are we using different source files? 0x511D40 is in the middle of 0x511C99 which is directly used by Dragon Fang.

EDIT:
Open Office is really slow. Regardless, I'm working on a new set of unused addresses that really do account for the Data portions. The XPath tracer I was using doesn't account for that by default.

 

[DLPB_]

Why not create a mod sdk where all mods register with the manager which allocates the ranges for it? Then unless all ranges are exhausted you'd never have to worry about it

I still don't understand why you can't just call VirtualAlloc() and put your code in the returned buffer from that though?

I am assuming that would mean lots of people each having to add a file in order for this to work.  It seems far simpler to me to just use space available in the exe already.  It's cleaner and neater, does not require any further knowledge.

 

[ficedula]

Eh. I personally prefer that if I'm going to add any new code in to the process (which Ultrasound does do), to stick it in a DLL and have that injected somehow. Yes, it requires the user to either run the game through a launcher, or inject the DLL via Aali's driver or similar, but frankly I expect the majority of users applying mods can do one of those. Bootleg installs Aali's driver automatically after all, right?

Seems far cleaner to me to put each change in its own DLL that can be easily upgraded, changed, or removed, and automatically avoids overwriting the data/code from another mod (unless they're both trying to change the exact same thing, I guess - but there isn't any possible solution in that case).

 

[DLPB_]

I am not so sure dlls are the answer... first it means more files scattered about, second, Aali's driver only allows you to inject 1 dll, third, even with my launcher it would just be more hassle, and fourth...  don't dlls stay in memory once injected?  Seems a little wasteful to me when all most people need is a few hundred bytes of free space that exists in huge quantities in the exe.

Unless you are doing something a bit more involved.

 

[ficedula]

I am not so sure dlls are the answer... first it means more files scattered about, second, Aali's driver only allows you to inject 1 dll, third, even with my launcher it would just be more hassle, and fourth...  don't dlls stay in memory once injected?  Seems a little wasteful to me when all most people need is a few hundred bytes of free space that exists in huge quantities in the exe.

Unless you are doing something a bit more involved.

They stay in memory in the particular process they're injected in, sure.

Is there anybody running FF7 these days who really can't afford a DLL taking up an extra 100KB of RAM?!

Obviously every coder will do what they prefer - but I'd much rather stick code in a separate file where it's easier to remove if you don't want the change or it turns out to be buggy, and also easier for the user to report what they've got installed.

 

[sithlord48]

Is there anybody running FF7 these days who really can't afford a DLL taking up an extra 100KB of RAM?!

100KB lets see you get at least 100x this is the smallest ram sticks you can buy today so yeah we can spare the RAM.

 

[DLPB_]

Well, my number 1 pet hate is all the dlls that would be running about and the hassle of people asking how they inject them, and all the nonsense that goes with it.   I think making it as simple as possible and keeping it all self contained in 1 exe is far more preferable.  If the space is there, why not use it?

Ah well, it's no big deal.  :-D

 

[paul]

If you used the driver to load 1 dll as the "framework" then that's all you'd need. Even if they wanted to change the same thing it could still work, you could even make it just load a bunch of lua scripts.

E.g the DLL would hook and manage everything and provide call backs in to lua code such as onBattleStarted, onFrameStarted.. that sort of thing.

If you don't use a DLL then how do the current mods actually work? Patch the EXE?

 

[Bosola]

Orthogonality is key for any modding ecosystem. Plus, a framework or DLL allows for cross-mod dependency management. I can't see why you wouldn't do this.