Zini wrote:
There are many flaws in the TES-CS. Too many to name them all here in this posting. But I think we should at least mention the three that are standing out most. Especially since people already having started to mentally step into the same trap again, that lead to this disaster that we call the TES-CS.

2a. Two tier editor component society

The Problem:

When it comes to editor components the CS has first class citizens and second class citizens.

The first class: These have a persistent window, that is part of the primary layout:

- The ID list
- The 3D editing window
- The cell list, with a list of references for a single cell slapped on it

The second class: These are usually accessible via some kind of dialogue-ish window. Examples:

- Dialogues
- Scripts
- Global Variables
- Classes
- Races
- Factions

Now that is a problem, because it does not reflect the typical usage pattern
(based on a TC-class project).

Examples:

A feature-scripter will rarely ever touch the 3D scene or individual cells. But he needs access to the ID list, the scripts and global variables.

A quest/story-scripter will need the ID list, the dialogue window and the script window, maybe with occasional access to the 3D editing window.

A dialogue write will usually use the dialogue window and little else.

A balancer will need the ID list, the classes and the races window.

Even in a smaller team with less strictly separated jobs, at any time any individual modder will only require a specific subset of editing components.

The Solution:

Make all components equal. Allow the user complete freedom when it comes to selecting which components he wants to see.

2b. The ID list

The Problem:

In a large ID list it is incredible hard to access individual IDs. A typical worldbuilder will spend more time searching through the lists than actually placing objects into the world. This is unacceptable.
Also the tab interface in the ID window deserve an entry in the UI hall of shame.

The Solution:

The separation into categories via tabs has to go. One might think a treeview could be a good idea. But that would be also wrong. Treeviews are good at displaying tree-structures in a compact way. They are bad when you want quick access to leaf-elements, especially leaf-elements in different parts of the tree. Once again this is a scaling issue.
Also, we should remember that all IDs share the same namespace. You can't have a weapon and a piece of armour with the same ID-string. In this regard the separate lists are deceptive.

What we should do is merge everything into one large list. And then add filter-options. Plenty of options; with the ability to name filter settings and save them for later.

Possible filter options would be:
- per type (Armour, Weapon, Creature)
- per group of types (Actor=Creature, NPC; Equipemnt=Weapon, Armour, Misc and some more; World Object=Static, Activator). These probably should be predefined.
- per wildcarded search-string
- a combination of the above
- or a list of individual IDs; this type filter could allow the ID list to serve as a kind of palette for the worldbuilder

2c. The 3D editing window

The Problem:

In the 3D scene by default you can create new objects and move existing objects around (and do some other editing with them).

If a specific dialogue window is open, you can modify the landscape instead. And if another dialogue window is open, you can modify the pathgrid instead.

This is an extremely counter-intuitive interface. Also, it is very inefficient to use.

The Solution:

Inkscape provides a good example of how to do it. If you don't know Inkscape, it is a vector-based drawing program. On the left side, it has a vertical toolbar. In this toolbar you find radiobutton-type buttons, each corresponding to one editing tool, that determines how interacting with the main editing window works.

For our CS we could have the following tools:

- objects
- landscape (probably more than one for different editing modes)
- pathgrid

Hircine wrote:
There should be a paint like tool, where a selected object say like an external
building could be placed. so you can paint things like trees and fences, buildings etc..

rather than drag and drop. (slow)

There should be a quicker and easier way of selecting objects rather than the current list.

Zini wrote:
Well, the advantage of this tool-approach is, that we can easily add new tools.

Even with the old CS, you were not limited to drag and drop. You could place objects via copy and paste. We will have to investigate, if that is sufficient or of we need a separate too. But these are details we can sort out when we design the 3D editing component.

There should be a quicker and easier way of selecting objects rather than the current list.

I do not agree. Sort of. It would be nice to have one. But it is impossible.

We can make the list configurable with the filter settings listed above (note, that these are only examples, we probably will have more). This should enable the worldbuilder to reduce the list to a manageable size and give him quick access to the IDs he needs.

Any attempt to make the process even more convenient would suffer fatally from scaling issues.

Star-Demon wrote:
I agree completely with the equality of elements. I also agree completely with the filtering. This game is massive, and a fully modded game is also massive.

We really need filters for most categories in each game-object. This will really, REALLY cut down mod development time.

The Dialogue and quest windows really, REALLY need some sort of workflow improvement. The engine was adequate in making these involved quests, but was incredibly cumbersome. If we can ask around for input by quest-makers or TC folks for suggestions on how to improve the flow and speed of development, that'd be the best. It's hte only thing I never mastered in the CS...

The problem with the GECK style interface for a tree with a search function is the search times and the constant re-searching. To be honest, the tabs should stay but be enabled/disabled by preference. Disabled tabs don't get loaded, but get searched when "get info" is used.

Star-Demon wrote:
Another thing -

This application could probably be a Gem to the community by itself. I think we really should get a lot of input from people and let them know about it.

pvdk wrote:
Don't worry about filtering being slow, I think we can figure out a way to get a decent speed with Qt, using a proxy model on the data. We might even want to use a local SQLite database or something to put the data in.

