Closed holly-hacker closed 7 years ago
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
I would also suggest a plugin switch to keep any plugin from loading at all.
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.
HorizonM does video streaming.
Added some examples.
@Margen67 - At 1 frame per second last I checked.
@ev1l0rd thats on o3ds
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
it'll be better to have a plugin can search and set memory like a cheat engine.
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.
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.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.<void?> <pluginname>_end(<arg?>)
.Comments? Ideas? Want to point out obvious flaws?
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
I would suggest against using ELF as the file format for plugins. Reasons why:
In summary, ELF is a woefully inadequate format for our purposes of implementing a plugin system.
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.
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.
Cheats sound like a good short term goal even though I'd not have much use for them personally
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.
@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?
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.
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.
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.
@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.
Did somebody say they need an FTP server? ( ͡° ͜ʖ ͡°)
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?).
See the reference. Closing this now. Please feel free to continue your discussion about this feature here, though. Thanks.
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.
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.
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.
@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?
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.
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.
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.
cough wiimmfi cough
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.
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
Been thinking for a while, and I've come up with a few possible use cases, and a rough concept:
Use Cases:
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...
But... doesn't Rosalina already have input redirection? Not sure what you want here...
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?
@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:
So it's already done! The only remaining question: When will it be added to the official build of Luma?
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
Can I get some help
No. GitHub is not a support forum, and this thread was 5 YEARS AGO.
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?
Why? For the same reason LayeredFS, Rosalina and Input Redirection were added, I guess? Also, it seems that NTR is "publicly discontinued".
Examples: