there has been NO change to plugins and how they work(IN MONTHS!!!!).. ONLY expanded
and the core functionality NEVER changed
and its LOCKED in now
it would ONLY expand, and ONLY if needed
the real standards is the programming standards inside the plugins.. clean that up and done!
Expanded it maybe but change it still is
changed where they can be loaded from, how they are loaded (granted most of that affect skinners and probably end users) but it also makes it more difficult for us to then second guess where the plugin might be installed from, sometimes this can affect the plugin.
And I don't think there is much point having a standards discussion thread ot a standards thread for plugins because the people that can effect them don't pay any attention to those threads.
they can be LOADED from anywhere you PUT them, that is/was part of the problem...
that has NEVER changed
NO GUESSING should be done... cause computers dont guess that good... damm logic! :)
if you want to bring any of your existing plugins up to "standard" and thats very loosely qouted, ill be happy to help and provide any info you need....
the latest plug-in example is with the newest RR (4/1/09)
which really only has 1 NEW method
and that is to provide you with a PATH that is valid to create a dir, and store and local data the plugin MIGHT WRITE!!!!!
if you want to make your plugin use a USER DATA folder location, which actually is provided to the plugin (when RR is in PROFILE mode) in the Initialize method
using a USER DATA folder, is PROPER WINDOWS programming, and COULD allow a common dir, that multiple plugins (same plugin but on different skins) pull commom data. (something I love now, cause I run in profile mode)
I dont have any of you're plugins to look at, and see what would need, if anything, needs to be updated... maybe put together a .zip file of all of them... and i can take a look
I would love someone to take charge of maybe a plug-in guide, where things can be laid out, then its up to the indivual programmer to follow or break the guidelines
So if I read you correctly, if I use a plugin everywhere then I put it in $RRpath$plugins; if its only for one skin, put it in $Skinpath$plugins; and for the ones used in multiple skins but not all, I guess I can create another directory $RRpath$otherplugins for the registered .dlls/support files and just put a copy of the .dlls in the $skinpath$plugins directory.
Does this sound retarded to anyone else but me?
Yeah G, the standards are more for "normal" users, normal being ones that don't use a ton of different skins all the time. Most pick one or a few to swap between so having a possibility that you might have say 2/3 skin loaded plugins dub'd in to diff skin folders really wouldn't be anything to worry about. You are not in the "normal" users group, you are in the much more advanced group that likes to push the limits and the limit here really is that RR is written in vb6, so there is only so much we can do to make plugins, ect as flexible as possible.
I will also add that to me, for what you want, your proposal sounds fairly un-retarded. What you could do instead of copying those dll's to those skins, just use the ole INC,Plugins.txt for those. That would elimate the dup'd dll copies and no worries latter if one of those plugins needs updating as you will only have one dll for each plug, so no guessing which is reg'd..
giz, and keep urself organized...
like sub directories for EACH plugin... example (my fav plug in, ok 2nd fav):
$RRPATH$\Plugins\RRExtended\ (files go in this path)
or say in a skinpath...
if you want to do the OtherPlugins\blablabla
then optionally, drop the GHOST dll in the skinpath\plugins, that should work, but keep in mind, where the "data" of a plugin comes from... my guess is alot of people use app.path or something like that, vs a common PROFILE folder...
app.path will be the path the REAL dll is registered...
I just decieded to make a change to something i just added :)
blue look me up tonight, its not a big deal at all... but it will help steer standards
Originally Posted by mitchjs
Just had a look at this latest new method.
I have an observation (no surprise there eh?)
The path you have decided to allocate is
C:\Documents and Settings\<Username>\My Documents\RideRunner\
Now most applications I am aware of either use
C:\Documents and Settings\<Username>\Local Settings\Application Data\RideRunner\
C:\Documents and Settings\<Username>\Application Data\RideRunner\
wouldn't be better to use one of them if we want to keep standards?
Yes I saw the comment by Blue that users won't be able to find the folders as they are usually hidden, but if it is good enough for almost every other development teams to use these folders then it should be good enough for us. Unless we are either suggesting that the people that are using RR are more stupid than those that use other software or we are going to put info in there that shouldn't really be in there.
How do I switch from Legacy to Profile mode, don't seem to be able to find a setting in RR.ini or the new RRConfig.
When making changes regarding plugins etc, it would be nice if these changes were put to the main plugin developers (I would probably consider myself one of these) for their observations first. (same would go for skins and skinners)
Well, if/when this starts getting used more, and one asks user to post their debug file(s), they are first gonna ask where, then they are gonna ask R U sure b/c i don't C the folder if the typical app data folders are used.
Originally Posted by Enforcer
Its actually a reg setting that enables that opt to be shown on the installer. This months release should inc a profile opt reg file to enable it.
Originally Posted by Enforcer
Then you have a little .exe or script that extracts it from the location it's at displays it, lets the user copy and paste it.
Originally Posted by Blue ZX3
Which if you're trying to make it as user friendly (or as we in the IT department like to say, iDiOt proof) as possible would be the way to go.
Funny you mention an exe...was thinking the same, like a debug browser so to speak..hehe
Crap...this is the second time that we agree'd on something!