[DaBrain]

I know - code freze, but I'd like to know a few things.

There are some features I need for Shadows of Lylat and I'd like to know wether these will be ever possible, or not.

First (again) ANI, EFF support for glowpoints. That would make some things a lot easier for us.

The second one is a bit more specific. Is it possible to disable a launcher setting for a single mission, without making the player disable it and restart the game?
I wouldn't mind if the game started again automatically.


Third (and probably most intersting one for other mods) question.
Is it possible to use something like "priorty data folders"?
There are some sounds and effects, that are always the same for all missions. Like the player ship sound.
We really need to change some of these files for some missions.

Possible example:

You know SoL will feature ground missions. Well, lets say we want to use the motion debris for space missions, but not for gound missions. The second idea is one solution, but using another data folder, that has a higher priority and some empty motion debris ANIs, is the other solution.
(In fact, this is about way more important content than the motion debris.)


Don't misunderstand this. Those may look like requests, but they are not. I just have to know what is possible, when I work on the content and the plans for SoL.

We'll probably find a way around a few problems, but it will lower the quality of the mod.

[karajorma]

If you can do number 2 you can do number 3.

[DaBrain]

You mean by switching the mod directory?

Yes and no. I don't want to replace all files, but a few of them. I'd have two directories with mostly the same files. Pretty wastefull.

But it works for stand-alone mods...


I'm not saying SoL will be stand-alone, but I think the thrid point just lost a lot of importance.

[karajorma]

No need to copy the entire mod directory. What you'd do is have a folder called Starfox and a folder called StarFox_Planetary_Assult. Stick all the planet specific stuff in that folder and include a mod.ini file that uses the main Starfox folder as your secondary mod. Everything in the assult folder would now have higher priority than anything in the main mod folder.

Once you're finished simply swap back to the main mod.

[DaBrain]

Makes sense. Yes, that's great.

@Coders Forget about the third point.

[WMCoolmon]

Originally posted by karajorma
No need to copy the entire mod directory. What you'd do is have a folder called Starfox and a folder called StarFox_Planetary_Assult. Stick all the planet specific stuff in that folder and include a mod.ini file that uses the main Starfox folder as your secondary mod. Everything in the assult folder would now have higher priority than anything in the main mod folder.

Once you're finished simply swap back to the main mod.

No.



Actually, it's not that bad of an idea. I just wanted to go for the imposing response thing.

But AFAIK changing the -mod commandline would involve reinitializing the cfile system, as it is now, if I understand correctly. That would be very messy.

*slides thread over to taylor*

[DaBrain]

Originally posted by WMCoolmon

 That would be very messy.

No good...

I don't want anyone to go through much troubble.

So changing the -mod line is complicated...

I guess deactivating other launcher flags for one mission only is just as complicated.

[karajorma]

Originally posted by WMCoolmon
But AFAIK changing the -mod commandline would involve reinitializing the cfile system, as it is now, if I understand correctly. That would be very messy.

*slides thread over to taylor*

I can't imagine it being that much messier than activating any other command line parameter at random. That's going to be crashalicious unless you have some sort of restart involved in which case cfile would be reinitialised anyway.

[taylor]

I'm getting way ahead of myself here since I have zero time to do this but I *think* it may be possible.  CFILE is initted with a series of roots in which you have mod0 and root0 mod1 as roo1, etc., the game directory taking a root and VPs taken roots.  Everything in the various roots is cached to allow fast lookups without having to hit the disk.  Originally though it always hit the disk for root0 until I changed it to cache most files and only hit the disk for certain directories which can receive new files during game play.  This is basically considered a non-init directory since it's contents can change over the course of a single game play.

Originally, when I was working on the icculus.org version and trying to get CFILE to see ${HOME} dirs as root0, I added a second non-init directory for root1.  I did this because of behavior I saw when looking for files in that later root.  It was totally user error though since the files weren't in the proper directories and so didn't get cached.  That's why a disk search was the only way to do it.  But this was done in a way that one function was modified and one was added to handle the second non-init root.  cf_find_file_location() can be modified like it was before to hit another non-init root before or just after root0.

