Luma3ds: [Suggestion] Plugin system similar to NTR's

[HoLLy-HaCKeR]

Title should explain it all.

What?
A plugin system for Rosalina, allowing things such as cheat menu's or other ram editing, maybe onscreen-displays.

How?

• A menu item called "Plugins" would be added to Rosalina.
• Displayed plugins are chosen either in a similar way as NTR, being game-specific, or also allowing plugins to be globally accessible (example would be the RAM corrupter).
• Backwards compatibility with NTR plugins and built-in support for GateShark cheats would both be a huge plus, but with a flexible plugin system a plugin could be made for these.

Why?
For the same reason LayeredFS, Rosalina and Input Redirection were added, I guess? Also, it seems that NTR is "publicly discontinued".

Examples:

• A plugin that runs on every frame or every n frames to write memory values. This would be either automatically enabled or toggle-able. An example would be a GateShark plugin. This plugin's settings entry would show up for every game, but show a different selection of cheats based on title id. The actual toggling of the plugin could be handled by the plugin itself.
• A plugin that reads some memory and draws something on screen every frame. Perfect examples are existing NTR plugins that show the clock, a speedometer for Mario Kart, the boss health meter for that one game I forgot, ...
• A plugin that changes LayeredFS settings on game launch. It would run only once, and depending on some parameters change what LayeredFS data is loaded. This would (for example) theme a game based on the time of day, or randomize a pokemon game on every boot. This example would require an API for LayeredFS to be exposed, so it might be a bit tricky.

[ghost]

A flexible plugin system could just load one for cheats or NTR stuff. No need for them to waste their time adding in those features. I recall the old psp custom firmware did it that way too

[Jan200101]

I would also suggest a plugin switch to keep any plugin from loading at all.

[noirscape]

NTR is discontinued in the sense that cell9 no longer publicly works on it. He's still working on it, there is just no longer a dedicated thread/issue tracker for it. You might consider that a good or a bad thing, but it remains as fact that NTR isn't dead.

It is becoming obsolete rather quickly though. The only feature it's really missing right now aside from plugins is video streaming.

[Margen67]

HorizonM does video streaming.

[HoLLy-HaCKeR]

Added some examples.

[noirscape]

@Margen67 - At 1 frame per second last I checked.

[Jan200101]

@ev1l0rd thats on o3ds

[Monotek18]

it'll be better to have the same way than ntr to load plugin, so we could use old plugin, but well most of the feature requested here are possible with NTR, it'll be nice to see them in Luma, so rip NTR

[jejer]

it'll be better to have a plugin can search and set memory like a cheat engine.

[kitlith]

So, people who want this, developers, etc... could we start laying out a plugin api that could be then implemented and PR'd? I've been working on adapting an ELF loader, got it mostly working on 3ds, and would love to get some sort of plugin loading going... but I'm not a designer, I'm an implementor, I guess. Ripping off NTR's api would not be the best idea -- not to say we can't take inspiration from it.

The following are a dump of my current thoughts on the subject.

"Basic" Machinery

• A version function, apiver_t <pluginname>_apiver(void) In case any breaking API changes are made, this returns the version the plugin was built against. Should do nothing else.
• A start function, err_t <pluginname>_start(<arg?>), passing a handle or pointer to struct. This is where you register any callbacks, allocate long-lasting memory, spins off a thread, etc. Called once the plugin is loaded.
• Callback registering. Could come in the form of filling in a struct with all possible callbacks, possibly passed to the start function, or as (multiple) dedicated function(s).
• An end callback. Free memory, remove callbacks, etc. Called before the plugin is unloaded. Could also be a function, <void?> <pluginname>_end(<arg?>).
• A frame callback. Called every frame, used when you don't need code running all of the time in a thread.
• Add/remove items from a (sub)menu. Perhaps have a dedicated menu for plugin options, and then a menu for each loaded plugin.

Features/Library

• Anything that should be provided by rosalina itself instead of libctru/libc/librosalina except what I have already mentioned? Anything special that needs doing because of the context we're calling from?

Other concerns

• Where should we be loading the plugins from? The menu thread? An entirely seperate 'plugin' thread? The main thread?
• When and how are plugins enabled?
  
  
  
  • Have to manually turn on, but state is saved as long as plugin start doesn't fail.
  
  
  • If consistantly failing on startup, what do we do?
    
    
    
    
    
    • We can make the user remove the offending plugin.
    
    
    
    • We can have a 'safe mode' button combination.
    
    
    
  
  
