Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ShivanSpS on March 29, 2011, 01:14:32 am
-
Ok, its 2am here and i work at 9am haha...
I was thinking about some things that i always see as a weak points.
1) Pilots... the retail behavior of having to create a new pilot for every campaign, or mod... this is very frustaing at most... 2 years ago, i friend of mine used to play fs2 witch me on the same pc, we ended having up to 37 pilots! because we dint wanted to lost progress in other campaign/mod...
It cant be a single pilot, using a array to save progress to every different campaign? so we can switch campaigns whitout losing any progress in another.
2) A Pilot when ends a campaign, and them it it decided to play it again by reset it, all missions should be still be visible on tech room... after all, he already played the missions... there is no point in hidding them (yeah i know there is cheat to see all missions).
3) the mod system... file loading, can be changed? mod system should be automatic, with the increasing number of fan based stuff, the current mod system seems to be weak. We end having a mess in the fs2 folder rather quickly, and is a nighmare for new players too.
-
Ok, its 2am here and i work at 9am haha...
I was thinking about some things that i always see as a weak points.
1) Pilots... the retail behavior of having to create a new pilot for every campaign, or mod... this is very frustaing at most... 2 years ago, i friend of mine used to play fs2 witch me on the same pc, we ended having up to 37 pilots! because we dint wanted to lost progress in other campaign/mod...
It cant be a single pilot, using a array to save progress to every different campaign? so we can switch campaigns whitout losing any progress in another.
There is new pilot code. Why don't you go ahead and test it? (http://www.hard-light.net/forums/index.php?topic=73257.0)
2) A Pilot when ends a campaign, and them it it decided to play it again by reset it, all missions should be still be visible on tech room... after all, he already played the missions... there is no point in hidding them (yeah i know there is cheat to see all missions).
*Shrug* Not a big deal.
3) the mod system... file loading, can be changed? mod system should be automatic, with the increasing number of fan based stuff, the current mod system seems to be weak. We end having a mess in the fs2 folder rather quickly, and is a nighmare for new players too.
Please elaborate. What do you mean by "mod system should be automatic"?
-
3) the mod system... file loading, can be changed? mod system should be automatic, with the increasing number of fan based stuff, the current mod system seems to be weak. We end having a mess in the fs2 folder rather quickly, and is a nighmare for new players too.
The only way i can see to make the mod system more user friendly is to have the launcher identify mod folders and generate a selection list, tbh though the current system work fine for the average user
-
The only way i can see to make the mod system more user friendly is to have the launcher identify mod folders and generate a selection list, tbh though the current system work fine for the average user
Which is something that wxLauncher is already doing.
-
Right now I think someone just starting really needs to read through the beginner instructions posted on the forums, which is not a bad thing IMO.
-
For #2, just use a new pilot? Load the old pilot when you want them in the techroom and the new pilot when you want to play the campaign over.
For #3, he might mean as far as multiplayer goes, that necessary resources could be pulled from the host or server. Some games do support this, yes, and I'll admit it would be a nice feature to have if we could pull it off. But we've got some other issues to get out of the way before that would be feasible.
-
@chief @2 that's the problem, the need to create more and more pilots, one pilot has to be enough, since you also need to think that maybe there are more of 1 person playing in the same, pc, personally y had 1 pilot per mod... 2 persons doing the same, the things get messy really fast. I gonna try out the new pilot code :)
yeah that another thing. But i dint say anything because most games don't even support map transfers to people that dint has them.
About a automatic mod system, what i mean is something like, removing the mod tab, engine loading all mission and campaigns of every mod installed, and when you select one campaign or a mission in the tech room, game will load the files needed, according to what the mod.ini of that selected campaign or mission indicates. This will allow a much better dynamic multiplayer and singleplayer with mods gameplay, since it will allow to change mods on the go, inside the game. I a multiplayer we could trying to save the Galatea in one mission and trying to get the Bastion to blow up the node at next.
But the loading of files need to be dynamic, right now it load all files at start and it cant be changed in game.
Sorry about my English... i have to admit, freespace has been the only thing teaching me English since i was 12 year old :P spell check here makes the thing a little easier :)
-
About a automatic mod system, what i mean is something like, removing the mod tab, engine loading all mission and campaigns of every mod installed, and when you select one campaign or a mission in the tech room, game will load the files needed, according to what the mod.ini of that selected campaign or mission indicates. This will allow a much better dynamic multiplayer and singleplayer with mods gameplay, since it will allow to change mods on the go, inside the game.
But the loading of files need to be dynamic, right now it load all files at start and it cant be changed in game.
Not going to happen. The current system is good and straightforward enough. Also, you are severely underestimating the amount of stuff that would have to be changed in order to make something like your proposal work. So it's not going to happen.
-
:jaw: Ship and weapons table overload just flashed before my eyes, followed by conflicting table entries.
Tables are compiled and loaded before the intro movie plays, to change this would i imagine require a heavy overhaul of the table system and introduce increased transition times between screens due to loading, also things like custom main hall's wont load
-
Why can't the FSO engine be made to "unload" the files it uses? So, when someone wants to use a different mod, they select it in the main hall, FSO says the current mod will be unloaded from memory, this will take a min or two, you sure? You hit yes and it un-loads all data and then re-loads based on mod.ini.
So, e.g. switching from MediaVPs to FSPort, FSO has already loaded the FS root directory and MediaVPs, now it dumps them and loads FS root + MVPs + FSPort cause that's what FSPort's mod.ini specifies.
Would that be a pain to code or not really?
-
It's a pain to code, there are literally dozens of places where things would have to be changed, then we'd have to make sure it all works....
It's just far too much effort for too little a gain; please bear in mind that there are only 6 or 7 active coders in the SCP right now, and we all have different things on our plates, and stuff we want to do with the engine. It's quite the achievement that we're making the progress we do manage.
-
please bear in mind that there are only 6 or 7 active coders in the SCP right now,
I didn't know ... sorry, I wish you had more help. :sigh: Thanks for all the SCP goodies, though! :)
-
i know, i was not demanding to make anything :P i just saying that those are the weak point i always sought in the game.
i only know C and a bit of C++, so i cant do much, the thing is i work 12 hours at day and i have university after that... but ill like to look intro the code myself.
-
Well, then keep in mind the following facts. FSO is an old engine. The source documentation is sparse at best, actively misleading at worst. It takes a skilled, enthusiastic developer about 2 to 3 months to get to a point where he can contribute more than trivial bugfixing.
-
The new pilot code will eliminate the need for most 'duplicate' pilots. Multi and Single player will be one pilot, and you should be able to seamlessly change from one campaign to the next. Once we get FSO to use the %APPDATA% folder on Windows, you won't need to worry about users sharing pilot files either. You'll just change who is signed on to the computer, and then you'll all have distinct pilot files. I think that'll pretty much handle most of the issues then. We're not going to work on stopgap solutions when these should already be right around the corner.
I will admit, mod switching would be cool. It would be a large undertaking by any coder interested in doing it though, but I imagine it would work similar to that behavior in Battlefield 1942. Keep in mind, this would only work for 'mods', and not full-on game switching, like Diaspora to FreeSpace, even if it ever were possible. With the way the community works now though, this would really only help multiplayer, and these guys generally know how to run the right game when they want to play. To really help that group, without reloading resource sets, what I think would be easier to implement is a verification to make sure that the users joining a game have all the resources the host has enabled, and if not, it could restart with the right mod command line options passed, and then perhaps rejoin the lobby (or game-in-progress if we get that fixed) automatically. This would dictate that all mods are installed in standard folder names, but we're working towards this end anyway so I think a solution like this might be possible in the future.
-
The new pilot code will eliminate the need for most 'duplicate' pilots. Multi and Single player will be one pilot, and you should be able to seamlessly change from one campaign to the next. Once we get FSO to use the %APPDATA% folder on Windows, you won't need to worry about users sharing pilot files either. You'll just change who is signed on to the computer, and then you'll all have distinct pilot files. I think that'll pretty much handle most of the issues then. We're not going to work on stopgap solutions when these should already be right around the corner.
I will admit, mod switching would be cool. It would be a large undertaking by any coder interested in doing it though, but I imagine it would work similar to that behavior in Battlefield 1942. Keep in mind, this would only work for 'mods', and not full-on game switching, like Diaspora to FreeSpace, even if it ever were possible. With the way the community works now though, this would really only help multiplayer, and these guys generally know how to run the right game when they want to play. To really help that group, without reloading resource sets, what I think would be easier to implement is a verification to make sure that the users joining a game have all the resources the host has enabled, and if not, it could restart with the right mod command line options passed, and then perhaps rejoin the lobby (or game-in-progress if we get that fixed) automatically. This would dictate that all mods are installed in standard folder names, but we're working towards this end anyway so I think a solution like this might be possible in the future.
cool... i love the new pilot code already :)
yeah, a auto switch for mods will be great for multiplayer, single player a has very small advantage on this. i agree with that.
Imagine multiplayer where you have all multiplayer missions of every mod installed on the list, and the game switching mods automatically.
BTW, i also like your solution, maybe there is a "restart way" to workaround this.
I known the game has no problem in having two instances loaded at the time, maybe its possible when you select a new mod to show up a "loading mod" screen, and keep focus on it, in the loading the game just switch mods like launcher do and launch a new instance of the game that loads with the new mod, when the 2nd instance is fully loaded, just close the first instance and set the focus to the second one.
But maybe is easier to do it from outside? with new code instead of modifying the existing one?
It is only for multiplayer, i think the best option is to completely change the way that multiplayer works, made it available only from command line arguments. Then a make a new app to manage multiplayer from outside the game. The app should list all multiplayer missions of every mod, that app should also be able to transfer mods to player that doest has them and when the host launch a a mission that will actually launch the game with the correct mod selected, auto generate multiplayer session, join players and procced to load mission.
-
I known the game has no problem in having two instances loaded at the time, maybe its possible when you select a new mod to show up a "loading mod" screen, and keep focus on it, in the loading the game just switch mods like launcher do and launch a new instance of the game that loads with the new mod, when the 2nd instance is fully loaded, just close the first instance and set the focus to the second one.
Which is actually the stupidest way to do this. You're the one wanting to play the game on low-end machines, and now you want us to spawn a second instance of it? Not a good plan, to say the least.
Also, you are seriously underestimating the problem. This is not an easy task. It will not get done anytime soon. Because, after all, the existing system works well enough for most people.
But maybe is easier to do it from outside? with new code instead of modifying the existing one?
It is only for multiplayer, i think the best option is to completely change the way that multiplayer works, made it available only from command line arguments.
Yeah, no. Not a good plan. Really not.
Then a make a new app to manage multiplayer from outside the game. The app should list all multiplayer missions of every mod, that app should also be able to transfer mods to player that doest has them and when the host launch a a mission that will actually launch the game with the correct mod selected, auto generate multiplayer session, join players and procced to load mission.
Which would make the whole thing even more complex than it already is. Also, "transfer mods to players who don't have them"? Are you crazy? You do know that the big mods, the ones that people are actually making multiplayer missions for, are in the multi-gigabyte download range? That's not something you can download on-the-fly, really not.
In short, you have a lot of preconceptions about what is and should be possible in FSO, which are basically all wrong. Once you get to know the engine from the inside, you will hopefully see why that is. Until then, I ask you to please listen to us coders (who know this stuff better than you) when we say something is impossible, or impractical.
-
just a thought, how hard would it be to have the game launch a new instance of it's self with a different set of command line options, and then shut down?
-
That specifically shouldn't be too difficult. Figuring out the right options is the harder part I'd imagine.
-
Still seems like a hack though...
-
Then there's the issue of going through all directories that could potentially be mods, looking for campaign files, building a list of settings that would need to be applied, parsing all appropriate mod.inis..... It just sounds to me like a lot of potential overhead for little gain.
-
I think that with some of the other framework changes we're already planning to make, it might become a bit more feasible than it currently is. If you can at least assume that all users should have their mods in folders with identical names, you would only need to fire up the same -mod command as the host. If/when we eliminate most manual mod installation, this should be ok to assume for the most part. Anyone without standard mods installed with the right path names would just be blocked by the host, unless the host has turned off the check for proper mod setup.
-
i wouldn't mind having the mod selection code built into the engine so that were not dependent on a launcher or command line to set mod. sorta have a screen before pilot selection that lets you choose your mod, then bring up the pilots list. this would pretty much run before anything is actually loaded (loading everything then unloading what you dont need is insane, my fs2 dir is huge, and i dont even have any major mods installed). mod.ini would be replaced by mod.tbl, many of the mod specific command line options would be set by that table. the game would scan for those to find mod folders. then use data in that table to create an entry in a list of mods. then of course you would have the whole interface to worry about and some settings would likely need to be made before setting a video mode. if something like that were to happen i think it would best be a popup window sorta like the debug spew. of course i can see how this kind of feature would severely complicate everything.
-
That, I think, is a more workable approach.
-
i wouldn't mind having the mod selection code built into the engine so that were not dependent on a launcher or command line to set mod. sorta have a screen before pilot selection that lets you choose your mod, then bring up the pilots list.
One fairly plausible way to do that would be to merge the code for a portable launcher into FSO.
At present the launcher runs FSO, which writes a file (possible settings) and exits, then the launcher writes an options file and calls the FSO executable - if they were actually bundled together then this actually gets easier as it wouldn't need either file but could pass the (possible) options directly back and forth using the existing FSO methods.
That may be worth looking at once wxLauncher is 'feature complete', but probably not before.
-
The git system gave me an idea for this recently too. Basically, we could have something like mod signing. A mod would simply be released with a list of files it contains, and their signatures. The compilation of these signatures would also become one signature, the mod's own signature. Therefore, a particular release of a mod would have one unique number. So, FSO could scan all mod folders for this signature set, and immediately tell if files were tampered with, at least without re-adjusting all relevant signatures in the file. You also wouldn't have to worry so much about folder names for mod installs, you'd simply need to find the folder with the right signature. FSO would be able to tell if any files it has loaded are not part of a signed set. If it believes the files are valid, the next step to joining a multiplayer match would be to make sure the signatures themselves match what was on the host. You'd only need to send one signature at first to cut down on handshakes, and if it doesn't match up, the client could ask the host for the full set of signatures and what mods they were tied to. Then the client could try to see if those signatures were available, in what folders, and reboot with the right mod options loaded.