I canned that thread and my suggestions for standardisation becuase of views I stated in a previous post in this thread. So do what you like.

Originally Posted by GizmoQ

Here are my thoughts: The biggest drawback to me in doing this is the manual labor required to uninstall, move, and reinstall the numerous plugins, but once that's done I would have reduced the number of sub directories under the RRPath by half. JohnWPB mentioned that they wold stop working if buried in sub/sub folders of the RRPath. Can anyone verify this? And If so does it require a change in the RR source or changes in the plugins to relative paths? I don't know. So I'm for it, but I don't look forward to it.

It's not down to the Road Runner source as to where the plugins go but the plugins themselves.

A good plugin will be able to be placed anywhere and still work.

Some of the older plugins may have to be updated.

The main issue will be with scripts that have hardcoded paths in them.

Agreed. Like you I am sure those and there are a couple more, too, that ought to be included. Should I PM them a personal invite? We know most of them are already collaborating on many aspects of Road Runner processes, implementation, development, and application, and I understand their too busy coding to do this grunt work of documenting standards. That's why I volunteered in 2004, 2005, 2007 and now.

I saw the need, tried to explain how I could contribute, but it wasn't that important then. I keep bringing up the "source code wars", cause I almost gave up on RR during that time seeing all the things I had previously predicted come to fruition. I actually had three different sources with three different skins and had to exit from one binary load another, then load a different skin in order to utilize specific functions, it was a mess, not to mention I was probably a danger to everyone on the roads while I did all this loading and reloading.

I call the current situation "skin wars" cause the latest crop of skins are moving toward incongruity. A great example I just found a couple nights ago is DFX4: an outstanding, feature-packed skin with new features unheard of before its time, but his implementation of RRMedia in conjunction with his multiuser definitions wipes out the saved "10 disk changer" playlists setup for any other skins. No offense, but It took me a long time to figure out how to use the 10 disk changer using the RRMedia demo skin, backed it up, switched to DFX and poof it was gone forever. Recreated it in DFX, backed it up and switched to Sonique Elite Beta and poof they were gone again. Did the restore in DFX and amazing their back. Switched from my Cadillac user definition to my Mustang user definition and poof they're gone again. No offense to JohnWPB cause he probably didn't know of the problem till I mentioned it a few days ago. That's not standardized, that's not interoperable, but we as a community need to find and identify these issues and determine how to deal with them.

Luckily the word got out early about writing info to the RR.ini, but now we are facing the same issues with the skin.ini. We now have skins, plugins, and scripts writing to the skin.ini. Plugins and scripts with multi-skin support should probably be writing to rr.ini. But its not clearly explained anywhere where everone has access what the (and I hate this word) "rules" are for using one over the other.

Lastly, I really thing Guino should have the final say. If he looks over this thread every once in a while and says, "O.K. Let's go with that." I feel confident the others will follow suit. But until he gives the go ahead these are all just recommendations not standards.

GizmoQ - I have a few things I'd like to add to this forum, seeing as it appears to be still an "open" thread ...

Firstly the background issue ... instead of suggesting "that all skinners must use ..." how about having RR become a little more intelligent. As RR loads a skin let it check if the BACKGROUNDPATH is actually set in RR, and if it's not then have RR load a default BG colour to get the skin going. Add to this the ability to actually have the "FILEEXSITS" IND/CMD actually work so it checks inside the skin if the BG image is there and if not the skinner can take appropriate action to allow the user to set the BACKGROUNDPATH variable from inside his/her skin. TEK3 does this using AI scripts, but it would be a lot cleaner to have this integrated natively in RR code.

Now a few other points raised so far ...

Originally Posted by GizmoQ

As the standards are set, we will also need another thread locked from new posts that will summarized all standards, list boilerplate for copy into skinners documentation, and address unresolved standardization issues. This too I am willing to maintain for the community. I realize this will become a lifetime project and am willing to take this on for the foreseeable future. Who else wants to help?

I'll willing to help you with documenting RR and maintaining it - if I'm able. This is a feature sorely needed for the project.

Originally Posted by GizmoQ

... saved "10 disk changer" playlists setup for any other skins. No offense, but It took me a long time to figure out how to use the 10 disk changer using the RRMedia demo skin, backed it up, switched to DFX and poof it was gone forever. Recreated it in DFX, backed it up and switched to Technik3 and poof they were gone again ...

TEK3 doesn't know what the f**k RRMEDIA even is, let alone wipe out any of its settings - hell I don't even understand RRMEDIA, it's way too complex for in car use anyway. TEK3 disc changer uses 5 pre-named .m3u files saved in your playlist folder ... these are called zzChngr1 - zzChngr5. This is as much as TEK3 does with a disc changer. I would love to know exactly what did happen to your 10 disc changer files tho ...

Originally Posted by EL CAMINO

i think is time to make RR what is meant to be, a community project not a couple peoples project,

I couldn't agree more ... This started out as an open source community, and lately it is becoming a "closed source" dictatorship. Yes I understand Guino owns the source, but in general this whole projct / community is ripping apart at the seams. There are two very distinct groups on this forum now ... the "members only" group who are a closed group and who are dictating the direction the project is going, and then there are the rest of the members who - like myself - really enjoy the RR project and appreciate all the effort Guino and others put in, but who are becoming increasingly disenchanted with the total disregard for their input by that previously mentioned group ... .

