sparhawk on 23/3/2005 at 10:45
Since there are alread two threads about loader applications I think it would be a waste of resources if work on such an application is started with only a limited focus, so that it requires additional effort to include new feature when we already can design them in, or at least plan for them right from the start.
As TDM is approaching a state where we can release our first version in the forseeable future (beta mappers only but still a release nevertheless), I would really appreciate it if we can come up with a format and a design which allows it to include TDM as well. If this application is properly designed, there will be only a very minor overhead on the programming, with the benefit of allowing ease of adding features later on, so I think the effort would be not wasted. And I also think it would be in the interest of the Thief community if we can provide a single application that handles all the stuff that a taffer needs.
As Doom 3 can also run on Linux and Mac (not supported by us, as we don't have any testers for that) I would appreciate it if a toolset is used which can easily be ported. This would mean eitehr QT or wxWidgets (formerly known as wxWindows). Both are easy to code with and very easy to port and run on all target platforms. My personal preference would be wxWidgets as I have experience with it.
The requirements on the applications would be such:
The main application is just a dumb fronted, which presents information always in the same way. The description of the FM itself must be in a format which can be easily read on all platforms, which means a textformat is preferable. Having a plain ASCII file with keywords is easy to implement, and has the additional advantage that it can also be read by humans who may not use the application. Also it will not require a special editor. I think if this can be agreed upon it makes sense to start defining the tags that are needed. Specifying the format of the file without specifying which filetype will be used is kind of pointless at this stage.
The algorithm, how a particular FM is to be installed, should be abstracted in a base class, so that the implementation is totaly independent of the rest of the application. Depending on the experience of the coders here and of the toolset which will be used, C++ would be a good choice. Java might also be a language of choice, because this is also portable and window manager libraries are available for all platforms.
I would also like to get a clear statement if potential loader coders are willing to include TDM in their plans. If not further engagement on my part would be fruitless, as we would have to provide a seperate application anyway in this case.
As I see it we can seperate the application into several independent parts:
User interface: which will handle the interaction with the user to select which FM should be installed.
Installation testing: This can include tests to check if the application is in a proper state to handle the desired FM, which includes check for additional required files, service packs, version check, etc.
FM installation: This is the complete workflow how a particular FM is installed in a given environment.
FM backup: This code handles the cleanup and backup of an installed FM in order to get back to the original state before a new FM is installed.
All of these parts can be modularized in such a way that a well defined interface is used which can be easily extended. In C++ this would mean abstract base classes which provide the basic interface without any implementation.
I think if we can combine the efforts on this application everybody would benefit from it, instead of starting multiple projects which all have the same goal.
Any comments?
SubJeff on 23/3/2005 at 11:06
I think it's a great idea myself.
Ideally this application would also replace DarkLoader. If you are going to make it multifunctional why not go the whole way?
I cannot give any input into the programming side but I can make suggests from an end-user pov. The same basic setup for TDM, T3Ed and T1+2 with tabs to switch between would be nice. I'd also like a integrated web portal (not IE thanks) that links to the major online databases for DLing. (The Circle, thiemissions and Komag may all hold TDM, T3Ed and T1+2 FMs).
People may know that there is an FM burn and post project being worked on for those without broadband. It would be nice to have some integration with that too, if only a link so that web portal can open up the site when it is all done.
Finally some way of managing tools and scripts that are required for the creation and running of FMs. Incorporate dram's T3Ed loader, Dromed launching, TDM launching. . .
This way all FM resources could be at your fingertips in one application. Big job, but would be amazing.
sparhawk on 23/3/2005 at 11:27
It would be a big job, yes. But it doesn't need to be a full verison in the first release. If the interfaces are well designed and planned, then doing this stuff is no problem. In TDM we have a similar approach. Of course you can not implement everything at once, but by defining a milestone and agreeing on what should go in the first version makes the development much easier and then build upon this.
The current threads for the loaders seem to me a bit head over heels right now, because there is already talk about the fileformat while there is not even a definite decision on what fileformat will be used (or required) and other basic decisions.
SubJeff on 23/3/2005 at 11:33
Actually my suggestion would lead to a larger program than is necessary. If you were only running T3Ed it would be wasteful. Could you have a modular design that allows for the installation, or not, of separate components.
The format issue will be sorted out eventually.
Kingers on 23/3/2005 at 11:35
My roadmap for Shadow takes into consideration TDM and may include a module for it however it would be Windows based.
sparhawk on 23/3/2005 at 12:20
Quote Posted by Subjective Effect
Could you have a modular design that allows for the installation, or not, of separate components.
This is what I tried to explain in my initial posting. By keeping the four main components modular with a well designed interface, this should be no problem. If we want additional features, like a news feed or similar this would have to be taken into account as well, but I see no big problem with this. All the proposed toolsets support internet connection classes with various protocols, so this should be not a main issue.
To make the application specific part independent this can be implemented via an plugin kind system. The installation check and FM installation process could be implemented in a seperate DLL. In the INI file you can provide a key which DLLs are are available and in the main GUI view you can create a tab for each DLL that you found, because each DLL represents a different game.
This way you can easily implement it for one application first, but you can extend it later on. So if you want to have T3 missions, you provide a DLL which knows how to handle T3 installation. If later a TDM handler is provided, we write the DLL for it, the user adds the key to his INI file and from this point on he will see two tabs in his view. One for T3 and one for TDM. Same can be done for T1 and T2 as well.
This system can also easily be ported over to Linux because shared objects are the same like DLLs on Windows.
sparhawk on 23/3/2005 at 12:23
Quote Posted by Kingers
My roadmap for Shadow takes into consideration TDM and may include a module for it however it would be Windows based.
I don't know if this is really helpfull because we would still have to provide a seperate app for Linux in that case. The benefit for us would be only for the Windows users in this case because they can use the same app.
New Horizon on 23/3/2005 at 14:29
Thought I would let you know Spar. My friend Brian just got Doom 3 for his Mac. He has offered to be a tester when the time comes.
sparhawk on 23/3/2005 at 14:44
Quote Posted by New Horizon
Thought I would let you know Spar. My friend Brian just got Doom 3 for his Mac. He has offered to be a tester when the time comes.
I guess the main problem would be to get a developer if he finds bugs.
Andruha on 23/3/2005 at 16:51
To fuel the discussion further, I made a rough draft of the client application that looks for mod updates at a remote portal, downloads selected mods to local repository and installs a mod after backing up the previous state of the target application.
The diagram:
(
http://img19.exs.cx/my.php?loc=img19&image=modloaderconcepts9kb.jpg)
Inline Image:
http://img19.exs.cx/img19/3005/modloaderconcepts9kb.th.jpg There are only conceptual entities and relationships. There is no ordering specified for the interactions.
To contribute to this diagram, one should ask a question (e.g. how does it back up the target application) about the system and see if the proposed concepts are sufficient to answer the question. Add, remove, optimize untill answer is reached, then move to a next scenario/question.
The entity names and interaction descriptions should be streamlined too; it will help establish common terminology.
Legend:
* buble - static entity that needs to be well defined (important for interoperability).
* box - dynamic entity that processes bubbles (programmers are free to implement them as they wish).
* bold box - extrenal system beyond the boundries of this application.
P.S. I deliberately avoided to use any technological names. Those can be chosen once the diagram is complete and is translated in a more detailed software diagram.
