The development speed of my patch might increase noticably in the future.
This is because I'm writing me an assembler which will save me typing machine code by heart.
I write all my code concepts in assembly, then translate them to machine code.
With my assembler, I can do the second step that with one click
I just have to add a bit more flexibility and support for more assembly mnemonics, then I'll be going on working on the patch
I'll probably release that little assembler right here once it's done.
Sure he said he would probably post it here anyway, it sounds a bit like a translator program
EDIT: Also, CNCVK, you need to know how to hack the exe before trying to convert its code, you'd need to know assembly code to hack it, and that is extremely hard for most people (me included) to learn. You should only really use any sort of hacking / assembler program if you know what you're doing
Ares Project Manager.
Open Ares positions: Documentation Maintainer, Active Testers.
PM if interested.
it's an assembler, it converts x86 assembler to opcode, so, would work for anything.
you can define labels that point to specific addresses, so you can like enter "call $LoadINIString$" and it knows what address to use. relative jumps are supported, you can enter at which address your custom code begins.
not all instructions are supported yet (heck I don't even know them all, I got that opcodes.hlp though).
the latest addition were 16bit operations and floating point instructions.
i know that this is a old topic, sorry, but did you made the tool by your self?
aslo, i hope you make it public, if more ppl learon to hack, it make it easier and better for the rock patch
there is one problem with multiple people editing the patch.
you have to put your own stuff somewhere in the exe, that's sure.
now, if 2 people accidently add additional stuff to the same place, it couldn't be united.
i had an idea btw.
@CnCVK: if you could make YR read a list of dlls to load, I could implement callers at many places in the exe, which would then be known as "events".
I would eventually be able to create something like "YR script", an assembly or even BASIC style language to code for YR, which would be compiled to dll files (would be my first compiler, but I guess I understand how they work).
this way, people could write their own function and just add them.
I would just have to do what I like best to do - researching, and adding events.
by "events", I mean something like this:
event OnUnitDamage(Unit* DamagedUnit)
DamagedUnit.Owner.DonateMoney(200);
end event
in the exe, in the damaging routine code the game would go through every dll and execute the "OnUnitDamage" function.
I'm not sure though how slow this would make the game...
I know there's a lot of ideology behind this, but if dll calls are simple enough to get working, this might be possible.
You know what, that is a fucking awesome idea. We've long dreamed of something like this, it would also make a lot of new and old "map" triggers possible without actually editing maps...