Hard Light Productions Forums
Hosted Projects - Standalone => The Babylon Project => Topic started by: FUBAR-BDHR on September 09, 2008, 04:47:14 pm
-
As some of you may have noticed we've released some rules and guidelines we would like everyone to try and follow for any new stuff. http://www.hard-light.net/forums/index.php/topic,56303.0.html
I figured there would be some questions, comments, and suggestions so I'm starting this thread for discussion on them.
-
I think it's a good naming convention system. I applaud it :yes:
.vp naming is down to authors discretion though i assume so long as the mod folder/.ini system is applied?
-
so long as the mod folder/.ini system is applied?
The last time I checked, it isn't. Since usually there aren't any new ships or table changes. Just dump the .vp to the root folder and the campaign will show up in-game.
-
We're trying to avoid additional stuff in the root folder. Lobo you should know all too well that extra files in there make troubleshooting harder. The only things that should be added to the root are multiplayer .vp files.
I'd suggest the .vp be naming be similar to the mod or campaign naming.
-
.VP contents will follow the convention. :yes: and go in a sub-folder alongside a mod.ini. No worries.
-
We're trying to avoid additional stuff in the root folder. Lobo you should know all too well that extra files in there make troubleshooting harder.
I know that with FSO using mod folders is a must. But at least back when I actually played TBP (roughly six months ago), none of the mods contained any new ships, weapons or tables (because no one wants to defy B5 canon), and therefore new campaigns could be "installed" just by placing the .vp(s) to the root TBP folder. Nothing wrong there. And I seem to recall actually reading instructions on some campaigns (possibly Drums of War) stating that putting the .vp files to the root folder is the correct way.
Yes, using subfolders would do the trick as well. And maybe minimize the cases where a TBP player decides to try FSO and manages to **** up his FreeSpace with improper mod installation. And definitely if an increasing amount of TBP mods actually change certain aspects of the game, instead of merely providing new campaigns.
Do watchu want.
and go in a sub-folder alongside a mod.ini.
Umm, why would we need mod.inis? As far as I know, there are no "MediaVPs" for TBP. Nor anything like FSPort.
-
Multiplayer. . . Easier to disable extra stuff that would break it.
-
I've a specific question about this:
I'm currently working with the model of the EA Nova and have begun adding glowpoints (the current model has none) - and I'll see what I can do about the Moment Of Interia
do I really have to go this as "EA Nova#mod"?
-
If you put the new EA Nova model in a mod, it will override the original model. But only if the models have the same name and ship class.
-
I've a specific question about this:
I'm currently working with the model of the EA Nova and have begun adding glowpoints (the current model has none) - and I'll see what I can do about the Moment Of Interia
do I really have to go this as "EA Nova#mod"?
Yes it has be a mod. For the best it should be a different .pof name. You have to look at it from the big picture. What if someone else want's to make some other changes and call it EA Nova as well? Now there are 3 different one, then 4, then 5. Without different names they all end up stepping on each other. This way the FREDder can choose which one he wants to use and it doesn't have to possibility of breaking any existing missions.
BTW that doesn't mean you can't put it your existing mod directory. It also doesn't mean that for EACW (which will need to be in a mod directory) you can't have a .tbm that replaces it EA Nova with the new .pof as it will only effect your campaign. It might cause some confusion though so if you can keep it consistent it would be a good idea.
-
What if someone else want's to make some other changes and call it EA Nova as well? Now there are 3 different one, then 4, then 5.
exactly.
Naming conventions are extremly important or we will start seeing campaigns with "mission 1", "mission 2", "mission 3" again :no: SUPPORT HELL!!!
-
I'm a bit confused as to what exactly has been decided, but the course that always made seance with me was, no changes to the existing main release, unless said change is to fix a content bug, and in that case the main release would be amended eventually.
for things like upgraded models (as opposed to fixed models which the end user would not immediately notice but might not notice the problems the no longer broken model no longer has) I figured there would be a mediaVP type solution where there is an overwriting mod which is backwardly compatible with the main release. and this would take on the main community development.
-
Nope that was never the plan. The mediavp analogy was probably a bad example but it's the only one we have. This new directory is for validated content for multi only but can be used by anyone. Any model updates need to be done as a separate mod. Nothing says you can't put more then one model into a directory. Now if they are useful for multi we may ask the developer to allow it to be incorporated into the multi directory.
I'll be updating the rules thread with definitions for all these terms as soon as I get the time to type it up. Probably won't be until tomorrow as I'm blowing off some steam tonight and hitting the bar.
Remember were still sorting all of this out so give us a little time. In the meantime as long as you keep stuff in mod directories and use unique file names you should be fine.
-
well like I said, new ship models would be in a mod, a mod designed not to effect game play, but would take precedence over the older files, and being a mod would need to be activated like one. any missions made with the main files would be compatible with the new ones in the upgrade mod. being in a mod would mean that they would only be activated via the user actively selecting it. overriding the original materials means they integrate seamlessly and are backwards compatible.
I guess I'm talking about something completely different than you and what these rules are about here.
and as for bugs in the core files?
-
the absolute priority is an yet unamed "update" mod.
Nothing new, nothing fancy, nothing shiny, just plain old fixing.
-
I'm a bit confused as to what exactly has been decided, but the course that always made seance with me was, no changes to the existing main release, unless said change is to fix a content bug, and in that case the main release would be amended eventually.
for things like upgraded models (as opposed to fixed models which the end user would not immediately notice but might not notice the problems the no longer broken model no longer has) I figured there would be a mediaVP type solution where there is an overwriting mod which is backwardly compatible with the main release. and this would take on the main community development.
that's just why I asked....
so I'll be making nova_mod ...
-
For the best it should be a different .pof name. You have to look at it from the big picture. What if someone else want's to make some other changes and call it EA Nova as well? Now there are 3 different one, then 4, then 5. Without different names they all end up stepping on each other. This way the FREDder can choose which one he wants to use and it doesn't have to possibility of breaking any existing missions.
Uh, I would strongly disagree with that. If they're all the same ship, they should all be the same model. Otherwise you end up in a situation like DLL hell.
-
OK but if person X has 5 HTL models in their mod including a Nova and person Y had 3 HTL models including a Nova in their mod and person Z wants to use 3 models from X and the Nova from Y in their campaign without them being named differently then there is no way to differentiate. With the different names you can easily choose from EA Nova#X EA Nova#Y and the original EA Nova. The player is none the wiser.
-
Why would there be more than one Nova model? The way the regular mediavps work is that all changes are merged into one single standard.
If somebody wants to make campaign-specific changes to a model (like what ST:R did with the Faustus) then he should copy the standard model and make the changes so that they only apply to the one campaign.
-
But this isn't the medaivps and there is no project to manage it. Each individual uses can mod. If someone doesn't like a particular model they can make a new one. It's up to the FREDder to choose what he want's to use. The only thing we are managing is the directory for validated multiplayer content.
-
Except that's sort of the point of a dedicated forum for discussing public mods. If multiple mods are in conflict, there should be a community-agreed procedure to merge them, or to pick one over the other.
(Please note, this is only for mods that are in direct conflict, such as one Nova with glowpoints but bad path data, and another with good path data but no glowpoints. If, for example, one person makes a 50-turret Nova and another makes a 100-turret Nova, I agree that those should be separate.)
The public development forum does not need to be (and shouldn't be) an authoritarian gateway for mods, but it should foster a modicum of responsibility and discipline. Otherwise you end up with a free-for-all.
-
this is exactly how the mediaVPs started, a whole bunch of different people started makeing upgraded models, someone had the bright idea to merge the different sets into a single package.
if person A had NovaX and person B has NovaY, then unless the two mods are merged they won't see each other no matter what the models are named, as long as the mod is installed properly (and not overriding the main install files WITHOUT having the mod invoked) there will be no conflict. if you want to make a mod derived from someone else's mod you either make it a sub-mod (of a sub-mod of a mod) or you just grab the parts you want and make your mod stand alone.
keep in mind we are talking in the realm of mods of TBP which it's self is a mod, so this sort of complicates the language.
just keep in mind if someone releases a stand alone model, it should be considered an incomplete (WIP, partial) mod, simply by virtue of the fact that it isn't packaged in a mod package. it should be stated that incomplete mods need to be removed before any support can be given.