Jump to content

Distribution Of Mods


sigget

Recommended Posts

Hi, i know ive talked about this topic before, but i think it gets more and more important to us each day and we need to figure out a solution soon.

 

As mods gets more advanced and contain more and more files the current style of uninstallation will not hold. The mods that are available now are uninstalled by reinserting the original files. And the original files are distributed with the mod. Mods are still small and only change a few small files. But this will soon change. And distributing mods containing large amounts of data copyrighted by Altar will not hold. Im sure Altar, who has had a very positive view on our modding attempts, dont consider the small files that are in the mods now a problem.

 

But as you can see this is a problem that must be adressed and solved. I havent started any work on this yet, and im not sure about how it should be done. So this is sort of a poll :-).

 

The way i think it should be done is that during input vfstool (or a gui-based tool) outputs a file containing the chunks of data that was written to the vfs. This file is essentially a patch. So your changes are cooked down into a single file of changes. When distributing the mod this patch is all you really need. Using a special tool its contents is inserted into the vfs and the game is modded. While the vfs is patched a backup-patch is created and stored on disk. This patch contains the original data from the vfs, hence the copyrighted original data never change locations. When uninstalling the backup-patch, or unpatch, is applied and the vfs is restored.

 

But there are still a few problems with this model. One, a patch is only guaranteed to work on the version it was made for. A solution to this could be to instead of distributing a patch, you'd send a script-file and the files that need to be changed. Very much like how the original altar patch system works.

 

A solution should be simple to use for mod developers and especially mod users. It should'nt be too complicated. And of course if we're gonna commit to it, it has to be open and documented.

 

How are these mods to be managed? Could several mods be installed at the same time? Do we need some user-friendly GUI-tool?

 

What's your opinion on all this?

 

// sigget

Link to comment
Share on other sites

Best case as i see it:

 

If possible get altair onboard with this and do the following.

 

a switch when calling the ufo prog holds a relative path (to ufo directory)

in that directory is a "mymod.vfs". wherever the content of the mymod.vfs masks the gamedata.vfs the mymod.vfs is used....

 

If this is at all possible this would make it a breeze to just compile your mod into a single vfs for portability and have a lot of them in different dir.. and a small tool that just checks the mod dir for vfs's...displayes them and then calls ufo exe with the switch ...

 

if this is not poosible some more thought will have to go into it ...

but its never wrong to _start_ from a best case scenario ....:rolleyes:

 

/viruz

Link to comment
Share on other sites

Fnurgs way is exactly what you are refering to, he uses the original UFO:AM patcher and one single file. We (fnurg and me) will use this in the next version of the Rebalance Mod. I'll do the writing, he does the repackaging (i guess he has the more complicated part). :rolleyes:

 

But what is really needed atm is any info on the new patch (does it change the way modding works) or on the official tools.

 

Maybe Slaughter can help here, he seems to have a good connection to Altar.

Link to comment
Share on other sites

I maybe got it wrong but fnurgs way _replaces_ files in the original vfs .. this is not ideal ..

best would be if the mods could reside in thier own vfs altogether, and be activated with a switch... to make two mods work together just unpack them to the same directory and then back to an uber mod vfs :rolleyes:

 

/virus

Link to comment
Share on other sites

Yeah, that would be the optimum, maybe the next patch is of help here?

 

But atm fnurgs way is the only one reasonable and at least semi-professional. No more DOS-batch files, eek, bring'em awaaaaay! :rolleyes:

 

Btw, if Altar decided to say no to our modding, i would stop at the very moment, but i admit i wouldn't understand it (hey our mods brings new customers and buyers AND MONEY!) . But i think they are clever and professional enough to see that, too. And if they wanted us to stop, they would have already told us so, believe me about that. :tank: (Slaughter has seemingly some good connections to Altar, so he would have informed us about that for sure)

Link to comment
Share on other sites

Does anyone here have any contact with the altair team .. we can just run it by them and if they say right away that this is not implementable then we move on .

 

