Andruha on 27/4/2005 at 10:57
Thief community has produced modifications of remarkable quality and numbers for Thief games. Recent release of T3 editor and The on-going Dark Mod project has added a new impulse to the modding community and has raised an issue of an application to manage the mods. While there are already plenty of discussions on which application to (re-)use, which technology is the most familiar and which format looks best, I feel that these discussions lack focus on unification and interoperability. Given a unified framework exists and is designed with interoperability in mind, it could provide a basis for Loaders that differ in style, implementation, platform requiremets (subjects of hot debades), yet manage not to separate the community.
With this in mind, I propose my take on such a framework. Any feedback is welcome.
Mod Loader Framework Short name: Mod Loader (ML)
(
http://img260.echo.cx/img260/5915/fmloadingimgmdl1er.jpg)
Inline Image:
http://img260.echo.cx/img260/5915/fmloadingimgmdl1er.th.jpg Legend:
arrow - a relation
box - an entity
bubble - an entity whose structure, format or syntax need standard definition.
PART 1: Elements Application boundry - is an arguable border between ML's internal elements and external elements. The boundry indicates crossection where interoperability (see Part 2) plays important role.
External:
Application - is a target of modification., e.g. T1, T2, T3, Doom3
Mod - a distribution of a modification. Example: missions, custom textures, custom models, tweaks, etc..
Catalog - a data management system. Data is information about previous, current and new (to be downloaded) mods. This data relates to physical properties of the mod (location), mission information and user subjective information (finished, rating). Catalog examples: a database, a simple text file, etc..
Portal provides on-line Catalog, mods repository, news, community, etc..
Container is a storage. Typical container type is a file system directory. Archive is a container too. In the context of the mod loader, containers store profiles, states of modified applications (backups), application installation, downloaded mods, mod files, etc..
Internal:
File synchronization - a tool that manages files according to a profile.
Mod manager - creates profiles for File synchronization tool, and updates the target Catalog with information about the current mod and current profile.
Profile is a task description applied to a concrete Application and mod. Profiles can be stored in case a roll-back is needed (e.g. a de-installation of a mod).
Task template profile - a template profile that implements a synchronization task, e.g. install, remove, backup, etc.. A template applies to all mods and applications.
Application Profile - describes installation of an Application.
Mod Profile - describes the distribution of a modification. It can be explicitly provided by the mod (then it would be external element) or derived from mod by the mod loader (then it is internal element).
UI provides interface to other internal elements. It allows to manage mods, view mod's mission info, to subjectively describe mod, search for new mods, and so on.
Update Tool - looks for new mods matching set of user-defined parameters. It retrieves a list of mods from mod portals and compares with mods (that were ever) registred in target Catalog.
Extensions
- Catalog enables to check for possible conflicts with already installed mods, therefore
Installation validator may appear
- ..
PART 2: Interoperability (to be continued)
PART 3: Standards and Technology (to be continued)
Edit: typosZiemanskye on 27/4/2005 at 16:22
A) EEP!
B) Why do we need this, like, in idiot speak?
DarkLoader works for T1 and T2, FleshLoader will work for T3, and Dark Mod will likely get/have something similar, so while the drawing's kinda pretty and all, I don't see having us really needing unification or interoperability.
You want to work on, or corral some people into helping with, go for it - but you're as well off making your own calls on file formats and framework and stuff.
Genuinely though - prove me wrong if I am, I'll no programmer (been there, tried that, failed miserably), so I can still get by with only sticking to point A. :joke:
dracflamloc on 27/4/2005 at 16:36
Just curious but why? Theres no need for two apps to do the same thing (ie launch t3 missions).
And I don't even think there are enough skilled/willing programmers in TTLG to follow this kind of program design. It's not like anyone is getting paid here...
A lot of the things on that design sheet have nothing to do with standards and unification. More like they are feature requests, and would be better off as a recommendation in an individual loader's thread.
I may however throw my base code for all those operations into a DLL when they are done so they can be called by anyone who wants to write an app using my formats etc.
New Horizon on 27/4/2005 at 17:17
Quote Posted by Ziemanskye
A) EEP!
B) Why do we need this, like, in idiot speak?
DarkLoader works for T1 and T2, FleshLoader will work for T3, and Dark Mod will likely get/have something similar, so while the drawing's kinda pretty and all, I don't see having us really needing unification or interoperability.
You want to work on, or corral some people into helping with, go for it - but you're as well off making your own calls on file formats and framework and stuff.
Genuinely though - prove me wrong if I am, I'll no programmer (been there, tried that, failed miserably), so I can still get by with only sticking to point A. :joke:
Dark Mod doesn't really need a loader since there is already a Mod loader incorporated into the Doom loading screen. Just drop your .pk4 into the directory and go for it.
Andruha on 27/4/2005 at 17:24
Ziemanskye, a few why's:
A new application is needed:
- There are people that would like to have one application for T1, T2, T3 and TDM
- There are people that would like to have new functionality in the loader (e.g. updates, personal rating, etc..)
- There is no T3 loader yet (FleshLoader is in development, and as far as I know only interface is completed).
- TDM does not have a Loader (I am not sure if it need one)
So with this design, without it, energy and time will be spent and it is not a bad idea to spend those resources well.
This design identifies essential elements:
- Catalog
- Synro.Tool
- Mod format,
- etc..
This design it not tied into a concrete technology
Therefore Application developers are free to choose what to implement, how to implement and what to reuse.
For example, Mod manager can be programmed, but file synchronization can be an existing utility.
Finally, this design solves the problem in general
For example, someone who
- has a file synchronization utility (there's many to download for free)
- knows how to install mod files and directories wise (what is defined in Mod pofile, Application profile)
- can manually create installation/backup profiles for the sync.utitility
- has a notepad
- can structuraly write a log about played mission, installed mods
can already today have basec loader functionality.
Other bonuses:
- A mod is bigger then just FM: Texture packs, model packs, tweaks (like in Minimalist Project), fixes (e.g. from Thief Series FAQ (Technical / Purchasing / Etc.)), custom scripts, etc..can be installed using a loader.
- Time can be saved by not having to write installers.
Interoperability and agreed standards are just enablers..
So, what do you think now? :sweat:
Andruha on 27/4/2005 at 17:47
Quote Posted by dracflamloc
Just curious but why? Theres no need for two apps to do the same thing (ie launch t3 missions).
Good point, but what if Thief runs on Linux? What if some people what a .NET application? What if someone whants a different front end (UI)?
Quote:
And I don't even think there are enough skilled/willing programmers in TTLG to follow this kind of program design. It's not like anyone is getting paid here...
The elements in the design are quet independent and can be implemented by various people. So actually, there could be
less work per developer then if someone had to do everything. Behaviour of each element is quite simple too. Moreover, existing tools can be used instead of some of the elements.
Quote:
A lot of the things on that design sheet have nothing to do with standards and unification.
Correct about standards - I have not covered them and interoperability issues yet. As for unification, isn't it what a framework does?
Quote:
A lot of the things on that design sheet .. more like they are feature requests, and would be better off as a recommendation in an individual loader's thread.
There are
really few elements in the diagram. If a lot of them are feature requests, so what is left then? Can you be more specific?
Quote:
I may however throw my base code for all those operations into a DLL when they are done so they can be called by anyone who wants to write an app using my formats etc.
Well, it is great you would like to allow others to reuse your work. But what is in that DLL? will it be useful in the context of new application? Will somebody understand the source?
Andruha on 27/4/2005 at 17:56
Quote Posted by New Horizon
Dark Mod doesn't really need a loader since there is already a Mod loader incorporated into the Doom loading screen. Just drop your .pk4 into the directory and go for it.
Well, a loader can do as little as that. It will be a bigger deal if a user has am extensive repository of mods (I wish TDM mods as long and succesful life as of T1/T2). And do not forget information about mods (briefings, ratings, finished, etc..)
ZylonBane on 27/4/2005 at 18:06
I stopped reading at "unified framework".
This is a frickin' MOD LOADER you're talking about, not million-dollar enterprise app.
Andruha on 27/4/2005 at 18:15
ZylonBane, do you alway judge things so superficial? "unified framework" are just words.. and you should know they do not mean a million-dollar enterprise app.
Boogalou on 27/4/2005 at 18:21
Edited; as this was posted by Evil Boog before he got his afternoon coffee :p
