Ziemanskye on 27/4/2005 at 21:45
That's EEP! as in an exclamation of shock, horror, and surprse.
Andruha on 27/4/2005 at 21:47
Quote Posted by sparhawk
It's nice to see somebody in a communtiy project working on a professional level. Considering some of the responses it is no surprise that this is seen as a useless overhead. :)
Thanks :).
Quote:
UI should have connections going back and forth between the Mod Manager (MM). The UI doesn't need to have a connection to any other component. All the information should be routed via the MM.
The arrow from Source should go to Update Tool and not the other way arround, because the source is presumably the input which defines the layout how to install a given mod.
The mod manager shouold communicate with the target and source only via the Update Tool. This way you can reduce the number of interfaces quite a lot, which are crossing the application boundary.
All those are good, yet debatable points: a couple of simpler interfaces and simple event handlers vs. heavy all-in one interface of MM; the application boundry is not set in stone too. Let me come back to it later :)
Quote:
Since application boundary is a term used in Function Point Analysis, i"m not sure if this is suppsed to be a proposal for this, but in this case I miss the approriate terminology.
I have no idea what Function Point Analysis is. I used the term informally. It just means a separate external element (right) from internal (left). My placement of the border is an example. A developer can move some elements (e.g. a syncronization tool) outside.
Andruha on 27/4/2005 at 21:50
Quote Posted by ZylonBane
Well thank heavens you already took care of the hard part.
LOL :thumb:
Quote Posted by Ziemanskye
That's EEP! as in an exclamation of shock, horror, and surprse.
Good to know.
Andruha on 27/4/2005 at 22:00
Quote Posted by Renzatic
Though I'm usually one that likes all the bells and whistles I can get, most people (specially people here) like everything to be as clean and simple as possible it seems.
I don't like messy things myself. The design is quite clean and simple actually.
Quote:
You have to consider what's might be useful later on. You could tag on tons of extra options that might have an initial wow effect, but won't be used by later on cuz all they want is a nice front end that launches them into their chosen FM.
What I'd do is start out with something basic and functional like Darkloader then build on it from there.
Agree absolutely. I just provided a couple of possible future features, like Installation Validor, applicability accross a wide range of mods. Also Update Tool is very optional. In fact, if you hide the part of diagram below entity 'Mod' the you get basicly a DarkLoader design (well w/o UI and Catalog to keep track of missions).
Huckeye on 27/4/2005 at 22:03
Quote Posted by Andruha
Huckeye,
Thanks for your support.
A bit off topic: in this (
http://www.ttlg.com/forums/showthread.php?t=95097&page=4) thread you asked about patching T1 and T2.
I solved the same problem with existing tools. Here is what I deed:
- created a central updates repository for T1, TG and T2.
- manually created custom configs, updates and fixed files following instructions in Thief Series FAQ (Technical / Purchasing / Etc.) (
http://www.ttlg.com/forums/showthread.php?t=75031) thread.
(most useful fixes for me: Game Freezes within a minutes / Running Thief on a Dual-Processor System or Got a Pentium 4 with Hyperthreading? and Direct 3D Device does not accurately report texture memory usage, or Help! I only get a black screen!)
- saved updates in the repository.
- installed a synchronization utility (I use SyncBack - it's free)
- created profiles for the sync. utility.
Now, whenever I reinstall any of the games, I just fire up the utility and tell it to run a bunch of profiles. In seconds, I am ready to enjoy my favoutire games.
Incidently, your question is strongly related to the functionality of the proposed design.
Thanks, I'll look at Syncback, exactly the kind of response I was hoping for. Eventually I want to write something myself but that is ambitious as I am an extreme programming newb :D
Andruha on 27/4/2005 at 22:33
Glad it helped. (-:
As for Syncback, do not forget to export your profiles and backup them for later. By default, this progy keeps profiles in some obscure place, and if you have to re-install Syncback you'll have to re-define profiles again. So the trick is to export/import.
Good luck with programming!
dracflamloc on 28/4/2005 at 00:39
First, off I didn't mean it to sound like there should be only one program per game or purpose.
Quote Posted by Andruha
Actually, if you
read a bit further then the bit you are qouting, you would see that i gave a possible very simple implementation. It still requires some programming.
"some programming" :erg:
For someone who is donating their time, thats a lot of programming. I'm creating FleshLoader to support DarkMod as well as T3. Eventually I'll add T1 and T2 support. But what you need to understand is that there are not that many C/C++ programmers here in TTLG. Especially not ones who have experience creating cross-platform code which can be compiled and used by many different programs. Its a grand idea you have. From a realistic expectations standpoint you are going way overboard.
Really in all honesty I like that someone knows how to design a program layout before actually coding it. Its a lost art.
With regards to linux... of you'd just read existing threads on this topic you'd notice that I have FleshLoader compiling and running just fine under linux.
An update checking feature could be implemented easily with the cooperation of thiefmissions.com and the other sites. I've already talked with the people running the site and planned to put in RSS newsfeed for any new missions that get uploaded.
Also, if you "unify" this and share the code modularly, what's the point? You'll end up with essentially one program. Maybe individual loader interfaces might differ slightly but theres really nothing special about a loader in the frontend except a list and notepad, and maybe an update checker. Not to mention, every new feature thats added will become a non-standard anyway which brings us back to square one. And what if someone wants to change the way it works a little once it is actually developed to be shared? One change would require a voting system of some sort so it doesnt screw up every other loader out there.
I invite anyone who wishes to help me in my programming of FleshLoader or any loader, to find the process needed to launch a T3 FM with custom scripts, backed up saves, etc.
With T3 you have quite a bit to worry about. The gamesys, saves, registry settings, INI settings, and just the general mess of the engine is going to be quite a hackjob implementing.
From a TDM viewpoint it's ridiculusly easy to install and remove mods. I could code that in a matter of minutes. Thats one of the good parts of the Doom3 engine. Just drop a pk4 in, do save backups, and thats all there is to it.
sparhawk on 28/4/2005 at 09:35
Quote Posted by OrbWeaver
That is not to say that such techniques are not valuable in many cases. They are just not applicable here.
This is the typcial repsonse from programmers who don't have a clue about software engineering. But don't worry. You don't hear this only in community projects you can hear this as well in professional developments. That doesn't make it true though.
sparhawk on 28/4/2005 at 09:43
Quote Posted by Renzatic
What I'd do is start out with something basic and functional like Darkloader then build on it from there.
And if you don't think about this BEFORE you start coding it, then you end up with an app that is not extensible and you have to live with it's shortcomings.
The usual repsonse is in such cases is:
It has historical reasons.
That can not be done.
We don't need it anyway.
It's overkill.
I want to get started coding, not do thinking first.
etc., etc.
OrbWeaver on 28/4/2005 at 17:04
Quote Posted by sparhawk
This is the typcial repsonse from programmers who don't have a clue about software engineering. But don't worry. You don't hear this only in community projects you can hear this as well in professional developments. That doesn't make it true though.
On the contrary: somebody who knows about software engineering will know how and when to apply it, and when it is not necessary. For example, a script to list files in a directory would need little planning beyond a basic description of its function; an FM loader would probably benefit from a page or two with a more detailed behavioural specification (in particular, things like "how will it recover from a power failure during FM installation?" and "at what point during installation does it update its database?" are important here), whereas a large enterprise project would require many detailed documents like Andruha's.
There is no
harm in using too much engineering, if that's what you're into, but if is too complicated for the developers to understand or use, it will end up being wasted.