• Any features missing in gelfload that would block this?
  
  
  
  • Unloading files is currently unimplemented. (Related issue)
  
  

Comments? Ideas? Want to point out obvious flaws?

[ghost]

What about something like this?

plugins> (plugin list)
X Enable / Disable (Have the plugin text change color depending on the state like green or red)
Y Config
L Quick menu (copies the plugin text to the root menu for easier config access if needed)

Have the plugin list in alphabetical order then put the enabled ones at the top of it and disabled ones on the bottom. It'd make less effort scrolling down a large list to find them. Also I'm not a coder so I apologize if anything sounds strange

[fincs]

I would suggest against using ELF as the file format for plugins. Reasons why:

• ELF is designed as an executable and linking format, which brings in many features that are only relevant for object files (and not final linked executable). As a consequence of this,
• ELF is a very complicated and exhaustive format. Writing correct ELF parsing code is a long and tedious task, and it results in an unnecessarily complex and big codebase that is difficult to get properly working. Remember that Rosalina has pretty tight space requirements on Old3DS.
• ELF is a format especially designed for and used by UNIX-like operating systems (and the 3DS OS is certainly not one of them). It contains many features and design choices that only make sense in UNIX-like operating systems. For example:
• ELF shared objects (which are ostensibly what would need to be used for the plugin system) are supposed to be built as Position Independent Code (PIC). This is supposed to facilitate page sharing when mapping the same .so to many processes, and it involves moving all potential offsets to a Global Offset Table. It produces slower and more inefficient code, not to mention it makes static tables of pointers (such as VTables) hard to manage without even more complicated management. We definitely neither need nor want this on 3DS. Instead, a simpler and more efficient system exclusively based on relocations (such as the one used in the 3DSX format) should be used.

In summary, ELF is a woefully inadequate format for our purposes of implementing a plugin system.

[AuroraWright]

I hate NTR's plugin system with a passion to be honest.
1) most NTR plugins simply contain the equivalent of AR cheat codes: http://doc.kodewerx.org/hacking_nds.html#arcodetypes
2) most NTR plugins' source code is kept closed
3) consequence of 2), there are cases of being unable to use different plugins at the same time as they conflict
4) AR cheat codes can be used at the same time without issues, are easier to make, you can make a cheat finder and so on

If there could be any sort of scripting language (to draw to the screen, apply cheat codes etc.) I'd like plugins, but as things stand I think the focus should be adding an AR/GW-like cheat code system.

[xelrix]

I would suggest that future luma plugin system be developed solely as frameworks. Barebone.
Not cluttered with other features such as screenshots, redirection, streaming, or ar.
Only the debugger and system patches.
Maybe screenshots.

The rest of the features can be developed and bundled as plugins themselves.
This is to ensure Rosalina to stay lite and to have minimal impact on performance.
Being modular also allows better customization on user end.

What the system needs to be focused on are not features, but api.
Extensive api would allow better plugin development potential.

[ghost]

Cheats sound like a good short term goal even though I'd not have much use for them personally

[HoLLy-HaCKeR]

Plugins could also be used for things that are not related to the running process/game, but for simply running some code you would otherwise need to run an app for. Examples would be on-the-fly switching of saved wifi networks, running a service such as an FTP server in the background. Maybe it would be easier to have them be in a format similar to .3dsx and launch them in a separate process? Some limited IPC would be needed for toggling the plugin and optionally for hosting a GUI inside Rosalina.

[kitlith]

@fincs I acknowledge your concerns about ELF. Perhaps it will not be what is used in Rosalina. I wanted to use ELF because it was trivial to get gcc to output ELFs that worked with gelfload. Moreover, it's a known standard that works on multiple architectures. I've got some of my tests running on both my computer (x86 and amd64) and on my 3ds, using the same source code. (just some slight differences as to how it displays the result, etc.) I'd like to make gelfload work on more arcitectures in the future, as well as clean out the inherited cruft. I'm sure that one could create a non-standard format that is also portable across multiple architectures, but I don't want to create custom formats (myself) unless I have to. Regardless of what format is used, I want to try and help. And I can do that by motivating discussion on the API, which should be (mostly) format agnostic.

