[#modding] _feature request:_ automatically assign ordinals to conversation choices.IIUC ...
Marked for crossposting by: Sol, sky orb
Message (jump):
<kernelmethod> feature request: automatically assign ordinals to conversation choices.
IIUC conversation choices are currently ordered automatically by the order in which they are provided in
Conversations.xml
, and (unless explicitly specified) aren't given a priority beyond the existing ordering inConversations.xml
. This makes it difficult to mod in a conversation choice to come between two other choices.Ideally, in the parsing of
Conversations.xml
each conversation choice would automatically be given descending priorities by the order in which they're parsed, e.g.
- the first option is given priority 0;
- the second option is given priority -10;
- the third option is given priority -20;
and so on. By making it a multiple of 10 (or some similar modestly large value) it should be easier to assign an option to come between two others (e.g., you can put in an option between the second and third by giving it a priority of -15).
Comments (4)
-
-
- edited description
- changed title to [#modding] _feature request:_ automatically assign ordinals to conversation choices.IIUC ...
- changed version to future
- changed milestone to moddability
- marked as proposal
-
assigned issue to
-
ah, yeah, that’s a fair point. I do think that having multiple forms of priority (in the form of the existing priority system plus an implicit priority in the proposed
Before="..."
andAfter="..."
) might be might also be a little confusing in its own right; e.g. it’s not immediately clear to me which would take precedence over the other? But overall it's probably the better option, especially if implementing it would be a lot more straightforward. -
- changed status to resolved
Added insertion attributes in 204.104
- Log in to comment
Once you involve inheritance (sometimes from multiple sources) where priority is also used, auto-decrementing the priority becomes excessively difficult to parse as a human.
Maybe a
Before="[ELEMENT_ID]"
andAfter="[ELEMENT_ID]"
would work better for what you're trying to do? (Not to mention simpler to implement into the blueprint baking process)