Larian Banner: Baldur's Gate Patch 9
Previous Thread
Next Thread
Print Thread
Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Link to Pastebin . I put this together in Sublime Text and this forum isn't maintaining the styling. I did try to add code tags where appropriate, but I'm exhausted.


This is going to be a very long post, apologies in advance. I also want to preface this with as much love as I can. This genre continues to be one of my favorites, and I have really been enjoying my time modding it. I only ask all of this so I can help contribute to the growth and survival of this genre, and thus, Divinity itself. As always, I appreciate any time Larian can take out of their schedule to discuss or read this feedback. Know that I make this feedback as a source of ideas to draw on not only for future Divinity 2 patches, but for the future of the engine/editor in general.

Also, I only use the word Iterator on some of these calls to denote a loop. You guys seem to view an Iteration as an async process in some spots, so choose whatever internal definition you need. I am simply using it to make it explicit that I am doing a loop.

First, I want to point to a post I made a few weeks back, http://larian.com/forums/ubbthreads.php?ubb=showflat&Number=628376#Post628376. I will be re-hashing some of the points made in this post as I have more perspective and can better articulate what I feel is required. That being said, here we go.


Script

I will be providing proposed Osiris Script APIs in each section, but here I want to specifically address the absence of two very important methods.

Code
String.Split() and String.SubStr()


These are important because it lets us create naming schemas. For example:

Code
	ASC_PROC_75_LightningBolt
	


With String.Split, I could split something like this up into a projectile (LightningBolt) and a potency (75). This, combined with the suggested ApplyDamage calls, is incredibly powerful. I could achieve similar things with String.SubStr, but it would be more unwiedly. Thus, I propose the following Queries.

Code
	String -> StringSplit((STRING)_String, (STRING)_Delimiter, (INTEGER)_Index, [OUT](STRING)_Result)
	String -> StringSplitIterator((STRING)_String, (STRING)_Delimiter, [OUT](STRING)_Result)
	String -> StringSub((STRING)_String, (INTEGER)_Start, (INTEGER)_End, [OUT](STRING)_Result)
	


I would imagine these are both pretty simple implementations as they likely map to very simple underlying workflows.

To make my case stronger, here is a usecase I would actually use, right now.

Code
	Skillnames: 
		ASC_FAKE_MODS_BOW-CROSSBOW_Ricochet
		ASC_BOW_Ricochet
		ASC_CROSSBOW_Ricochet

	IF
	  CharacterUsedSkillOnTarget(_Caster, (CHARACTERGUID)_Target, _Skill)
	AND
		StringContains(_Skill, "_FAKE_", 1)
	AND
		StringSplit(_Skill, "_", 4, _ModifierGroup)
	AND
		StringSplitIterator(_ModifierGroup, "-", _Status)
	AND
		StringConcatenate("ASC_", _Status, _Modifier)
	AND
		HasActiveStatus(_Modifier, 1)
	AND
		StringSplit(_Skill, "_", 5, _SkillName)
	AND
		StringConcatenate(_Modifier, "_" , _First)
	AND
		StringConcatenate(_First, _SkillName, _RicochetToUse)
	THEN
		CharacterUseSkill(_Caster, _RicochetToUse, _Target, 1, 1);
	


This lets me designate skills as "Fake", and then based on criteria hotswap them with another skill, allowing me to dynamically change skills on the fly. The problem is, because I don't have a String.Split() call, I have to perform a number of lookup calls (One for status, One for Skills to map to, and possibly one for Animation not listed here. There might be more as well as I get further into this) I know it isn't easy to read, but it's a common structure I can use that would be efficient as hell both in performance and long-term resource usage as I expect some of these lists to grow very, very large.


Runes


Stats -> Extra Properties -> Self:OnEquip

Runes either need to support OnEquip and have the act of socketing them trigger OnEquip, or there needs to be an event specific to runes (like OnSocket) that fires upon
- Socketing a rune to an equipped item
- Equipping an item with a rune
- Unsocketing a rune on an equipped item
- Unequipping an item with a rune

Ideally runes would just be metadata to equipment. Would make this very simple and intuitive.

The use case for this is drastically expanded itemization. Statuses are regarded by many as the best hook between an item and a script, and for good reason. Being able to have runes that grant OnEquip statuses would be huge.

Code
	[EVENTS]
		Script -> OnRuneSocketedInItem((CHARACTERGUID)_Socketer, (ITEMGUID)_Rune, (ITEMGUID)_Item), (STRING)_ItemSlot)

	[QUERIES]
		Script -> GetItemRuneIterator((ITEMGUID)_Item, [OUT](ITEMGUID)_Rune)
		Script -> GetItemRuneAtSocket((ITEMGUID)_Item, (INTEGER)_Socket, [OUT](ITEMGUID)_Rune)

	[CALLS]
		Script -> RemoveItemRuneAtSocket((ITEMGUID)_Item, (INTEGER)_Socket)
		Script -> AddItemRuneAtSocket((ITEMGUID)_Item, (INTEGER)_Socket)
	


The above assumes Runes would be treated as stand-alone instances of an Item Template. If Larian would prefer the approach of simply adding metadata to an Item Instance (I suspect this will be easier), see below as I have another issue to bring up with Item metadata.

The usecase for this I think is very simple. Being able to query and interact with an object in the game should not be something we are lacking. I think Runes have a lot of potential as customizable progression, but their current state as stat stones is causing them to not realize their full potential. Being able to query this data will let us do far more things, such as allowing Runes to add proc effects to gear. (I'm ignoring Tags for now because that's going to be it's own thing)




Items


Stats -> Tags
Script -> Item/Tag interaction
See the Tags section below.

[QUERIES]
Code
		Script -> GetItemPropertyIterator((ITEMGUID)_Item, [OUT](STRING)_StatName)
		Script -> GetItemProperty((ITEMGUID)_Item, (STRING)_StatName, [OUT](INTEGER)_Amount)

		Script -> GetItemPropertyStatusIterator((ITEMGUID)_Item, (STRING)_Status, (STRING)_Trigger)
		Script -> GetItemPropertyStatus((ITEMGUID)_Item, (STRING)_Status, (STRING)_Trigger)
			_Trigger defined as one of the following: ["OnEquip", "OnHit", "OnAttacked", "OnBlock", etc] //Optional but would be nice
		


[CALL]
Code
		Script -> SetItemLevel((ITEMGUID)_Item, (INTEGER)_Level)
		Script -> LevelUpItem((ITEMGUID)_Item)
                Script -> SetItemProperty((ITEMGUID)_Item, (STRING)_Property, (INTEGER)_Amount)
                Script -> SetItemPropertyStatus((ITEMGUID)_Item, (STRING)_Status, (STRING)_Trigger)
		


This is more what I think will be worthwhile in doing. Assuming Larian wants to treat Runes as metadata, calls like this make more sense. Ultimately, I don't think modders will care too much about what a rune does (Unless it's to add or remove one), so long as we can flag a weapon with a rune in some way that we can query. As of right now, finding out what an item does is very difficult due to the random generation.

Also, I think having a way to interact with item level in script would be a nice quality of life change, especially in Divinity 2 where level and tier are vastly more defined than Divinity 1.


Combat


Stats -> Statuses
Statuses are currently incapable of critical hits. That being said, if you guys implement the ApplyDamage calls, this ultimately won't matter (but would still be nice!).

This also applies to Healing.


[EVENTS]
Code
		Script -> OnObjectBeginAttack((GUIDSTRING)_Defender, (GUIDSTRING)_AttackerOwner, (GUIDSTRING)_Attacker)
		


We currently have a way to determine when someone attacked something, and when a skill was used. We have statuses to hook into when skills hit, so we are missing a way to determine when an attack is started. This is important because it gives us a hook that we can use to override an attack with something else. There are a ton of uses for this, from status effects to replacing what a "basic attack" does.

Code
		Script -> CharacterReceivedDamage((GUIDSTRING)_Source, (CHARACTERGUID)_Target, (INTEGER)_Damage, (STRING)_DamageType)
		


Rimevan has already commented on this one, just re-listing it to keep it in everyones mind. This call was especially neglected, originally only listing _Target.

Code
		Script -> CharacterVitalityChanged((CHARACTERGUID)_Target, (REAL)_Percentage, (INTEGER)_Amount)
		


Bugfix, imo. Percentage should be a REAL, not an Integer. Also, RecievedDamage returns an exact amount, but VitalityChanged does not. This seems arbitrarily limiting.

