psy_commando

Ok, I fixed the problem. It was actually my multi-threaded (horrible) task handler that caused the problem. I replaced it with calls to std async, and I seem to be getting the exact same performances! So hopefully this is completely fixed now.. I updated the front page. Here's the link to the build on github : https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_statsutil_0.23.1a EDIT: Also updated the "modding setup" I made for the tutorial, and etc.. It also comes with the latest version of kaoutil now! (Which I completely forgot to release since last November..) https://app.box.com/s/v3ri7qqisu2rf4db0qfvm7rhx8imxnf7 EDIT2: I made a release for kaoutil 0.42 since it was long overdue! https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_kaoutil_0.42

Found my first bug after talking someone into using my tool! Because I haven't heard much since I began releasing builds. For some reasons not all script files are properly handled on windows 10. The program won't pop any warnings, but it'll only export a small number out of the 383 script files it should produce. Some people reported 52, and on my laptop only 29 came out.. It doesn't appear to be tied to threads, since setting it to a single thread didn't change anything. Since I only have windows 10 on my laptop, its the kind of things I couldn't readily verify myself. But I'll try running more tests on windows 10. It probably has to do with the version of POCO I'm using. Since I use their directory iterator class. Upgrading to the latest poco might take a while... Because they transitioned to c++ 11 so they changed their API a bit. Which means I'll have to change things as well if they work completely differently..

Also, I wrote a crappy little tutorial, to try to get people to try it, since I noticed most people seems really intimidated by this. All you need is in this zip : https://app.box.com/s/v3ri7qqisu2rf4db0qfvm7rhx8imxnf7 Well, besides the rom and emulator of course. Here's the tutorial in images. I wanted to write a Gist on github instead, but adding images to that is a pain, so there you go: http://imgur.com/a/bBnmQ If anyone has any questions about it, feel free to post in here or PM me!

Ok, so I decided to release Statsutil 0.23. https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_statsutil_0.23a I didn't include randomly generated dungeon data editing, because I want to be sure what everything does first to avoid having to rewrite over and over, and mess around each times.. I need to investigate. But my motivation is pretty much down to 0 in the last few days. So I assumed it might be better to just release this with just the script editing stuff and stop possibly keeping people waiting over it. Even though, I'm pretty sure literally everyone waiting on this got thoroughly scared by the format the game scripts are in by now.. I can't really simplify things any more this soon though, since I don't know what can be automated and what can't yet. It'll become clearer the more we find out about the script engine.. I'm pretty sure LSD tables can be automated, but some of the original tables have quirks to them that can't really be reproduced. And, the 3 main file types for a level sse, sss, and ssa could possibly also be simplified into something cleaner and simpler, but it'll require a lot more investigation along with feedback and report from users..

Alright! So my first attempt at loading the level data from a SIR0 file finally worked! Kind of.. [video=youtube;fSgLQYMQl0k] After struggling with dumb mistakes while assembling my modifications, and involuntarily ROP-ing the game, I managed to make it work without crashing! But there's some strange issues tied to Z depth and position markers, and camera panning info missing or incorrect somehow? I'm assuming it might be my rip of the level table that might be bad in some way.. But this proves that adding levels to the game isn't something far-fetched at all! At least, so far Once I work out the issue, I'll try with the NPC table too, so we can add extra NPCs! And I'll probably try to dump the personality quizz data and make it so you can add as many starters and questions as you want Then, I think we could probably try to figure out a way to make the game more extensible with some extensive ASM modifications! EDIT: Its not the table. Still not too sure what the problem is.. I'll try partially loading the file each times it needs to look up for a name. It'll be slow as hell, but if its an issue with memory management, it'll show.

