Atahualpa's coding adventures

Involved development of the OpenMW construction set.
User avatar
Atahualpa
Posts: 791
Joined: 09 Feb 2016, 20:03

Re: Atahualpa's coding adventures

Post by Atahualpa » 17 Feb 2017, 10:28

Zini wrote:#2: Sorry, no idea. Dig into the OpenMW codebase?
It looks like we simply took that bit from a research source (e.g., here). Will do a research on that topic later.
Zini wrote:[...] If anything, I would improve the editor in a way that it is compatible with OpenMW when dealing with multiple flags. With your changes the editor clears all flags when multiple flags are set. We could improve upon that by looking what OpenMW is doing (or even what vanilla Morrowind is doing) and then mimic that in the editor. But I don't consider that an important change.
*sighs and grabs his shovel*

User avatar
Atahualpa
Posts: 791
Joined: 09 Feb 2016, 20:03

Re: Atahualpa's coding adventures

Post by Atahualpa » 17 Mar 2017, 12:19

Okay, another one: I'm currently integrating the rank data into the Factions table/subviews. At the moment, the changes largely imitate the vanilla behaviour when it comes to ranks (see the attached screenshots from the original CS).
  • There are 10 ranks per faction; the amount of rows is fixed. (Easy to change in the future.)
  • You can "delete" a rank by giving it an empty name. This sets all requirements of that rank to zero and disables the corresponding cells in the table. (New ranks are also initialised with zeros.)
  • The empty rank will stay there until you save and reload the file.
  • Saving and loading the add-on file creates the following situation: The list of rank names is filled, i.e. all rank names are shifted upwards until the string array has no empty strings in between existing names. Please note that the requirements stay at the same position.
  • Because of this "filling", you end up with a distorted rank list.
I don't like the vanilla behaviour because it is not very intuitive. A more sophisticated approach would be to have two main editing options in that table:
  • "Delete Row": Deletes the selected row (moving all higher ranks upwards) and adds a new blank row at the end of the table in order to maintain the fixed amount of rows. Disabled if there are no ranks.
  • "Add Row": Adds a new blank row above the selected row. This shifts all higher ranks downwards. Disabled if there already are 10 ranks.
If you insert an empty string, the corresponding requirements are set to zero and disabled in the table. Blank rows in the middle of the rank list are deleted when you save your changes.


What implementation do you prefer? Keeping the vanilla style or improving the usability? Anything to add?

OpenMW-CS_FactionRanks_01.png
Ranks in the original CS.
OpenMW-CS_FactionRanks_02.png
Deleting a rank disables the requirement fields and sets all values to zero.
OpenMW-CS_FactionRanks_03.png
The blank row stays until you save and reload your file. Inserting a new rank name enables the requirement fields again.
OpenMW-CS_FactionRanks_04.png
After reloading the file, all rank names have been shifted upwards -- the requirements haven't changed their position. The table's contents are "displaced" now.
OpenMW-CS_FactionRanks_05.png
As you can see, we now have a new empty line at the end of the table to make up for the deleted rank.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Atahualpa's coding adventures

Post by Zini » 17 Mar 2017, 13:56

Your version sound much more sensible than the vanilla one. Can this be done in a re-usable way? We may need to use it in other sub-tables eventually.

User avatar
Atahualpa
Posts: 791
Joined: 09 Feb 2016, 20:03

Re: Atahualpa's coding adventures

Post by Atahualpa » 18 Mar 2017, 21:41

Zini wrote:Can this be done in a re-usable way? We may need to use it in other sub-tables eventually.
That is the plan. I'll tinker around with the code and try to keep our current structure when implementing this.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest