[Galemp]

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?

[mjn.mixael]

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?

[Goober5000]

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.

[Galemp]

As a temporary fix I was thinking of editing the mission names to identify them as FSPort, at least...

[Goober5000]

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.

[mjn.mixael]

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.

[Goober5000]

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?

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.

[AdmiralRalwood]

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.

[niffiwan]

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.

[Goober5000]

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.

[karajorma]

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.

[niffiwan]

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:

Code: [Select]

valid_mod_mission_dirs = fsport-mediavps_2014, fsport

BP:WiH could have:

Code: [Select]

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.

[Goober5000]

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.

[Yarn]

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:

Code: [Select]

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.

[jg18]

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.

[chief1983]

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.

[Goober5000]

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.

[chief1983]

And how many mods go so far as to modifying/removing ships from that table, especially with modular tables nowadays?

[Cyborg17]

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)

[chief1983]

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.