Small CO Memory Functions Library...

[ColdStart]

I've begun to work on a small dynamic load library (DLL) for Conquer Online in pure assembler. Due to it being programmed in assembler not only will the library be incredibly small in file size, but it will also be much faster than any Visual Basic, C++, or Pascal equivalent. Not to mention I just plain love programming in assembler languages.

Before I get started on some major functions, I would like some of the more intelligent users to suggest and chose features for each so that developers and program users will benefit alike.

So let me go through a list of possible features and choices...

• The library will use an external memory table file that is given as an argument in a function so that rather than updating the program using the library, or the library itself, a user can replace this table file or edit this table file so that the program can still be used without waiting for a developer's direct update.
• The external memory table file mentioned above would use a proprietary, or exclusive to the library, format which is human-readable in a text editor and also has a converter for other memory table files such as CT v6 and 7 from CheatEngine.
• The external memory table file mentioned above would be a common and single format such as CT v6/7 from CheatEngine which is not directly human readable but easier to directly work with and add to using the format's official editor.
• Dynamic pointers and static pointers will be supported. Dynamic pointers can have a finite amount of 16 points.
• To connect to an address in memory for read or write a function will get a quick numeric hash, such as Adler32, of the address identifier in order to go through a list of a converted raw memory table while matching against the hash in each table record, get the table record that matches, and return the final pointer address.
• If the common memory table format such as mentioned above is used the name, ID, description, or comment field will be the identifier for every address.
• An extended feature for the library proprietary format to allow read, write, and execute permissions for their respected functions would be available.
• An extended feature for the library proprietary format to contain function and subroutine calls with arguments using named labels for machine registers and stack. This would allow programs using the library to not only easily call these functions and subroutines, but also prevent breaking of old programs left unmodified and unpatched due to the memory table being able to be globally external and easily updated.
• The library will automatically cut string values read or written with a zero-terminator rather than using a specific length. The only problem with this is obsolete strings may not have a terminator and use a specific length. An additional function will be for overriding the counted length before the zero-terminator and using an argument specified length.
• No matter which format is used, the data type for read and write must be given. The return value data type for the library proprietary format mentioned above would be listed as NULL or a proper data type.
• To conserve memory, the table will be loaded as a raw memory table object and reused by a creation function that returns a handler to this object within memory. The creation function would be included automatically and privately within a load table routine.
• The library will have separate functions that either use an argument specified raw memory table object handler and Conquer process handle or the last used table and process. This will reduce code repetition for programmers using the DLL.
• The library will come with multiple interface/prototype files for the DLL. The languages would be MASM, C, Visual Basic.NET, and AutoIt3.

Now that you have looked through that wonderful list I created, please suggest what to keep, add, or remove from this library so that is useful to programmers working with the DLL, pleasurable to the users using the program, and optimized for your CPU!

Please don't kill me if this does not entirely make sense to you. If you don't understand a little something, feel free to ask, but if you have no clue as to what I am talking about, then please use the search feature of this forum to figure it out.

[PearlRaven]

any tcp/ip functions for packet logging/editing?

[yokoyoko]

I like the external table & not directly editable idea. Also it'd be nice if you release a guide on how to set up interface files for other languages. Overall impression: very nice idea!

[ColdStart]

Originally posted by PearlRaven+Jan 14 2007, 04:14--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (PearlRaven @ Jan 14 2007, 04:14)</td></tr><tr><td id='QUOTE'> any tcp/ip functions for packet logging/editing? [/b]

This is a memory modification library, not a packet logging or editing library. Such things are already out there for a wider range of games and programs.

<!--QuoteBegin--yokoyoko@Jan 14 2007, 11:21
I like the external table & not directly editable idea. Also it'd be nice if you release a guide on how to set up interface files for other languages. Overall impression: very nice idea![/quote]
If I did in the end use the "not directly editable idea", game function execution and value permissions wouldn't be implemented. That is why I rather dislike the "not directly editable", since after all there would be a converter for the library proprietary format. I might be able to use some alternative fields in the non-library proprietary format to replace such things, but it would actually be harder in the end to work with.
"Interface files" are just header or code files that import all the functions from the DLL so you wouldn't have to. So rather than importing each separate function from the library and declaring each argument it has and at what alias or name it should be called, you just include the interface/header files. Interface files are widely available and really quite easy to make and shouldn't really require a guide.

[yokoyoko]

another thought: if you can include packet sending functions or just functions that does a specific thing, such as go to a specific coord (send the appropriate packets based on values in the memory), trigger in-game keypress (eg send F1 to the game without actually occupying the keyboard, kinda like partner) and possibly mouse clicks, whether it'd be calling a in-game function or equivalent packets , and maybe just a event based function that executes whenever a specific type of packet is received.

Sorry if this is out of the range for your dll, just my ideas. I also have some ideas on what kind of data to read from the memory, if you'd like to know them ^^