Post 1.0 Plans

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Post 1.0 Plans

Post by Zini »

Well, that took us long enough. But it is finally here:

https://gitlab.com/OpenMW/openmw/blob/m ... -stage1.md

If you want to discuss the design document, comment here or make a new thread. If you want to propose a change please provide a merge request on GitLab (or a pull request on GitHub, if you absolutely must).

Note that the graphics parts are still missing. scrawl was supposed to fill them in, but that didn't happen. We have someone else who will help out with that though. Updates should arrive soon.

Edit: Also note that the design document is still the version with oldscript+. We will not go down this route, but the section is still relevant because newscript will have to cover all the functionality listed here.
User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: Post 1.0 Plans

Post by drummyfish »

Awesome work, I don't think I've ever written so much text... for convenient reading I've created LaTeX-rendered pdf with TOC.
User avatar
Thunderforge
Posts: 503
Joined: 06 Jun 2017, 05:57

Re: Post 1.0 Plans

Post by Thunderforge »

Zini wrote: 27 Jun 2018, 11:18 Edit: Also note that the design document is still the version with oldscript+. We will not go down this route, but the section is still relevant because newscript will have to cover all the functionality listed here.
I'd like to reiterate Zini's point. All of the feedback from the previous discussion of scripting has been taken into account, and the consensus is clearly to adopt newscript (most likely Lua) as opposed to oldscript+. However, the document has not yet been updated to reflect that. Still, the parts of the document are a good system of the sort of things we want to make sure to include.

If anybody would like to update the document to reflect this change, we would appreciate any Merge Requests/Pull Requests to do so.
User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: Post 1.0 Plans

Post by wareya »

Just to ensure that my opinion isn't lost by being in another thread, I'm pro-newscript but completely neutral on Lua. If whoever designs/implements it deems it worthwhile, I would be 100% behind a custom language. Special purpose scripting languages are not hard to make if you're a competent programmer with a lot of experience.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Plans

Post by AnyOldName3 »

I'm not sure that anything custom is a good idea, MWScript-based or not, no matter how trivial the implementation.
  • We have to provide all our own documentation and support, but existing languages have their own documentation and StackOverflow threads. This is a bigger part of language usability to a lot of people than whether or not the language itself is any good.
  • We have to provide our own tools, such as editors and debuggers, but we might be able to include something that already exists into the CS. At the very least, I can copy and paste any common language into Notepad++/Vim/whatever and get syntax highlighting, even if we still need a from-scratch built-in editor and debugger.
  • Given the huge quantity of things that might be de-hardcoded and moved to scripts instead of engine-side C++, I'm not sure that making the language special-purpose is a good idea, as we're potentially going to need all the power of a general-purpose language.
User avatar
wareya
Posts: 338
Joined: 09 May 2015, 13:07

Re: Post 1.0 Plans

Post by wareya »

The point about documentation isn't very salient considering what using Lua for dehardcoding would actually be like in practice. Lua is very minimal.

The state of debugging under Lua is already not very appealing.

Special-purpose just means it's not like python or C++. Lua is already a special purpose language in the sense I'm using the phrase.

Going with Lua would hold back what kinds of syntax newscript could use, and Lua doesn't exactly have fantastic syntax in the first place.
roturier
Posts: 1
Joined: 28 Jun 2018, 00:08

Re: Post 1.0 Plans

Post by roturier »

Thanks for the document. I have some questions,


I assume that contents which are already configurable in the vanilla CS are implied and don't need to be added to the doc? (eg governing magic school, graphics and sounds are implied optional arguments for "Magic Effect")

What does abandoning oldscript mean for basic dialogue functionality in the construction set, since dialogue results are MWscript compiled directly after dialogue? Functions like "Choice" and "Goodbye" are very basic, if they are really meant to be deprecated and their use discouraged, what would dialogue results look like? The functionality provided by these basic elements can still benefit from simple improvements (example: the ability to have a choice in a greeting direct to an entry in a topic), but does that come at the cost of abandoning the intuitive function words? Is a basic form of oldscript+ out of the question for dialogue results, or is the dialogue scripting system to be abandoned in favour of some sort of dialogue tree CS UI, or separate oldscript and non-oldscript result boxes (exclusive or in sequence), or some other system entirely?


Topics: Is the ID feature for topics meant for fast localisation? If several content files use the same name for a new topic but with different "topic IDs", the dialogue topics list would display several identical topic names, even if they should logically overwrite each other without harmful conflict (example: one content file adds flavor dialogue available from general NPCs and uses topic "beer" with a generic entry, and another content file gives another topic "beer" to a particular NPC with a particular entry for a quest) so as a content developer right now I'd still feel compelled to use the actual topic text for topic IDs, and put the responsibility on content loading order to avoid conflict between content files that aren't necessarily aware of each other. All this isn't to say that topic IDs aren't useful, but for localisation, wouldn't a CS tool that scans topic links in all dialogue do a more comprehensive job?

Topics: I see no mention of greetings (the first entry spoken by a NPC), are they also topics, so that new ones could be added? How would the priority of new greetings work with the existing greeting0-9 topics? If greetings will stay common topics like in Morrowind, are there any plans for dialogue sorting improvements to the double-linked list when several content files use the same topic?

