Thread: Discussion of Standardization in RoadRunner skins, plugins, addons and whatever else

Originally Posted by GizmoQ

Global variable for end user setup should never be changed by a skinner, but global variables like weather. For example, I have four skins that all have four weathercities plus the gpsweathercity. When I press and hold to change the first city in one skin (because I save those variables in RR.ini) I know that when I open up another skin that first city data will be the changed data, I don't have to do it again for each individual skin.

Hahah that one is, and is not my fault! I hated having just one city that was stored in the rr.ini, and having to use either notepad or RRConfig to change it. So, I set out and created the dynamic code for the buttons, and the OSK to enter the city names. At the time this was specific to the DFX skin, and thus the settings were saved in the DFX's skin.ini.

Over time, I guess other skinners have copied that code, and now it should be moved to the rr.ini.

Look out for the next version that when you enter a city name, you are presented with a list of matches to choose from (I got sick of typing Miami and RR setting the weather for Miami, Missouri!) This does not use an .ini setting, so no worries there hahah!

Originally Posted by GizmoQ

@Valhera@ - One of the things that I feel we have lost is the collaboration we used to have. If your changes to ElCamino's addon were openly discussed in the forum, maybe a consensus could be reached and everyone could benefit from the changes, then it could be included in the plugins directory. I used to make it a habit to dissect every new skin released for pieces that I liked and then port them to my skins, but this created a duplication nightmare. I remember CDRSkull used to write hardcoded .exe addons for his skins because he didn't want his code stolen, but that doesn't support the community.

Well unfortunately my hands were tied regarding the "open" changes... for much the same reasons as you mentioned about CRDSkull. I suppose there is a difference between "stealing code and passing it off as your own" and "re using published code.plugs with the authors consent" , which I dont think was really happening. But after reading these post I'm happy to go the way it's being suggested here ... I don't write lougins aper say. more on the lines of John's "helper scripts" for my skins ... so that's how it will remain.

Originally Posted by JohnWPB

Ok, If if it's so NOT needed then......why doesn't RRMedia work when I put it in Road Runner\Plugins\RRMedia then????

I know why, its because it uses $RRPATH$ as the root starting directory. That is exactly why I thought a PluginsPath in the rr.ini would just be a good idea. If a plugin takes care of itself based on where it is at, thats perfect. If not, that path can be uses as a "home base / Root Directory" for reference in the script or plugin. It also give the Plugin manager that Sonic is working on a place to look for the plugins. Say you install the plugins in a different directory, of your choice, how will the plugin manager know where to look? With a PluginManager.ini file? So why not just put it in the rr.ini and be done with it. It's one line, its simple, and matches the rest of the way RR works with SKinPath, BackgroundPath, MEdiaPlayerClassicPath and on and on....

nice.. i know someone would have a better argument than me on the matter. Skins have a home.. backgrounds now have a home.. why not plugins?

Originally Posted by GizmoQ

Sound fine to me. I haven't been a moderator since the early eighties back in the BBS days and it was a pain in the **S then. So I wasn't really looking to forward to it. You guys can handle that part for me.

I saw the discussion on the INC,PLUGINS.TXT and if we can get a consensus here will be added to post one of this thread cause now that most plugin conflicts have been resolved this makes sense to standardize at this time.

Speaking of plugin conflicts, I'm surprised no one has chimed in about plugin formats for labels, variables, an indicators starting with pluginname_XXXX. Which I thought was an outstanding idea, but needed to be better disseminated.

Plugins.txt should definitely be a standard as its actually MORE noob friendly than adding to a cluttered menu.skin. I also think the common consensus is that all plugins should start with plugin name in all of there elements. Go ahead and manlaw that one!

well my 2p's worth for ai type plug's that have been public released , should go into the plugins folder to , but in val's case which is the same for me and others , if you have altered a public release script then it should be added to the help folder of the skin , which most skins have too, and documention noting that your skin uses an personnal update of that script then its down to the end user to install it .

if a skin uses an installer to install then it should be an option to install these plugins.
like the rr installer now which allows you to check what you want to install, as there is a doc scr before the selection scr so the info to say that this skin uses updated script can be shown.
but saying that how many people actually read these scrs and a help file really .

"Next...Next...I Agree...Next...Next...Done"

Yep thats basically whats done, all in about 1/2 sec.

Anther thing I would like to see put in a sub folder is the preset files (*.pst) called something like "Presets" that is one item that can have a lot of file with it, I have 13 preset files in my root rr folder.

Originally Posted by Blue ZX3

Anther thing I would like to see put in a sub folder is the preset files (*.pst) called something like "Presets" that is one item that can have a lot of file with it, I have 13 preset files in my root rr folder.

definitely! Would require change to the source.. but mitch and i spoke on this.. i'm not sure if he ended up changing it or not. I believe he was gonna think of a way to not need a separate file for each preset.

A suggested plugin standard.


All plugins should have an indicator that has the same name as the plugin, so that other plugins can tell if they are running or not.

All these dbl post E, aren't helping your post whore'n count.