If that didn't confuse you - you're 1 step ahead of me when I first heard it. CEAutoASM simply takes the script, a true/false for enable/disable, and a variable to put an Allocation ID into - to be passed back to, in this case, Visual Basic. This is the pre-function that eventually calls CEAutoASM.
#TRAINER NEED FOR SPEED MOST WANTED 2 CODE#
we now have a way to use AutoAssemble scripts, in the code of our choosing In fact, Dark Byte ripped the exact code from CE - modified it a bit for DLL form, and voila. Public Function Assemble_Script(strPassedScript As String, bolPassedEnable As Variant, intPassedAllocID As Variant) As Longįor those who dont know what this DLL is yet, it basically takes a script (string), and can enable/disable them, just like in Cheat Engine. but if the same, just return a true and not run CEInitialize Basically - you can keep running it over and over, and it knows/remembers the process ID it last connected to - knows to compare that with the current process ID, and if different, re-connect. I needed a way to keep track of this, so I wrote this pre-function. You're only supposed to use the Initialize function, once per game session. CEInit(lngPassedPID As Variant, lngPassedPHandle As Variant) As Boolean
I'm attaching modAutoAssembler.bas to this post. If I wanted to handle my own tab strips or other forms of visual control, I simply pass a Null to the function - where I'd usually pass object tabStrip1 The best part of this function is you can use any piece of it, and choose to not use specific parts. incase you had 20 check-mark boxes, but only 10 current scripts. You can also specify a check box control array, and it will populate the captions of those with the script name, and unhide them (i.e. For instance: When loading the scripts, if you pass the function a link to a tab strip, which resides on a form, it will auto-populate the tab-strip with semi-references to the scripts. Module contains a few special functions, which 'operate' controls in a project. Support for up to 99 scripts by default (although the possibilities are endless) The new function handles nulls, and does a lot of other checking/pre-work, just before it calls CEAutoASM A "Pre-Function" to the DLL's own CEAutoASM function. I've had to build a pretty big module to support it Features Include: Basic, as in how you interact with the DLL. No, not basic, as in any other autoassemble DLL could convert scripts better. I also made a module specifically to handle autoassemble.dll - simply because the DLL, imho, is very 'basic'. When I ripped it out, I re-focusd on the 'global vision', and now it only uses 1 Rich Text Box to display any scripts, which are loaded from a \AScripts\ folder
I didn't like this approach at all, furthermore, it completely went against the universal trainer theory, as most the code was behind forms, and not in modules. The previous version was going to use about 20 text boxes and the registry to save/load non-default data to/from. That, showing the Auto Assembler DLL implementation I created, then ripped completely out, re-designed and re-implemented.
simply because it's not about building a trainer for NFS-MW, more-so a 'universal trainer'. That's the reason this project is taking me so long. As of more recent, the idea hit me that the trainer, in EXE form, could be a trainer for darn near any game. If anyone has ever seen the south park episode where Cartman's trapper keeper started integrating everything into itself, then you'll have an idea of the vision I have for *the* mack daddy of trainers (until some other kid 1/2 my age comes along and 1up's meh).īack a few months ago, I wanted to make a good Visual Basic Project file that could be the 'shell' and start-point of any trainer.
Slowly but surely - as I'm moving here in the next 2 weeks (across country - bout' 2500+ miles from where I currently reside).īy now: Most of you have probably already moved onto other games as have I a bit - but I'm still keeping this trainer going. *EDIT* - VB Module and DB's ceautoassembler.dll have been moved to this post: