Dynamic field from nested object

[LordMidas]

• feat: add ability to dynamically generate text based on object field such as Name for skills and items, using Obj/Field notation in shorthand.
• feat!: require subfolder path for perks, items, skills
  • This allows files with the same filename to exist.
  • For perks this is the scripts/skills/perks/ folder so they remain unchanged. Shorthand: [Anticipation|Perk+perk_anticipation] or [Obj/Name|Perk+perk_anticipation]
  • For items it is the scripts/items/ folder so now we have weapons/knife instead of knife. Shorthand: [Knife|Item+weapons/knife] or [Obj/Name|Item+weapons/knife]
  • For skills it is the scripts/skills folder so now we have effects/stunned_effect instead of stunned_effect. Shorthand: [Stunned|Skill+effects/stunned_effect] or [Obj/Name|Skill+effects/stunned_effect]
  • Delete SkillObjectsByFilename table. Skill objects are instantiated on demand during a nested tooltip query.
  • No longer instantiate all items at the start of the game. Instead they are instantiated and added to ItemObjectsByFilename on demand when a nested tooltip is queried for them.

[Suor]

So we do that caching to items but not skills, why?

[LordMidas]

Doesn't seem necessary and just hogs memory. For items it is necessary because we need to have the item available for the nested tooltips of skills which want to refer to that item e.g. reload_bolt which needs an item.

[Suor]

Sorry, doesn't make sense. Why don't you create an item on demand like everything else?

[LordMidas]

We do that in this new system, we create it on demand. But when we create it, we also add it to this table with a strong reference so it always exists. We need it to persist outside this scope as well because the skill's tooltip will need to refer to that item. If we just create it on demand and return it, the object will be garbage collected and we won't have access to it anymore. See how our hook in tooltip_events.nut where we need to access an item if necessary, so the item needs to exist.

We don't need to do this for skills i.e. they don't need to exist outside that scope as they are never accessed outside it.

[Suor]

Why we need all this dummy player, fake item and stuff? Why don't use the real thing?

[LordMidas]

Why we need all this dummy player, fake item and stuff? Why don't use the real thing?

This is a long topic but I'll try to summarize it:

• Many things require to have a container in order to generate a proper tooltip. Therefore, for nested tooltips of skills we need to assign them to a container.
• For the tooltips of skills of items, those skills need to have a reference to an item so that skill.getItem() works properly. Therefore, we need to equip the item on a character in order to generate the proper skills which are generated through that item's onEquip function.
• Active skills in particular need this because there needs to be an update on the character's skill_container in order for the weapon to add its damage and other things to the character which are then necessary for the tooltip of the skill.

Without this DummyPlayer most of the framework will not work because skills will be hanging without a container and items will be hanging without being equipped.

This is just a brief summary of it, going into much detail of it will be probably too long here.

[Suor]

I understand that you need a player, but a skill usually already has one, why not use that?

[LordMidas]

I understand that you need a player, but a skill usually already has one, why not use that?

For example if I want to give the nested tooltip of stunned_effect inside a random tooltip, this stunned_effect is not present on any player. So, we temporarily assign it the container of the DummyPlayer and generate its tooltip. For the stunned_effect this isn't a problem because it doesn't need container in getTooltip so it will work even without the DummyPlayer, but there are many skills that require a container or an actor e.g. reload_bolt.

[LordMidas]

Closed in favor of #17