Andruha on 27/4/2005 at 20:16
Fingernail,
This specification (as you put it) exists already in the DarkLoader, threads about mods, requested features, and so on.. in the form of code (that many people do not understand and cannot adept) or in natural language that is not good for computers. I just analyzed the this information, filtered essential functionality from details like .NET, Delphi, zip, etc.., then normalized and filtered again and again.. (reversed engineered, if you will).
This specificatation is a guideline that breaks down loader application in simple and managable chunck.
Andruha on 27/4/2005 at 20:21
Quote Posted by ZylonBane
Then write it.
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.
And to answer you: no I won't write as I am not a programmer, but a designer. To do a simple program for me is as hard and time consimung as for a programmer to translate a basic high-level programming statement into a machine code.
I'll stick to what I do the best.
sparhawk on 27/4/2005 at 20:51
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.
I think we still need some maintanenance for the save games to keep them per mission. Unless you want to redistribute the entire darkmod baseline for each individual mission. The pk4 concept is sure a big advantage, but I still think that at least some basic maintenance might make sense. I think we can only see this for sure when we have two independent maps (aka missions) where we can see what is needed and what will be taken on by D3 itself.
sparhawk on 27/4/2005 at 21:03
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. :)
When I look at the image I think there is room for improvement.
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.
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.
OrbWeaver on 27/4/2005 at 21:03
I agree with ZylonBane. Trying to apply large-scale software engineering principles to a Mod loader is using a sledgehammer to crack a nut.
That is not to say that such techniques are not valuable in many cases. They are just not applicable here.
sparhawk on 27/4/2005 at 21:04
Quote Posted by Andruha
To do a simple program for me is as hard and time consimung as for a programmer to translate a basic high-level programming statement into a machine code.
I don't get it. Whats the problem with translating a HL construct into machine code?
Andruha on 27/4/2005 at 21:15
Quote Posted by OrbWeaver
I agree with ZylonBane. Trying to apply large-scale software engineering principles to a Mod loader is using a sledgehammer to crack a nut.
You are right. It is overkill for others (no one around me in RL will believe me I spent time doing this), but I like designing and it does not took too much time (nothing compared to the time fm creators spend).
However the nut shell is cracked: more functionality can be achieved with less concepts (which translates in less software elements, less code, less work). Iron out a few details and take the nut.
Andruha on 27/4/2005 at 21:21
Quote Posted by sparhawk
I don't get it. Whats the problem with translating a HL construct into machine code?
It is just an analogy. It is not reasonable to expect a programmer to work with machine code, therefore why one would expect a designer to program? (I don't mean it is impossible).
ZylonBane on 27/4/2005 at 21:25
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.
Well thank heavens you already took care of the hard part.
Renzatic on 27/4/2005 at 21:30
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.
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.