I forgot to post it here, but I made yet another preview build. This time, a lot of things are better labeled and formated! https://app.box.com/s/8wuv2ncderm4e97171wqhdbm8z7won2w I've been hitting some issues with random dungeons data handling, and my motivation has been pretty low these days, so its been pushing back the release of the next version of statsutil. Meanwhile, I've also found a really nice assembler for the NDS for romhackers, "ARMIPS assembler v0.7d by Kingcom" and I've been experimenting with it. Its great, it saves so much hassle I'm working on trying to load at runtime the level list, and I've hooked about 11 references to the level list so far, both in overlay_0011 and the arm9 binary. I'll have to look into the remaining overlay files, and I need to fix my custom made "level_list.bin" sir0, since apparently I've doing something dumb while putting it together.. Hopefully it'll work on the first few tries.. ^^; EDIT: Also, for those interested in testing the tool, I shared a little "workbench" for extracting the rom, exporting the scripts, and then rebuilding the scripts and rom. Its a simple bunch of batch scripts that calls the appropriate tool automatically and does everything for you, so you don't have to type stuff in the console all the time.(It should come with the latest preview build of statsutil) https://app.box.com/s/v3ri7qqisu2rf4db0qfvm7rhx8imxnf7 Basically, just put the rom file in that directory after you've extracted it, drag and drop it onto the first batch scipt, it'll export the rom's file into the "rom" directory. Then double click on the "decompile everything" batch script, it'll export the script, the text, stats, etc.. Do your edits. Then if you've just edited the scripts click on the "3b" batch script, so its faster. It'll build a new rom with your changes, named literally "rom.nds". Then just run "rom.nds" in you favorite emulator.

They're inside the folder in the google drive he linked : https://drive.google.com/drive/u/0/folders/0B4K1yEh7ip9EZ3AzbXJzU2tpRGs

So looking at your images on your google drive, they're 24 bits per pixel. The game needs indexed color images that are 4 bits per pixel/15 colors. I doubt MSPaint can export images in that format. Gimp can, and I think Krita can too. You'll need to use/edit the stock palette of the portraits too for best results. Its funny that nothing warned you about that, I thought I set up something.

Hey! Glad that the tool was useful! ^^ The kaomado in that zip doesn't seems to be valid. It can't be exported with kaoutil and portraits are all black in-game, so I'm a bit curious about how you made your edits? Its possible there's a bug with kaoutil.

