- Objects vars can now be removed via ClearVarObject.
I don't quite understand; this would remove a variable from the object? If so, would the object regenerate the variable on future inits or not?
This would remove an object type variable from an object. You can set int values to 0, or some other value to indicate "emptiness", however there is no "NULL" object UUID (although that would be a good idea), so the "reset to initial value" or "reset to null" function for objects is
ClearVarObject.
But I wonder what this means in consequence
I believe what they did is instead of assigning it a "local" handle that is invalidated when the item is moved, dropped, transferred, etc., they gave each item a unique UUID that persists even when the item is manipulated or moved.
And would this last mentioned call be able to output several items for several stacks of an item template in inventory? 'GetItemhandleForItemTemplateInInventory(CHARACTER Character, STRING Template, OUT INT Itemhandle)' always returned the handle of one stack and therefore required to move the item handle out of inventory to return the handle of another stack.
I'm not sure, it depends on how they translated the old function call. Theoretically it can return multiple rows.
Though since I'm still working on D:OS 1 EE, my fears, similar to FrauBlake's who's my Brother in Paranoia, have returned in regard to FX and potion handles (there are status handles, too?).
Effects use the same global handle pool as far as I know. About statuses I'm not sure, the old savegames didn't assign an ID to them as they weren't "entities", so I think statuses don't count towards the limit. But since effects do, sooner or later you'll run out of them
Speaking of D:OS 1 EE: Is it possible to run out of handles here as well? I mean: what if I double or triple the amount of used effects, potions and statuses for an average playthrough through scripting, would I introduce a ticking bomb into the game?
Some attempts were made to reduce the number of handles used in the EE, but they wouldn't have converted everything to a 64-bit system if it wasn't really necessary, so I believe that it is still a very real problem in the EE, yes. Although a 32-bit ID would theoretically allow 4 billion items to exist, in practice many of these 32 bits are reserved for other purposes, and depending on their usage the actual maximum item count may be as low as 65k or such. Also it is my impression that the handles function like a counter, not like a pool, so creating an item with ID 1234 and later destroying that item won't allow the engine to re-use that ID later.
Also I'd like to correct my previous post a bit: I used the "old" (D:OS and EE) types for the D:OS 2 function signatures because that was the best way to compare them against the old signatures; the actual signatures have more specific types. To give you an example, the
SetVarObject(STRING Source, STRING VarName, STRING Object) function mentioned above in fact looks like this:
SetVarObject(GUIDSTRING Source, STRING VarName, GUIDSTRING Object). Basically,
GUIDSTRING is the new umbrella type for all "entity-like" objects, and the
ITEMGUID / CHARACTERGUID / TRIGGERGUID are its aliases. This means that it is legal to pass an ITEMGUID as a parameter to a function that expects a
GUIDSTRING. I'm not sure if the reverse is true.
Random musings:
I was thinking about how I would explain Osiris scripting to someone who hasn't seen it before, and I believe the best analogue would be relational databases (SQL). "Events" (in Osi terms) would be triggers, each "query" and "database" would be a relational join.
For example the following rule:
IF
StoryEvent(CHARACTERGUID_S_FTJ_AlcoveChild_001,"JoinCombatWithUnnis")
AND
DB_CombatCharacters(CHARACTERGUID_S_FTJ_AlcoveChild_001,_ID)
AND
DB_CombatObjects(_Char,_ID)
AND
_Char != CHARACTERGUID_S_FTJ_AlcoveChild_001
THEN
EndTurn(_Char);
... could be expressed in SQL like this*:
SELECT EndTurn(_Char)
FROM StoryEvent('CHARACTERGUID_S_FTJ_AlcoveChild_001', 'JoinCombatWithUnnis') AS SE
CROSS JOIN DB_CombatCharacters AS DB_CC
INNER JOIN DB_CombatObjects AS DB_CO ON (DB_CC._ID = DB_CO._ID)
WHERE DB_CC._Char = 'CHARACTERGUID_S_FTJ_AlcoveChild_001'
AND DB_CO._Char <> 'CHARACTERGUID_S_FTJ_AlcoveChild_001'
* technically this wouldn't work as StoryEvent is a trigger, but I'll ignore that to demonstrate the concept. Each "AND" in Osiris is basically an implicit join.
Is the distinction of global and non-global items removed then?
I don't think so. They're still stored in a separate folder (
Mods\DivinityOrigins_1301db3d-1f54-4e98-9be5-5094030916e4\Globals) and seem to be handled differently from local objects.
Globals were probably introduced for performance reasons (accessing any game object from any part of the game would mean that either all game objects should be loaded all the time, or they could be loaded on-demand, which would cause script functions to stall the game engine while the load is ongoing, effectively lagging the game), and I think those reasons are still valid today, so I believe globals are here to stay. I don't think I have seen any game where this problem was solved in a painless way. Bethesda games have "global-lite" objects; they are kinda global, but have many weird restrictions around them and scripting is anything but fast. (Go search for "skyrim script lag" to see what I mean.) Infinity Engine games used global variables for passing data between different maps, and area enter/exit scripts to execute the needed changes based on the globals. Ultima games went even further and needed "enterFastArea/leaveFastArea" scripts when characters left the player's immediate vicinity, to have bearable performance. (They also had a nifty scripting engine that used cooperative multitasking and x86-like bytecode; quite advanced for its time.)
