How does this address your contradictions?
I did not contradict myself. UI is display plus getting input and sending orders to the game engine.
How on earth could Toady let them do more than they have?
Like I said - make the UI a separate part of the engine and work through APIs.
Toady's not likely to add others' work into his game, though, so don't expect him to.
"The Game" and the UI are - I believe - two different things in this case.
Each time the way dwarves choose jobs changes somehow, whether by adding new ones, improving AI, whatever, the UI with assigning jobs would probably be affected, especially if it's as complex as you seem to think it should be. Trust me, it's almost always more complex than you think it will be.
Ok. If the interface reads a list of states a dwarf can have and displays one of them on a dwarf. the same with his leg or whatever. The interface can be just as data-driven as the game itself is. Assigning jobs - if you need to assign a job to a dwarf, then you do it. The new job cfor a dwarf can be simply an entry in the description files. It's been done already.
Look. I'm a programmer. I do that for a living. I know that it can be done and how it can be done. Because the process is essentially the same for every data-driven system. All you need is good design.
1. Actually not. Currently the UI and game engine are pretty entertwined. (More so than the game and graphics part, which are actually seperate threads.) Hence why the game pauses while you designate, amongst other things.
If the game part and the graphics part are separate threads, it's just one step further.
The game pauses because the UI tells it to. Not because it's magically connected.
It's a simple: "Hey... engine. stoopp... he's designating a new garbage dump... it's gonna take a while."
And later" Ok, engine - this is the new designation, do what you will. Now start again."
2. Don't forget the managing program (DF foreman or something) that actually ran as part of DF.
Yes. But that's all still another pretty much hacked-in tool.
3. AFAIK, Toady used to be more open about the game and it source code, untill some forum members reverse engineered it and made it their own game. Don't know what happened with it.
Wow. Didn't know that. It's a shame though:/
4. They kinda will. Memory adresses change, entire menus are added or replaced. Even adding a singe item category could break the whole thing.
Memory addresses don't matter when you do an API.
Entire menus don't matter if all you have is a list of actions that you can take, and that's categorized.
Adding an item category would in fact not break the system that's data-driven. It would simply work. Remember, that UI can have the same base data that the engine has.
5. Can't we use a system similair to Dfterm + Stonesense and use that as a different UI. Stonesense esque visuals, and Dfterm had a way of remotely controlling stuff.
I think that isometric is not the way to go.
1. Top-down gives you a much better overview over what actually happens where.
2. Can't cope with ASCII properly(it could be used as a fallback for items that have no sprites thus making additions to the engine not require graphics department.
3. I would rather have a ood way of controlling stuff ingame than through external tools. That's kind of my point. Not saying something like this wouldn't be used, but rather - it could be integrated easily.