Tool: Advanced Script Studio [ASS|WIP]

[~Pokedude~]

Introduction
Dear ROM hackers,
I recently decided to create an all-in-one cross-platform script editor for games of advance generation. Yes, there already is cross-platform stuff, yet it's either uncompleted, written in an ugly language or does not consist of enough features. My aim is to create an easy-to-use tool with endless amount of possibilities!

Features

1. Fully customizable XML file - you will be able to change command names/parameters with a few simple clicks within the tool.
2. Fully customizable command table: change ASM code, create new script commands and much more!
3. Editor in IDE style - you will finally able to manage all your scripts (and also remove them if needed) without creating dozens of backups or losing useful time by using the hex-editor!
4. Fully customizable special table: to implement quick and reusable features for your hack
5. Intellisense and code completion to make scripting a simple and comfortable task
6. The ability to choose between multiple syntax'
7. (ROM-Map: to organize other stuff regarding your hack)
8. [...]

Your contribution
Unfortunately I will not yet give the possibility to you to commit your own stuff - I've seen many open-source projects here on PokeCommunity and almost all of them were written in a horrendous code-style. If you contact me, though, and prove that you are able to conform with all coding style-guidelines, your effort in helping with the code itself is highly appreciated! :-)

If you are neither good at programming or organizing stuff, you might help out by suggesting new features, beta-testing the tool and giving moral support. You might also participate at discussions regarding ASS and contribute usefully. You are more important than everyone else!

How can I watch this project code-wise?
Of course I've already created a repository on GitHub and added some XML-parsing code that I worked on the past days. Take a look by visiting the following site:
https://github.com/Pokedude9/AdvancedScriptStudio
I always try to keep the code clean and readable. If you nevertheless issue any lack of readability, contact me. <3

Todo-list code-wise:
Dynamic link library:

• Creating XML structure and parsing XML file
• Writing a class that handles ROMs
• Decompile scripts from ROM (+ macro support)
• Compile scripts to ROM (+ macro support)
• Adding preprocessor options and dynamic symbols
• Adding multiple syntax styles

Application:

• Writing custom widgets for enjoyable editor appearance
• Writing an editor for editing command XML files
• Implementing a project solution file structure in order to manage scripts and more
• Implement ASM compiling support
• Writing an ASM editor/command table editor (+ special table editor)
• Writing an intellisense system and add built-in documentation/tutorial
• (Writing a ROM-Map organizing system)

Closing words
Don't get me wrong about the commit-limitation; I just want to keep the code-base clean as this is the most important aspect in a programming project. If organization is not assured, progress will be slow as code readability is bad. But don't forget there is also the possibility to contact me if you feel competent enough to fully participate as a coder.
Do not hesitate to start a discussion and suggest features or leave some critizism. :-)

 

[chrunch]

Looks very nice, you might want to change the name to have a better acronym though. :p

One suggestion I do have is a built in hex editor, like the one in XSE but more useful. Best of luck, a new script editor is definitely something that's been long overdue!

EDIT: also support for legacy languages would be nice, if that's not planned already. I'm too used to XSE to switch right away.

 

[~Pokedude~]

Looks very nice, you might want to change the name to have a better acronym though. :p

One suggestion I do have is a built in hex editor, like the one in XSE but more useful. Best of luck, a new script editor is definitely something that's been long overdue!

EDIT: also support for legacy languages would be nice, if that's not planned already. I'm too used to XSE to switch right away.

But I really like that acroynm. =)
Anyways, of course the legacy languages like pokescript and XSE will be supported. But the scripting commands will have slightly different naming inventions (instead of message and boxset in PS, will use msgbox right away). The "new syntax" will be probably just in this style:

msgbox(@ptr, 0x6); // more programming-like :-P

----------------------------------------------------------------------------------------

Edit:
I've now tested several possibilites of handling binary files (specifically ROMs) and it appears that the fastest way is RAW ARRAY ACCESS. This means, for example, instead of

binaryWriter.ReadUInt16();

this is used:

// m_Data is ROM in a byte array
// reads two simbling bytes and reverses them
ushort ReadHWord()
{
    byte lobyte = m_Data[m_Offset++];
    byte hibyte = m_Data[m_Offset++];
    return (ushort)((hibyte << 8) | lobyte);
}

Those methods involving bitoperations seem to be at least as trice as fast as stream access, in some cases even faster. Of course, reading a whole byte blob would be too imperformant this way. That's why I access the native Buffer.BlockCopy method in order to read large byte blobs. The changes involved can be looked up at https://github.com/Pokedude9/AdvancedScriptStudio/blob/master/src/Core/Rom.cs.

Already implemented:

• Easy reading of pointers
• Peeking of value types (position does not advance)
• Offering a "RomState" which contains information about whether it's FR/LG, RS or EM and more
• Finding free space
• Aligning offsets to 2/4/8
• Finding a byte sequence in ROM
• [...]

Looks solid so far! Mono is really enjoyable to work with :-)

Spoiler:

Values from: BPRE v1.0 => Offset 0x1000

----------------------------------------------------------------------------------------

Edit2:
I've finally finished the first steps of decompiling with different syntaxes. While macros and references are not implemented yet, the basic decompiling stuff works! I'm full of ideas right now, so process will go quite fast.

Spoiler:

The power of OOP <3

 

[~Pokedude~]

Macros implemented
I finally got the bug-free parsing of macro definitions done! The dynamic system allows this to work in every desired language; I've also provided the possibility to create own languages, if wished. The new code can, as always, be looked up under the following domain: https://github.com/Pokedude9/AdvancedScriptStudio

The code needs a bit clean-up, as I've written algorithm methods all over the classes without storing them in an external code file. I will do that the following days! ;-)

Spoiler:

 

[ThomasWinwood]

I cannot legally look at your source code or collaborate with you because there's no license given. As such, I can't determine how well-documented your code is, but the lack of external documentation (not even a README file) doesn't give me hope.

 

[~Pokedude~]

Well, the project has not been running for long, so it lacks documentation. But you are totally right about the license. I've added it to the code but not to Github. Thanks :-)

 

[Joexv]

Macros implemented
I finally got the bug-free parsing of macro definitions done! The dynamic system allows this to work in every desired language; I've also provided the possibility to create own languages, if wished. The new code can, as always, be looked up under the following domain: https://github.com/Pokedude9/AdvancedScriptStudio

The code needs a bit clean-up, as I've written algorithm methods all over the classes without storing them in an external code file. I will do that the following days! ;-)

Spoiler:

Looking good so far, love the acronym. But I feel like instead of {buffer:thingtobuffer} it should just be {thingtobuffer} just less things to type out. Good luck!

 

[~Pokedude~]

Thanks!
As I already mentioned within the code, I will implement a "text-adjuster", just like XSE. It will also feature a "property-picker" which automatically inserts {Buffer:Player} when you click on some button. :-)

 

[loser]

Looks cool, might want to change the acronym though. It's not really that funny.

 

[Lance32497]

I like your ASS, I mean your tool XD, I love the features, looking forward on it.

 

[esperance]

An interesting tool you've got here! The feature list is impressive and you seem to be making quick progress.

I took a peak through your ROM code and you really seem to be recreating the wheel here. A lot of what you've written is easily managed by what is already available to you in .Net. As you said, array access is faster than using something like BinaryWriter but these days the difference in speed is negligible and shouldn't really be a factor.

Also, I have to admit that your choice in acronym isn't really that funny.

 

[~Pokedude~]

You guys are right with that acronym beeing immature, but "AdvancedScriptStudio" wasn't meant to be acroymed at the beginning, just figured it out while creating this thread. ^^
I know what you're trying to say, Hopeless Masquerade, but when I see the decompiling process taking twice as long when using the default .NET implementation (on Mono), I'm better off writing a new, clean, fast and secure API. Certain functions, such as the "FindSequence" method would take terribly long when not using an array beforehand, for example.
If you can mention any reason to switch back to .NET BinaryReader/Writer, I'll do :-)

 

[esperance]

You guys are right with that acronym beeing immature, but "AdvancedScriptStudio" wasn't meant to be acroymed at the beginning, just figured it out while creating this thread. ^^
I know what you're trying to say, Hopeless Masquerade, but when I see the decompiling process taking twice as long when using the default .NET implementation (on Mono), I'm better off writing a new, clean, fast and secure API. Certain functions, such as the "FindSequence" method would take terribly long when not using an array beforehand, for example.
If you can mention any reason to switch back to .NET BinaryReader/Writer, I'll do :-)

The most obvious reason I can see is that it prohibits the tool from working with other tools concurrently, as it reads the data once upon opening and then overwrites the entire ROM each time it is saved. By using BinaryReader/Writer you can read from/write to specific portions of the file as needed, which allows other tools to modify the file at the same time.

 

[~Pokedude~]

Why would you need such a functionality? Imagine a tool writing data (or, more likely, any kind of metadata) at the same spot in the ROM as another tool at the same time. The result would be a mess!

 

[DizzyEgg]

Why would you need such a functionality? Imagine a tool writing data (or, more likely, any kind of metadata) at the same spot in the ROM as another tool at the same time. The result would be a mess!

An example could be compiling a script and assigning it to a person or other event via a-map.

 

[~Pokedude~]

True, but apart from that I do not see any advantages, because many other tools do block the file and get me shittons of errors when trying to access the ROM in any hex editor. No matter how you look at it, a class which handles ROM reading and writing (even with StreamReader/Writer) is much cleaner than having 2 variables on global scope, called "romReader" and "romWriter" in my opinion... :-)
But what we can do is the following: instead of writing the full 16/32 MB to the file again, we could just create a class which is called "RomEntry" or something. Every time you write bunch of data, a RomEntry with specified offset and length is created and is saved to the original file. So any changes in AdvanceMap and other tools will not disappear, if done while the ScriptEditor is opened. I think that's a good compromise! :-)