@AuroraWright The main use I envisioned for plugins was implementing features that don't need to be core nor need to always be enabled, such as the FTP server that @HoLLy-HaCKeR mentioned. (Does input redirection really need to be a core feature? Does GDB need to be included for every user?) Me and @xelrix seem to be having similar lines of thought. If this is not the kind of architecture that you want to go for, that's okay. (I may want to try and fork one of these days... but that's not going to happen any time soon.)

In short, I'm going for a framework for extensibility for rosalina that you could build a cheating system on top of rather than a framework for cheating, regardless of the plugin file format that is being used. What issues might there be with this idea, and my earlier, more specific proposal?

[Stary2001]

i agree with @fincs on this one - ELF is bulky and a custom (3dsx-ish?) format should be used instead. Rosalina is specific to the 3ds, and so portability doesn't really matter.

[fincs]

I wanted to use ELF because it was trivial to get gcc to output ELFs that worked with gelfload.

It's so trivial you may even forget not to use ELF in favour of a less bloated format ( ͡° ͜ʖ ͡°)

Joking aside, I happen to have developed several executable formats and have achieved a working ELF processing codebase that can be easily adapted to produce new executables. ELF to custom format conversion is a trivial step in the build process.

Moreover, it's a known standard that works on multiple architectures.

I don't think Luma3DS will ever run on anything that is not a 3DS (or ARM for that matter). Also, it is only a standard on Unix-like operating systems because it is a format that has been specifically designed for Unix-like operating systems.

[Peacock1090]

I'd be down for a simple AR cheat feature function before you boot up a game like they did with NDS flashcarts, since once I got to understand Luma's Rosalina and LayeredFS features it basically did everything that I would also use BootNTR for better and more efficient anyhow. It probably wouldn't be a huge drain on its resources too unless you were using a bunch of cheats at once, but I'm not a programming expert so I could be wrong.

[AuroraWright]

@kitling I'm personally for a "all in one" philosophy if there's no downside to it (see how Luma has several FIRM/loader patches which can't be turned off because they simply do no harm), so I see no reasons to remove Rosalina features and turn them into "addons". GDB and input redirection need to be turned on and otherwise cause no harm; this would also be the case for a FTP server.

[mtheall]

Did somebody say they need an FTP server? ( ͡° ͜ʖ ͡°)

[HoLLy-HaCKeR]

Did somebody say they need an FTP server? ( ͡° ͜ʖ ͡°)

Make it run in the background and you're golden ;)

so I see no reasons to remove Rosalina features and turn them into "addons"

@AuroraWright it wouldn't be removing features, they would simply be optional. It would be good for people who want a minimal install of Luma on their NAND and have more features on the copy on the SD card. Plugins could also be moved to a separate repo, which will improve development in various ways (such as dedicated issues, giving more/different people full rights, ...). They could also serve as examples for other developers on how plugins should be made, meaning more plugins in the end. And finally, making them a plugin and thus optional would clean up the menu just a bit more, meaning it is more noob-friendly.

All that will not mean that Luma won't be an all-in-one solution anymore, it'll just make it modular. I don't see any downsides except for effort having to be put in (but that's part of the fun, right?).

[ghost]

See the reference. Closing this now. Please feel free to continue your discussion about this feature here, though. Thanks.

[zayzu58]

NTR isn't publicly discontinued, not anymore at least. The latest version was released last month by cell9 himself. That GBAtemp edit is just a remnant of old drama.

[Monotek18]

I hate NTR's plugin system with a passion to be honest.

most NTR plugins simply contain the equivalent of AR cheat codes: http://doc.kodewerx.org/hacking_nds.html#arcodetypes
most NTR plugins' source code is kept closed
consequence of 2), there are cases of being unable to use different plugins at the same time as they conflict
AR cheat codes can be used at the same time without issues, are easier to make, you can make a cheat finder and so on

If there could be any sort of scripting language (to draw to the screen, apply cheat codes etc.) I'd like plugins, but as things stand I think the focus should be adding an AR/GW-like cheat code system.

As a cheat code maker/NTR Plugin dev (if we can call that like this)

1) No there is stuff that is not possible to do with AR and possible to do with C (like the one that decrypt Pokemon from RAM, or stuff like that.)
2) Just use the best one or simply RE it to add the stuff you want. (most that are closed source are the one from speedfly, otherwise most are open source)
4) 1 Plugin is like a lot of AR code, so yeah you can select more than 1 cheat in 1 plugin, they are not easier to do but faster. (C is even much easier than a complex AR code (yeah except for AR code that write XXXX to YYYY, very basic))