So I guess the basic idea is to have that non-init directory set by a mission, when set it will get searched before root0.  When the mission is over the non-init variable can get reset to NULL and it will skip searching after that.  Anything in this non-init directory would get searched first when it's set.  This will only work properly with one directory so the first person who asks for it with multiple directories will get slapped.  Also it would have to work in a known and fixed location which would be subject to cross-platform issues, ie. in a directory in the moddir that is root0.  Second thing is that it won't work with files inside of a VP.  Anything existing in a VP will have to be initted and then it gets really tricky since we almost have to change everything to get the search order correct.  Of course anything outside of a VP is subject to filesystem rules so case sensitivity comes into play (all directories have to be lower case, file case has to match a particular thing, etc).

If those conditions are ok then the feature would take maybe and hour to code in.  If not then I don't really know what to suggest since doing this another way could cause some pretty serious problems or a rather large amount of work if it's found to be possible.

[DaBrain]

Actually  we could need more than one other directory, but that's really not important.

*gets slapped*

One alternative directory is essential for the mod. The other ones are not important at all.

I can give you more details via PM if you want.


It looks like I'm saddeling you with all my requests...

Thanks, you're helping us to make new things possible.


I was thinking about this for a while. This could be used for FS2 too. Especially for nebula missions. New, dull sound effects, damped sun graphics and nebula ANIs instead of motion debris.

If I find a coder to alter this in the FS2 nebula missions, I'll work on the graphics and maybe on the sounds too. (Still working on my sound skills... )

[WMCoolmon]

IMHO it would be better to make a list of the stuff you want changed on a per-mission rather than per-mod basis and make a list...from what taylor said, the limitations are that you get a messier mod directory and can only switch out one set of files.

Plus it would help loading speed if it were possible to check if it's necessary to reload a file, instead of doing it every time in case people change it with the -mod changing command line parm.

If we were going to implement mod switching, I'd much rather see it be done automatically from the campaign screen.

[taylor]

Wait, had an idea... with minimal changes (more than the other method but not too bad) we could possibly have cached VPs get preferential searching.  Basically they would get loaded on init just like other VPs but you would name then so that they would come last in the search order.  So you would have your primary mod VP of files, "a_best_mod_graphics.vp" and then "b_best_mod_graphics.vp" where the second one would some modified content which exists with the same filename in both VPs.  During mission parse it would set one or more VP filenames which we then figure out in CFILE and give first order VP searching.  root[0] files on disk (the ones not cached) would still get searched first but we could do a little magic with the VP search order.

This would invalidate any platform issues, not produce any extra speed decreases, not make the mod dir messy, and allow for multiple file search orders.  Plus you wouldn't have to produce a special VP just for replacement stuff since it could contain talking head animation, voices, music or whatever and those things would still get use regardless of search order.

Does that better address the needs that you have?

This really wouldn't fix all of your needs but some don't require this type of change.  For instance the background bitmap and sun graphics are referenced when the game starts so we can't really change those later.  You can just put the dulled versions in the table and only those will get loaded into memory in the mission with the current code even.  Motion debris handling would have to be modified to allow changing, or just turning it off, on a per mission or sexp basis.

[DaBrain]

Sounds really good to me.

Maybe this could fix abig TBP problem too.
TBP has a problem with races. Only EA is really working correct.

If you play a Narn mission and your Wingmen tells you to "get this green beam shooting bonehead... ect", it's kinda strange.

This could really make different races possible. Even new HUDs and changed HUD sounds.

This is great.

I'll write you soon what exactly SoL needs this feature for. I hope it will work for this.

[stithe2000]

This would be great on many levels... Allowing for more special sounds for each race, mission packs, etc.... This will open up new doors for an already awsome space flight sim project!