Hi!

We posted 3 word docs about on our official website:

http://www.divinityoriginalsin.com/download.php

One about how to create dialogs, the other about useful Osiris tricks and another one about what we call good practice. Hopefully these help some of you out there. We expect to add more in the future!

Amazing. Thanks for responding to our requests for official written documentation! I did notice a few typos, but nothing too major. Keep up the good work, and hopefully this is a precursor to some general improvements to the editor

Added a Word doc about combat, which gives a glimpse of stats as well.

http://www.divinityoriginalsin.com/download.php

Another great document, although I wish the document explained more stuff about alignments (like how Also, the Useful Osiris Systems document would really benefit from explanations of the code behind the databases. These databases are only useful if your mod is dependent on main. Much more work, yes, but many more benefits for users. Once again, stellar work anyhow; I just think the docs shouldn't assume main is dependent.

Thank you, thank you, thank you. Please keep them coming!

I liked the Creating Combat document, although I think it should be called Creating Combat and Characters since it goes into the details behind the characters.

I noticed that the document said its possible to create custom treasure tables, but I can't think of any instance where we have been able to successfully do this. The game completely ignores any attempts to modify treasure tables, or add our own.

The combat commands don't work for me in the editor. I've tried them in edit mode and run mode. I'm talking about the ones that involve hitting Ctrl+Shift+* For instance R is supposed to rez your character. That would be really useful if it worked.

Hi,

i noticed that DOS seems to load all "Stat" files of all mods and the "main" values.
It seems it than depends on how the values are internally handled, so the "TreasureTable.txt" seems to override a entry with the same name, going by the editor log warnings.

The problem is that ItemCombos.txt or other files are always just added, so it is not possible to remove or modify a given combination, just add a new or extra one.

So as example i was trying to add extra boosts for weapons to earlier requirements like BR 3-4. What happens is that while my new entires become available, the old versions are also still active. So as example i'm unable to remove old crafted boosts from the tables and replace them completely with new values.

Is there some way to control what tables are overridden by name and which are added? A list per excel file would be nice, so we understand what original values will always be active and which can be completely changed.

I would also like to have more control over what tables are added to existing ones and which should completely replace old tables.

As example, its a real pain to try mod item combos if you cant actually fully replace the original tables via mod.


Thx Andy

PS: A quick hack would be to use a special named "Stats Override" folder which controls that any stat files in this folder will completely replace the tables, instead of adding to existing entries.

I also just noticed that the numerical "Requirements" from the weapon.txt are ignored for crafted weapons? Can someone explain how and where the "Requirements" values are calculated and if the scaling can be changed somehow?

I tried to add more variety to crafted weapons, so you can have lower quality weapons with low requirements and higher quality weapons with higher req., but without the information where the crafted scaling is coming from and how to change it, this is simply not possible.

I know that the "AutoLevel" value in the itemcombos is what causes the crafted weapon to "level" to your HL, while all other weapons are 1:1 lookups via "Act" level from the item tables. So theoretically i could change crafted tables to use this 1:1 relation too and steer requirements, but thats a huge pain in the a..! Thats because i would need HL1-20 entries and duplicate those for CR/BR 1-5 levels, which would become a huge mess to maintain.

From what i can see the only reason this is done for none crafted weapons is to be able to use different roottemplates, which are basically just different mesh's and icons.

What i was expecting is that the "Strength 6" entry for crafted weapons is a 1-10 scale, that than gets "leveled" by the logic. Atm this value is completely ignored and all crafted weapons always end up with the exact same requirements, no matter if you enter "Strength 1" or "Strength 10", which makes it impossible to create any new weapons that differ from this auto formula.

Mhh seems either my posts are to long or no one can answer my questions, so here are 2 short questions.

1) Where does the numerical "Requirement" values for crafted items come from?
2) How can you override/clear a existing "stats" table entry so you don't have org. and new entries mixed up, for the "item combos" tables?

In the "creating combat" file, it says that
Ctrl+Shift+F11 opens the Console.
On my system, that combination does nothing, whether it be in-game, in the editor, or in the editor game mode.
It also says Ctrl+Shift select an enemy, but that combo does nothing, either.

Many of those shortcuts and commands are not enabled in the public version of the editor.

Oh!
Well that explains, then!
Thanks.

Another problem with stuff from the official documentation. Might be the same reason.
Registering and Unregistering triggers does nothing.

With a sample trigger called SampleTrigger, I've got the following code to test the feature.



As you see, if a character enters the area, the trigger should get unregistered for them, causing the LeftTrigger event to be fired, so they first turn to stone and then burst into flames. That's what the official documentation says, anyway.
It doesn't. People get properly petrified if they walk out of it, but if they walk in, the unregistering does not cause the second part to activate. Repeated walking into the trigger by the same character also causes them to combust repeatedly, unregistering notwithstanding.

I just used your script with exactly those calls and it worked fine.

How do you have the trigger registered? Are you using registerforcharacter or registerforplayers? I used registerforplayers.

Also which doc are you reading this particular line from?



I'd probably tackle this problem differently anyway, the time between the character burning and being petrified is tiny.


