Atahualpa's coding adventures

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

Re: Atahualpa's coding adventures

Post by Atahualpa »

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: 1176
Joined: 09 Feb 2016, 20:03

Re: Atahualpa's coding adventures

Post by Atahualpa »

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?

Ranks in the original CS.
Ranks in the original CS.
Deleting a rank disables the requirement fields and sets all values to zero.
Deleting a rank disables the requirement fields and sets all values to zero.
The blank row stays until you save and reload your file. Inserting a new rank name enables the requirement fields again.
The blank row stays until you save and reload your file. Inserting a new rank name enables the requirement fields again.
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.
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.
As you can see, we now have a new empty line at the end of the table to make up for the deleted rank.
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: 5538
Joined: 06 Aug 2011, 15:16

Re: Atahualpa's coding adventures

Post by Zini »

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: 1176
Joined: 09 Feb 2016, 20:03

Re: Atahualpa's coding adventures

Post by Atahualpa »

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