Ballos' Lab

No, that just partitions your hard drive so you can install Windows normally. (And it only works on an Intel Mac – which I do have – plus it requires that you buy a copy of Windows.)

Better than an entire computer.

 

Sooooo, is their any time frame for a release now that a few days have past? *begs*.

 

You know by now that I don't take answers on a silver platter nor even care for them much. I'm not looking for any assistance, it's simply not the way I work. Thanks nevertheless, though, I appreciate it.

Well, I'm afraid you might forget a few flags, for example for the weapons, or forget descriptions of BlockID's that you can use for tilesets.

Of course some members know them trough my FAQ, but some newbies may don't. And I'm hoping for a good editor of course (But I think you will do a great job) If I want to use a flag you don't know I have to choose one of the "???". Could you atleast add a 0x?? before the question marks?

 

That's the screenshot from the editor I had posted back in the old days. Don't judge it based on that - that's old stuff.

I don't actually have the old editor's source anymore, and it's all HIGHLY outdated code. The interface is likely to change a bit as well. I'll post screenshots of the new thing when I have something more usable.

In the meantime, stop begging for a release date. I gave an estimate already.

 

I guess I'll just have to sit a twiddle my thumbs then........
*Gives support*

 

A question: Will this editor be able to edit mods made in Sue's Workshop and will Sue's Workshop be able to edit mods made with your editor?

 

...I got the impression that this is just for editing the data stored in the executable. Meaning, that it can't edit maps.

 

Is there anyway that I could get ballos's lab?

 

Is there anyway that I could get ballos's lab?

No, because it isn't out yet.

 

In the meantime, stop begging for a release date. I gave an estimate already.

Is there anyway that I could get ballos's lab?

If you want it Immediately maybe you could make a deal with Ballos directly, although you might end up serving his lab for the rest of your days ... with a lunchbox named Barlog (not to be confused with his loveable brother balrog)

edit: dang andwhyisit strikes again

 

with a lunchbox named Barlog

 

Barlog?

"HASSUH!"

"God bless you."

"Hey, that was my battle cry!"

Anyway, I don't know if RuneLancer needs beta testers, but I guess not
So...

I have a new idea anyway, but it would need much work I guess.

Why not create your own "scripting language" out of the assembly, or let the users create them and you can switch between assembly and that language (unknown commands will be displayed as assembly though)?

For example:

NPC.MoveX = [par1]

mov eax, [par1]
mov [edx+0010], eax

Or for those who like TSC:

<NMX[par1]

Or for those who like C:

NPC.MoveX.Set([par1])

Something like this
It would make the whole thing easier and everyone can define it as he likes to.

 

So... you want me to write not only a programming language compiler into this thing, but also a disassembler powerful enough to reverse-interpret any written assembly code back into this language?

You're a funny man.

 

It was just an idea, I got from Prof. Eich :x
Scrap it if it's too hard.

 

It was just an idea, I got from Prof. Eich :x
Scrap it if it's too hard.

Well... it's not "too hard," it's just not possible. For many, many reasons.

First, there's no such thing as a reliable decompiler (decompiler, not disassembler.) Why? Because assembly has more "precise" instructions that a programming language would (after all, programming languages get compiled to assembly, so the instructions in the language need some equivalent in assembly.) Some instructions don't have an equivalent and would only be fit for use in an assembly context anyway, such as cdq (which sign-extends eax into edx) or in most cases, operations made on the stack or on the program counter.

You can rough it out, but there's no way you can decompile code then recompile it reliably into the exact same assembly code. Especially once you get your hands dirty with some tighly-written assembly hacks that cache things in registers for extended periods of time to save space or does weird funky things.

If it were that simple, crackers all over the world would be using someone else's decompiler to quickly decompile and figure out protection mechanisms. All software would essentially be open source.

 

Well I was talking about making a thing like this:

Command:

A = [par1]

Equal in Assembly:

mov eax, [par1]

Or something like that:

A.MoveX += [par1]

Equals:

mov eax, [edx+0010]
add eax, [par1]
mov [edx+0010], eax

Something like that.
All instructions like the above will equal the command. Meaning instead of the assembly it will display the command
You could just make a .ini file for every "commandlist". This works only for NPC's, so why not specify that in the "commandlist" as well?

Everything which is not in the "commandlist" is displayed as assembly.

 

That's essentially how decompilers/compilers work.

Like I said, the problem is as follows. Suppose you're decompiling (the code has to come from somewhere, after all) and you have something that doesn't fit what's in the ini file. Then you're screwed: there's no way to represent the command(s). You can't support every existing case.

And take this case for instance...

mov eax,[offset1]
mov ecx,[offset2]
add ecx,0x10
add eax,ecx
mov [offset1],eax

This is essentially offset1 = offset1 + (offset2 + 16). The compiler would choke on this or anything more complicated than...

ecx = offset2
ecx = ecx + 16
offset1 = offset1 + offset2

...which is a lot longer in assembly than the earlier snippet is, so just loading and re-saving without touching anything would change the code. In fact, using a template-based approach for commands, the code would be saved back to the EXE as...

mov ecx,[offset2]
add ecx,0x10
mov eax,[offset1]
add eax,ecx
mov [offset1],eax

Now suppose some other part of the code jumps midway into this code (maybe setting something else in eax/ecx and jumping to the "ecx = ecx + 16" condition): wham. Broken. The offsets have changed, so it could jump "between" two instructions and crash monumentally. Even if it lands on an instruction, the jump would still jump to unexpected code and almost certainly crash...

 

Well, for the first one:

Everything which is not in the "commandlist" is displayed as assembly.

I have no idea for the secound one though You just could specify a adress range for the npc's, weapons and so on.
If someone changes the offsets, his/her own bad luck, I guess.

 

I have no idea for the secound one though You just could specify a adress range for the npc's, weapons and so on.
If someone changes the offsets, his/her own bad luck, I guess.

The offsets are no problem. You can just look them up in the pointer table - in fact, any editor worth its salt should do that. Of course if you relocate the pointer table, well there's only so much code can do...

And wherever you're looking in the code, it's always the same set of instructions: 80x86 assembly. There's no reason, for instance, a weapon can't mess around with a specific NPC's data (for instance, a shrink ray could set a "shrink" flag on its target) so restricting the code to one specific subset of functions (ex, the weapon update routines) won't change much. It's really a problem of code content: if it were as simple as just translating stuff into instructions, as I've said, we'd have all downloaded a decompiler and figured out everything there is to know about CS by now.

To be perfectly honest, I've started writing a decompiler just for the fun of it (in ACE, a scripting language we use at work that's probably also used by a group of middle-eastern engineers living in a cave somewhere) to see what I can work out. What's doable is isolating functions by dynamically creating a parse tree by following jumps and calls. But if you already know where the functions are located (as would be the case with an editor) that doesn't help much.

Still, I'm going to Germany late this september. Little vacation - I've always liked the german language and Germany sounds like a hell of a nice place. When I go there, I will treck all the way over to your house and beat you with a giant papier-maché trout for making me take on yet another project. ;D

 

ACE? That's german orange juice
Well, someone who mess around with the code and change all the things probably don't need scripting languages A scripting language would be a good help for newbies or people who are too lazy to write 3 commands when they can do it in one
Even a small change. "A = 32" is probably easier, faster to write and easier to mention than "mov eax, 0x20".

What town will you visit anyway Rune?