While I'm working on adding the last touches to statsutil for the next release, I wrote a bit of an explanation/summary on how the script engine works in general. Or at least, that's how I understand it right now: About the Script Engine: Each sub-directories in the /SCRIPT directory correspond to a scene/map/tileset. Except /SCRIPT/COMMON. The COMMON folder houses the master script, unionall.ssb. It contains repetitive functions that are called often throughout the game from various scripts, and also executes the game's levels and scenes in order. Level/Scene Directory Naming: ---------------- Each folder is named depending on the kind of level it is. "D" usually refers to a level/scene right before a dungeon. Or a dungeon hub/entrance. "V" usually refers to a full screen visual. Such the ones with the large background sceneries. "T" usually refers to towns, like T01P01 is Treasure town. "G" usually refers to the guild, and its interior. "S" are a bit all over the place. They seem to often refer to side-episodes, but some of the main game events also happen in those. "H" is Sharpedo Bluff. "Home"? "P" are usually places that don't fit in the previous categories. They're mainly for the scenes that happens on the road to somewhere this far. The second set of digits + letters refers to the sub-level. So for example, treasure town's market, T01P02A, has a higher value in its second set of digits than the town square, T01P01A. The very last letter seems to indicate variations of a level. So D01P11A, the beach during day, has a variation D01P11B, the beach at dusk! Now, back to the content of the sub-directories. The script data file defines the behavior and purpose of its accompanying *.ssb script file(s). Script Data Naming: ---------------- Script files follow a similar naming rule as to the levels/scenes directory names. However, there are a lot more possible letters. The first number right after the first letter is usually the chapter, then the next set of digits is usually the "step"/scene# within that chapter, but not always. "m" : Usually a main plot scene. "um" : Usually a "station" for a main plot scene. ("Station" explained in the *.sss file section below) "s" : Usually, the same kind of things as "m". The differences are unclear. "us" : Usually, the same kind of things as "um". The differences are unclear. "n" : Usually a side story scene. "un" : Usually a side story "station". ("Station" explained in the *.sss file section below) "c" : Unknown. "t" : Apparently title screen scenes. Of course, since "sss" and "ssa" data files can be named anything for the most part, there are a lot of instances where the naming diverges from those rules. enter.sse files are always named enter. enter files ---------------- The enter.sse + enter##.ssb pair defines the content and logic of the playable level. enter.sse instantiate actors and objects at the specified position, and associate action script to them. It also regroups them by layers, so that several actors/objects can be displayed or hidden simply by hiding or showing a layer. The enter00.ssb file is always run when entering the level. The subsequent numbered enter##.ssb files are action scripts, and their number correspond to the ID in the action script id attribute that an object or actor may have in the enter.sse file. *.sss files ---------------- The *.sss + *##.ssb files are what they refer to as "Station" by the devs. They're like entire or partial enter.sse + enter##.ssb pair in a way. They're merged with the current state of the level pretty often. They're loaded depending on context, aka the current chapter flag, to populate a playable map with actors, objects and etc. Often, they're picked and loaded by the enter00.ssb script when the level is first entered. But, its not always the case. *.ssa files ---------------- The *.ssa files are referred to as "Acting" files by the devs. They're mostly used for scripted dialog/cutscenes. They always have at most a single *.ssb script file. The entity data they contain seems to override any enter.sss's. However, sometimes, "Acting" sequences are used for playable/interactive scenes too. They can also load "Station". Several debug scripts are "Acting" sequences for example. *.lsd files ---------------- There is always at most a single *.lsd file per directory, and its name is the name of the level/scene in lower case. The *.lsd files seems to list only "Acting" sequences present in the directory. Their exact purpose isn't very clear. Its possible that one of the functions in the script refers to indices in the directory's *.lsd file to load local "Acting" sequences. *.ssb files ---------------- SSB files are plain script data. Script instructions are grouped into routines/functions. There are 5 types of routines: [TABLE=class: grid, width: 800, align: left] [TR] [TD]Common Routines(type id 9)[/TD] [TD]Found only within the unionall.ssb file. Those are basically a fusion of all 4 types of routine below. They can be either of those, depending on the Instruction used to invoke them.[/TD] [/TR] [TR] [TD]Actor Function(type id 3), Object Function(type id 4), Performer Function(type id 5)[/TD] [TD]They're function that are run by an entity specified in the static parameter of the routine, in the SSB's routine table. Upon the main function of the script being executed, the entities referred by each of the routines will execute the instructions within them. Another thing to note is that, "entity attributes" instructions, or any instruction that needs to have a specific entity picked as target through a preceding "entity accessors", such as "lives", "performer" or "objet", does not need to have a target specified within one of these routines! The target will always be the routine's target entity.[/TD] [/TR] [TR] [TD]Function(type id 1)[/TD] [TD]For a lack of better term, function denote what is both the main and first routine of a script file.(Except in unionall.ssb) Its this routine that's run first usually. It never takes any parameters, and its the most common form of routine.[/TD] [/TR] [/TABLE] Instructions: ---------------- The instructions in the script for pmd2 are very basic. They're simple codes with a fixed or variable number of parameters. Each code executes a corresponding function within the game's program at runtime, with the parameters specified. The method for controlling the code flow is simple jumps and conditional jumps. The conditional structures are typical switch + case statements which come in different flavors. Most of the case statements are conditional jumps, while some are more specialized and do not actually trigger a jump. Some instructions have something close to return values. Its possible to place case statements after those instructions, and conditionally jump based on the return value. Its possible that entity accessors actually work this way. They tend to fall into those categories: [table=width: 500, class: grid, align: left] [tr] [td]Conditionals [/td] [td]Those include switch statements, and branch statements. [/td] [/tr] [tr] [td]Entity accessors[/td] [td]Those are either of the 3 : "lives", "object", "performer". They return an entity on which the next appropriate instruction may be executed upon. [/td] [/tr] [tr] [td]Attribute[/td] [td]They're functions that get or set attributes for an entity picked by an entity accessor. [/td] [/tr] [tr] [td]Method[/td] [td]They're functions that act upon an entity picked by and entity accessor. [/td] [/tr] [tr] [td]Single Instruction[/td] [td]Basically the typical instruction. [/td] [/tr] [tr] [td]Closing Statement[/td] [td]Those mark the end of a function/routine. So far, "End", "Return", and possibly "Null" seems to be used to terminate a routine. "Hold" was also used in a similar way sometimes, but its unclear what it does, since its sometimes used in the middle of a script, and the script would simply continue past the "Hold".[/td] [/tr] [/table] More categories could be made however. But a lot of instructions aren't yet fully understood.

