Larian Banner: Baldur's Gate Patch 9
Previous Thread
Next Thread
Print Thread
#647326 10/07/18 12:40 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
I recently edited and added a hand full of pages to the Osiris section of the wiki. However, there seems to be no contribution guidelines (like with the community guides here: https://docs.larian.game/Community_guides), so I was wondering whether this is okay or whether Larian has other plans for the Osiris section in the wiki?

If it is okay to edit the Osiris pages in the wiki, I would have some suggestions / questions:

- Should we mark pages created / edited by the community so it becomes obvious that the information on that page is not provided by Larian (and therefore might not be complete or can contain errors)?

- There is a "See also" section beneath each doc that is quite handy, but I think that this might become pretty unmanageable if we add more docs to the wiki. I would suggest to create categories for certain scripting topics (e.g. a category "Dialogs" or "Combat") and collect calls, events and queries targeting certain topics there.

- Would it be okay to add all definitions from the story headers to the wiki so we can brose / search / categorize them although for the beginning the pages would not contain much more that the function definitions? I'm unsure about that one, there is a wikia wiki somewhere out there in the wild that has just done that and its always leaves an underwhelming feeling upon finding it. But on the other hand those stub entries would give a better overview and might be a good starting point to further develop the docs.

DerCapac #647328 10/07/18 12:49 PM
Joined: Sep 2017
Location: Belgium, Ghent
addict
Offline
addict
Joined: Sep 2017
Location: Belgium, Ghent
Sections outside of the Community Guides are generally locked from public editing.
If a certain page is accessible, that was a mistake on our end.

That being said, your contributions are definitely appreciated! I would generally advice to put them under the community section so we can review them more easily. Normally I would then move them into a community section of Osiris. But if you want to make suggestions to existing pages, you can denote as such on the page you create in the community section, or just ask us directly (like here) and we'll see if we can integrate your suggestions into the actual Osiris section smile

I'm going to defer to Tinkerer for the specific suggestions about the Osiris section, as he has a better overview of that section's structure smile

Sincerely,
Kevin


CTRL+K the elf
DerCapac #647330 10/07/18 12:53 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Okay, then I'm sorry to have messed around there. If the pages shouldn't be editable then you should check on that again cause to me it looks like I am able to edit all pages in the Osiris section.

Last edited by DerCapac; 10/07/18 12:54 PM.
DerCapac #647331 10/07/18 12:57 PM
Joined: Sep 2017
Location: Belgium, Ghent
addict
Offline
addict
Joined: Sep 2017
Location: Belgium, Ghent
No problem laugh It's great to see people interested in the wiki smile

We get notified of changes, so we can always check and revert things. It's just a safety measure against spam. We'll indeed take a look at the user privileges of the Osiris Section then.


CTRL+K the elf
DerCapac #647341 11/07/18 08:52 AM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
As far as I'm concerned, it's fine that anyone can edit the Osiris API pages. I indeed go over newly added pages and check them for errors. At some point, I'll also try to complete them by looking at the code and documenting all failure conditions and the like.

As to the other suggestions:
* You could add community-created pages also to their own category, if you want. I (or someone else) can then remove them from it once the information has been verified.
* Adding categories for thematic calls/queries/events are fine, but I'd still like to keep the individual "See also" lists as well. E.g. CharacterMoveTo links to StoryEvent because when it finishes, it throws an event and StoryEvent is how you catch events.
* Creating stub pages for all undocumented APIs: after a while, I started linking related APIs even if there was no page for them yet, but I'm not a big fan of adding pages for all undocumented calls already. If you wish to see what is available, you can just open the story header from the story editor's File menu). I had a similar experience as you did with DOS1 back in the day when modding (I didn't work for Larian yet at that time), and I'm not really keen on repeating it. That said, have you seen https://docs.larian.game/User:Sunjammer/api ? I think it fulfils basically the same function, and at the same time it is clear what has been documented and what not (and we could create a separate version for DE once it comes out, so its clear what's in the original DOS2 and what's in DOS2:DE).

DerCapac #648047 16/08/18 04:07 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Okay, little follow up question: How are the contents of the Wiki licensed? When editing a page the Wiki tells me to check https://docs.larian.game/Divinity_Engine_Wiki:Copyrights but the page does not exist.

Background: I'm working on a tool that fetches data from the Wiki. Currently I am investigating possibilities for a even deeper integration but that would cause a large amount of requests being made so I'm thinking of shipping my tool with cached snippets from the Wiki. As I would republish contents from the Wiki in that case I want to make sure I don't violate any copyright claims.

DerCapac #648098 19/08/18 10:26 AM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
I planned on bringing this up internally on Friday, but I forgot. I'll try to do it tomorrow.

There are plans on showing the wiki data also in the editor, so the concept of fetching and displaying data should not be a problem. I'm also fairly confident that bots from search engines and spammers request way more data per day than development tools like yours (or ours) ever will.

Regarding the licensing, that's indeed a bit of a can of worms. I'm sure we can license the Larian-created content under CC-BY-SA or a similar permissive license. However, we cannot do that for content that has been added by other people, or for e.g. Drathe's images that adorn the home page. So we'll have to see how to tackle that.

DerCapac #648099 19/08/18 12:17 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Thank you for taking your time looking into this. It's great to hear that you are considering using a CC license, and I totally understand that this is something a company has to reflect on before taking the step.

I just checked the user contributions on the Wiki and luckily the Osiris API section looks pretty clean, so a license switch should be possible for this section. The rest of Wiki, well, it looks more complicated (but I don't know which users are exactly Larian employees). Handling of and working with the Wiki would be a lot of easier if all contents live beneath the same license.

The reason I'm thinking about caching the pages beforehand is that the editor I'm building my extension for offers a feature called "Signature help". It's a little window that pops up every time you start writing a function call. It displays a preview of the function and also can display short help texts. The editor internally triggers the lookup code for that feature on a lot of keystrokes, therefore I need some kind of cache. Also, the short help text sometimes needs to be handpicked from the Wiki, the first sentence of the description is not always a good choice. So currently I scan the Wiki for API articles, create a snippet file with the extracted contents for each API method and review / edit them afterwards. I also use these files to organize all the API calls into categories.

DerCapac #648109 19/08/18 06:40 PM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
I think that apart from me, all Larian employees use a handle that starts with "lar". I agree that having everything under one license would be the easiest, but we cannot just relicense everything that other people wrote without their explicit consent. I don't know what the best way of handling this is. Mailing everyone to ask whether they're okay and deleting their contributions if they're not or don't reply is one way, but not necessarily the best.

Regarding the description, maybe we could add a one-line summary to all API wiki pages, like we have internally in the code for behaviour script.

And yes, caching is definitely a good idea.

DerCapac #648111 19/08/18 09:18 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Of course, retroactively applying a licence to the contributed content is not doable. As there are no licencing rules on the Wiki right now, probably the regular copyright laws kick in. But I didn't want to make it so complicated, in the end the Wiki is mainly driven by Larian and some enthusiasts, and I'm sure a good solution that suits everyone can be found.

Adding an explicit summary to the Wiki seems like a lot of work and I personally think it makes more sense to invest valuable time in filling in the gaps. (Like you just did, now we know what HappyWithDeal and ExecuteDeal actually do!) I was also thinking of adding a generated markdown snippet to my documentation view so new entries could be created more easily (those ''' around the signatures always cause headaches and could be generated automatically)

Also, in the end users might not like the feature at all and would prefer to quickly open the documentation. So if you should decide to go with a permissive licence we could take the current state of the extension as a test balloon and see if people actually like it.

DerCapac #648120 20/08/18 07:12 AM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
I realised last night in bed that you actually don't need to care about the license of the wiki. The reason is that browser caches are legal, and your tool is doing exactly the same as a browser cache:
* https://books.google.be/books?id=I9...hing%20exemption%20copyright&f=false
* https://law.stackexchange.com/quest...ount-as-copyright-infringement/3589#3589

The links above only cover the EU and US, but I'm not aware of browser caches being contentious or disabled in other parts of the world. That said, it's of course a good idea to fix the licensing limbo of the wiki content in any case.

Regarding the summaries, I agree that in the end they're probably superfluous. However, maybe instead of editing them locally, you could just edit the descriptions on the wiki directly to ensure that the first sentence of the description always summarises its function? I don't foresee any problems such changes could cause.

Glad you like the updates!

DerCapac #648169 21/08/18 09:47 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Great, with the legal issues out of the way I decided to publish my extension for VS Code. In case you are interested in what I've done to the Wiki, you may find it both on GitHub (https://github.com/sebastian-lenz/divinity-vscode) as well as on the VS Code marketplace (https://marketplace.visualstudio.com/items?itemName=sebastian-lenz.divinity-vscode).

DerCapac #648232 25/08/18 02:15 PM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
Quite impressive! smile The main wish of the people who tried it here was for it to handle mod dependencies, but looking at the commit history, it seems you already added that in the mean time.

Another observation was that the warnings don't take into account suppression files regarding unused databases, until they realised that this is a new feature in DE that you can't know about yet (or, in case you got early access, aren't allowed to talk about smile ).

In any case, it's not a big secret. Sometimes, the Osiris compiler did not catch typos in database names. For example:

Code
IF
CharacterDied(_Player)
AND
DB_FreeResurrect(_Player)
AND
DB_Player(_Player)
THEN
// Free resurrect for players!
CharacterResurrect(_Player);
// Not twice in a row
NOT DB_FreeResurrected(_Player);


The DB_Player in the above fragment should read DB_IsPlayer, and the DB_FreeResurrected should be DB_FreeResurrect. Osiris did not notice anything wrong with this fragment because it can infer the type of the _Player variable from the CharacterDied event signature.

In order to catch such errors, the Osiris compiler now gives warnings (which are treated as errors; it previously has some similar warnings that only appeared in the log file but did not trigger errors and were not shown in the regular story editor) for all databases that either only checked or only defined in all story goals of the current mod and any mod it depends on. After all, such checks will always fail and such defines will never be used.

However, this can result in false positives. A common example is helpers in the Shared mod, which often check databases that will only be defined in other mods that actually make use of these helpers. To suppress these false positives, a new file can be added in the Story directory of a mod, with the name story_orphanqueries_ignore_local.txt. Every line of this file contains the name of a database followed by its arity (= number of fields/parameters).

When compiling a mod, the contents of all story_orphanqueries_ignore_local.txt files from the dependent mod and this mod are merged, so the ones defined in the Shared mod will also apply to your own mod.

In addition to the previous file, there are two more files you may now see in the Story directory of a Mod:
* story_orphanqueries_ignore.txt: this file is recreated by the story editor every time you compile story (so no need to restart after changing the story_orphanqueries_ignore_local.txt file). It simply contains the contents of all relevant story_orphanqueries_ignore_local.txt files: the one from the current mod and any mod it depends on. This is the file that is read by the Osiris compiler to determine which warnings it should not show. Since it gets overwritten every time, don’t make changes to it since they will get lost.
* story_orphanqueries_found.txt: this file is generated by the Osiris compiler every time you build story, and contains all of the databases for which it gave the aforementioned warning. These databases are in the same format as used by story_orphanqueries_ignore_local.txt, so you can just copy/paste its contents in case these are new false positives that should be suppressed.

One final note: the line number printed for these warnings is bogus, as no line number information is available anymore at the time it gets shown. In general ctrl-shift-f for the database name will be the easiest way to find the location(s) where it is used/defined.

DerCapac #648246 26/08/18 09:38 PM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
Awesome, it's really cool that you took the time for looking into my extension!

I'm unsure what you mean about the missing mod support, could you give me a hint of what did not work for you? A known issue is that the code completion currently does not pick up items from depended levels (as it only scans the *.lsf files in the current project directory). I've tested the extension against projects depending on the main game and the goals of the main game showed up. However my code currently strongly relies on an up to date story.div being present as it reads the goals from it. As this strategy comes with a lot of issues attached to it, the next version will pull this data directly from the other mod directories or the pak files.

Indeed, I don't have early access so I was not aware of the new files for ignoring unused databases. Thanks for the good explanation, I will implement that once the DE version has landed.

DerCapac #649277 10/09/18 09:29 AM
Joined: Feb 2018
D
apprentice
OP Offline
apprentice
D
Joined: Feb 2018
New version is out which adds better mod support and support for "story_orphanqueries_ignore_local.txt" files. Also, magician Norbyte showed up and burned all of his source points to add some really astonishing new features.

DerCapac #649335 11/09/18 06:44 AM
Joined: Mar 2016
Location: Belgium
T
addict
Offline
addict
T
Joined: Mar 2016
Location: Belgium
Yes, Kevin forwarded a discord message about it on our internal chat. A complete Osiris compiler with debugger support?! You guys are becoming absolute heroes of the scripters here smile


Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5