Feature proposition : Quest log

Discussion in 'Fallout Tactics Modding' started by nadeauhugo, Apr 29, 2020.

  1. nadeauhugo

    nadeauhugo Author of FOT mod THE SUM Modder

    498
    Mar 9, 2014
    Hi everyone,

    Having studied a lot the new (and totally AWSOME!) Script Engine from Melindil, I am safe to assume we almost have everything we need to implement a "Quest log" feature inside Tactics, and thus without much efforts and hassle. For all mods played in a more RPG style, the "Quest log" for me is a must, as it helps remember which quests you still need to do and where, and thus, from any location (as you know, in Tactics the objective list only works locally.) This appear more important for me than ever because recently I started a new game of FO2, and in it the quest log is just perfect. First a list of locations, then a list of tasks. Nothing fancy, but straighforward and clear. In this game, you can even stop in the middle of the desert and decide where you should go next.

    In Tactics, it could be an holotape-type item or a generic item that, when equiped on one of the two slots, lead to a worldtext.

    What will be needed to do one of those scenarios, if this is not already possible :

    1. A way to update or overwrite a locale string inside "OnLongTick" function.
    OR
    2a. A way to call the "World Text window" function using a string parameter.
    2b. A way to detect a specific item being equiped
    The first method would be my favorite as it would make the Quest log function exactly like any other holotape, BUT it might create a bug as normally a holotape already added to the pipboy can not be added again. This means that even if the locale string is updated, the holotape might show the previous "Quest log" in mission maps where it has been open before. This might be solved with another function inside "OnLongTick" to also update the pipboy notes, or holotapes.

    Using either methods, we would then simply have to assign a Campain variable to each quest (which we most certainly have to do anyway) and compose a log (or quest list) dynamically using all these variables whitin LUA code. Even if all the quests are done locally, you would still need to see them from other locations to remember that you still have those quests to do. If the variables used are string with values like "no, assigned, yes", it would be possible to a)keep the unassigned quests invisible, b)show the assigned quest in the list, c)show the resolved quests in the list in a different way (grey for example).
     
    • [Rad] [Rad] x 1