I'd do this:
IF
CharacterEnteredTrigger(_Player, TRIGGER_GR_SampleTrigger)
THEN
CharacterApplyStatus(_Player, "PETRIFIED", 15.0, 10);
TriggerUnregisterForCharacter(TRIGGER_GR_SampleTrigger,_Player);
BurnThePlayer(_Player);

PROC
BurnThePlayer((CHARACTER)_Player)
THEN
CharacterApplyStatus(_Player, "BURNING", 3.0, 1);

The "useful Osiris systems" document describes the registering stuff.

The point of the code was simply to test Register and Unregister functionality, not for the time difference, with the status applications just to indicate various pieces of the code had fired correctly. Your snippet is probably better if I really wanted someone to be burned and petrified.

Anyway, meanwhile I resolved my original problem, thanks.
EDIT: Actually no I didn't.
If I use my original code, with RegisterForPlayers in the Init, then the petrification and burning effects fire every time the character enters the trigger.
Unless I misunderstand something, after it has been unregistered once, that character's entering the trigger should cause no event to fire whatsoever, so that the character should get put on fire and petrified exactly once, upon entering the trigger.

When testing, did you use an EventTrigger or a BoxTrigger?

Box trigger.

Never used an EventTrigger. Larian doesn't really seem to use them much either, I think they might be a legacy item from old games.

On the unregistering thing, If you use unregisterforcharacters it should unregister for that character only. If you use unregisterforplayers it will stop future events for other players and not just the one character.

If you are getting repeats on the same character with either one of those calls something is wrong, because I know those calls work.

Yeah, something's wrong alright.

Just tried the same code I posted above (except I fixed the bit on line 8 where I had a typo in the trigger name) with an EventTrigger whose Root Template I changed to a Boxtrigger.
This is what happens:
As the character enters the first time (and doesn't exit).
Character gets the Burning status, then the Petrified status.
If the Petrified status fired while the character is still in the trigger, that means it is now unregistered... apparently.

Character leaves trigger.
Petrified status is applied again.

Character re-enters trigger.
Burning Status is applied again, Petrified status is not applied again.

Character re-exits status.
Petrified status is applied again.


So far, the code appears to work as expected for a normal Boxtrigger.
So I suppose the lesson is that EventTriggers can be Unregistered, but fire events even if they are?

One more thing I should probably have addressed before: the dialog file states,
"Before you start creating your speakers and voices, make sure you have the speaker file (\LSProjects\EyesOfAChild\Data\Mods\Main\Story\Voice\Speakers.lsb) checked out. You can do this by pressing the 1 button."

If I press the 1 button, I get a "Fileaccess: Could not open filename" error.
Any ideas why?

Also where is this CharmIntimidate.template anyway?

The checked out thing is not necessary since I believe that locks the file from editing by other larian people. A solo modder wouldn't need that and the checkout function doesn't do anything in the public editor anyway.

You can create speakers though anyway through the speaker manager, it's one of the buttons on the toolbar. Speakers aren't strictly necessary but can be helpful for assigning dialogs in the keyword editor. You can still do it without them but you can only keep track of them by speaker number.

Not sure on the template, I would check the extracted main pak file.

You can probably straight up take the speakers.lsb file from the MAIN pak and put it in your mod as well. That way all the voices would be properly attached. I just remade them to my own liking using the voice acting sheets you can also find in the pak files.

The time between applying the statuses does not matter, if you want one, you have to use a timer.
With the way Osiris works, it is even hard to create 'racing conditions' (although possible ;-)

What is important to know is that what Larian calls an 'event' is not what you would probably expect from events (or if you know interrupts for processors or whatever).
They do not 'fire' immediately, they are queued and executed at some later point when 'their time has come', i.e. when they are next in the execution stack.
So the first chance for an 'event handler' to be executed is AFTER your current statement has completely finished, which includes all procedure calls and all other handlers, in the case above, all CharacterEnteredTrigger() handlers throughout the code, because Osiris needs to check at least if the 'a character entered a trigger' condition of all other rules need to be considered in this situation.
(Your handler might be the last one executed, depending on the file name.)

It also does not matter, where in your code you put a handler, Larian often puts them between two procedures of the same name (especially the TimerFinished() event), putting it between two PROCs does not mean it will be executed immediately though. It will be executed at the earliest AFTER all PROCs of that name have finished executing. Some other 'events' might have been queued earlier though and will be executed before. Calls and rules from setting values are executed immediately (With the 'rules' I mean stuff like IF DB_Companion( _Companion ) ...). 'Events' are not.

That means for example, that you cannot set a variable in a PROC, add items to the inventory, clean that variable at the end of your procedures and use that variable in the ItemTemplateAddedToCharacter() event because it will no longer exist there since you cleaned it before the event actually executes.
It took me forever and tons of testing (and a lot of tears ;-) to find out why some pieces of my code did not work although I expected them to work, always thinking of 'traditional events'.

In the original example it could be that no 'event' is actually executed because by the time the event 'fires', there is no longer a trigger. (But I'm not sure about that, did not do anything with triggers yet except for simple point triggers for teleporting. I'm also not sure if unregistering a trigger should even 'fire' the LeftTrigger() event at all.)