• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Our weekly protagonist poll is now up! Vote for your favorite Conquest protagonist in the poll by clicking here.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

Development: Extending the Script Engine

Giga Universe

Working on a tool.
  • 121
    Posts
    17
    Years
    Would this be a very bad idea? Would it be feasible to make out own script engine for a game to support a greater variety of commands, such as 'takepokemon', iv checkers, etc. If we did, we wouldn't have to edit the current routine, just make a new routine, and run that from a regular script use 'loadpointer' and such.
    It could greatly extend scripting possibilities: functions could have return values, and work with variables properly, etc.
     
    The scripting-system is too mixed with the rest of the code to replace it. You can add new commands though. Especially 'special' has lots of free slots. Just add your function to that table. I'll post offsets here later.

    (Besides you don't really need return values, etc. (and there is LASTRESULT )If you want proper flow control and variables you can just use ASM. Scripts are just intended for simple things. Extending the scriping system isn't just hard but also not the point.)
     
    Nice idea, but hard to implement. Adding command and specials is somewhat easy, but XSE and other editors still won't support these new commands withour #raws.
     
    The scripting-system is too mixed with the rest of the code to replace it. You can add new commands though. Especially 'special' has lots of free slots. Just add your function to that table. I'll post offsets here later.

    (Besides you don't really need return values, etc. (and there is LASTRESULT )If you want proper flow control and variables you can just use ASM. Scripts are just intended for simple things. Extending the scriping system isn't just hard but also not the point.)

    Thanks :)

    Nice idea, but hard to implement. Adding command and specials is somewhat easy, but XSE and other editors still won't support these new commands withour #raws.

    But couldn't we just create a new loader and call that from a normal script? We could then completely rewrite it, and it probably wouldn't be that hard to create something that reads a custom function table. We could always write another script editor...
     
    Thanks :)



    But couldn't we just create a new loader and call that from a normal script? We could then completely rewrite it, and it probably wouldn't be that hard to create something that reads a custom function table. We could always write another script editor...

    I've already done this in some ways. I didn't write a custom script caller, I simply extended the table which has all the scripting commands on it, and slightly rewrote the engine to support the extended table.

    It wasn't hard to do, and the game worked fine with the new commands. The only real issue was the lack of support from the script editors which obviously didn't recognise my new command, and displayed it as a bunch of #raws.

    For the record, the command I made was a nice simple buffermapname command, which buffered the name of the map number you gave it.

    Anyway, certainly feasible, and not that difficult to pull off, but I second Knizz's comment. Just use specials instead, as this keeps support for XSE etc.
     
    Back
    Top