![]() |
Standardization of PokéScript
“PokéScript 2”: A Standard IntroductionThis standard was put together by A. Nicholi, cosarara97, Jambo51, Shiny Quagsire, and mewthree9000 on Sunday, the Fourteenth of June, 2015, and was set to be implemented in A. Nicholi’s compiler Lapis, cosarara97’s Red Alien, Shiny Quagsire’s Script Editor Advance (SEA), and finally mewthree9000’s PokéTronic; Jambo51 also provides influence for support of his ROM base project as well. It is our hope that others may follow this de facto standard, and that it be updated under the same lineage by appropriate authorities later in time as necessary. For that reason, its contents have been released under the GNU Free Documentation License. Because of how large the Pokémon ROM hacking community was and the fact that it lacked any standards for scripting whatsoever, it was deemed necessary by the authors that there be designed a standard for the PokéScript assembly language, so as to unify developers’ efforts and maintain a common denominator for compatibility amongst applications that used it. The authors thought it just to also invite others to derive from it, only because they were the ones writing applications that would utilize the standard at the time. Initially, A. Nicholi was the standard’s sole writer, and the four others were specification consuls. Why here?I decided to publish this here and on the Cave of Origin so as to further the goal of this standard at large; I’m putting effort forth to unify the endeavours our community’s developers make and put us all on the same sheet of music, for the betterance of our projects and products, and I’m doing that by putting it here in addition to other places of relevance/importance. Why this?If you’re working with PokéScript it may be a wise idea to follow this standard – two new assemblers for the language are in development now, and it isn’t very different at all from what XSE and PKSV-UI use. The standard will provide full compatibility with those two programs, actually. FilesDownload R6 as LaTeX or as a PDF Download R5 as HTML or as a PDF Download R4 as Markdown or as a PDF Download R3 as Markdown or as a PDF Download R2 as Markdown or as a PDF Download R1 as Markdown or as a PDF |
Out of curiousity, why? Why work to standardise PokeScript when XSE is so widely used and accepted. Although there may be a few undocumented scripting commands there (or areas that just aren't clarified enough) what would this actually add to that? PokeScript hasn't been commonly used in years now, why resuscitate it just to copy things over from existing, useful scripting tools?
Or am I completely missing the point here? |
Quote:
Also, I don't think he means PokeScript as in the tool. He just is using it as a name for the scripting language. IMO it's a poor name, as there are several scripting "languages" in the game. OWScript, worldscript or even mapscript might be better. |
Quote:
|
Quote:
Try #define FACE and XSE'll throw a type mismatch with the faceplayer command. ;) Quote:
Quote:
|
Quote:
|
I didn't ask why did you make a thread here. Come on now.
As to the 'same sheet of music' comment, the majority of hackers (at least, in this community) use XSE. They're already on the same sheet. Honestly, it just sounds like work for the sake of work - which is fine, you can do whatever you want - I don't see how this will be helpful to the future of hacking. |
I don't care what happens with this editor as long as I can keep using XSE's syntax (which it looks like I can). A super extra awesome bonus would be to include something like (I think it's) PKSV's movement planner feature. It makes writing movement scripts so much more intuitive, and would save me a bunch of time when writing them. As it is now, I'm constantly referring back to the movement #raw list and my map to determine, "Okay, so I want this person to run left (looks at list for correct movement) how many spaces (looks at map to count tiles)? Now it needs to walk two steps up and right (looks at list again)." PKSV's quality of life features were great. The syntax wasn't.
EDIT: A toggleable auto comment feature would also be good for noobs reading decompiled scripts, or people asking for help with them. For example: Code:
The ability to automatically convert movement #raws from one version to another would be nice too, so that you could port those scripts easily from Firered to Emerald and vice versa. |
A standard for pokéscript, or whatever you want to call the scripting language used to control events in third generation games of Pokémon is the first step into better tools and standardization (which, at least in reference to coding, is a good thing)
However I would like to make a few suggestions. One thing that always kind of annoyed me is the fact, that there is only one method directive "#org" which is then also used for text and "other" data. In the message command (which does not exist btw.) a pointer is loaded using "loadpointer" and then a standard script is executed to display the message (displaymessage, waitmessage, closeonkeypress etc. ) - If I have another data structure, a "custom" command (ASM routine etc.) that uses another data structure as parameter, I am forced to declare that one as a text or movement. In XSE the decompiler links the "message" command to text and the applymovement command to movement. If I do something like Code:
Therefore, there should be other directives, like "#text", "#something" or even "#asm", they all should be kind of customizable (In the attempt I made once to write a code editor I build a class based plugin system, because an asm method cannot simply be described in an XML/INI file. As for the rest I think thats all pretty much the same in XSE nowadays so switching to a new tool would not be too difficult for users. ~SBird |
I'm cool with anything as long as it's format is the same with XSE not that I matter xD
Plus if it adds easier implementation of movements then switching with it would be very nice.. add a live error checker and your golden! :D |
Quote:
Quote:
|
Quote:
EDIT: btw my tool has been around for a while. |
Quote:
~SBird |
Quote:
|
Quote:
Speaking of the thing, I've added a second revision of the standard. There's more complete directive coverage, a standard header, and it's formatted much more similarly to LaTeX with the MS PMincho font. |
Revision 3 has been published, and brings forth the #legacy and #thumb directives, differentiation between modern and legacy PokéScript and their semantics, allowances, etc., and lastly the command structures and their typings as well. Added as well were macro functions while (allowing looping) and text (allowing inline dynamic text).
What I would love to hear about from you, the users, is what directives and macro keywords you'd think would be a good idea to add, what your thoughts are on the divide between modern and legacy PokéScript with #legacy, and anything else you feel like sharing about the project. Thank you! |
I'll admit that I just skimmed over it, so maybe I missed it, but I don't believe there's any kind of discussion on the supported number formats.
It would probably be good to specifically discuss them, as you do with strings - decimal integer literals, hex literals (both lower and upper-case) prefaced with 0x. And, of course, any other literals you feel useful / necessary, such as perhaps binary literals prefaced with 0b. |
Revision Four is posted, guys. With this update comes the definitions for #freespace, #reserve (with an addition onto the XSE syntax), a specification for cascading preprocessor definitions (#defines having the values of other #defines by name), and also a specification for the macro functions XSE implements with things such as msgbox and giveitem.
In other news, I've finally got to start talking to two other scripting developers, namely Shiny Quagsire and also mewthree9000 (yes, as in the creator of Chaos Black). It's my goal that we can all come to a group consensus for what we'd like to see in this language and get something we're all relatively happy to implement in our tools. Collaboration is big with this, despite the apparence of me fronting the thing. :) EDIT: I forgot to mention it, but the numerical specification Sagiri was talking about got added too. \o/ |
Did you consider that thumb code can switch to arm code?
|
Quote:
Quote:
|
Quote:
The deal with ARM code is that there is hardly a reason for it to be in the ROM because of how sluggishly it executes from it (being the pipeline to it is 16-bit). The only place ARM code makes sense is in EWRAM, because that RAM has a 32-bit bus; ARM code is full 32-bit, whereas Thumb is a "thumb of the arm" 16-bit subset. With that said, I do think for completeness' sake we should add it, provided I'm not pelted with objections from the developers of the other SEs. I don't think it's the responsibility of the standard to go and cut people off from something the ROM puts in front of them regardless simply because they shouldn't use it – the standard shouldn't be a railing holding up someone who seriously wants to use ARM in the ROM :P |
Quote:
Everything depends on the behavior of the disassembler. |
Quote:
Having this feature just introduces more work for someone implementing the standard, and quite frankly I cannot see any benefit. |
Quote:
Quote:
I assume it would be nice to have pokescript and asm in a single integrated environment. |
Quote:
|
| All times are GMT -8. The time now is 8:40 AM. |
![]()
© 2002 - 2018 The PokéCommunity™, pokecommunity.com.
Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, The Pokémon Company or The Pokémon Company International. We just love Pokémon.
All forum styles, their images (unless noted otherwise) and site designs are © 2002 - 2016 The PokéCommunity / PokéCommunity.com.
PokéCommunity™ is a trademark of The PokéCommunity. All rights reserved. Sponsor advertisements do not imply our endorsement of that product or service. User generated content remains the property of its creator.
Acknowledgements
Use of PokéCommunity Assets
vB Optimise by DragonByte Technologies Ltd © 2023.