davewave
Addon Developer
- Joined
- Jun 17, 2008
- Messages
- 92
- Reaction score
- 0
- Points
- 0
I Wasn't sure where to put this as it wouldn't technically be an addon however it concerns addons.
How many times have you had to start off with a fresh install of orbiter just to see if that latest mod will work, often because it crashed another setup you already had.
There seems to be a fine balance, or delicate art, in mod installation and my proposal is to create either a rule, a program or a classification system that will be forwards and backwards compatible when new addons arrive.
Now I use JGSME for addons, and many people usually do. This is a given.
I propose that, with a lot of testing and playing, every mod that is released be given a code which indicates in what order it should be installed. The code will also contain a classification code which informs you if will crash with another mod.
For example, I might have two addons both with classification "B". This might mean that during testing, adding two classification B mods will disrupt the other in some way and that you chose to install at your own risk. This is similar to how chemicals at my work place are separated, for example, you wouldn't store a strong alkaline and strong acid in the same pantry.
The mod will have an Install order and a classification code.
For example, the base mod (or orbiter install) would probably have an install order of 1 or A.
I'd prefer to keep the coding generic so as to avoid the neccesity to number EVERY SINGLE addon out there (thats a lot of work). But rather addons that have proven safe to install no matter what order.
So, you would have Orbiter Base: Install Order A, Classification A
then the orbiter sound: Install Order A+1, Classification A
KSC Tiles for example: Install Order A+1, Classification A
the +1 means that it should come AFTER an A install, and the classification is a way to "group" addons together which can then be referenced from a chart.
The entire focus of the project would start off by having many people test installation orders and mod conflicts. Nothing is more annoying than having installed an awesome looking mod just to have orbiter crash because it relied on some random texture from an assumed mod.
Probably at some stage this project should also look at prerequisites but that is really the responsibility of the developer to get right.
A lot of the problem starts with developers posting their addons up mainly because they either INCLUDE the required mods in their mod (thereby causing a conflict with something else you had that the mod wasn't expecting) or they simply post a link (sometimes broken) to another mod you have to go fetch.
part of the "unification" of this project is to unify and to standardize the way this work. It can be a monumental frustration of havnig spent 2 hours downloading mods, clean install, just to have it crash and not know why.
I know that people would rather be making addons than classifying old ones so I get that participation to scrutinize every possible combination would be minimal.
I further propose that to enable the change, we slowly implement this system as new mods come out and the addon should be "approved" by an official addon tester (on the forums) for compatability. The mod then gets a classification stamp (as above) and is then released to the community.
Testing should be done with all the big ones (Tiles, UMMU, sound, NASSP etc). I know AMSO and the like I have them on a separate install but when I get to building space stations in orbit using XR2, and dragon fly, and uRMS and uCargo and uCGO and various bits and pieces, things for some reason, slowly decay.
In order for developers to be able to identify what collisions their mods might have with others they should check out what aspect of orbiter files they change "e.g. graphics, models, animations etc".
It is a big task but I think that if we do it on a progressive level and also report feedback (e.g. I just tried the new mod and it crashes with X mod) then the feedback is sent to the addon testers of the forum and maybe the classification is changed to reflect this feedback.
In this way we can already implement this unification project now.
Thanks for reading.
comments, etc... say hi
How many times have you had to start off with a fresh install of orbiter just to see if that latest mod will work, often because it crashed another setup you already had.
There seems to be a fine balance, or delicate art, in mod installation and my proposal is to create either a rule, a program or a classification system that will be forwards and backwards compatible when new addons arrive.
Now I use JGSME for addons, and many people usually do. This is a given.
I propose that, with a lot of testing and playing, every mod that is released be given a code which indicates in what order it should be installed. The code will also contain a classification code which informs you if will crash with another mod.
For example, I might have two addons both with classification "B". This might mean that during testing, adding two classification B mods will disrupt the other in some way and that you chose to install at your own risk. This is similar to how chemicals at my work place are separated, for example, you wouldn't store a strong alkaline and strong acid in the same pantry.
The mod will have an Install order and a classification code.
For example, the base mod (or orbiter install) would probably have an install order of 1 or A.
I'd prefer to keep the coding generic so as to avoid the neccesity to number EVERY SINGLE addon out there (thats a lot of work). But rather addons that have proven safe to install no matter what order.
So, you would have Orbiter Base: Install Order A, Classification A
then the orbiter sound: Install Order A+1, Classification A
KSC Tiles for example: Install Order A+1, Classification A
the +1 means that it should come AFTER an A install, and the classification is a way to "group" addons together which can then be referenced from a chart.
The entire focus of the project would start off by having many people test installation orders and mod conflicts. Nothing is more annoying than having installed an awesome looking mod just to have orbiter crash because it relied on some random texture from an assumed mod.
Probably at some stage this project should also look at prerequisites but that is really the responsibility of the developer to get right.
A lot of the problem starts with developers posting their addons up mainly because they either INCLUDE the required mods in their mod (thereby causing a conflict with something else you had that the mod wasn't expecting) or they simply post a link (sometimes broken) to another mod you have to go fetch.
part of the "unification" of this project is to unify and to standardize the way this work. It can be a monumental frustration of havnig spent 2 hours downloading mods, clean install, just to have it crash and not know why.
I know that people would rather be making addons than classifying old ones so I get that participation to scrutinize every possible combination would be minimal.
I further propose that to enable the change, we slowly implement this system as new mods come out and the addon should be "approved" by an official addon tester (on the forums) for compatability. The mod then gets a classification stamp (as above) and is then released to the community.
Testing should be done with all the big ones (Tiles, UMMU, sound, NASSP etc). I know AMSO and the like I have them on a separate install but when I get to building space stations in orbit using XR2, and dragon fly, and uRMS and uCargo and uCGO and various bits and pieces, things for some reason, slowly decay.
In order for developers to be able to identify what collisions their mods might have with others they should check out what aspect of orbiter files they change "e.g. graphics, models, animations etc".
It is a big task but I think that if we do it on a progressive level and also report feedback (e.g. I just tried the new mod and it crashes with X mod) then the feedback is sent to the addon testers of the forum and maybe the classification is changed to reflect this feedback.
In this way we can already implement this unification project now.
Thanks for reading.
comments, etc... say hi
