Add way to access name for tiles by identifier

[NPBruce]

Possibly {tile:?}

Also consider item use.

[eorahil]

are you talking about tile code (TileSideAlley1) or the name you give to a tile when you create it? The problem with the Tile Code is that the tiles list has been translated so you can't see its code.

Almost all tiles appearing in a text are related with the addTile event so these texts could be automated #321

The tile dict creation can be done quickly but the prefered mode should be that the asset importer could read the localization file and automate the creation of the tiles dictionary. I supose there will be a new expansion for the game including new tiles and the atomatic creation of the dictionary could be regenerated dinamicly. Same for items.

[redwolf2]

Automating it would be great. This would allow options to completely disable the dialogs of place ? events ("show, don't tell") or show the event text in a different way, like shorter texts, only graphics (3x \).

Something like {tile:?} would be needed regardless of those options, if you want to refer to it. For example, in an event like: "Walter LynchHerbert West takes out his syringe and pushes the remainig serum into a corpse. Place a {monster:zombie} in the {tile:kitchen}. All investigators in the {tile:kitchen} become {effect:dazed} by the musky smell of the liquid. If one investigator inside the {tile:kitchen} has the item {item:brass_key}, it drops to the floor."

[NPBruce]

I am leaning towards {component:TileScenarioEntry} for the name of the tile used there {component:QItemInBox} for the name of the item picked by QItemInBox and so on. Could also just overload qst with {qst:TileScenarioEntry}

[eorahil]

qst elements are translated in the text editor. If you have {qst:quest.name}. when you edit the scenario, the text field will have "Exotic Material" not {qst:quest.name} but we are talking about a tag that isn't translated in the editor but in the gameplay (Like {rnd:hero}) For this, its better to have another tag for referencing components. Can be: q, this, component, com or something like this. I will start coding asuming the q tag, but if we decide anoter one it can be changed fast.

[redwolf2]

Sounds good. Elements like {strength} are nice to read, but could also be replaced with {q:strength} to simplify parsing and validation. Just do the rest using naming conventions, like {q:tile.mom1.kitchen}. However, if you want to introduce some context help (showing the item card/tile on mouse over in a popup), that may be more challenging.

[NPBruce]

I would prefer for consistency that this only works with quest components, so it won't affect symbols and you can't reference a tile name directly, only a Tile component, which it will use the name from.

[NPBruce]

This is the last feature for 1.1 before the freeze. If you are in this that is fine, but if your haven't started is it ok if I do it?

[eorahil]

It's almost done. It can only reference quest components and are resolved:

• Event: Replaced with the text of the event
• Tile: Replaced with the name of the Tile
• Token: Replaced with the text of the token
• CustomMonster: Replaced with the custom monster name
• Spawn: Replaced with the text shown in the spawn
• QItem: I want to show the QItem name but it has many i'm not sure. I will print a name of the first element in the list.

[NPBruce]

For QItem use game.quest.itemSelect[]

[eorahil]

ok

[eorahil]

As they are components and to not make confusion with the {qst: variables, I think the best name for these variables are {c:NameOfComponent}. instead of {q:NameOfComponent}

[NPBruce]

OK, I would like to suggest some changes though:

Spawn: Replaced with the text shown in the spawn

Probably more useful to put the monster name in (this works the same as QItem). This is redundant with {qst:Spawn.text}.

Token: Replaced with the text of the token

As above, probably not useful.

Event: Replaced with the text of the event

As above and I want to use this for a hero name from a previous rnd:hero (#186)

[eorahil]

The spawn is a good idea to place the monster. The spawing text can be even automated this way;

SpawnHumanoid1: "Place the monster {c:SpawnHumanoid1} in the space shown."

by refering itself if you want a spawn by trait.

But for the rest, I think the qst variables shouldn't be used inside the editor. They are directly replaced so the only way to use it is outside valkyrie. I think that using these news should be the best way to do inside valkirie and not needing to edit inside and outside valkirie at time,.

[NPBruce]

I am saying I would like this new text reference in 1.2, and please write up how you would like it to work in an issue.

[NPBruce]

I have changed the way that c:Event works and removed c:Token. I would like a bigger picture look at text references before adding the direct text reference in.

[eorahil]

I don't agree with the removal of the Token item text. It's really useful to avoid duplicated texts for every tokens. All token related texts are duplicated in localization files. The good structure would be a token with an specific texts and the event showing the token should reference the token text in a more stable mode than writing in the event text {qst:x} reference. Something that if you click inside the text element accidentally will translate the texts. Think about translators who will edit your scenario and translate every text inside de app . all qst references will be lost. Agree with the new "event" text use to get the random hero selection of an event but not for the token. it was removed not replaced. Now I don't know how to insert automatic text to token spawns without using the "volatile" {qst: system.

[NPBruce]

What I am trying to say is don't use c: for this purpose, use something else, either qst with modifications or something new, because this behaviour should work for all components equally not just Tokens. The solution should also apply to other texts such as buttons, so I would prefer either some sort of toggle to change the qst behaviour in the editor or an alternative to qst which is the same except that it isn't replaced in the editor. I don't want to push out a feature in 1.1 without a plan for how this would work because removing a feature is harder than adding.

Does that make sense?