Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Galemp on October 03, 2015, 11:40:08 pm
-
POW!
Figured I'd repurpose an old topic. I've been playing FSPort (cross-platform, woot) with my 8-year-old stepdaughter and the FSPort multi missions are commingled with the retail ones. There's no way to distinguish them and of course picking an FS2 mission would kill the game.
Is there a way to hide retail multi missions when a mod is loaded? Failing that, can we edit the FSPort multi missions to appear at the top of the list, or identify them as such?
-
Well, we do have a game_settings.tbl flag to not display campaigns and their associated missions in single. Perhaps that same code could be repurposed for this case as well?
-
This should be opened as a request on the SCP board. There isn't a general-purpose solution for this, and it's not specific to FSPort -- it would affect every mod. And neither a whitelist nor a blacklist would be appropriate if you want to allow users to create their own multi missions based on a mod. Solutions can be brainstormed, but at the very least the code should be modified so that loading a mission for the wrong mod does not kill the game.
-
As a temporary fix I was thinking of editing the mission names to identify them as FSPort, at least...
-
Don't edit the mission names or filenames; you'll confuse people who are looking for the old ones. But putting FSPORT at the beginning of all mission descriptions would be a good idea.
-
This should be opened as a request on the SCP board. There isn't a general-purpose solution for this, and it's not specific to FSPort -- it would affect every mod. And neither a whitelist nor a blacklist would be appropriate if you want to allow users to create their own multi missions based on a mod. Solutions can be brainstormed, but at the very least the code should be modified so that loading a mission for the wrong mod does not kill the game.
Wait, how would a blacklist stop modders from creating missions based on a mod and having them included? You blacklist the retail missions and all others, even new ones go through. It seems like... actually nevermind. This is FSPort and I don't have capacity to care.
-
This should be opened as a request on the SCP board. There isn't a general-purpose solution for this, and it's not specific to FSPort -- it would affect every mod. And neither a whitelist nor a blacklist would be appropriate if you want to allow users to create their own multi missions based on a mod. Solutions can be brainstormed, but at the very least the code should be modified so that loading a mission for the wrong mod does not kill the game.
Wait, how would a blacklist stop modders from creating missions based on a mod and having them included? You blacklist the retail missions and all others, even new ones go through. It seems like... actually nevermind. This is FSPort and I don't have capacity to care.
Yes, you never miss the opportunity to say how much you don't care, do you? :rolleyes:
Never mind that I said this affects every mod, not just FSPort. The reason is that there is no way to blacklist every conceivable mission. A user might have some multiplayer missions in his data directory that he created himself, or that he downloaded, that aren't listed in the FSPort blacklist. Or he might be playing a mod release that doesn't have a blacklist (let's say Blue Planet or Inferno). Either way, he still risks loading a mission that isn't compatible with that mod.
That's why I said the proper solution should be in the code. Ideally the mission listing should detect somehow that the mission isn't compatible. If that can't be done, then at least loading an incompatible mission shouldn't crash the game.
-
The reason is that there is no way to blacklist every conceivable mission. A user might have some multiplayer missions in his data directory that he created himself, or that he downloaded, that aren't listed in the FSPort blacklist.
If a user is leaving missions in their bare data directory instead of a mod folder, that's entirely their fault and a really stupid reason for not having a blacklist of the retail FS2 multi missions which are known not to work.
That's why I said the proper solution should be in the code. Ideally the mission listing should detect somehow that the mission isn't compatible. If that can't be done, then at least loading an incompatible mission shouldn't crash the game.
I agree that it shouldn't crash the game, but unless you can actually determine that they're incompatible and prevent them from showing up in the menu in the first place without actually loading them, a blacklist would be superior from a UX perspective.
-
I think you'd need to partially parse the code looking for weapons & ships that don't exist, and then ensure that you gracefully bail with a warning message instead of crashing. But that's only part of the issue, you could have mod table settings that'd seriously alter the behaviour of a mission, e.g. full colour head anis, alternate sexp behaviour, and probably others that I can't think of off the top of my head. To have a better solution FSO would need to be more aware of what mod it's currently running; or you could flag each mission with the mod directory it was found in.
-
I'll split and move this to the SCP forum.
If a user is leaving missions in their bare data directory instead of a mod folder, that's entirely their fault and a really stupid reason for not having a blacklist of the retail FS2 multi missions which are known not to work.
Where is he going to put multi missions based on the bog-standard FS2 other than in data/missions? I suppose he could create an extra mod folder just for that, but that's an extra step that most people won't take.
But you make a good argument about the blacklist; a solution doesn't have to be 100% foolproof for it to be useful.
-
Well the biggest problem with a code blacklist is how the hell it can tell the difference between, let's say, the media VPs and Blue Planet? Both are mods but one shouldn't run FS2 missions while the other absolutely should.
-
How about mods need to configure (in game_settings.tbl?) what other mods and/or retail ~directories~ that they compatible with? When you find a mission (after first making sure that parsing it won't crash FSO no matter what you find) then toss out any which aren't in the correct directory, or in a VP in said directory? (or maybe more intelligently, do that check before loading the mission)
i.e. FSPort with 2014 mediavps could have:
valid_mod_mission_dirs = fsport-mediavps_2014, fsport
BP:WiH could have:
valid_mod_mission_dirs = blueplanet2, blueplanet, <RETAIL>
That could require a reasonable amount of work though, I can't remember if it's possible to find the full path of a file within a VP or not, but I'm fairly sure that you can easily find the full path of a file not inside a VP.
-
Well the biggest problem with a code blacklist is how the hell it can tell the difference between, let's say, the media VPs and Blue Planet? Both are mods but one shouldn't run FS2 missions while the other absolutely should.
The idea -- at least as I understood it -- was for each mod to have their own blacklist, something like multi_blacklist.tbl. It wouldn't be in the code itself. But as mentioned above, it would require each mod to add this file to their distribution.
How about mods need to configure (in game_settings.tbl?) what other mods and/or retail ~directories~ that they compatible with?
Now this is an interesting idea. It doesn't need to be limited to multi missions either; it could be used in the Tech Room single-mission list.
-
I like niffiwan's idea, but using a whitelist like that would break every campaign for that mod unless those campaigns included their own whitelist. I think it should instead be implemented as a blacklist, like this:
Invalid mod mission dirs: mediavps*, <RETAIL>
What's that asterisk at the end of "mediavps*", you ask? Well, it indicates that every mod folder beginning with "mediavps" should be included in the blacklist. Thus, the "mediavps*" mod refers not just to "mediavps" but also "mediavps_3612", "mediavps_2014", "mediavps-95603dt", "mediavpsanythingreally", and so on. This eliminates the need to change game_settings.tbl (or whatever file this line is stored in) every time a new version of the MediaVPs is released.
-
If a user is leaving missions in their bare data directory instead of a mod folder, that's entirely their fault and a really stupid reason for not having a blacklist of the retail FS2 multi missions which are known not to work.
Maybe better suited for a new topic, but you're saying they currently don't work at all? Are you referring to the standard multi mission pack? It's of interest to me since I'm currently digging through the netcode.
-
It sounds like the only time that this becomes an issue is when an FS2 mod gets to the point where it can't be turned into a standalone but is so heavily modified that it breaks retail missions. This isn't something that happens often, and at that point, perhaps just simply not loading any root level missions via an option would be enough to suffice? Because at that point, the mod is probably using less retail data than it provides, and anything for that mod specifically should be put within the mod's data folder.
But we're saying that even in this case, there are some missions that do work and some that don't cause crashes, for say, BP, or FSPort? Then include those missions in the mod explicitly. Make a few tweaks to make it worth doing that. Trying to hybridize one mission environment that is mostly broken into another environment the ways being discussed all sound like pretty nasty hacks to me.
-
Maybe better suited for a new topic, but you're saying they currently don't work at all?
He means FS2 multi missions that are known not to work under a particular mod. Not that they are known not to work at all.
It sounds like the only time that this becomes an issue is when an FS2 mod gets to the point where it can't be turned into a standalone but is so heavily modified that it breaks retail missions. This isn't something that happens often, and at that point, perhaps just simply not loading any root level missions via an option would be enough to suffice?
It doesn't have to be heavily modified. AFAIK, all that's necessary to trigger it is to have a ships.tbl or weapons.tbl that doesn't include an asset that the mission requires.
-
And how many mods go so far as to modifying/removing ships from that table, especially with modular tables nowadays?
-
Whenever a mod has lot of ships.tbl entries. We had to remove table entries for The Aftermath to get it to work. Yes, it was based on BP, but there you go.
In case we're still brainstorming, why not have an optional string within the mission file that saves what mod the mission was created under and maybe its dependencies? Then you can blacklist the appropriate mods. (Yes, you would have to add this to a lot of existing mission files, but it's probably the most efficient way to distinguish. You also wouldn't be able to use specific missions from a mod, but that feels like an edge case, anyway)
-
If a mod has that many ships.tbl entries I think the focus of the mod is on those ships, and not the retail ones. Therefore there are probably missions built to use those ships, no? Would you still need to list those retail missions then? Why?
As far as I'm concerned, you start deleting retail data, you lose retail missions. I don't see why it has to be any more complicated than that. If you want to play retail missions, then fire it up without the mods. If you want to play the mods, then play the mod's missions.
The only other solution I can think of here is to find a way to gracefully not allow a mission if its required assets aren't available. Having any kind of list is going to be a nightmare for maintainability reasons, and I personally would recommend against it.
-
Ugh. OK, first thing. Dunno if it happens in Multi, but Single already warns a player if he tries to load a mission that's missing assets. We don't need to code auto-removing those missions from lists because that will make modding worse. Missions that are part of mods under development often have changing assets.
I still don't see what's so wrong about a black list of mission files or blacklist of mission directories like Yarn suggested.
I assume Galemp is looking for something similar to my original request for the game_settings.tbl to ignore campaign files. I've built a mod that's based on MediaVPs and retail data. I use my own ships.tbl, weapons.tbl, everything to trim the fat out of the mod in terms of what's being loaded into the engine. Modders have no way to trim the missions that could be loaded from up the mod's loading path.
FSPort is built on retail data. It changes a lot of crap, and in fact, uses it's own ships.tbl, weapons.tbl, etc. It simply needs a way to do with missions what we can already do with tables. Trim the fat from up the load chain.
All this automated stuff is overkill. If FSO is not warning about bad mission data in Multi like it does in Single, then that should be added. Then add a single mission blacklist somehow just like how we have a campaigns blacklist.
-
As far as I'm concerned, you start deleting retail data, you lose retail missions. I don't see why it has to be any more complicated than that. If you want to play retail missions, then fire it up without the mods. If you want to play the mods, then play the mod's missions.
Yep, I mostly agree, but the devil is in the details. In Galemps user case (multi co-op FSPort "campaign") the issue is it's hard to tell which missions belong to which mod. That's the issue that Yarn's blacklist idea will address, FSPort could easily make a single table entry to ensure that missions in retail & standard mediavps directories would not be shown. I agree that a blacklist or whitelist per mission would suck to keep up to date, but at a directory level (where the directory represents the mod) there should not be any reason to update that table entry once it's created. That should only be needed if the required dependencies change their names, and by adding appropriate wildcards that should be able to be dealt with as well.
If we look at the other use cases, we have single player campaigns and standalone missions, either part of the mod, or user-created. Single player campaigns are already catered for (#Ignored Campaign File Names AND $Campaign File Name:). Standalone missions are rare, but could also be excluded appropriately by the above suggestion.
The only other solution I can think of here is to find a way to gracefully not allow a mission if its required assets aren't available. Having any kind of list is going to be a nightmare for maintainability reasons, and I personally would recommend against it.
I thought that adding graceful failures to the mission parsing would be harder than adding the directory blacklist. However, based on what mjn.mixael just posted, maybe it wouldn't be. I got the impression that selecting the wrong mission in multi caused a crash, and you're talking about modifying our glorious netcode.. maybe all servers & clients could pop the warning about bad assets, and then do what the "master" does (hopefully backout!), but I still feel like this is harder option.
-
I got the impression that selecting the wrong mission in multi caused a crash, and you're talking about modifying our glorious netcode.. maybe all servers & clients could pop the warning about bad assets, and then do what the "master" does (hopefully backout!), but I still feel like this is harder option.
I think, when a mission is selected, all the players' computers try to load it at the same time. Why not modify the sequence so that when the host selects a mission, it is examined (via a bare-bones parsing) for missing ships and weapons. Only if there are no entries missing does it then start to actually load the mission and send a signal to all the clients for them to load it as well.
By tying this code to the Commit button, rather than the loading of the menu, the performance delay is brief and only limited to the selected mission rather than every mission in the list.
-
That still doesn't address the issue. If I want to fire up FSPort multi, there's loads of missions listed I can't use. What, do I have to attempt to load three or four Dogfight missions before I find the right one? And what if we want to agree on a mission first, then find out it's not available? Menu options that aren't available shouldn't be shown.
It seems to me a text file mission blacklist similar to the campaign blacklist in single-player is the way to go. Forget about automation, just list all the retail missions that will be in every FS mod. If there's user-made missions there, presumably the user will be aware of them (just like in the single-player tech room). And as its been noted, anything in the root Data folder is not our responsibility.
-
How about both that mission blacklist and the bare-bones parsing when Commit is hit as a backup to prevent accidental or misguided mission loads?