Originally Posted by GizmoQ

The RR.ini variable "BACKGROUNDPATH" was discussed and Guino agreed to create this variable in the source code for standardization, but I guess it was not widely publicized because skinners are still creating their own variable to perform the same task.

Indeed ... reference to Enforcers sentiments above. Guino may have added the variable, but it was only publicized to a "select" few skinners, and those "select" few skinners / programmers continue to see themselves "above the law" in terms of participating fully in an open community like this one. Until such time as there is 100% co-operation from all members of this forum, standardisation and development will not succeed.

I couldn't agree more ... This started out as an open source community, and lately it is becoming a "closed source" dictatorship. Yes I understand Guino owns the source, but in general this whole projct / community is ripping apart at the seams. There are two very distinct groups on this forum now ... the "members only" group who are a closed group and who are dictating the direction the project is going, and then there are the rest of the members who - like myself - really enjoy the RR project and appreciate all the effort Guino and others put in, but who are becoming increasingly disenchanted with the total disregard for their input by that previously mentioned group ... .

WHO is in this group, I'd like to give them all my source code that I worked on. its not the "new source" of course, but the 11/07 source with all the changes i have made over time. not super commented, but still good

1) The background path:Road Runner\Backgrounds
is perfect, I did this to comply some time ago with the DFX skin when transparencies became a reality, as who needs a backgrounds folder within each skin?!

2) Plugins path:Road Runner\Plugins
Also Perfect.....

As these paths seem to be what everyone has settled on, I say go ahead and make this the "law of the land" and put that information in the first post in this thread. As mentioned, this stuff has been discussed and disussed so many times, its like crying wolf. Lets start with these 2 things to organize, and move forward from there. It is a good start, and if enforced, will start to fall into place.

Some notes on organizing the plugins:

All of the stand alone DLL's (Winamp.dll, GDIPlus.dll, MP3Art.dll and the likes) do NOT need to be in any specific location. As long as they are registered, they wil work. (All of mine are already in Road Runner\Plugins" on my system )

The harder part is many scripts are a combination of DLL's, .ini's, Exe's ect. (RRMedia, Movie Times, Traffic Cams, RRGas, RRPetrol, RRMail... just to name a few) are dependant on having folders in the RR Root directory.

It will be necessary to alter these plugins, to use the new \Plugins\ folder

There actually is an easy ways to do this. A new RR.ini entry needs to be made, that is simply:PluginsPath=c:\Program Files\Road Runner\Plugins\

I would not even make it an option in the RRConfig, just set the above line in the RR Installers default rr.ini file, and spread the word to everyone. (Die hard users can change this path to what they want by manually editing the rr.ini in a text editor if they really want to)

This will make it very easy for plugin creators to get the path from Road Runner, and append whatever folder structure from there.

Most scripts and plugins already contain code that gets $RRPATH$ to base things on, its just a matter of changing it to use $PluginPath$ instead.

This variable can be used throughout the plugin / script and will point to the correct location for any support ini's, text files, XML files ect ect.

This also gives those, that just do not like to conform to standards, the option to change that path in the rr.ini, Heck you could have:

PluginsPath=Z:\SomeCrazyPlace\My Plugins\

and the plugin, using the rr.ini pluginspath would then look in:

Z:\SomeCrazyPlace\My Plugins\RRMedia\

This seems like the best way to go, and will make it easy for the most part to update current scripts & plugins, by simply using the path from the rr.ini.

This will also force plugin creators to * N O T * use hard coded paths! I do not know how many posts I have seen where someone has installed Road Runner to D:\Road Runner and plugin xyz does not work, and script 123 bombs out with a file not found error.

Hope this all makes sence, and let me know if this seems like a good direction to go in.......

1) The background path:Road Runner\Backgrounds
is perfect, I did this to comply some time ago with the DFX skin when transparencies became a reality, as who needs a backgrounds folder within each skin?!

2) Plugins path:Road Runner\Plugins
Also Perfect.....

As these paths seem to be what everyone has settled on, I say go ahead and make this the "law of the land" and put that information in the first post in this thread. As mentioned, this stuff has been discussed and disussed so many times, its like crying wolf. Lets start with these 2 things to organize, and move forward from there. It is a good start, and if enforced, will start to fall into place.

Some notes on organizing the plugins:

All of the stand alone DLL's (Winamp.dll, GDIPlus.dll, MP3Art.dll and the likes) do NOT need to be in any specific location. As long as they are registered, they wil work. (All of mine are already in Road Runner\Plugins" on my system )

The harder part is many scripts are a combination of DLL's, .ini's, Exe's ect. (RRMedia, Movie Times, Traffic Cams, RRGas, RRPetrol, RRMail... just to name a few) are dependant on having folders in the RR Root directory.

It will be necessary to alter these plugins, to use the new \Plugins\ folder

There actually is an easy ways to do this. A new RR.ini entry needs to be made, that is simply:PluginsPath=c:\Program Files\Road Runner\Plugins\