also they can tell us of their own thinking on how to streamline the modding .. they are in a uniqe position to know whats possible and not.

 

/P

Link to comment
Share on other sites

ok im absolutely no programmer so i dont understand all your saying but from a combination of what i hear here and common logic i could cook up this:

all changed code by mods goes into a mod file, in the file meant to be edited there will come a sort of command(pointer) saying, get the next piece of file from this and this part of the mod file, then at the end of the code of the modded piece it would point back at where to continue in the original file. thus not deleting original code or putting mod code in original files.

 

with this an uninstallation tool that keeps track of the pointers set so they are deleted at uninstallation thus returning to the pre mod code.

offcourse this uninstallation tool could also check if several mods dont put pointers in the same area thus conflicting eachother, and give an apropriate error message.

 

is this what you suggested? i didnt completely understand, and dont know if what i suggested is possible.

 

-leon

Link to comment
Share on other sites

Hello everybody,

 

please let me express our support for mods here. We are really impressed by the level of support and commitment our game receives from people like you. I must say Thank You again.

 

For the distribution of patches:

 

1. It is even now possible to use the system you suggest. If you create a file named "cfg.vfs" and place it in the same directory where you have gamedata.vfs, the files in the former will be preferred over the files in the latter. This is not an ideal solution (we would like this to be more general, so that you have multiple mod files alongside each other), and that's the reason we didn't make it public sooner, but now, seeing the level of support here, I think even this may be useful.

 

2. We are working on a collection of modding tools: beside the vfs packer and unpacker, we shall also publish the documentation for the configuration files, the documentation for our propriatary 3D format, a tool for converting binary saved files (mostly 3D models) into text files, and a tool for creating custom missions.

 

3. There will be also a patch that will make the game support the modding better (allow multiple mod.vfs files, allow loading custom missions).

 

Hope this helps.

 

Martin

Link to comment
Share on other sites

Gosh! That's indeed good news! Especially the cfg.vfs file will be of GREAT help.

 

But now i have a small question to fnurg, Llama8 and Nameless regarding the new Rebalance mod. Shall we complete 4.0 and wait for the official tools then OR shall we keep on modding the "old" way? What do you think?

Link to comment
Share on other sites

so you'll have to convert your mod to the new mode...doesnt differ too much from the way you do it now though does it? not too much work i think.

well its kindof your call, your the one doing all the work ^^

and besides, like martin said, the method was not perfect and i think there will be another way later on too to which youll have to adapt your mod, so...it all depends on the amount of time you need to bide :rolleyes:

Link to comment
Share on other sites

Thanks for your input Martin, it kind of solves the problem 'best case style' :rolleyes:

 

 

Two mods at once might be trickier though .. but i still think the best solution might be a tool that combines the mod.vfs's you want to use.

 

some checking on the common files should be done to check that they dont collide...

you could store all mod.vfs's in one directory and creating a new merged one would still keep the original ones.... exellent :tank:

 

the tool could even indicate wich ones are compatible or not ...

 

if we could compile zlib or equiv. into the exe we could even use zip as storage format .. containing a description txt and a thumbnail ...hmmm might be carried away a bit now but remember 'best case' :)

 

 

/virus <-- eagerly awaiting the 3d tools and documentation :D

Link to comment
Share on other sites

Wow, that are great news, thanks Martin!

 

Agree on the mod-merger tool - giving you the choice of which file to use if there are overlaps. Combination instead of simple choice for configuration text files would be a nice extra feature...

 

Excuse me if somebody already posted sth to that effect, i didn't really check:

Byte comparison will not be enough, we would need a string comparison function (as the length of a text file might change if e.g. a number is changed to more digits, a name changed to more letters, an extra line inserted, ...).

It could compare the changes against the original file for each of the two mods (which line has changed, which has been inserted, etc). If the mods change the same line, you would get a message informing you about that and letting you choose the one you prefer. For inserted lines, just insert all of them (possible problems here?).

 