I tried ripping it on my end and there weren't anything like that in notepad++. Is it possible you changed the encoding, or did you change the line ending automatically to something else? Sometimes some text editors convert/change all line endings on save. I didn't notice it with notepad++ though. Its not yet implemented in statsutil. I've been a bit careful about implementing it, because I'm planning on introducing a few asm hacks to load a good chunk of the game data via files, so that a lot more things can be modified without having to figure out how to add things to the list in the exectutables. SIR0 are the perfect vector for that, and the game make use of those a lot already. Its a bit tricky though. Its not very hard to add simple direct editing of the starters however. I could definitely add something to do it to the current wip release, but I wonder if its worth it? Well, when you extract the pokemon data, notice the ones numbered 537 to 551. Those are dummy entries that can be used for pokemon with 2 genders. All the ones named "reserve" are single gender only, and usually meant for NPCs. Basically, just edit those files to your liking. Then, you might want to make those spawn in dungeons, but I still haven't implemented dungeon editing. Its scheduled for the current WIP of statsutil though. You can set one of those as starter and play as them though. Right now its probably better to just edit pokemon entries rather than adding though. For moves its pretty much the same thing. Except moves 543 to the end seems to be unused and available for tweaking. But we don't know much about moves, and its highly probable that their effects are at least partially hard-coded. Basically, you'll probably have to do trial and error and see what works and what doesn't because nobody is really sure. There has been little interest in testing anything over the years so we don't know all that much. No problems!

LF is linefeed. It basically indicates a new line. Did you turn on the option in notepad++ to display all characters? Because each unique string of dialog is separated by a line feed from the next. Its just usually not displayed by the editor, unless you toggle this on. It shouldn't affect anything, unless the LF box appears before the "\0" of a given string.

So, I found out way later that there was a bug with the last preview release where the routine table wasn't rebuilt properly. And so I made a new preview build https://app.box.com/s/gxrv5dib47svzowk49aac9lxt3h85o49 Hopefully, this is the last one before I get this thing out.

Made yet another preview build: https://app.box.com/s/4tkji56cs89u27spghg362d7s18uv2yo Its mainly bugfixes and a slightly simplified syntax. Routines now have their xml node reflect their type, and the type attribute is omitted, except for aliases(Though I could change that too). The extra value each routine had that was 0 for common and standard routines is omitted completely with those. Signed values are also properly exported and parsed, hopefully. So no more random "65535" in the middle of nowhere.. Just a reminder but any suggestions/questions are welcome!

