Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Kazan on July 21, 2006, 08:48:26 pm
-
who's working on PXO? taylor? how are you planning on supporting mods in PXO?
-
It's still open ended right now, but I'm working it out in my head. I've got quite a few other things that I need to code on before getting back to PXO though.
Just getting the server side fully ported/portable is still my primary work for PXO. The client/host side upgrade to handle all of my proposed multi changes (dynamic server client version bumping, automatic checks/testing for compatibility and capability, etc) will come after I get all of the stuff fully ported cross-platform. PXO is a ****-load easier to make big-endian compatible than FS2NetD is, but it's still got its quirks, and the server side is an almost 100% from-scratch rewrite.
I want to make mods parts of the compatibility/capability checking. The host will advertise what capabilities it needs (ie, mission/mod in use, number of ships/weapons that need to be supported), the host version will be dynamically bumped based on those capabilities. Each capability will be put together to form a particular version string. When the client gets this particular version string (in the broadcast packet) it will see if it also has those abilities. If so then the host is made available. Per some discussions with multi users previously, all hosts will be listed if a client supports the dynamic versioning, but if the client doesn't support one or more capabilities for that host then it will be greyed out and unusable.
The PXO server itself won't have much, if anything, to do with this. The PXO server is only going to offer tracker capabilities for user sign-in/stats, chat, and game tracking. The mod features will be totally on the FS2_Open side so that we don't have to keep upgrading the PXO server with new capabilities, just get it working and keep it working.
-
dynamic versioning? do i follow you correctly as in that means changing mods on-the-fly?
-
Well, it would allow compatibility changing on-the-fly. That could mean mod changing on-the-fly in the future, but that's more of a CFILE issue that's also on my todo list. On-the-fly mod changing would go along with the advertising of what it needs to be compatible. The on-the-fly version changing is more to allow you to play a retail compatible mission with retail clients/hosts, then host a non-retail compatible mission, without restarting, and automatically ban clients which have no hope of being compatible.
Part of all of this is the new hacked tables support. Instead of tbl checksums it will checksum the ship/weapon entries after they have been loaded and that will be part of the capability checking, so that different versions of the same mod can still reject older/incompatible clients or hosts. Eventually I'd like to have tbm sent over the wire to make up for the compatiblity issues, and allow on-the-fly changing for those, but I'm already reaching for the moon here already so I'll wait until after I some a lot more working code before I start on something like that. :)
The tbl entry checksum thing is basically the same as the new testing I'm doing in the pilot file code. The new pilot files will tag each campaign used with checksums of entries for 5 ships and 5 weapons which are randomly selected. If you try to load a campaign and it doesn't pass the test then the pilot code will automatically prevent you from using that campaign, to avoid data corruption, and try to offer you a different campaign which is compatible with the data in use at that moment. The on-the-fly mod changing will hopefully be available for this too (the original plan anyway) so that you will be able to switch mods without restart in order to play the correct campaign.
-
what happens when mods release updates
-
when browsing servers and you encounter one that is not compatable with your current setup (meaning its greyed), you should still be able to select that server (not connecting to it), and get info about what mods are being run, such as what version you need and wehere to download it from, ect. perhaps integrate this into mod.ini. include a server message in the file that will be sent as part of the brodcast packet, which identifies the mod version, what media vps should be installed to run it, what build, and a url to the offitial mod site. modders are then responsible for keeping their inis up to date :D
-
Erg, I hope not. I dislike mod.ini immensely, it's cross-platform incompatible and can't be loaded into VP Files. :no:
Unless the new launcher supports it...although I still dislike having another text-based format to support, when we already have a perfectly good (and relatively consistent) TBL system.
Being able to update mods based on the server's version is one of my wet dreams for Freespace, though.
-
The mod.ini files will be supported with the new Launcher, but it will prefer the new ini format instead. The new format will integrate options, settings and mod info into one file, be cross-platform, work out of VPs, be commulative, be supported by both the game itself and the launcher, and I hope to teach them to sing too. Well... maybe not that last part. :)
I hate mod.ini files, they were messed up since their inception, so other than supporting them for reading mod order from the new Launcher will pretty much ignore them.
And the problem with using TBL is that we have to make the launcher support it too. The ini code is simple, already in the game (used for anything not-Windows), and easy to add to the launcher (but not that crap that it has now).
-
There are some nice things in the current mod.ini system but I agree that there could have been lots of improvements. Having the ini contain a blurb about the mod is quite a nice idea for instance.
-
i really havent bothered using the mod.ini system. i never bothered learning to use it cause i like to keep my mod simple. still there needs to be a sistem in place, to tell a user what files they need to play on a particular server.