Code
		Script -> CharacterRecievedHealing((GUIDSTRING)_Source, (CHARACTERGUID)_Target, (INTEGER)_Amount[, (STRING)_ArmorType])
		


Making this consistent with RecievedDamage. This call doesn't exist, but it would really be nice as VitalityChanged alone isn't enough design space due to it being an inaccurate percentage. What sets this apart from VitalityChanged is this is specifically a result of someone healing something, not an arbitrary change in health.

Code
		Script -> CharacterArmorRecievedDamage((CHARACTERGUID)_Target, (GUIDSTRING)_Source, (INTEGER)_Damage, (STRING)_DamageType, (STRING)_ArmorType)
		


We currently have no way to know if armor was damaged. Following suit with _ArmorType

[QUERIES]
Code
		Script -> GetStatusDuration((GUIDSTRING)_Target, (STRING)_Status, [OUT](REAL)_Duration)
		Script -> GetSurfaceGroundLifetime((GUIDSTRING)_Target, [OUT](REAL)_Lifetime)
		Script -> GetSurfaceCloudLifetime((GUIDSTRING)_Target, [OUT](REAL)_Lifetime)
		Script -> GetSurfaceGroundSize((GUIDSTRING)_Target, [OUT](INTEGER)_Size)
		Script -> GetSurfaceCloudSize((GUIDSTRING)_Target, [OUT](INTEGER)_Size)
		


For DoT playstyles, these calls would be amazing. Being able to create playstyles around feeding a surface or status and then exploding it based on size and/or duration sounds like a fun playstyle. Note that I am aware Shouts can consume surfaces with increasing potency of effects, but there is no way to Query for the "scale" of that effect, so there is no way to create an instance of remote damage with it.




[CALLS]
Code
		Script -> ApplyDamage((GUIDSTRING)_Source, (GUIDSTRING)_Target, (INTEGER)_Damage, (STRING)_DamageType[, (INTEGER)_DamageRange, (STRING)_AbilityType), (INTEGER)_CanCriticalHit, (INTEGER)_CanMiss])

		Script -> ApplyDamageMod((GUIDSTRING)_Source, (GUIDSTRING)_Target, (INTEGER)_DamageMod, (STRING)_DamageType[, (INTEGER)_DamageRange, (STRING)_AbilityType), (INTEGER)_CanCriticalHit, (INTEGER)_CanMiss])

		Script -> ApplyDamageWeaponMod((GUIDSTRING)_Source, (GUIDSTRING)_Target, (INTEGER)_DamageMod, (STRING)_DamageType[, (INTEGER)_DamageRange, (STRING)_AbilityType), (INTEGER)_CanCriticalHit, (INTEGER)_CanMiss])

		Script -> ApplyDamagePercent((GUIDSTRING)_Target, (GUIDSTRING)_Source, (REAL)_Percent, (STRING)_DamageType)
		


Rehashed this greatly from the forum post and expanded on it now that I know what's going on. These 4 calls will be integral for more advanced effects and I already have a ton of use cases for these (Hybrid Damage, Damage Over Time, Scaling Damage). Ultimately, the ideal world to me is one where all damage calculation can happen in script and be variable.

I specifically am trying to not include a "Skill" definition here because I want these damage attributes to be variable, not static.