Alright, I made a new build with script data support! I also achieved bit perfect recompilation for script files! That means, I can decompile all scripts and recompile them, and the resulting files will be bit per bit identical to the original! It was pretty much the case originally, besides a single value in the header that was mystifying me and the others. After gathering some data, I noticed that original files that had the same nb of strings had the same value for "unk1". After gathering some more, I realized that, the value of "unk1" was actually nb of strings * 1.5, rounded up! Its probably just some dummy value, but now the output is 100% identical to what their compiler does! Its extremely useful when trying to find bugs though, since it helps trim down the number of binary differences. In fact, it allowed me to spot and fix 4 bugs in 5 minutes But anyways. About the script data! I'm still not 100% sure what are the meaning behind all values in those though. So I just labeled some of these with "unk" and I'm hoping having an easier way to visualize the data will help us understand what they all do! I figured the actor/"lives" id, object id, the event's common routine id, however. One thing to note about objects is that, their names aren't unique. They're just a sprite filename. So to try to make it a bit more readable to humans, I put the numeric id followed by an underscore and followed by the sprite name for the object as the objectid attribute. The parser only reads the number, and doesn't care about the name after the underscore. So just something to keep in mind! The syntax has changed again, and it will probably change yet again before the actual release. So just a heads up! Here's the new build: https://app.box.com/s/mdce0jiaip5v2k0hde7ks1j1dpwitpwr Once again, if you can, try messing around with the values and let me know what happens! That would be extremely helpful!

I found a bug with how the signed values are handled. The script engine uses 15 bits signed integers, and I figure that the way I'm handling them might have caused the partner in the intro to run off-screen instead of up in front of the hero.. It probably happens in other cutscenes too. I'll try to inverstigate. I've also been working on the data format, and having some fun with it [video=youtube;YdzQzueCUkA] I made a lot of progress in the last few days! We should have a real release in a week or so, provided everything goes well!

New build! https://app.box.com/s/06l5f78lv51stv34pddc89hxhj5n6sxd I found out that one of the tables I found in the binaries was actually just as long as the list of routines in unionall.ssb.. And after looking at it, the names matched pretty much what was in the routines. So I set it up so that commands refering to unionall routines (most things like JumpCommon and CallCommon) have their parameter replaced by the name of said unionall routine! It should make things a bit more readable. Also, I added support for recognizing script file xml. So, you can now drag and drop decompiled script xml(for single decompiled scripts only for now) onto the executable(it needs to be in the same folder for some really dumb reasons..), and it'll compile it with the correct region and etc.. Also, I might have spotted a possible issue with strings. I had to default to utf-8 because of issues when setting it to the actual encoding, and some editors might scramble some characters after its recompiled.. I'll look into finding a definitive solution for this, possibly converting everything to and from utf-8 if need be, instead of just putting the data as-is and expecting the editor not to try to re-encode everything. But for now, \x is your friend! For example, the character for "é" can be replaced by "\xE9". And when the text is parsed, the utility will turn it into the correct character. PMD2 also has its own character escape sequence syntax you can use if you want. Its the ~. Just put an hexadecimal value after, and the corresponding character should be displayed instead. "~E9". Be sure to let me know of any possible improvements or bugs with the thing. And also, let me know if you think you figured out what a command is for. Most of the script is pretty much unknown or uncertain.

Good to hear! On my end, I edited the intro script on the beach to jump to the debug menu instead! [video=youtube;-RQBaeWdue4]

Ok, I fixed it. Its literally a single boolean I set to false instead of true by mistake.. https://app.box.com/s/5z9vr9gm2j9gi7pljm8obs8azp8ogrnn Keep in mind that I changed the name of an attribute in my local copy, so you'll probably need to re-export the script to use the new build.