After that, yeah I understand you don't want to add that since NTR CFW can do already, and on any CFW.
But yeah, that a shame, it could be faster to use on a CFW directly.

[movr1r1]

Seriously, Luma3ds with plugin support, lol.

I love the NTR plugin thing, but adding this or any cheat system to Luma would make it as a gaz factory, we already have the stuff to do that.
We just don't need it, and it's fine as it is.

[HoLLy-HaCKeR]

@movr1r1 do you think there is any better way to load applications at any time than with Rosalina? Luma would just have to provide a plugin api, but it could allow for so many cool things.

First of all, we can get rid of NTR for the most part, because this API could allow for more possiblities in a more flexible manner. It wouldn't have to be loaded explicitly by the user (and thus doesn't require a cia to be installed), doesn't crash two out of three times, and has a nice menu to use on top of it.

Second, small applications could be ported to a Luma plugin and run at any time. Think about FTP servers, playcoin increasers, WiFi switchers, savegame editors/switchers, maybe a lightweight reddit browser, all without having to close the game.

Third, this would be perfect modularity. Luma wants to be the all-in-one solution, so why not allow third-party developers to contribute to this?

[Jan200101]

I get what movr means.
Lets say there is another CFW that comes up... lets call it schub.
If Luma added NTR plugin support then there would be no need for BootNTR (any version of it) anymore and other CFW's like schub would need to adapt to that for its userbase.

[weirdal3333]

Would it be useful if someone made a P2P Nintendo network plugin? It would be impossible to be banned (like the TOR network) and would be extra useful if it worked offline (like freenet) or during local play.

[Dimensional]

Uh, tor just anonymizes the connection. It doesn't do a thing to the PC itself, so using that is a bad example. What it sounds like you're suggesting is a 3DS/NNID version of the altwfc. That'll take some years to get worked on, as the altwfc for Wii and NDS are still a little buggy.

[Jan200101]

cough
wiimmfi
cough

[weirdal3333]

So, can we put a patch for wiimmfi in the Rosalina menu?
Also allow for changing the server's ip address in case you have your own server.

[Jan200101]

Wiimfi is a mainly Wii and DS based Service.
It would be cool though it if Luma patched TWL to use wiimmfi by default but thats another suggestion

[kitlith]

Been thinking for a while, and I've come up with a few possible use cases, and a rough concept:

Use Cases:

• Load-time patching. (think being able to throw in corbenik/cakes patches for easy patch prototyping, each patch loader being implemented as a plugin)
  
  
  
  • Be able to use the same plugins for both firmware patching and application patching?
  
  
  • I might be the only person that actually wants this, idk
  
  
• Run-time process manipulation. (ala NTR plugins, GDB stub, and Input Redirection)
• Persistent Background Processes. (FTP has been the main one mentioned so far)

My original thought was to have two types of plugins: loader plugins for the load-time patching, and rosalina plugins for persistent background processes. However, then I remembered run-time patching (which is possibly one of the main reasons people want this). It could be fit into rosalina plugins as well, but then we have two different places doing, well, patching. Which I guess wouldn't happen if nobody cares about the load-time patch plugins, anyway, and I'm just over-thinking things.

And I guess if nobody else wants load-time patching, I'm back to roughly where we started, except with a few use-cases specifically listed. :man_shrugging:

At least maybe I'll generate some conversation on this subject...

[urherenow]

But... doesn't Rosalina already have input redirection? Not sure what you want here...

[HoLLy-HaCKeR]

Yeah I'd still love to see this. Right now, if someone wants to add a feature that relies on Rosalina they would have to fork the entire CFW and add it, and everybody who wants that feature would have to install the (potentially outdated) fork. With plugins, however, they would just have to drag&drop the plugin file in Luma's working directory and it would work for as long as the plugin api exists (and Luma can still be safely updated).

When I initially requested this, Rosalina was still very new and a lot of development was going on. But since development has slowed down a bit nowadays, perhaps this is the perfect time to look into this?

[kitlith]

@urherenow If they were implemented as plugins instead of just built in, that's what category I'd put it under. This won't happen though. Though they also fit as persistent background processes that provide a server... :man_shrugging:

[CookieXD]

So it's already done!
The only remaining question:
When will it be added to the official build of Luma?

[AuroraWright]

They were implemented in a very quick and hacky way as per the author's own admission, we'll see about implementing them in a better way