The last one is more to give us a percentile option that follows the semantics of dealing damage (It's dealt TO something, BY something). I wouldn't expect this one to scale, only to attribute the damage properly.


Code
		Script -> ApplyHeal((GUIDSTRING)_Source, (GUIDSTRING)_Target, (INTEGER)_Heal[, (INTEGER)_CanCriticalHit, (STRING)_ArmorType]);
		Script -> ApplyHealMod((GUIDSTRING)_Source, (GUIDSTRING)_Target, (INTEGER)_HealMod[, (INTEGER)_CanCriticalHit, (STRING)_ArmorType]);
		Script -> ApplyPercentHeal((GUIDSTRING)_Source, (GUIDSTRING)_Target, (REAL)_Percent[, (STRING)_ArmorType]);
		


Same semantics as above. A flat heal, one that reflects the heal table, and one that is capable of percentile. I want these specifically so I can modify values dynamically, which I cannot do with something like REGENERATION. Is _ArmorType isn't possible, then just expand these 3 methods into 9, with each batch targeting health/armor/magic.


Code
		Script -> ApplyStatus((GUIDSTRING)_Source, (GUIDSTRING)_Target, (STRING)_Status, (REAL)_Duration)
                Script -> AddStatusDuration((GUIDSTRING)_Target, (STRING)_Status, (REAL)_Duration)
                Script -> AddSurfaceGroundDuration((GUIDSTRING)_Target,  (REAL)_Duration)
                Script -> AddSurfaceCloudDuration((GUIDSTRING)_Target, (REAL)_Duration)
                Script -> CharacterSetCooldown((CHARACTERGUID)_Character, (STRING)_Skill, (INTEGER)_Cooldown)
		Script -> CharacterDied((GUIDSTRING)_Source, (CHARACTERGUID)_Target)
		Script -> CharacterDie((GUIDSTRING)_Source, (CHARACTERGUID)_Target, (INTEGER)_GenerateTreasure, (STRING)_DeathType)
		


Adding a source to all these calls. (I specifically added Died/Die for Executioner interaction and it's like). Also added two new ones to further expand combat. AddStatusDuration to let us better manipulate statuses and a way to influence individual cooldowns.



Tags


Tags have so much potential, and giving love to them would be the second thing I most want from this post. Tag support is single handedly destroying the (imo) true solution to bridging the gap between the game and script.

Stats -> Weapons/Armor/Etc
Tag support doesn't exist here, despite there being a tag field. I have heard rumor that this was planned, and likely didn't make it in time. If the editor is going to see patches, seeing this patched would be amazing, especially if...

Stats -> Runes
Socketing tagged runes should cause the item they were slotted in to receive the tag. This would let us key so many effects off gear without having to rely on hacky status solutions, and I would also imagine tags are far, far lighter weight.

[QUERY]
Code
		Script -> GetObjectTagIterator((GUIDSTRING)_Object, [OUT](STRING)_Tag)
		


This single query used in conjunction with ItemEquipped/ItemUnEquipped and proper tag support would be huge. We could build proc tables and make combat so much more dynamic, like a rune that causes you to cast a fireball at anyone who is FireLash'd (as an example).



Compatibility


Rather than re-hash what has already been discussed about this topic, I am instead going to link to http://larian.com/forums/ubbthreads.php?ubb=showflat&Main=77048&Number=626850#Post626850

With the advent of Add-ons, mod compatibility is now something that needs to be given more of a spotlight, otherwise we will have to rely on 3rd party support which will segment the modding community further and cause installing mods to become more difficult.




Abilities


Polymorph -> data.txt
Polymorph has no entry in data.txt to adjust the bonuses it provides like every other ability.



Missing Modifiers
Alright, so I've been meaning to bring this up for awhile. It seems very limiting that damage modifiers are only attached to abilities, and not as stand-alone stats. We could do so much more with progression if the idea of Pyrokinetic and +%Fire Damage were separated into separate values. I hate that these two ideas are coupled. It really limits design space, makes itemization more difficult, and is abrasive to modding. I want to be able to give players bonuses without allowing them to increase their skill in something. If we had this, modders would be able to customize what attributes did very easily for very little cost.


The Benefits of Rendering from a List
Abilities, Civics, and Weapon Abilities should be rendered from a String Array internally (or perhaps some ENUM array), and that ENUM Array should be exposed to us. Most of the framework for this is in place already. Abilities are referenced via String in Requirements, Queries, and most other places I have seen. We just need a way to push and pop entries.

If you could just do this one thing, it would allow modders to add custom abilities and hook into the existing framework you have built around them. It likely wouldn't be THAT simple, but I also think this would be a huge gain for little work.

Code
		AddAbilityDefinition((STRING)_AbilityName, (STRING)_AbilityDescription, (STRING)_Category)
		OnAbilityValueChange((CHARACTERGUID)_Learner, (STRING)_Ability, (INTEGER)_Value)
		



Talents


Elemental Affinity -> data.txt
Elemental Affinity has no entry in data.txt to adjust the bonus it provides like most other talents.

The Benefits of Rendering from a List
Similar to Abilities, Talents need to be rendered from some keyed list that we can modify. Fields that interact with Talents are, again, strings. It honestly feels like Larian was moving both Talents and Abilities towards being moddable, and honestly it looks like it's so close to being complete. All we need is, assuming Talents are rendered from a list, the following:

Code
		AddTalent((STRING)_TalentName, (STRING)_TalentDescription, (STRING)_LearnEvent)
		OnTalentEvent((CHARACTERGUID)_Learner, (STRING)_LearnEvent, (INTEGER)_WasRemoved)
		



If you made it this far, then all I can say is thank you for reading. I tried to only include what I thought was specifically limiting design space and seemed fairly straight-forward to address given the current systems in the game. Feel free to question any of this or add your own.

Last edited by Sinistralis; 26/10/17 04:18 PM.
Joined: Jan 2010
Location: USA
F
enthusiast
Offline
enthusiast
F
Joined: Jan 2010
Location: USA
While we're on the subject of needed functions, here's a few I'd like:

call OpenBookUI((CHARACTERGUID)_Character, (ITEMGUID)_Item)
I want to be able to programmatically open books.

I can then replace the "loot book -> open inventory -> read book" process with simply "read book when looted."

In fact, it would be nice if we could programmatically execute all root template use actions.

event ItemMovingFromTo((ITEMGUID)_Item, (GUIDSTRING)_FromObject, (GUIDSTRING)_ToObject, (INTEGER)_IsTrade)
ItemMovedFromTo has an issue in the trade UI where: if I identify an item after the item has been moved, the tooltip does not update.

So, either the trade UI needs to be listening for item/tooltip changes, or we need to be able to do something to that item in transit.



LSLib Contributor | My Mods: DOS2, DOS2DE | 560K Steam Workshop Subscribers
Joined: Jan 2010
Location: USA
F
enthusiast
Offline
enthusiast
F
Joined: Jan 2010
Location: USA
Originally Posted by Sinistralis
With String.Split, I could split something like this up into a projectile (LightningBolt) and a potency (75).

Don't forget you would also need StringToInteger and StringToReal queries.


LSLib Contributor | My Mods: DOS2, DOS2DE | 560K Steam Workshop Subscribers
Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Was not aware StringToInteger and StringToReal did not exist. We would only need one of these, but it would be nice to convert both directions.

Joined: Oct 2017
Location: Germany, BW
F
apprentice
Offline
apprentice
F
Joined: Oct 2017
Location: Germany, BW
Wow, yes please!
I was already looking for ways to access item properties (and level) or their metadata. I guess I am out of luck then, am I not? I don't care if everything would be a string, just give me something to work with :)

Please tell me, if there is a workaround to modify equipment ingame (via script or Osiris).

Also, is it possible to get the item worn in a specific slot (head gear for instance)?
There is ItemGetFromInventory, but I don't get what CHARACTER|ITEM:object and FIXEDSTRING:statsId is for.

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
@Fumihiko The call you are looking for is

CharacterGetEquippedItem

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
I forgot to touch on Tooltips in the above post as well. Right now, you guys have the ability to point to Potion data. If that could be expanded so a skill could reference any other skill properties, it would go a long way to improving tooltips for scripted abilities.

Joined: Sep 2017
Location: Belgium, Ghent
addict
Offline
addict
Joined: Sep 2017
Location: Belgium, Ghent
I made it!
Thanks a million for so much dedication Sinistralis smile

Apologies in advance, but, off the top off my head, it's hard for me to answer more specific on any of this except for "we're reading it", but know that we are indeed reading it laugh And I'll be digesting the content for a while to fully grasp everything laugh

I also made Rimevan and Tinkerer aware of this thread since they're a bit more adept when it comes to story and scripting and might offer some more insights like on your previous post wink

Sincerely,
Kevin

Last edited by Larian_KVN; 06/12/17 03:10 PM.

CTRL+K the elf
Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
I honestly am not expecting a detailed response to this one, it's just too large. I'm a huge mechanics guy though and that's where I've spent 100% of my time so far. I know a lot of this is stuff Ameranth and Baard have already brought up, I just wanted to add my voice and map out some APIs to try to help out and better visualize what I'm talking about.

Thanks for letting me know!

And Rimevan, I know some of this is stuff you read/responded to already. I just wanted to rehash some of the stuff we talked about since I have a much clearer idea on what, at least, my needs are.

As always, thanks for your time.

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Another one:

Code
  [CALL]
  Script --> SwapSkillForCharacter((CHARACTER)_Character, (STRING)_SkillToRemove, (STRING)_SkillToAdd


The usecase for this is to replace an ability without affecting the users hotbar. I do feel like this might be more difficult than it seems as that functionality might be built in at a much deeper level. Alternatively, a way to get a spells position on the hotbar and set a position on learn would also work and might be simpler.

Also, AddSkill needs a "Show Notification" parameter. It's missing in Osiris.

Last edited by Sinistralis; 30/10/17 05:24 AM.
Joined: Dec 2016
Location: United States
member
Offline
member
Joined: Dec 2016
Location: United States
Thanks again for the research and write-up, Sinistralis.

And thank you, readers at Larian; your attention and consideration to features like these mean a lot, as even only a few changes can often mean great increases in the usability and power of this tool.

Joined: Jun 2014
veteran
Offline
veteran
Joined: Jun 2014
One thing could potentially make the editor a force to be reckoned with: plugin support.

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Can you elaborate further on what you mean by plugin support?

If you mean the ability to write the underlying code to create new APIs, I think that would be ideal. It lets us expand the functionality of the editor for Larian, and they can just add that support at a later date if they feel it's worthwhile.

I'm not entirely clear on what the gameplan is for the editor, or how much of a priority it is. If we had the ability to just fix these problems outselves, I am certain many of us would have already started working on a lot of these things. I know I would be at least.

Joined: Jun 2014
veteran
Offline
veteran
Joined: Jun 2014
I mean like Bioware promised to do for the Dragon Age toolset: the possibility to "inject" functionalities in the editor via plugin - of course, that never happened. But it could work for DOS2, if the developers are willing to devote time and efforts to it. Rewards would be several times the effort.

Joined: Jul 2014
Location: East Coast
journeyman
OP Offline
journeyman
Joined: Jul 2014
Location: East Coast
Found another one while making my skill generator program.

DamageSourceType is missing a 'SourceShieldMagicalArmor' value.

It also lists 'TargetCurrentMagicArmor' twice.

Last edited by Sinistralis; 31/10/17 05:05 PM.
Joined: Nov 2017
Location: Quebec, Canada
Larian Alumni
Offline
Larian Alumni
Joined: Nov 2017
Location: Quebec, Canada
Hi there everyone, sorry I'm late to the party.

I'm a Gameplay Programmer at Larian and hopefully I can help calrify Tags since I had a hand in their implementation.

Originally Posted by Sinistralis
Stats -> Weapons/Armor/Etc
Tag support doesn't exist here, despite there being a tag field. I have heard rumor that this was planned, and likely didn't make it in time. If the editor is going to see patches, seeing this patched would be amazing, especially if...


We actually do have tags working with equipment stats (weapons/armor/shields), but perhaps it isn't the way you were expecting. Tags from equipment stats are added to the character's tags and are never present on the item's tags. It was done this way for two reasons.

A) So that we can have items that provide story/dialog events for a character
B) Items can already be tagged through the editor

If you want an example of how A) works, open the stats editor and navigate to "Projects-> Divinity: Original Sin 2-> Stats-> Armor-> ARX_Barracks_ConfiscatedGoods_NobleHelmet"

*There are a few things you need to make sure to do if you want a tag to be visible on the item tooltip and character sheet:
- Make sure the tag is present in the Tag Editor
- Make sure the tag category is one of the following: Gender|Race|Profession|Origin|Story
- Make sure the tag description is filled out (optional)
- Make sure the tag description is translated (optional)

As for B), item templates (or root templates) can have their own tags already. You can find them under the "base" category.

Sincerly,
Koala

Joined: Sep 2017
Location: Belgium, Ghent
L
stranger
Offline
stranger
L
Joined: Sep 2017
Location: Belgium, Ghent
Hi Sinistralis,

It's been a while since you posted this list, but I have been too busy to respond until now. We've checked the whole list and came up with a list of additions and improvements for both story and script. It'll require some patience, but I'm sure you'll like the changes that are coming smile

Thanks a lot for all the feedback!


Moderated by  Larian_KVN 

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