It's too bad that there's no way to get the files out somehow... EDIT: I was looking around in the .exe as well, and I found a Visual C++ tag. So at least we know what compiler they used.
http://www.youtube.com/watch?v=EaTeueUL3X4 Considering there's a Big the Cat model in the trophy room, is it be possible to do something like this with him? Because that would be the best.
Kind of expected that considering the Havok files it reads are the ones from the Windows MSVC binary packfile format, and it's already available and compiled for it in .dll/.lib ready to be used. In other news related to the shadow problem, I imported a Generations material into an Unleashed stage and shadows didn't cast. Chimera imported an Unleashed material into a Generations stage, and the shadows casted over them. So I guess it's not material related. Currently testing if it's terrain-mesh related then.
Disassembling the exe seems like the only way for someone to make their own object definitions. I know SADX's exe was atleast partially disassembled, but I don't know how feasible it is to do the same to Generations, atleast to rip out the .cpp and .h files to study and insert brand new ones.
It would be easier to add a parser or something that could load files from a 'mods' folder instead of injecting the files into the .exe directly. Of course, we'd still need to figure out the format of the code in the first place...
Hence why it'd need to be disassembled so that you rip could them out and look at them. Once you have it disassembled, I'm pretty sure just putting the files back in would be just as trivial as adding a parser at that point. Unless there's a way to get at the .cpp and .h files without disassembling the whole exe.
Disassembly doesn't work that way. You don't get CPP and H files out. You get the raw x86 assembly, with variable names stripped and no documentation. Stuff would be a hell of a lot easier if it were as easy as ripping the original C++ code.
So there's no way to get at the .cpp and .h fiels at all? Not even disassembling from one hex address to another, where we think the .cpp files are contained, and then rewriting the assembly into c++ (or whatever else?) via trial-and-error testing? I thought it would. Hard work, for sure, but I thought it possible, atleast.
That's not how compiled languages work, and C++ compilers will only generate assembly code that gives people trying to manually decompile it more of a headache. You can try to reread the assembly code and turn it back to C++, but the results depend on your knowledge of the given C++ implementation, and even then will never be the same as the original file. C++ also makes no guarantee that everything will be together. I think some decompiler programs do exist but I don't know how good they are with C++. If there are debug symbols, version control strings, etc. they might help, but not much. Debug symbols will point you in the direction of some functions, but you'd need to understand the compiler's name mangling rules.
I did make a post in the 'official' mod topic of Generations in the Sega forums asking if Sega could add a parser. I don't know if we'll get a response, though. EDIT: Annnnnd they pay no attention. I suppose I should have guessed that.
It's more of a topic, but here: http://forums.sega.com/showthread.php?387639-Sonic-Generations-Mod-Thread&p=7099433#post7099433 They've been posting Dario's pictures, so they're not unaware of us, but it still seems to be more of a 'post random mods here' topic rather than a 'develop and discuss mods here' topic.
Let 'em jizz all over renaming character skeletons. :v: What I'm more interested in lately is that the work folder is implemented, but no actual data seems to be there at the moment. It was used as the DLC folder in Unleashed, overriding some of the internal contents of the AR files(XMLs for increasing the memory limits for GIA, considering it's MUCH bigger on the DLC), as well as the extra Stage-Add.pfd's with the higher quality lighting. Now, the exe does have some references to the work folder, and there's another folder inside called "TemporaryDebugData". If anyone figures out this folder could probably be used as a mod folder instead of having to repack the CPKs all the time, you're getting all the internets ever. EDIT: On the topic of terrain receiving shadows, I've tried blanking out all the GIA data from Seaside Hill and get the geometry inside Windmill Isle act 2. Shadows casted over terrain, so with all these tests, I think shadow receiving might be related to: - XMLs, this one's crossed out because just pasting over the Seaside Hill geometry makes shadows appear in the terrain. - Collision, I replaced the collision with a simple square and shadows were still there. - Material/Texture/Texset, they're not related given that we've tried replacing a material from Unleashed to Generations, and viceversa, and shadows remained as they were in both stages(receiving in the Generations' one, not receiving in the Unleashed one) - Shadows aren't actually casting: As shown in the Chu-nan case, this is false. The shadows are there, they cast over normal objects and Sonic exactly as in Unleashed. - GIA Data: This one I'm close to debunking it as not related, but I'm not sure yet. Atlasinfo files seems to not have changed at all between both games, and the extra padding is indeed padding and nothing else. Haven't seen any custom flags or anything. - .terrain-group files? - .terrain files? - gi-texture.gi-texture-group-info? - visibility-tree.vt? - terrain-block.tbst? - sgmain.lit-anim? - .terrain-model or .terrain-instance-info files inside the tg-###.ar files? - .model files? (might not be related since models imported into other objects receive shadows like the China spinning floors)
It certainly would be time-saving, but I don't think it would help out with the code. How'd you find this out?
If you mean the work folder stuff, in a conversation with Zoney and chimera about the extra GIA DLC maps for Unleashed. He gave me the whole work directory in which inside the work folder you could see folders with the names of the AR files, and with extra files inside. These were xbcompressed XMLs that were a modification of the Terrain.prm.xml files already inside, to increase the GIA memory limit and loading range. Given that we're seeing the same folder in Generations and with references to the exe(and I mean in the form of a string like "work/"), perhaps it might have some use. If you mean my edit, it's all from fooling around and trying out different files.