I would not even make it an option in the RRConfig, just set the above line in the RR Installers default rr.ini file, and spread the word to everyone. (Die hard users can change this path to what they want by manually editing the rr.ini in a text editor if they really want to)

This will make it very easy for plugin creators to get the path from Road Runner, and append whatever folder structure from there.

Most scripts and plugins already contain code that gets $RRPATH$ to base things on, its just a matter of changing it to use $PluginPath$ instead.

This variable can be used throughout the plugin / script and will point to the correct location for any support ini's, text files, XML files ect ect.

This also gives those, that just do not like to conform to standards, the option to change that path in the rr.ini, Heck you could have:

PluginsPath=Z:\SomeCrazyPlace\My Plugins\

and the plugin, using the rr.ini pluginspath would then look in:

Z:\SomeCrazyPlace\My Plugins\RRMedia\

This seems like the best way to go, and will make it easy for the most part to update current scripts & plugins, by simply using the path from the rr.ini.

This will also force plugin creators to * N O T * use hard coded paths! I do not know how many posts I have seen where someone has installed Road Runner to D:\Road Runner and plugin xyz does not work, and script 123 bombs out with a file not found error.

Hope this all makes sence, and let me know if this seems like a good direction to go in.......

i actually suggested creating the pluginspath variable in rr.ini too but it was turned down by some people as unnecessary. If we can do it for backgrounds we can do it for plugins.. thats the way i see it.

ps, sometimes it is best not to be in a list. (any way it was late and I added the TBC so I could add others later

Originally Posted by JohnWPB

I am so glad to see this!!!!

Some notes on organizing the plugins:

All of the stand alone DLL's (Winamp.dll, GDIPlus.dll, MP3Art.dll and the likes) do NOT need to be in any specific location. As long as they are registered, they wil work. (All of mine are already in Road Runner\Plugins" on my system )

Right lets seperate plugins from essentials first.

GDIplus.dll is and essential and should not be considered a plugin, thus it should be in the root of Road Runner.

Winamp.dll (and the other player dll which I can't think of) is again probably a required dll rather than a plugin one and again should be in the root.

MP3Art.dll not sure about this one, but this is probably a plugin and therefore should be in <RRpath>\plugins\MP3art\ (note not the root of the plugins folder, nothing should be in the root, except maybe documentation to help developers)

Originally Posted by JohnWPB

The harder part is many scripts are a combination of DLL's, .ini's, Exe's ect. (RRMedia, Movie Times, Traffic Cams, RRGas, RRPetrol, RRMail... just to name a few) are dependant on having folders in the RR Root directory.

It will be necessary to alter these plugins, to use the new \Plugins\ folder

as far as I know the above mentioned plugins do not need to have folders in the root of RR, I know for sure RRTrafficCams, RRGas and RRPetrol don't.

Originally Posted by JohnWPB

There actually is an easy ways to do this. A new RR.ini entry needs to be made, that is simply:PluginsPath=c:\Program Files\Road Runner\Plugins\

I would not even make it an option in the RRConfig, just set the above line in the RR Installers default rr.ini file, and spread the word to everyone. (Die hard users can change this path to what they want by manually editing the rr.ini in a text editor if they really want to)

This will make it very easy for plugin creators to get the path from Road Runner, and append whatever folder structure from there.

Most scripts and plugins already contain code that gets $RRPATH$ to base things on, its just a matter of changing it to use $PluginPath$ instead.

This variable can be used throughout the plugin / script and will point to the correct location for any support ini's, text files, XML files ect ect.

This also gives those, that just do not like to conform to standards, the option to change that path in the rr.ini, Heck you could have:

PluginsPath=Z:\SomeCrazyPlace\My Plugins\

and the plugin, using the rr.ini pluginspath would then look in:

Z:\SomeCrazyPlace\My Plugins\RRMedia\

This seems like the best way to go, and will make it easy for the most part to update current scripts & plugins, by simply using the path from the rr.ini.

This will also force plugin creators to * N O T * use hard coded paths! I do not know how many posts I have seen where someone has installed Road Runner to D:\Road Runner and plugin xyz does not work, and script 123 bombs out with a file not found error.

Hope this all makes sence, and let me know if this seems like a good direction to go in.......

Originally Posted by Sonicxtacy02

i actually suggested creating the pluginspath variable in rr.ini too but it was turned down by some people as unnecessary. If we can do it for backgrounds we can do it for plugins.. thats the way i see it.

See I don't get this need for the pluginpath to be known to RR and/or the plugins.

All a plugin has to do is exists in it's own little subfolder (or in fact anyway on the PC even) of the plugins folder and know where Road Runner is. It knows where it is so it doesn't have to look to the RR.ini to find out where it should be.

Anything else it needs to know is going to be relative to where it is or where roadrunner is.

if a plugin needs to read another plugins ini file then there is something wrong, but again all the plugins are stored in their own subfolder off of a general plugins folder, the plugin can easily work out what the plugin folder is.

NB. MyPath = app.path is all you need in VB6 to know where you are, I'm sure AI has a similar command.