Free Allegiance Forums

Basically my tool was intended as a tool for centralising mod distribution. Think something like the linux package managment with some very basic dependancy stuff, but not nearly as good as the linux one obviously.

Basic flow would be:

Program downloads xml files from specified servers (say mesial's site, FAO, RT's servers etc), files describe mods (their name, description, mod version, what mod it supersceeds url to thumbnail, where to dl mod files from and their md5 hashes, where to put them in install, what things conflict with that mod - where something else also changes those files, solution to conflict)

Program examines users allegiance dir - md5 hashes files.

User is then presented with a list of mods available, with ones already installed highlighted (can tell what's installed from hashes).

User can select what they want to install and what to uninstall.

Program downloads compressed files, uncompresss them, copies and deletes files as appropiate.





"Default allegiance" would be a 'mod' with all the hashes of a completely clean install of allegiance with no broken files.

If you ran the tool and installed "Default allegiance" then it would insall allegiance for you (though I haven't thought about it making registery changes - so you couldn't use it to install alleg by it's self)

Only issue is that some mods are not compatible with each other. Are you going to have "This mod won't work with that mod" type stuff?

madpeople wrote:QUOTE (madpeople @ Mar 22 2010, 12:28 AM) ...with some very basic dependancy stuff....

...what things conflict with that mod - where something else also changes those files, solution to conflict...

This topic was largley for orion, who is working on something similar, I just threw it out here because others were interested.

I'll be posting more details at some future date.. our ideas overlap a lot in functionality.

I just thought that it might make sense to integrate this with the CSS update and file protection system.

There are a few reasons to do that besides making mods more accessable by allowing people to install them hastle free from within the allegiance launcher.

Just thought I would throw out that idea to get people tinking about it - I mean if we're talking about building a smarter update system, which uses file hashes, and the ASGS replacement will also want to update files and look at file hashes, why not make the CSS update system smarter (and actually make it a proper update system with file protection abilities, instead of a file protection system which is misused as an update system).

All you would need is for the CSS to recognise a 'protected' field for files from the FAO server, so that no mods of those 'protected' files are allowed. The rest of the system would remain the same.

In normal operation the system would alert the user to any files which don't match any known hashes for those files, and present a range of valid versions of the file to download (the default version from FAO, and any modded versions from any servers the system is set to get files from)
Also, I thought there should be a "free mod" mode where the system doesn't alert the user to invalid non-protected files - invalid because they don't have hashes matching any files the system knows about, non-protected, because protected files would still be subject to checking of valididity. To allow the user to run with potentially broken files - so we can still develop mods, or test/use ones which haven't made it onto one of the mod servers (perhaps private squad mods?). Though I guess if this was integrated into the CSS then which servers were available could actually be passed dynamically, so that people with the tag say "@RT" got automatically configured to download mods from a provate RT server in addition to the standard servers, so private squad only mods could be distributed through the system, with no involvment of FAO staff (except to set up the CSS to pass the address to the RT server to the updater for @rt people loggged in).

I love it guys...keep us posted!

What I am working on is ostensibly something to put in place until CSS replaces ASGS (and probably a bit after that, until my system can be integrated into CSS - I also wrote the CSS autoupdate system, so I am pretty familiar with it and what its limitations will be for version 1.0).

I just had an idea, mods could have an associated level of detail included in its meta data - so you could have the system understand that some files are all the same mod, but at different LODs, rather than being different mods for the same file.
That way people could filter to only display high detail mods or medium detail. Perhaps a 1-10 scale rather than low medium / high?
That way we could have overall LOD selection for allegiance like other games have.

Ah, you mean like the "low/med/high geometry terrain" type settings in other games?

yeah.

People who make textures often make 2048x2084, 1024x1024, and occasionally 512*512 high res mods of the default 128*128 or 256*256.
when I made my high res rocks, I made a whole range of poly counts - from slightly more than current rocks to silly levels - the intention being people choose the best one for their system.

If we use the shockwave texture as an example (and assume you had made a modded version too). Instead of the tool listing different resses as different mods like
Shockwave Default (128*128)Shockwave mod [madpeople] (512*512)Shockwave mod [madpeople] (1024*1024)Shockwave mod [madpeople] (2048*2048)Shockwave mod V2 [madpeople] (512*512)Shockwave mod V2 [madpeople] (1024*1024)Shockwave mod V2 [madpeople] (2048*2048)Shockwave mod [Orion] (512*512)Shockwave mod [Orion] (1024*1024)Shockwave mod [Orion] (2048*2048)
It would have different resses counted as the same mod
Shockwave Default
(128*128)Shockwave mod [madpeople]
(512*512)(1024*1024)(2048*2048)Shockwave mod V2 [madpeople]
(512*512)(1024*1024)(2048*2048)Shockwave mod [Orion]
(512*512)(1024*1024)(2048*2048)
So only 4 things would be listed instead of 10, and then you select from a drop down which version you want. The res description string (second level of the list) would have an associated number relating to the resolution - 2048*2048 might be 10, 1024*1024 might be 7, 512*512 might be 5, 256*256 - 3 and 128*128 - 2. People could then select from a drop down list to only show "ultra" quality - things with a number above say 8, or very high (things 7 and 8), high 5 and 6, standard (2,3,4) and low 1.
Or they could select say "Highest available" which would show only the highest quality versions avaialble - files with no high res mods and only the default 128*128 quality levle 2, or 512*512 ones which were found in the art source/CDs would also get shown along side level 10 ones - so people could select to install all the best quality things very quickly.

================================================================================
======================
Possible additional functionality
Sound and VC file building. I was thinking about this before, and a post on something similar made me decide to post it (I decided to put my reply in this thread rather than the other though)

HSharp wrote:QUOTE (HSharp @ May 2 2010, 05:16 PM) I was starting to make some program a while ago for easily adding new VC's and updates both quickchat and sounddef mdl so its easy to add new chatpacks or individual VC's. You can alter your current VC's that when you give out a VC you can actually change what command it gives to people (but it doesn't work the other way round ) which was going to be a main part of the program. Ideally a code change would also be required so that even if a person does not have the corresponding VC instead of getting the 'Unknown Chat' or nothingness as it is now the text would appear but obviously no sound would play.

I might start working on the program again sometime when i'm less lazy and don't have a job, but in the meantime making a chatpack is quick n easy to do, easy to do yourself as well if you just look through quickchat and sounddef mdl to see how they work.

I was thinking about something which allowed automatic building of those files from a selection of source files.
Source files would provide (different lists in different source files)
- have a list of sound files and associated IDs
- have a list of menu items and associated keys and IDs
- a list which associates menu items IDs to other menu items IDs (structure of menus) or sound file IDs (which actually get played)
The program would then merge selected lists (different chat packs would be different lists) and produce appropiate output files.