Topics: When referencing a topic... from within a dialogue text (this includes journal entries),
a useful functionality to support would be explicitly hyperlinking (referencing) a topic/topicID while displaying different text (text that is not the topicID's text). Having to use exact topic text in sentences to get it hyperlinked leads to awkward phrasing and it's frustrating for writers. Real example: "chairs start flying" is the real topic name, dialogue line wants to use "chairs started flying" but link to "chairs start flying" when clicked on. A player might be confused if they look for a link they used that had text too different from the actual topic, but that's on the content dev.


Instances & Objects: are content files able to apply partial edits to the records and subrecords of an object ("class")? If I understand correctly "Record Variables" could add new subrecords, but how about the ability for a content file to apply or apend edits to existing subrecords without modifying the whole record or subrecord? Example: I create a new faction object "Gente Nueva" and want to add faction reactions to the faction object "Thieves Guild" so that "Thieves Guild" will hate members of "Gente Nueva": in vanilla this cannot be done without modifying the whole "Thieves Guild" faction object. The same issue applies if I want to change a single aspect of a NPC, like giving it a new face: in vanilla this can only be done by by editing the entire NPC and overwriting changes to other subrecords of the NPC from any other content files, even if they would be compatible changes.

Instances & Objects: where does the ability to distinguish instances created in the game come from (vanilla: 8 digits added)


Script Instructions UseSkill (or whatever ends up fulfilling this functionality): does "Progresses the skill id by a value of v" imply that progress counts towards level ups? (as noted later, "Note that regular script instructions that change skill level do not count towards level ups.") Assuming it does, similar functionality that allows you to change skills *without* counting towards level ups would still be useful to have, especially for temporary stat manipulation on companion NPCs if they otherwise get to level up themselves.

General de-hardcoding: what about original morrowind's hardcoded objects (gold, soul gems)?


Some of these topics probably deserve their own thread but I'm not familiar enough with the project to know whether they're worth discussing in-depth so early.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Plans

Post by AnyOldName3 »

While I remember, either I or someone else needs to check that the things typically resolved using Wrye Bash or Mator Smash can be done nicely. E.g. omwaddons need to be able to append to a levelled list without caring what's there, and ideally, as the above post suggests, it would be nice if mods could change small parts of larger records without a total overwrite, for example by specifying that they want to change one field of a record to a specific value, even if this involves extra checkboxes to ensure that the modder thinks that the change should be non-invasive.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Post 1.0 Plans

Post by Chris »

roturier wrote: 28 Jun 2018, 01:28 Topics: When referencing a topic... from within a dialogue text (this includes journal entries),
a useful functionality to support would be explicitly hyperlinking (referencing) a topic/topicID while displaying different text (text that is not the topicID's text). Having to use exact topic text in sentences to get it hyperlinked leads to awkward phrasing and it's frustrating for writers. Real example: "chairs start flying" is the real topic name, dialogue line wants to use "chairs started flying" but link to "chairs start flying" when clicked on. A player might be confused if they look for a link they used that had text too different from the actual topic, but that's on the content dev.
I'd personally prefer to see a complete separation of topics and dialog, and also sorting and categorization of topics. One of my ideas was a way to tag a specific dialog text as having follow-up topics that are listed separately, rather than being highlighted words in the dialog itself. Essentially like a So for example,
Some NPC wrote:Welcome to Balmora, stranger. Haven't seen you before.
Follow-up: I'm new here, About Balmora, Services, Rumors
It would provide links that are relevant to the particular dialog, either as a way to dig deeper into a particular topic or to continue a discussion, while being able to go back to it later at any time and not preventing you from talking about something else. It also doesn't require the developer to write dialog in such a way that specific words or phrases lead on to those follow-ups.

Additionally, it would be nice to see topics sorted into different categories, separating things like specific directions, local information, and general history/lore into separate lists, rather than one massive ever-growing topic list. I'd actually try to take heavy cues from Daggerfall's dialog system (which was really good about providing a sense of dynamic conversations with lots to talk about, while also not being overwhelming), rather than trying to band-aid Morrowind's wiki dialog.
User avatar
rocky1138
Posts: 2
Joined: 26 Sep 2016, 02:15

Re: Post 1.0 Plans

Post by rocky1138 »

Thanks for this. It's excellent. A few remarks (as you've asked for them):
Important: If OpenMW reaches 1.0 before OpenMW-CS, we need to wait for OpenMW-CS to catch up before we continue with feature development.
I appreciate the sentiment, but I don't think this is the right approach. As much as I want OpenMW-CS to be feature-complete, forcing everyone to wait could stall development and even force a hostile fork. With FOSS stuff, I feel like getting as many people involved as quickly as possible is imperative. The features will grow with more people, not less.

If OpenMW-CS has some really long-living incomplete features, consider a bounty. The money can come from crowdsourcing. I know I wouldn't mind throwing a few dollars here or there to see it get finished.
... create a single content directory (per content file) within the data directory. This content directory would then contain the content file and the usual directory structure (Icons, Meshes, Music, ...).
I love this solution. It's always kind of bugged me that all of the assets just get mashed into one directory.
Therefore, the solution here is to simply give the local variable precedence over the ID. If the script author intended to give money to Fargoth, he should not have created a local variable with the same name.
OK.
GMSTs
If you use an acronym, can you define it? I don't know what a GMST is.
Records for the existing types (sys::LightArmorType, sys::MediumArmorType, sys::HeavyArmorType) will be created by the engine when loading older omwgame files (these records are mandatory for newer omwgame files).
Does this mean that we will be able to create more armour types of our own design? ExtraLight, SuperHeavy, etc.
Location-Based Background Music
Vanilla never had this, correct? As far as I could tell, as a player, it just seemed to play non-combat music in sequence.
Graphics
I'd love to see two things:
  • Depth of field
  • Shadows
Post Reply