Larian Studios Forums Divinity - Original Sin Divinity Original Sin - Mods Trouble with dialog system

No, the problem here is only a non-native speaker being unable to clearly say what he means ;-)

The container does not matter at all. It's the same for any container including our character inventories and bags we might have in our inventories.

What I was trying to say was, that we have to be careful when dealing with _ItemHandles, because they do not represent a single item but a complete stack of items. For items that cannot stack like armor or weapons of course, this makes no difference, but it does for all items that are stackable, like basically all ingredients. Which matters for you because you need to deal with ingredients in your crfting mod.

You mentioned before that you don't use something like ItemHandleDelete but something like ItemTemplateRemoveFromCharacter which most likely has an _Amount parameter, so you are not affected.
Just keep in mind that if you ever deal with handles, you have to be careful.


Well, all that matters in the context of treasure generation is, if the call GenerateItems() is ever reached or not. (or CharacterGenerateCustomTradeTreasure())
Those are the Osiris calls that actually trigger treasure generation - and handle use.

Everything else is only setting internal Osiris facts to determine if those calls can be reached or not.

There are other calls of course like CharacterSetCanTrade() which probably only affect if the trade diamond button shows up in a dialog or not.

And yes, Pickpocketing can also start a trade generation, which is no different from the 'regular' trade generation before trading. (After all the game must make sure that the pickpocketed character carries something that can be looted.)

The thing that is still unclear to me is, if characters have the same generation as real containers (barrels, chests, ...), both use treasure tables but the engine could differentiate between them by looking at the root template type, one being a character, the other an item.

If characters also have their treasure pre-created every player levelup and on every zoning, it might be a massive waste of handles. Because on top of that comes the required generation after the stack of items 'waiting in the background' has been 'claimed' by an NPC through an Osiris call.
So there seem to be at least two cases of treasure generation, the standard one on player levelup and zoning - done by the engine alone - and the other on explicit Osiris calls like GenerateItems() (which works only for characters).

The GenerateItems() call looks weird because it takes two characters as parameters, but maybe that is only a relic from previous games. Trade treasure does not change if you trade with different characters, unless a generation is explicitely triggered by character level differences.
I have no idea why the call requires two characters.

Thank you for your answers!

I really have to think about my item transfer plans. Weapon transfer should be okay. But for other items I need handles. And it's quite strange what happens (just for testing purposes):


If all items with this template are one stack it works fine. If there are several stacks only one stack gets transferred, so I have to repeat the event (or the process, what I do in my actual script) until all stacks are transferred.
It seems the engine only picks one handle of several handles (for several stacks) or there is just one handle for one stack and the other stacks are unhandled (would not make sense?).


Maybe it checks the player to relate item level and player level for item generation?

I'm sure all stacks have handles but for the needs Larian had at some points, it was probably enough to return one handle. And it looks like Larian never implement things a more generic way but for a current need.
(This also answers one of my questions, if the GetHandle... query could ever return a tuple if multiple stacks were present: the answer is no then.)

If you wanted to make sure you transfer ALL stacks, you could use a recursive procedure.
I use '-1' as _Amount parameter for the move call, because it transfers a complete stack without the need to pass a specific amount.
(Sorry, I HAD to use spaces between parameters where you didn't because I always find code without them hard to read outside of syntax-coloring places. I also always 'qualify' my own stuff so that chances for name conflicts are lower, thus the name 'AbraxasProc_...' ;-)




That makes sense, thanks for bringing this idea up


I really wish Raze had more time to dig info from Belgium ;-)

I have time, but everyone in Belgium has quite a bit more going on at the moment. What specifically did you want to know?

Do you also have a cat that doesn't like you sleeping on weekends ? ;-)

We are speculating a lot about treasure generation, 'handle waste' and pre-emptive measures to avoid the 'out-of-handles-crash' at the moment. And about how some things in Osiris work.

I don't feel too good about disturbing the devs with obnoxious questions at the moment since D:OS2 understandably has the highest priority at the moment. (Not to mention what other future project they may be working on.)
But if you say it's okay, we could discuss what we'd like to know and compile some questions for Belgium.

I've been following the discussion, but I'm not sure how much detail I'd hope for asking a fairly open ended question. Everyone else has been very busy, getting ready for Gamescom and multiple-country press tours, among other things.
I can preface a few questions with a brief synopsis, so anyone not familiar with the system, or without time to answer, can skip the rest. Or it can wait, but I'm not sure there is going to be a significantly less busy time period before D:OS 2 is released.

Any answer that might help us understand the system is better than none.

