A while back, Buggi posted the source code for the extra cheats DLL here. However, it became apparent that the DLL would only stay loaded with some type of SC4 SDK, which is true. Maxis has a set of C++ headers defining types and classes used in the DLL.
I was just talking with an EA custom representative (http://pastie.org/1142153.txt?key=q6hxmiqibxg00pgpgts10g). He seemed to understand what I was talking about and said that the developers were still active, and that he'd forward my suggestion of releasing the SDK to the developers, as we've come so far with modding the game. Did he? I don't know, let's wait and see.
Hopefully, Maxis and EA realize that this game is successful because of how much effort we've put into mods, BATs, and tools that we, the community, made, and that we can take this to the next level.
Thoughts? Comments?
(and on an unrelated note, I really hope this is in the right forum)
That will be really cool , I just saw your thread at ST, some ideas might pop up out of my head :)
However I hope you/we can go further and ask for some internals format :)
This would be an incredible boon to the SC4 modding scene...if SC4 is like the PC version of FFVII, then a .dll could be used to alter virtually anything from the .exe.
But, obtaining the SDK is dependent upon those who have it being legally capable of releasing it. EA owns the rights to the game, after all...
A toast to good luck, eh?
Considering Valve Software whose a big gaming company, released an SDK with whoever buys their stuff, I don't see why EA doesn't take their example from working with them and do the same, for the SimCity situation, I mean Valve goes a step up that the big guy will want to learn, even talk to an amount of players you won't believe on improving the experience, why not EA do it for us?
Valve started HL with the sdk in mind, I'm not sure Maxis started Simcity with a SDK in mind :(
All I got to say is for EA to wake or release the SDK. Ya the version for the Ipad is coming out but still use computer users who cant afford an IPad need some more things to do with sc4.
I BACK U UP 100%
Quote
Nelson ________ to ppedriana | Sep 21
Hey Paul,
I sent an email to Ocean Quigley a day or two ago to figure out who to contact about this, since the customer support representatives weren't much of a help. Ocean told me to send a note to you. If I recall correctly, you were the lead developer for SC4. You see, in the 7 years SC4's been on the market, the community's already come up with brilliant mods and buildings. We just figured out how to get the game to load DLLs, but we need some type of SDK to get it to stay in memory.
So my question is if it would be possible to release this SDK, or who else to talk to about having it released. We've come so far when it comes to modding capabilities, and for our efforts to be in vain would be a large disappointment to the community.
-Nelson
--------------------------------------------------
Pedriana, Paul <<< SC4 LEAD DEV >>> to me | Oct 20
Hi Nelson.
>> We just figured out how to get the game to load DLLs, but we need some type of SDK to get it to stay in memory.
Can you explain what you mean by getting it to stay in memory?
Thanks.
Paul
--------------------------------------------------
Nelson ________ to Paul | 1 minute ago
Well, we know (or at least assume) SC4 has a list of functions that can be overridden or modified in some way, but there's no way to do so. When the Extra Cheats DLL was released, a piece of the source was released, though it relied on classes we also figured needed some sort of SDK to work. Lastly, when we figured out how to get SC4 to load DLLs, we also learned that the game unloads the DLL if there isn't a function of a certain type present. Once again, we needed an SDK to define the enumerated type.
For the record, I think it's awesome that these people are actually responding and engaging in dialog with you / us. It could be a great step towards keeping SC4 relevant (and the very best) for twenty more years.
So basically the game can not save the after effects of DLL?
This is debatable, I guess one example is the rain tool DLL. There had to be a reason it was then locked out before the game went on the market. While it had been brought back by modding, the effects do not save. Some people who use the rain tool seem to want the effects to stay. However, after using the rain tool, (in my case at least) the rain would eventually flood the city, because for whatever reason, it kept raising the default water level somehow, I did not want to save anyway. While I know some already know this, what I don't get is why the one effect will not, while another effect can.
I am talking about the extra cheats DLL and the moolah cheat, which this is only possible to be enabled by DLL, any money you enter, it seems it will save that city with said amount of cash after you reload the city again, without having to enter the command again, where as it can not remember when you entered the show time command, so you actually have to enter that command every other time, because it can not save that part. It just bugs me that the one effect can work, and be saved, while the other can not again.
I thought by SDK we were talking about developer tools that allowed programing of stuff, like programming new types of cars or making bike automatta get pathed onto the game's roads or something.
I do need to mention this behavior is not a SC4 thing alone, while Valve has their Source SDK, even though you can add DLL, and enter existing cheats, just like SC4, it will not save turned on commands, even the console commands they developed, the next time you load that saved game. At least what I experienced for both so far. Because of this, I don't know if they actually are going to be able to solve the request, but at least they are not completely oblivious towards us.
The rain tool isn't a DLL "$Deal"$
Its a DBPF file (your standard plugin file) that simply re-enables (and gives icons to) two terrain tools that have not been enabled in release. It simply contains the menu exemplar, icons, and description keys. You can see bits of the tool itself (mostly the visual effects) in the Effect Directory. From what I gather, it most likely works by increasing the moisture level in the area to match/exceed the moisture level required for sea level, while of course determining the area and power. The reason why it goes away after city reload is due to the fact that (probably) moisture is calculated upon city load and not saved to savegame mapping.
The reason why the moolah (and a few others) stay in effect after reload is due to the fact that they modify statistics that are saved in the city savegame, unlike with the moisture map (and subsequently the water created by rain tool).
Its great to hear that the developers still hear us, though :thumbsup:
And on that note, there's a lot in the EffDir, though I'm having a hard time figuring the thing out (only person I know of who has gained a usable knowledge of it is Gizmo, hence his rain "weather" mod and darker night mod). I've been trying to follow Redlotus's (mostly complete) spec file, but both the Maxis and Gizmo's effdirs are nearly impossible to pick out properly. I suppose I could create one from scratch...
Quote
Pedriana, Paul | Mon, Oct 25, 2010 at 7:13 PM
To: Nelson _____
I just met with Ocean today, coincidentally.
Are you saying that you made an SC4 plug DLL and SC4 recognizes it and tries to load it but decides it isn't right and doesn't use it?
Paul
Nelson _____ | Mon, Oct 25, 2010 at 9:31 PM
To: "Pedriana, Paul"
Exactly. It loads up the DLL, runs whatever's in DllMain->DLL_PROCESS_ATTACH, then doesn't use it and detaches from it.
Quote
The function it calls is GZDllGetGZCOMDirector. Look for that in the attached source code, in particular in the cGZCOMLibrary::Load function.
Paul
EmptyPluginCOMDirector.cpp (http://pastie.org/private/1rawe3w3pwcvc0rt4vveg)
GZCOM.cpp (http://pastie.org/private/f6up9293nml6i9dyz2g6mw)
GZCOM.h (http://pastie.org/private/p7nyj5cgu8qglchu6ujdq)
RZCOMDirector.cpp (http://pastie.org/private/ao6pjmyqnrb1fyt5st785g)
RZCOMDirector.h (http://pastie.org/private/8axqsatcwpkbeybl1glhva)
Asking nicely does work. ;D
&apls
And there are a few more headers needed before it will compile. :(
I believe in the past Paul has been known to help the community. I would suggest that we don't bug him with lots of questions but this is great work so far guys.
Simmaster, it might pay next time you flick Paul message include a link to SC4D for him to take a look at what his work has become. ;D
VERY well done nelson. &apls
Let's start to write our own dlls :D
meister
It is indeed missing a few more header files, I think we'd need pretty much all the header files (or somewhere close to it) to be able to compile it and such. But I think the providence of these pieces of code are for us to analyze, I already see things that we're missing, and I've noticed them in what shreds we have of the extracheat DLL. Though we would still need them for the types and functions for compliling... or at least, a user-made equivalent of it. But this is awesome news nonetheless. &apls
Quote
That code I sent you is not complete and not self-sufficient for compiling. I would need to go through some formal code release efforts to publish working code for that base system. But I think there should be enough there for you to strip away code and get a DLL loading.
Paul
So now we can without any further files/info create DLLs that stay loaded throughout the game, just we can't do anything useful that connects to the game while they are loaded. It's bit hard to understand all the technical wizardry in here :)
This is an amazing breakthrough &apls &apls
Thanks Nelson and Paul :)
Quote from: Jonathan on October 26, 2010, 01:57:40 PM
So now we can without any further files/info create DLLs that stay loaded throughout the game, just we can't do anything useful that connects to the game while they are loaded.
In theory that should be the case, but when I tried to run this (http://pastie.org/private/vpy6gz8gdk5eorumrs9ga) demo it try's to load the GZDllGetGZCOMDirector and would find something it didn't like and then would unload the dll and terminate the game. ::)
Quote from: null45 on October 27, 2010, 09:01:20 PM
In theory that should be the case, but when I tried to run this (http://pastie.org/private/vpy6gz8gdk5eorumrs9ga) demo it try's to load the GZDllGetGZCOMDirector and would find something it didn't like and then would unload the dll and terminate the game. ::)
Perhaps this could be of assistance.
bool cGZCOMLibrary::Load()
{
if(!mbLoaded){
cRZString sOSEncodedPath;
::ConvertStringEncoding(msLibraryPath, sOSEncodedPath, kCodePageSystem);
///////////////////////////////////////////////////////////////
//Platform-specific dynamic library loading
//
#if defined(K_WIN32)
bool bCriticalFailure = false;
#if defined(_UTF16)
bCriticalFailure = !::GZCOMLoadLibrary(mHandle, sOSEncodedPath.c_str()); #else
if(::GetVersion() & 0x80000000) //Windows 95/98/ME -- use ANSI path
bCriticalFailure = !::GZCOMLoadLibrary(mHandle, sOSEncodedPath.c_str());
else{
Uint32 nWideLength = msLibraryPath.size();
std::vector<RZUnicodeChar> widePath(nWideLength+1);
::ConvertStringEncoding(msLibraryPath, &widePath[0], nWideLength, kCodePageUTF16);
widePath[nWideLength] = 0;
bCriticalFailure = !::GZCOMLoadLibraryW(mHandle, &widePath[0]);
}
#endif
if(bCriticalFailure){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Error loading library %s\n", msLibraryPath.c_str() );
}
if(!mHandle){ //If the library load failed...
cRZString sFailureMessage;
RZChar* pWin32Message = NULL;
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&pWin32Message, 0, NULL);
if(pWin32Message){
sFailureMessage.Sprintf(RZText("Failed to load the requested dll \"%s\"\nWindows error message - \"%s\""), sOSEncodedPath.c_str(), pWin32Message);
RZ_ASSERT_MESSAGE(false, sFailureMessage.c_str());
::LocalFree(pWin32Message);
}
return false;
}
#elif defined(RZ_HAS_DLOPEN)
try {
mHandle = ::dlopen(sOSEncodedPath.c_str(), RTLD_NOW);
}
catch(...){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Error loading library %s\n", msLibraryPath.c_str() );
}
if(!mHandle){ //If the library load failed...
cRZString sFailureMessage;
const char* const pdlError = dlerror();
sFailureMessage.Sprintf("Failed to load the requested dll '%s' (%s)\n", msLibraryPath.c_str(), pdlError);
RZ_ASSERT_MESSAGE(false, sFailureMessage.c_str());
return false;
}
#else
RZ_ASSERT(false);
#endif
///////////////////////////////////////////////////////////////
// Mark the library as loaded.
mbLoaded = true;
// Get the com director accessor method. GZCOM will perform all necessary
// functions via the GZCOMDirector.
typedef cIGZCOMDirector *(*FunctionTypeGD)();
FunctionTypeGD pfn = NULL;
///////////////////////////////////////////////////////////////
//Platform-specific dynamic library loading
//
#if defined(K_WIN32)
if (!::GZCOMGetProcAddress( pfn, static_cast<HINSTANCE>(mHandle), kCOMDirectorFunctionName)){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Library %s does not have function %s(). Presumably it's not a GZCOM DLL.\n", kCOMDirectorFunctionName, msLibraryPath.c_str() );
}
#elif defined(RZ_HAS_DLOPEN)
try {
pfn = (FunctionTypeGD) ::dlsym(mHandle, kCOMDirectorFunctionName);
}
catch(...){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Library %s does not have function %s(). Presumably it's not a GZCOM DLL.\n", kCOMDirectorFunctionName, msLibraryPath.c_str() );
}
#else
RZ_ASSERT(false);
#endif
///////////////////////////////////////////////////////////////
//Check if the function was found in the library. If not, it may not be a problem as the
//library may simply not be one that we want to use.
if(!pfn){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load: The function '%s()' was not found in library: \"%s\"\n", kCOMDirectorFunctionName, msLibraryPath.c_str());
Free();
return false;
}
//Call the COMDirector function
cIGZCOMDirector* const pCOMDirector = pfn();
if(!pCOMDirector){
cRZString sMessage;
sMessage.Sprintf("cGZCOMLibrary::Load: Failed to aquire GZCOM director from library: \"%s\"\n", msLibraryPath.c_str());
RZ_ASSERT_MESSAGE(false, sMessage.c_str());
Free();
return false;
}
RZ_ASSERT(!mpDirector);
mpDirector = pCOMDirector;
// Toss over a pointer to GZCOM .. provides the ability for the dll to
// call into the framework. Note: this function is called EVERY time
// the dll is loaded.
if(!pCOMDirector->InitializeCOM(GZCOM(), msLibraryPath)){
cRZString sMessage;
sMessage.Sprintf("cGZCOMLibrary::Load: GZCOM Director failed initialization in library: \"%s\"\n", msLibraryPath.c_str());
RZ_ASSERT_MESSAGE(false, sMessage.c_str());
Free();
return false;
}
}
return true;
}
cGZCOMLibrary::Free(){
if(mbLoaded){
DEBUG_OUTPUT_LOCAL("cGZCOMLibrary::Free: %s\n", msLibraryPath.c_str());
if(mpDirector)
mpDirector = NULL;
///////////////////////////////////////////////////////////////
//Platform-specific dynamic library unloading
//
#if defined(K_WIN32)
::GZCOMFreeLibrary(static_cast<HINSTANCE>(mHandle), msLibraryPath.ToChar()); #elif defined(RZ_HAS_DLOPEN)
::dlclose(mHandle); #else
RZ_ASSERT(false);
#endif
///////////////////////////////////////////////////////////////
mHandle = NULL;
mbLoaded = false;
}
return true;
}
I have looked at that code, it fails somewhere after it calls the cCOMDllDirector constructor from the pointer returned by GZDllGetGZCOMDirector.
If the RZ_DEBUG_OUTPUT and RZ_ASSERT functions worked that would at least tell me where it failed. &mmm
I have a DLL with the classes and stripped code. While the game doesn't terminate, it attaches and detaches with no error. :(
Quote from: simmaster07 on October 29, 2010, 01:20:41 PM
I have a DLL with the classes and stripped code. While the game doesn't terminate, it attaches and detaches with no error. :(
The error messages would probably only show in a debug version of the game unfortunately, if they work in the retail version I have no idea how to enable them. ()sad()
Eh, I'm not giving up just yet.
(added comments marked with //--)
//-- Since the game can run the DLL without identifying it as a GZCOM DLL,
//-- we can safely presume that we're up to here.
//-- Note: kCOMDirectorFunctionName = GZDllGetGZCOMDirector
//-- If the DLLMain entry point is in the DLL, DLL_PROCESS_ATTACH
//-- is executed.
// Mark the library as loaded.
mbLoaded = true;
// Get the com director accessor method. GZCOM will perform all necessary
// functions via the GZCOMDirector.
typedef cIGZCOMDirector *(*FunctionTypeGD)();
FunctionTypeGD pfn = NULL;
///////////////////////////////////////////////////////////////
//Platform-specific dynamic library loading
//
#if defined(K_WIN32)
//-- The game is trying to convert mHandle (DLL handle) to an instance of a handle(?)
//-- Right now, pfn is NULL
if (!::GZCOMGetProcAddress( pfn, static_cast<HINSTANCE>(mHandle), kCOMDirectorFunctionName)){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Library %s does not have function %s(). Presumably it's not a GZCOM DLL.\n", kCOMDirectorFunctionName, msLibraryPath.c_str() );
}
//-- pfn will now contain the address of the GZDllGetGZCOMDirector function, if it exists
//-- Otherwise, RZ_DEBUG_OUTPUT() is called and pfn will remain null
#elif defined(RZ_HAS_DLOPEN)
try {
//-- NON-WINDOWS systems: get the address of a symbol, or in this case, GZDllGetGZCOMDirector
//-- This would imply that a library, such as .so files on Linux systems, can also be loaded
pfn = (FunctionTypeGD) ::dlsym(mHandle, kCOMDirectorFunctionName);
}
catch(...){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load() Library %s does not have function %s(). Presumably it's not a GZCOM DLL.\n", kCOMDirectorFunctionName, msLibraryPath.c_str() );
}
#else
//-- Cannot load a library on this system
RZ_ASSERT(false);
#endif
///////////////////////////////////////////////////////////////
//Check if the function was found in the library. If not, it may not be a problem as the
//library may simply not be one that we want to use.
if(!pfn){
RZ_DEBUG_OUTPUT("cGZCOMLibrary::Load: The function '%s()' was not found in library: \"%s\"\n", kCOMDirectorFunctionName, msLibraryPath.c_str());
Free(); //-- DLLMain: DLL_PROCESS_DETACH
return false; //-- Fail DLL loading, continue loading SC4
}
//Call the COMDirector function
cIGZCOMDirector* const pCOMDirector = pfn(); //-- A pointer to GZDllGetGZCOMDirector()
if(!pCOMDirector){
//-- The function did not return a value
cRZString sMessage;
sMessage.Sprintf("cGZCOMLibrary::Load: Failed to aquire GZCOM director from library: \"%s\"\n", msLibraryPath.c_str());
RZ_ASSERT_MESSAGE(false, sMessage.c_str());
Free(); //-- DLL_PROCESS_DETACH
return false; //-- Fail load, continue loading SC4
}
//-- mpDirector is currently null
//-- Thus, !mpDirector would return true
RZ_ASSERT(!mpDirector);
//-- Now we assign mpDirector the value returned by GZDllGetGZCOMDirector()
mpDirector = pCOMDirector;
// Toss over a pointer to GZCOM .. provides the ability for the dll to
// call into the framework. Note: this function is called EVERY time
// the dll is loaded.
//-- If the InitializeCOM function isn't found, unload and continue
//-- InitializeCOM() provides access to the framework.
if(!pCOMDirector->InitializeCOM(GZCOM(), msLibraryPath)){
cRZString sMessage;
sMessage.Sprintf("cGZCOMLibrary::Load: GZCOM Director failed initialization in library: \"%s\"\n", msLibraryPath.c_str());
RZ_ASSERT_MESSAGE(false, sMessage.c_str());
Free(); //-- DLL_PROCESS_DETACH
return false; //-- Fail DLL loading and continue loading SC4
}
}
return true;
EDIT: Have to fix one compile-time error before I can do a test on a new DLL.
Go, Simmaster, go! :thumbsup:
It's good to see the support you get!
I'm looking forward to the magic! :P
I'm impressed.
David
So that's where the name "Pedriana's Plant" comes from &idea
This is quite fantastic, thank you so much. If only I knew C++ XD
Joe
Erm, and what happens to us loyal Mac users? We can't run .dll files &mmm
I'm afraid not (yet)
http://en.wikipedia.org/wiki/Wine_(software)
I suppose Mac also don't run .ini files, and no one could convert the DLL's to .ini so SC4 could run thoes instead.
Most mac users can modify the EXE directly. It is possible and not that hard to add another (just one, more requires harder work) submenu to the networks menu. GoaSkin got far in that, the
Problem was legalities of distribution and that the windows EXE is encrypted (or something like that)
Quote from: j-dub on September 08, 2011, 09:48:26 AM
I'm afraid not (yet)
http://en.wikipedia.org/wiki/Wine_(software (http://en.wikipedia.org/wiki/Wine_(software))
I suppose Mac also don't run .ini files, and no one could convert the DLL's to .ini so SC4 could run thoes instead.
I do own VMWare (I don't think SC4 will run, disk copy protection &mmm ), but my main Mac is a PPC (I share Intels with others)... I guess .ini files are a no-no too. Time to dig out a PC, I think :L
So its not like you can use Boot Camp to switch operating systems on Mac anymore and look at Windows files that way, instead of digging up a PC?
I could, VMWare supports the use of Boot Camp (so you can use the same installation in Boot Camp or VMWare)... PowerPC Macs (the one I am typing on) cannot run Windows, and I'm not using the other Macs most of the time (they're not exactly mine, I'll have to see what I can do). I'm on a rather restrictive budget which all but rules out Intel Macs, but I am planning on refitting one of my PC's to run CXL and other games. I'll see what I can do. &idea
In the files Paul sent me, he also sent the code which actually loads the DLLs. It makes provisions for non-DLLs, so if it's possible to compile .so files on Macs, it should theoretically run.
Would it be possible for you to upload the file he gave you, or did he give them to you on condition that you didn't share them? That way if/when you go MIA, it is possible for someone to take the lead for a bit?
You've done so much, it would be a shame for it stop because of RL :) (Please don't take that the wrong way)
Seconding the above request, for the same reasons.
There's a lot of potential in a .dll...
Quote from: simmaster07 on October 25, 2010, 07:31:12 PM
EmptyPluginCOMDirector.cpp (http://pastie.org/private/1rawe3w3pwcvc0rt4vveg)
GZCOM.cpp (http://pastie.org/private/f6up9293nml6i9dyz2g6mw)
GZCOM.h (http://pastie.org/private/p7nyj5cgu8qglchu6ujdq)
RZCOMDirector.cpp (http://pastie.org/private/ao6pjmyqnrb1fyt5st785g)
RZCOMDirector.h (http://pastie.org/private/8axqsatcwpkbeybl1glhva)
Asking nicely does work. ;D
They were already uploaded earlier in this thread. ;)
Yes, those are the files necessary for compiling the .dll, but there's a code that has to be included in one of the files that tells SC4 to keep it loaded.
Simmaster07 says he's obtained the code. Jonathan and I are asking for him to post it, if he is able, so that people will be able to work on the .dll in the event he vanishes. :)
Case in point: simmaster07 was last active September 17th, 2011. It's now June 13th of 2012.
Sad to see another promising project fall to the depredations of Real Life.
Quote from: dragonshardz on June 13, 2012, 02:02:51 AM
Case in point: simmaster07 was last active September 17th, 2011. It's now June 13th of 2012.
Sad to see another promising project fall to the depredations of Real Life.
Hello.
Just came back from a hiatus, I'm going to see if I can work on this some more.
Can I suggest the first thing you do is upload everything you have on the dlls just incase RL hits again?
Quote from: Jonathan on June 13, 2012, 08:59:05 AM
Can I suggest the first thing you do is upload everything you have on the dlls just incase RL hits again?
All of my previous work has been lost. I'm going to use what I already posted to try constructing another prototype DLL, and then I'll have everything on Github.
Even the email you got the files from?
Well good luck and I look forward to the github repo
Quote from: Jonathan on June 13, 2012, 09:04:16 AM
Even the email you got the files from?
The email addresses pretty much follow the standard "first initial/last name" naming convention that corporations use, and the username can be found in the first page with the email conversation, but I don't want to be a burden and have Paul being flooded by emails from everyone. There's also the fact that the initial correspondence took months to get even an initial response.
Regardless, the address was
ppedriana@ea.com
I meant didn't Paul send you some files over email, and won't they still be attached?
Quote from: Jonathan on June 13, 2012, 09:10:07 AM
I meant didn't Paul send you some files over email, and won't they still be attached?
The files that were attached were the ones that were already posted, but they're still attached, so we shouldn't lose them (unless Google closes my account, and they're on Pastie anyway).
I have them on my computer as well.
Oh right, I was a under the impression you had other files.
Quote from: HappyDays on November 06, 2011, 01:46:07 PM
Yes, those are the files necessary for compiling the .dll, but there's a code that has to be included in one of the files that tells SC4 to keep it loaded.
Simmaster07 says he's obtained the code. Jonathan and I are asking for him to post it, if he is able, so that people will be able to work on the .dll in the event he vanishes. :)
&Thk/( If this is the only obstacle then it must be in Extra cheat since it certainly remains loaded after the start of the game!
The files are still there but sent the post no longer exists!
Quote from: NCGAIO on June 14, 2012, 08:45:43 AM
If this is the only obstacle then it must be in Extra cheat since it certainly remains loaded after the start of the game!
The source code Buggi posted to the extra cheats DLL is incomplete. So is the code that Paul sent us. We're basically playing a guessing game, trying to (in a way) reverse-engineer a DLL based on what we were given.
Very belated post, a link to the GitHub repository:
http://github.com/simmaster/gzcom-dll
DLL is nonfunctional at the moment.
- "$Deal"$
Quote
"When writing the code implemented note that only DLL that must be present in the address space of any process - is ntdll.dll, this DLL is loaded, even in the absence of the executable imports"
Link - http://www.xakep.ru/post/28092/default.asp (http://www.xakep.ru/post/28092/default.asp)
Has simmaster07 gone again :( ?