Hmm, I tried compiling the same script, and I got the same error. I probably broke single script import at one point. Thanks for the feedback! I'll try fixing it. In the meantime, you can try the full import/export. It should work for now. EDIT: I found the issue. The double quotes weren't escaped during export for some reasons: <Instruction name="message_Mail"> <String language="English" value="[CN]The Special Episode\n[CN]"Today's 'Oh My Gosh'"\n[CN]stars [CS:Y]Sunflora[CR] as the main character." /> </Instruction> I'm considering making strings PCData or CData to avoid having to deal with this kind of stuff. AKA store strings this way instead: <Instruction name="message_Mail"> <String language="English">[CN]The Special Episode\n[CN]"Today's 'Oh My Gosh'"\n[CN]stars [CS:Y]Sunflora[CR] as the main character.</String> </Instruction> Or maybe using this way: <Instruction name="message_Mail"> <String language="English"><![CDATA[[[CN]The Special Episode\n[CN]"Today's 'Oh My Gosh'"\n[CN]stars [CS:Y]Sunflora[CR] as the main character.]]></String> </Instruction>

@Mariohuge Does the tool says anything, or give any error message in particular? Also, did you re-dump the script? Did you do a full export or you just export a single script? And what xml file are you editing in particular? If you want, you can also try atom : https://atom.io/ It does some nice highlighting and etc for xml. But I use notepad++ too, so I doubt that's the issue. It might help seeing things better though.

Hard to tell from just that. You might just have accidentally erased a < or something like that elsewhere maybe? I made a new daily build : https://app.box.com/s/bv0z12ksanioltp5zmy4v7i1bwl4r9a9 I did some bugfixing, I added handling for a few more parameters types, and improved the error output in some common cases. And I made it generate labels for a few more commands. I also got rid of the number that gets appended to attributes in the xml, except for nameless parameters. Maybe it'll help a bit?

European EoS supported fixed! : [ATTACH=CONFIG]13550[/ATTACH] Here's an example of how the text for the european version is laid out: <message_SwitchTalk svar="PARTNER_TALK_KIND"> <CaseText int="0x1"> <String language="English" value=" Let's go to Treasure Town." /> <String language="French" value=" Allons à Bourg-Trésor." /> <String language="German" value=" Auf nach Schatzstadt." /> <String language="Italian" value=" Andiamo a Borgo Tesoro." /> <String language="Spanish" value=" Venga, andando para\nAldea Tesoro." /> </CaseText> <CaseText int="0x2"> <String language="English" value=" We have to go to Treasure\nTown." /> <String language="French" value=" Allons à Bourg-Trésor." /> <String language="German" value=" Wir müssen uns nach\nSchatzstadt begeben." /> <String language="Italian" value=" Dobbiamo andare a Borgo Tesoro." /> <String language="Spanish" value=" Vamos a Aldea Tesoro." /> </CaseText> <DefaultText> <String language="English" value=" We have to go to Treasure\nTown." /> <String language="French" value=" Allons à Bourg-Trésor." /> <String language="German" value=" Wir müssen uns nach\nSchatzstadt begeben." /> <String language="Italian" value=" Dobbiamo andare a Borgo Tesoro." /> <String language="Spanish" value=" Vayamos a Aldea Tesoro." /> </DefaultText> </message_SwitchTalk> <Instruction name="message_Close" /> Also fixed the several issues with text the current build I linked in here has! (or at least I hope I did) Here's the latest build. Its still not release ready though, and probably really buggy!! : https://app.box.com/s/46p3cth904upbp3hq03vj1csfcav585i Btw, guys I need your feedback! Otherwise, I'll wait until I'm sure things are much more polished before releasing anything!

Well, anything is possible really. If you're ready to put the time and effort. I made a little video of some quick and dumb edits I did using the script editor: [video=youtube;iuupE6EUdtg] And here's my short term roadmap: Scripts Make script handling stable and as friendly as possible. Figure out as many parameters as possible. Reverse and implement script data support, make the matching data file "visible" to its script files. Possibly validate references in-between files, like a sort of linker? Write documentation. [*]Maps Reverse map tiles format and implement support and editing. Finish implementing sprites support + rewrite most of gfxcrunch. Possibly add a way to auto cut down user inputed images into usable image strips. Add support for menu and border import/export. Add support for font + character map import/export. Add support for animated backgrounds import/export. Work on first release of level editor. [*]Audio Get audioutil audio import working. Possibly work on a dse player [*]Code Make level(event) table loaded externally from a SIR0 into the game at runtime. Make starter list loaded externally from a SIR0 into the game at runtime + possibly add more logics/questions etc to the personality quizz. Investigate how to possibly add more actors. And more..

It took me a while to make things works and fix all obvious bugs, but here you go: https://app.box.com/s/ufet70cr9lxruusr4cl4uaib5rbi11ra Its a crippled version of statsutil, since I still haven't fully fixed the commandline argument parsing. Its definitely not what I'd call ready for release, but its probably enough to mess with the scripts! It also supports ONLY the north american version of Explorers of Sky right now. I didn't test the european and japanese versions yet. And EoT and EoD need a lot more work before I can support them! But you can drag and drop a ssb file on it, and it'll write an xml file. You then need to open a console in the same directory and type the name of the xml file plus the "-scripts" switch after to get it to compile your xml file. You have to make sure the pmd2data.xml file is in the same directory as both the file you're drag and dropping and the executable though. Here are the command lines that'll work right now for handling scritps: ppmd_statsutil.exe "script.ssb" Decompile a single script file to xml. ppmd_statsutil.exe "script.xml" -scripts Compiles a single script xml file. ppmd_statsutil.exe -e -romroot "EoSRomRoot" "EoSStats" -scripts The one above exports all scripts from the game into the "EoSStats" directory. If you omit the "-scripts" at the end, it'll just export everything supported right now, the scripts, game text, pkmn stats, moves, etc.. The "EoSRomRoot" directory contains arm9.bin and a directory named "data" which contains the rom's file. That's the typical layout when you export a rom using DSBuff or most other tools. ppmd_statsutil.exe -i -romroot "EoSRomRoot" "EoSStats" -scripts The one above compiles all the script's XML data presents in the "EoSStats/scripts" directory into the SCRIPT directory of the target "EoSRomRoot" rom root directory. If scripts are missing or added it should keep going. It has to load COMMON.xml though! Its a quirk I have to fix, but I forgot to change it. The XML for the script should be fairly straight forward. Most of what parameters and instructions do is unknown, but I managed to figure out a bunch of them, and convert them to user friendly names. Here's what a typical file may look like : https://gist.github.com/PsyCommando/a2bc5c609f69a84fd56d35d9febd2445 The number appended to parameters (for example "_1") is just a dummy btw, it doesn't determine the order the parameter is parsed. Its simply to make it standard XML, so most parsers won't complain about duplicate attributes. Here are some of the values ripped from the binaries that can be used (Not the event list stuff): https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/ScriptEngine/arm9.txt Here are all the instruction names, and the nb of parameters they take : https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/ScriptEngine/opcodelist_eos.txt It would probably be easier to look at what the dev did and mess around with the values to learn how it works. Also, some command take a string as parameter, and because the european version of the game has several version of a string in several languages, I made strings a sub-node, instead of an attribute like most parameters. You need to create a separate entity. Unless the entity itself is already a special entity. Some of the important pokemons have a unique entity that's not the base pokemon of their specie. The script engine is unloaded during dungeon play. So, I'm assuming that would need to be done via editing the ASM code of the game. You can set some dungeon parameters and flags before entering one though. Idk if its supported however. That could be possible. You'd need to add some custom flags though, or re-use existing ones. I'm planning on looking into ways to load custom lists of maps, actors, flags, and etc eventually, once I can get around to editing the game code directly. That would be possible. But I need to reverse the level data, aka SSA/SSE/SSS format first. With the scripts only, you can't add new enities or markers or triggers, since all the position data is in the matching script data file. Most likely yes. audioutil isn't yet capable of importing midis and sample though. But its shouldn't be too hard. Via ASM editing its all doable. Via script, it might be doable, but I haven't had much time to dig around for those things, and I can't confirm or deny. I know that unionall.ssb contains the strings for some of the prompts. And several other files do too! There is a lot of pretty funny debug text that got translated too, and looking at those debug snippets helps understanding how the scripts works too! Thanks! ^^ Its my pet projects right now tbh, so I really enjoy messing with this game. And I'm eager about seeing what people do with this too!