But I'm still reluctant because it looks like we probably won't get too many chances to get real info directly from the source. I would not want to waste that chance.
Maybe some other forum people like Abraxas or Sniper (or someone not yet directly involved in this discussion) might want to add their thoughts before you 'shoot'.

We are all well aware that handing out info to modders is not Larian's highest priority, can never be and will never be.

Our late discussion has been a lot about handles and preventing waste of them.

So some additional questions already came up in my mind that have not even been discussed in this thread:

- does creating new items via script (Osiris and character/item scripts) or crafting use new handles even if the new item can be added to an existing stack ?
- does a treasure table entry with a minus (like 'new subtable "-10"') fill a stack without using a new handle if an item of that type still present in an NPC inventory ? (the reason why I ask this is that I do not understand the difference between 'new subtable "-1"' and 'new subtable "1,1"' which have the same effect but two different notations)
- does adding items (or parts of a stack) to the trade window already use a new (intermediate) handle ?
- do 'incomplete' objects use handles ? (those without assigned stats, decoration like bushes, walls, ... or a spawned mattress if I remove the stat; I might have to use pre-placed globals and move and SetOnStage() instead of spawning)
- do characters get their handles from the same pool as items ? (would affect summoning and spawning, other characters are pre-placed and hopefully never need to change handles ;-)

Even more questions might arise.

Most important:
If there is anything we can do to push the inevitable reaching of the limit further away without totally stripping the game of everything it currently has (like totally emptying most treasure tables), we shall attempt to do it. It would give us more freedom in mods.
(Well, Sniper is probably very far away from the limit because his standalone mod is way smaller than Main ;-)

The responses:

- all new item instances will create a new handle. Even it the new item is added to an existing stack, it will have created a new one temporarily
- both cases in treasure use up handles in the same way. -1 is guaranteed to give you what you ask, while 1,1 may fail to find level-appropriate items and you won't get anything
- if by incomplete objects, they mean scenery, yes those use handles as well, but they come from a different pool. Sceneries are objects which are purely decoration though. So as soon as you can to interact with it, or reason about in scripting, it will be an item. Globals can never be scenery, as scripting can reason about them.
- characters, items, scenery, triggers all get their handles from different pools. Handles never change for existing instances, but each time you spawn (by script/skills/...) a new instance, a new handle will be created.

Thanks a thousand times for digging out this info although it's really bad news ;-)


This hits crafting really hard.
(Even splitting stacks is 'bad' if I understand correctly. If I'm wrong though it would mean that I could actually access two or more items by one _ItemHandle in Osiris ;-)

Would still be interesting if creating more than one item at a time uses only one handle, because if it did, using the 'Recipes' page of the crafting window could help some, since it allows for complete stacks to be created in a single step. The 'Experiment' page does not support this.
So an open question would still be if creating a stack in crafting is a 'single item instance'.

Looks like every 'extended crafting' mod is really poison in the whole 'new instance' context ... and I have to rethink a lot of my item conversion recipes ;-)


I found this out in my recent tests but good to get confirmation


So at least we do not start out with a horribly high number of used handles right at the beginning.
I might change some of my pre-placed stuff to 'Scenery' in the editor because it's pure decoration.
(And thanks, this also explains what the 'IsScenery' checkbox means.)


That means we do not need to care about anything besides items because it would take far more of all the other stuff to create problems, far more.

Yesterday I found out that treasure is most likely NOT pre-generated on zoning or levelup but still on demand, only the algorithm for creation changed.
Some info about treasure generation

This makes me more confused than ever how the crash on zoning could happen, because if generation is no pre-generation, what could have caused the crashes ? Did we trade more than before ? That much more ?
(I had the crashes twice when I was already in Hunter's Edge, still very far from 500 hours. Others had them too when it had rarely happened in classic. All I had changed for my first successful playthrough was increase root template stack sizes and add recipes for item destruction/conversion. Seriously confused ... even more so since I think some people with zoning crashes could still continue playing but were locked out of the zones that caused crashes.)


I guess there is no chance we ever get a code fix which uses a 32bit int instead of a 16 bit small for handle counters in 'old EE'.
(Just mentioning because D:OS2 does not look very appetizing now that a lot of focus must be on 'the PvP thing', e.g. restricting amount of usable skills with 'Memory' is only explainable with making the upcoming 'PvP balancing hell' a little bit more bearable for Larian IMO ;-)

If D:OS 2 limited the learning of skills like the EE does, it would greatly detract from the mechanism of skill book crafting and discourage experimentation both with crafting and trying different skill combinations.
Limiting the number of active skills in combat doesn't reduce the number of possible permutations (the current intent is that a small investment in memory will give the same number of skills as a specialist build in the EE, while focusing on it would give a skillset larger than was possible in the EE).