Zini wrote:
The storage method is a topic we have to discuss separately. Because of the ESM/ESP structure it is rather complex. But I agree. UI-performance, even for such tasks as filtering and sorting should not be an issue.

Hircine wrote:
one thing that we could do, (to make things easier and faster for users)
(for 3D world editing)

Is like a hotbar or pool of objects which are most frequently used or is made up by the User.

so if a user is re-making Balmora for example. he/she would have baskets, pots and various exterior buildings on the hotbar. This kind of thing could increase work flow.

I am going to load up the old CS again and think of ways the quest/dialogue system could be improved and try to redesign that.

Zini wrote:

Is like a hotbar or pool of objects which are most frequently used or is made up by the User.

so if a user is re-making Balmora for example. he/she would have baskets, pots and various exterior buildings on the hotbar. This kind of thing could increase work flow.

What you are describing is the ID list with the one of the filter options I listed. No need to add a separate GUI element.

I am going to load up the old CS again and think of ways the quest/dialogue system could be improved and try to redesign that.

Well, the obvious solution is to split the quest from the dialogue system, since they have absolutely nothing in common.

But lets first get the basics sorted out. I still have some posts to make, before we get to work on the components in detail. Sorry for the delay btw.

sir_herrbatka wrote:
BTW: I think that the cell list could use some sort of "last modyfied" too, not any great design, just a thought and no idea where this menu should be located.

Greendogo wrote:
A lot of flaws in the script compiler as well as scripting functions that don't quite work correctly along with odd formatting/syntax inconsistencies can be found in the most recent "Morrowind Scripting for Dummies (v9.0)".

A big flaw for me is that it is a lot of trouble to have to go up to the preferences menu to change the "Grid Snap" and "Angle Snap" amounts when they should be easily accessible from a front menu slider or something akin to the slider/number-boxes in photoshop used to change the brush diameter. Also, a keyboard shortcut that you could use without moving your mouse would be really nice, since you might be moving an object into just the right position at the time. Maybe you could change this by holding a key and using the wheel on the mouse simultaneously? ctrl + g + wheel = grid snap change, while ctrl + a + wheel = angle snap change?

Zini wrote:
Can't access these files (only have an outdated copy of Scripting for Dummies and the up-to-date versions seem to be impossible to get hold of without registering with some dodgy download sites).

Anyway, these are probably not limitations of the CS, but the scripting language. There are some things in the scripting language that we can't fix without breaking compatibility. However others have already been addressed. If you want to post some examples of what exactly you mean with "odd formatting/syntax inconsistencies" I will comment on them.

Greendogo wrote:
The new version is supposed to contain a large amount of new information. Also, you don't need to register to download files from PES, you will just download from the public servers which are never busy anyways.

Just download it from this link and choose one of the links on the left (the blue free public ones) that say "Download Now!".

Regardless of whether it is a problem with the CS or with the scripting language, it is still a good update to have.

Greendogo wrote:
Sorry for the double post, but here is an example of formatting inconsistencies dealing with the "fix" notation (->) found in such things as "player-> setmediumarmor 100":

From the section on syntax

The fix (->) is a little more complicated. If IDs are contained in quotes, you should not
leave spaces around the fix:
"Sirollus Saccus"->GetItemCount netch_leather_greaves
The above will work, but spaces around the fix would cause problems. (Thanks to
Simpleton and DinkumThinkum for this info.) However, since it has also been
reported that a lack of quotation marks can cause problems in combination with spaces
round the fix, I'm going to recommend that you don't leave spaces round the fix at all
(should be fine in all cases).

I know there are more but this is just an example of what is in the guide.

Zini wrote:

A big flaw for me is that it is a lot of trouble to have to go up to the preferences menu to change the "Grid Snap" and "Angle Snap" amounts when they should be easily accessible from a front menu slider or something akin to the slider/number-boxes in photoshop used to change the brush diameter. Also, a keyboard shortcut that you could use without moving your mouse would be really nice, since you might be moving an object into just the right position at the time. Maybe you could change this by holding a key and using the wheel on the mouse simultaneously? ctrl + g + wheel = grid snap change, while ctrl + a + wheel = angle snap change?

These features definitely need to be made more accessible; one way or another We will look into it in detail when we are designing the respective editing component.

The new version is supposed to contain a large amount of new information. Also, you don't need to register to download files from PES, you will just download from the public servers which are never busy anyways.

I had to fiddle around with my browser settings to make this page working (running with extremely restrictive settings here; for security reasons). But it worked eventually.

A lot of flaws in the script compiler as well as scripting functions that don't quite work correctly along with odd formatting/syntax inconsistencies can be found in the most recent "Morrowind Scripting for Dummies (v9.0)".

I guess you mean the pages 166 and 167? Most of these issues have already been addressed.

We can't extend the script name limit without breaking the ESM format.

And I am not entirely sure, if what is described under "Fractional Numbers" works (been a while since I worked on this part of OpenMW). Might give a compile error, but definitely not a runtime error,

MSfD describes the script size length as a 16-bit limitation. I don't see any such limitation in the ESM documentation I have. But I am not entirely sure about it. Would have to look into the code of the ESM reader.