But this is maybe overkill. Any volunteers? :rolleyes:

Link to comment
Share on other sites

Gosh! That's indeed good news! Especially the cfg.vfs file will be of GREAT help.

 

But now i have a small question to fnurg, Llama8 and Nameless regarding the new Rebalance mod. Shall we complete 4.0 and wait for the official tools then OR shall we keep on modding the "old" way? What do you think?

I'm not fussed either way, since it's not me that's doing the work...

:rolleyes:

Well, it is with the glossary...

Link to comment
Share on other sites

  • 3 weeks later...

I just read on this thread that the game actually takes several cfg.vfs-files, thats great news, did you guys find out in what order? Is it alphabetically?

 

Ive been experimenting with the cfg.vfs a little, ive been trying to find out what files in the configs-directories are actually used, there are duplicates everywhere! Since i dont like to test these things manually ive removed the configs-directories from gamedata.vfs and imported the configfiles into a seperate cfg.vfs. Then im logging diskaccess to cfg.vfs to find out what regions of the file is used, and from that data i can see what files inside cfg.vfs are read by the game. The problem is that the game crashes during loading of the tutorial-mission, havent tried other tactical-missions. Ive tried to create cfg.vfs both with mine and flux' tool and it still crashes.

 

Perhaps there is some kind of exception to the extra vfs mechanism. That some files MUST be in gamedata.vfs.

 

By looking at the disk access logs i recorded it seems that the game starts by traversing the entire vfs, going through all sub-directories and building an internal representation. To maintain this representation is needs to maintain a lists of children -files and/or directories in every node and likely also a pointer to every nodes parent-node. I think that this is what we see in Unknown1 of UFO_ENTRY (refer to the vfs spec on my webpage), i havent looked into this in detail yet.

Link to comment
Share on other sites

I just tried to rename gamedata.vfs to cfg.vfs and then create an empty gamedata.vfs to replace it. If the game works as we understand it this should work, and the game should behave as usual.

 

But the truth is that it doesnt, it crashes while loading the tutorial mission.

 

My conclusion is that SOME files can be put in cfg.vfs and some can not.

 

I will experiment further to see what is really going on.

 

UPDATE: after analyzing disk access to the identical cfg.vfs and gamedata.vfs ive found that the game still accesses gamedata.vfs, these accesses are to ranges of the file that hold tactical/anims, tactical/configs, tactical/models and tactical/particles.

 

These are some of the files that were accessed:

tactical\anims\rc4_unit_anim_pack.txt

tactical\configs\game\listofanim_hum.txt

tactical\configs\game\listofanim_mut.txt

tactical\configs\game\listofanim_ret.txt

tactical\configs\game\listofanim_weapons.txt

tactical\configs\game\listoftimes.txt

tactical\models\effects\line_2.txt

tactical\models\effects\projektil.txt

tactical\models\symbols\action.txt

tactical\models\symbols\attack.txt

tactical\models\symbols\cursor.txt

tactical\models\symbols\cursor_throw.txt

tactical\models\symbols\foot.txt

tactical\models\symbols\ground_launched.txt

tactical\models\symbols\ground_planned.txt

tactical\models\symbols\h_bar_black.txt

tactical\models\symbols\h_bar_green.txt

tactical\models\symbols\h_bar_red.txt

tactical\models\symbols\h_bar_yellow.txt

tactical\models\symbols\line_50.txt

tactical\models\symbols\line_70.txt

tactical\models\symbols\next_mission_point.txt

tactical\models\symbols\paralyse.txt

tactical\models\symbols\plocha.txt

tactical\models\symbols\select.txt

tactical\models\symbols\select_a.txt

tactical\models\symbols\waypoint.txt

tactical\particles\nabojnice.pcfg

tactical\particles\special fx_group

tactical\particles\special fx_group\teleport.pgrp

 

If you have successfully modded any of these files let me now!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
  • Create New...