Gurkoz Sound Mod And Rebalance 4.1b

[MadTaco]

I really enjoy GurkoZ sound mod (gives a bit more atmosphere to certain things) and the Rebalance mod is pretty good as well. But, I have found that the two are not compatible. I use the .bat file and have not yet attempted manual installation, which is what I may try within the next few minutes. Has anyone here found a good workaround?

 

Edit: I really don't know how it is possible, but I got both mods to work hand-in-hand. I noticed both mods make exclusive use of the cfg.vfs, so I naturally assumed it wasn't worth trying since I have no .vfs editor or compiler. So I decided to use Rebalance only, and moved localization.vfs to localization folder, and re-named the real one reallocalization.vfs which seemed just fine and dandy. I then re-named the GurkoZ sound mod cfg.vfs to gurkozcfg.vfs, and left it in the main folder, and then threw in Rebalance cfg.vfs to take its place. I started the game up, and much to my surprise I saw both modified splash logos, both GurkoZ AND Rebalance. I tested it out in-game and the new sounds and Rebalance changes are present. Maybe I shouldn't be, but I am damn surprised.

 

Good lord, I typed so much about something so small

[Slaughter]

lol Glad to hear you worked things out. Another option would have been to use the Alpine tool. But it seems that as long as there is cfg.vfs the game will take it into account. Alpine for instance uses alpinecfg.vfs...

[MadTaco]

That's what I figured, that the game simply recognizes ALL present cfg files in the main folder. Never heard of that before, though, since most programs simply won't recognize other-named files. Least it works

[Aralez]

Sorry if i understand this wrong, but are you saying that all files ending with ...CFG.VFS are rcognized? For example manamanacfg.vfs?

[Fulby]

Yes, hence alpinecfg.vfs so it works but doesn't overwrite an existing cfg.vfs. What I found at the time though was that if two *cfg.vfs files contained the same file, UFO wouldn't load. Maybe I did something wrong, but that's what it seemed like to me.

 

Edit: Having checked again with an alpinecfg.vfs (containing Rebalance mod + other stuff) and the cfg.vfs from Rebalance mod, UFO loads but cfg.vfs files overwrite alpinecfg.vfs files. (next version of alpine to save files to zzzcfg.vfs maybe )

 

Fulby

[Aralez]

That would make sense, since two files try to overwrite each other.

 

Oh and thanx for the quick answer

[sigget]

That's good news! I posted this on the 'Distribution of mods' thread where Martin revealed the cfg.vfs -mechanism.

[Nameless]

well actually its exactly what martin said =P

well anyway, it would be smartest to give each mod their own vsf file with their respective names.

the only problem would be when the different vsf files try to edit the same file, such as two weapon mods trying to work at the same time.

how will the prog know which one to take? it (naturally) only recognizes entire files, so if two weapon or whatnot mods have been made accesing similar files than the two mod makers would need to contact eachother and create a special combo mod

but still, this is a piece of good thinking from altar, yes?

[sigget]

If there is several *cfg.vfs -files containing the same files, the game will choose only one of them. So using several mods at once with each in its own file will not work if they try to change the same file. You can only have one weapon mod for instance. The way the new version of Alpine works IS the way to go, scripts calling functions that build new files and then create a new vfs archive.

[Nameless]

so you mean it combines your (several) mods into one new vsf file?

it checks all the files and when two mods do use the same file it combines those files if they edit only different lines in that one file? (offcourse mods editing the exact same line couldnt work)

sounds like a brilliant piece of programming if its what i understand it to be =)

[sigget]

Thats how i understood it. The config files are all really database files consisting of lists of entries, if a tool were to read in all the entries, and then let a script modify them by adding, changing and removing entries, and then create a fresh cfg.vfs with the modified config files it could allow several mods to be loaded at once. It could also detect when mods collide. I think this is the best way of handling mods, and i think this is the direction Alpine is going.

[Slaughter]

Yep, I believe that is exactly how it does it sigget. And it stores it in the alpinecfg.vfs file...

[Fulby]

so you mean it combines your (several) mods into one new vsf file?

it checks all the files and when two mods do use the same file it combines those files if they edit only different lines in that one file? (offcourse mods editing the exact same line couldnt work)

sounds like a brilliant piece of programming if its what i understand it to be =)

It doesn't work quite like that, instead each "plugin" is written in a simple script language which tells ALPine what to load, modify, add, delete, save etc. Even two plugins changing the same 'line' of the file (i.e. the same value of a property of an item) is possible, but the second plugin applied will overwrite the value of the first. ALPine doesn't check for conflicts like this, it might do in the future but I don't consider it a high priority. See a very long post in the Plugin Creator thread for a longer explanation. What it now allows is setting the order in which plugins are applied, so if necessary the modder can say "put this plugin after plugin X for it to work properly" in the plugin's readme file.

 

The script commands to make a plugin have gotten a lot easier since ALPine 1.0, now all a modder has to do is make a file in UFO's format but with only the new weapon/magazine/etc, and a single line in the plugin code will add that item to the game. Changing existing data is more involved but not difficult and there's several example plugins to examine.

 

Thats how i understood it. The config files are all really database files consisting of lists of entries, if a tool were to read in all the entries, and then let a script modify them by adding, changing and removing entries,

That was version 1.0 of ALPine .

 

and then create a fresh cfg.vfs with the modified config files it could allow several mods to be loaded at once.

Added in 1.5, made possible by your vfstool .

 

It could also detect when mods collide.

It could, I question how robust such a system could be made to catch the different kinds of conflict, but also there's what to do when a conflict arises. If you ask the player to choose which mod's change is applied, how will the modder or the player or ALPine know whether choosing the other mod will break something in the first mod.

 

I think this is the best way of handling mods, and i think this is the direction Alpine is going.

This is the sole purpose of ALPine and is what version 1.0 did. Everything since then has been to make it easier to write and use plugins.

 

Fulby

[MadTaco]

I still think it's rather neat how the system works on its own without ALPine plugin, I have never seen a game or a program go off the end of the file to check for "cfg.vfs" before

[sigget]

Even Doom I read custom external archive files. Specified on the command line using the -file option. Which made it possible to choose which mod to run.

 

Ive been told that Quake3 imports external archives in alphabetical order and uses them all.

 

So Aftermath's mod technique is in no way unique, nor is it the best.

[Slaughter]

And why are they using all these text files? I would prefer a access like database, that's for sure...

[sigget]

Access is a piece of crap, but any form of binary file would be better, parsing text slows down the loading process alot! Ive been thinking of ways to speed it up since my computer isnt top-notch any more. If we could remove the compression and convert all the models that are in text into their binary equivilents, we might speed it up.

[Slaughter]

Sounds good!