Results 1 to 3 of 3

Thread: [Gaming Staff] Advanced Admin Guide (WIP)

  1. #1
    Jadli's Avatar The Fallen God
    Gaming Emeritus

    Join Date
    Dec 2013
    Location
    Czech Republic
    Posts
    8,528

    Default [Gaming Staff] Advanced Admin Guide (WIP)

    Advanced Admin Guide (WIP)
    By Jadli
    Credits (research and scripts): Callistonian (lot of joint research), Serious Potato, Medik, Fynn, jojo, Mergor, jimmy_dude, Vipman


    Chapter 1 - General Overview
    - This guide primarily focuses on describing more advanced methods of admining. Majority of the basic stuff to be able to admin is already decribed in the Admin guide by Dux. If you havent read it, definitely do so first, as here I will assume you already know all these things.
    - This guide, especially the two following chapters, are very technical, therefore some (slight) modding might be required.

    Rules:
    - See the list of recommended rules, exploits and bugs - LINK
    - ... TBD

    Basic balancing (light modding):
    - Campaigns of almost every mod are balanced specifically for singleplayer use. Thus, often some smaller or bigger edits may be needed to make it properly functional or balanced for a hotseat, depending on what level of competivity and skill is going to be present in your hotseat. Naturally, for less competitive hotsets it may not be that crucial. Nonetheless, good thing to keep in mind is also that whatever balance you make for a hotseat, it generally works only if players have similar experience and skills. In other words, an experienced player controlling a weaker faction can often quite easily defeat a less experienced player with a more powerful faction.
    - Generally, these changes should be primarily done in terms of giving equal opportunities and initial standing for each faction, such as the same kings purse, similarily developed settlements, starting strength (of armies), balanced unit rosters, and so on. Focusing too much on balancing initial positioning of armies at warzone of hostile factions may not lead to an expected result for the reasons mentioned above, generally its better to leave the starting armies of factions at war far enough from each other, to give players a necessary space to find their own way.
    - However, this of course depends on what you want. If you know you have skilled players, or you want to force players into some difficult situations like this (due to historical, lore, or even difficulty reasons) right from the begining, than you can do it like this as well, but then the balancing of starting armies must be very precise. Likewise, sometimes you dont want to have balanced factions (again, for various reasons, in this case mostly historical/lore based), but
    instead for example a poweful faction and then many weaker factions that are forced to cooperate in order to survive.
    - ... TBD
    Last edited by Jadli; August 06, 2023 at 01:29 PM.

  2. #2
    Jadli's Avatar The Fallen God
    Gaming Emeritus

    Join Date
    Dec 2013
    Location
    Czech Republic
    Posts
    8,528

    Default Re: [Gaming Staff] Advanced Admin Guide

    Chapter 2 - Fixing bugs and exploits
    - This part features solutions to various greater or smaller bugs, as well as ways to avoid players being able to use some of exploits. Typically, most of these bugs/exploits are directly forbidden by hotseat rules, but naturally, its better to remove the ability to use exploits entirely.

    Difficulty settings bug
    All factions except the first faction always play on normal difficulty. Therefore ALWAYS start your hotseat on normal difficulty, so that the difficulty is the same for every player.

    Missing scrolls
    - One of the greatest bug in hotseating! You can never see any of the regular scrolls from singleplayer, except the end turn reports, marriage proposals, adoptions, messages from other players, etc... You cannot see many very important scrolls, such as the new traits/ancilllaries, deaths of characters, etc.... And most importantly, you cannot see any of the ingame (historical) event scrolls, including yes/no event scrolls, which may be a huge issue, especially in some mods.
    - This is all simply due to the fact, that when a previous player hits end turn and sends you your turn, the save is already made within your turn. Therefore then, same as in singleplayer, if you load a save from your turn, you cannot see any scrolls, as they were already "shown" to the previous player. You see them only if you yourself physically hit end turn on the previous turn and access your turn immediately (such as, when you play several factions in row).
    - List of missing scrolls here
    Spoiler Alert, click show to read: 
    Code:
    Revived on Reload:
    - turn end summary
    - guild offer
    - marriage offers
    - adoption offers
    - player-to-player hotseat messages
    - diplomacy scroll
    
    Not Revived:
    - historic events
    - disaster news
    - traits & ancillaries news
    - family news (marriages, adoptions, births, coming of age, deaths, man of the hour, etc.)
    - diplomacy changes news
    - standings news


    - Solution 1: A very simple one, hence recommended to use! In a campaign_script, you simply replace all instances of "monitor_event FactionTurnStart" and "monitor_event PreFactionTurnStart" by "monitor_event CharacterSelected" (or SettlementSelected, up to you). You can do this simply via regular find and replace functions (ctrl f + r), so it would take just a minute to do. It should cause no issue to the campaign, but you should always double check that the script is still working after this replacement. What this accomplishes is, that all events are moved from turn start, to the moment when a player clicks on something (hence it will trigger after a player enters the turn through the password screen, not before for the previous player!)

    - Solution 2 (advanced, credits to Callistonian): Instead of the previous solution (which technically may not trigger if a player doesnt press anything in his turn, etc), one could trigger the events by GameReloaded event. This event is triggered everytime you load a save. Then you also have to keep a system of counters, that checks, which faction turn is it, and whether an event has already been triggered or not. Therefore, this requires a bit more work. Sample script is below:
    Spoiler Alert, click show to read: 
    Code:
    monitor_event GameReloaded
       if I_EventCounter faction_a_turn == 1
          if I_EventCounter event_x_pending == 1
             set_event_counter event_x_pending 0
             historic_event event_x_event true factions { a, }
          end_if
       end_if
    ....
    end_monitor

    - You can also use a simpler version of this (by Serious Potato), which however works only for the first turn (so for some faction introduction messages, possibly some initial faction yes/no choices)
    Spoiler Alert, click show to read: 
    Code:
    monitor_event GameReloaded
        campaign_wait 0.1
        if not I_HotseatEnabled
            terminate_monitor
        end_if
        if I_TurnNumber > 0
            terminate_monitor
        end_if
    
        if I_LocalFaction hre
            historic_event INTRODUCTION_HRE true factions { hre, }  
        end_if
        ...
    end_monitor


    - But keep in mind, this fixes only the event scrolls, not the other generic scrolls, that do not get revived.

    - Hotseat (password) scroll: Until recently, the internal name of the hotseat (password) scroll hadnt been confirmed. If one could check whether this scroll is opened/closed by the player, that would be potentionally very useful to hotseat modders. However, eventhough we know how to check for the scroll, it turned out to not be extremely helpful with the "missing scrolls" issue. The reason is, similarly like the previously mentioned issues with FactionTurnStart, this event actually gets triggered by the previous player as well, when making a save. As the scroll opens for the player, and then it closes down when hitting Esc to make a save. Therefore it doesnt entirely solve the previous issues, but combined with GameReloaded or other monitors it can still be useful to use.
    - The monitor can be used like this:
    Code:
    monitor_event ScrollClosed ScrollClosed hotseat_scroll (or ScrollOpened ScrollOpened)
    ...
    end_monitor
    Historic_event scroll
    - Just a note in regards to the historical scroll (from the previous) section, as it is used for all the event scrolls (including yes/no scrolls). In a hotseat, make sure to specify for which factions is the historic event supposed to be shown (as the event counter is triggered the same moment). In singleplayer modes the modders often do not specify that, as they assume only one human faction, hence it would always be the one to see the scroll. However, in hotseat, you need to be sure the scroll is shown to the correct faction (which also is the moment, when the event trigger fires), and hence at a correct time.
    - Therefore, simply make sure that all the relevant historical events have the part (in bold), which specifies the faction
    Code:
    historic_event event_x_event true  factions { a, }   ; true is for enabling yes/no option in the scroll

    - This all also of course assumes, that you used some of the previous solutions for the player to actually see it. Anyway, even if the player wouldnt see it, this would still ensure that the event counter gets set on the correct faction turn, so should be definitely part of every hotseat campaign script.

    Scripts/events incompatible with hotseats
    - Another huge issue in hotseating! While there is no completely perfect solution (unless you use EOP as described in Chapter III), it is definitely important to mention this, as some hotseaters may not realise what is causing the issues.
    - Most scripted events use console commands to a certain extent. However, in hotseats we always disable the console so that the players cannot use it. This is unfortunately also causing the console commands in scripts to cease to work. This may especially become an issue in a majority of bigger mods, where many features and mechanics of the mod are dependant on scripts (such as DaC, TATW, TES, ...) , and thus do not work properly... or, if even worse, may cause issues or crashes.
    - Keep in mind this is not about scripts that are naturally not meant for hotseating, such as events for AI factions, etc. Those would have to be reworked completely.

    - Solution 1: Enable console for everyone. This however cant work in competitive hotseats, as every player could access the console, so its likely possible to use only in "friendly" hotseats.

    - Solution 2: You can keep the console disabled(=locked), but add admin logon and logoff instances into the script for each instance of console command used in a script. This can quite nicely solve the issue. However, it bears some security risks, as the admin password must be directly written in the script (message me for more info on this), therefore it is not a perefect solution. Asumming you use this, then you should also add at least 10 random commands not doing anything before each logoff instance (such as add money 0), as if a player opens console in his turn, he see the last 10 commands used

    Spoiler Alert, click show to read: 
    Code:
    monitor_event ...
        
        if I_HotseatEnabled
               console_command logon password
        end_if
    
        console_command ... (here you place your script)
    
        if I_HotseatEnabled               
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command add_money 0
               console_command logoff
        end_if
    
    end_monitor


    - Solution 3: Use EOP. The new releases of EOP simply allows all console commands in a script to run withoutt the enable console. Therefore, that solves the entire issue easily.

    - One important example of a script not working because of the disabled console is below..

    Turns pear year (characters ageing) bug
    - Scripts that increase turns per year, or in other words change how fast or slow characters age, when do the seasons change, etc infamously do not work in a hotseat either and revert back to vanilla... the reason is the same as above (but I deemed this deserving of a separate mention). Many mods use alternate amount of turns pear year (such as 4 or 12) for various reasons, such as to avoid characters dying of old age in some fantasy mods, or to focus on a shorter historical period. However, the script requires a console command (console_command season winter/summer) to change the season. Changing of the seaons also is what causes the characters to age, as well as of course the changing of season on the map itself. Therefore, it is not possible to play a hotseat with different different amout of turns per year than the vanilla one! (which is 2TPY) Unless you use EOP

    - Solution 1: Not really a solution, but a recommended change. Simply, in case your mod uses different amount of turns per year than the vanilla, you should change it back to the vanilla (so remove the the season script in the campaign_script, and change the "timescale" in descr_strat to the default value), as the different timescale will likely not work anyway, and character do age. Hotseats are much shorter than singleplayer campaigns (usually a few dozen turns maximally), so even with 2 turns per year not much would get affected, and its probably more fitting to the pace of a hotseat anyway.

    - Solution 2: In case you play in a hotseat with enabled console, hence not competitive hotseats (as players can acess the console), or if you use EOP, you should use this version of the Turns Per Year script (by Serious Potato), which correctly determines the first faction (as the turn order may change due to the selected factions)
    Spoiler Alert, click show to read: 
    Code:
    ;## First faction after slave turn ##
    ; credit to the DCI team for this small, but powerful script
    ; first faction after the slave turn is not always the same, so this script helps identify it
    ; used for season script & seasonal events script
    
    declare_counter first_faction_after_slave        ; 1 = is first faction after slave, 0 = not, -1 = set to this in slave's turn
    set_counter first_faction_after_slave -1
    
    monitor_event PreFactionTurnStart not FactionType slave
        if I_CompareCounter first_faction_after_slave == 1
            set_counter first_faction_after_slave 0
        end_if
        if I_CompareCounter first_faction_after_slave == -1
            set_counter first_faction_after_slave 1
        end_if
    end_monitor
    
    monitor_event PreFactionTurnStart FactionType slave
        set_counter first_faction_after_slave -1
    end_monitor
    
    ;#################### 5. Season Script 12 TPY ####################
    
    ; meant to be used with a timescale    of 0.0835 (descr_strat)
    ; do not use events with specific dates (even 0!), they will not work reliably with this timescale, use historic_event instead
    ; hotseat compatible, does not rely on local faction tests
    ; "flickering seasons" at the start of the player's turn are rarer than with the old script
    
    declare_counter month
    set_counter month 1                                        ; set to start in January (needs to match starting season in descr_strat)
    
    monitor_event PreFactionTurnStart I_CompareCounter first_faction_after_slave == 1
        and I_TurnNumber > 0
            inc_counter month 1                                ; advance the month
    
        if I_CompareCounter month == 12
            set_counter month 0                                ; start a new year
        end_if
    
        ; set the season for each month
            if I_CompareCounter month == 1                    ; January
                console_command season winter
                set_event_counter summer 0
            end_if
            if I_CompareCounter month == 2                    ; February
                console_command season winter
                set_event_counter summer 0
            end_if
            if I_CompareCounter month == 3                    ; March
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 4                    ; April
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 5                    ; May
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 6                    ; June
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 7                    ; July
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 8                    ; August
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 9                    ; September
                console_command season summer
                set_event_counter summer 1
            end_if
            if I_CompareCounter month == 10                    ; October
                console_command season winter
                set_event_counter summer 0
            end_if
            if I_CompareCounter month == 11                    ; November
                console_command season winter
                set_event_counter summer 0
            end_if
            if I_CompareCounter month == 0                    ; December
                console_command season winter
                set_event_counter summer 0
            end_if
    end_monitor
    
    ;## advance character age ##
    
    ; characters only age during winter -> summer transitions (after the slave turn)
    ; by briefly setting the season to summer before the actually desired season, ageing doesn't happen unless we want it to
    ; do not set summer when month == 0 (December), so the only "natural" winter -> summer transition occurs
    ; advance character age at turn 13, 25, 37 etc. (synchronous with the turn of the year)
    
    monitor_event FactionTurnEnd FactionType slave
        and I_CompareCounter month != 0
    
        console_command season summer
    end_monitor


    Local Faction bug
    - In many mods where the modders didnt think about hotseats, I_LocalFaction condition is commonly used in scripts. This is supposed to check which faction is controlled by a player. But unsurprisingly, the issue in hotseats is, that there are many factions controlled by players. Therefore, such conditions can be true for more factions than its meant to be. To be more precise, its always true only for the faction which has its turn momentarily.
    - In some types of scripts, this condition can still be used fine (such as when, you want to check whether the current faction is controlled by player). But you have to check all the instances of this condition being used, most of them likely have to be rewritten to avoid issues (such as when during an event the script is supposed to check which faction is the local one and do somehing based on it..)

    - Solution 1: Simply replace all the instances of "I_LocalFaction" (or only the ones where its necessary) with "not IsFactionAIControlled", or other similar conditions, to resolve this.

    Defeated armies can move for factions earlier in turn order
    - This is one of the most known and serious bugs. Players earlier in turn order are able to move their defeated armies, as the movement points get replenished for all character during the end turn (rebel turn), while the factions later in turn order (before the turn end) cannot move the defeated armies (which is how its supposed to work). This creates a very unfair situation in a hotseat. Usually it is simply solved by forbiding this by the hotseat rules.
    - However, it is also possible to fix this by giving a trait to every defeated general which takes away all his movement points. However, this would work for armies led by captains - therefore, in this setup, one would have to forbid the players to use armies without a general (there is also a way to to script all captain led armies to be disbanded)

    Defeated armies on ships
    - When a navy with an army is defeated, it works the same way as described above, it loses movement points (unless earlier in turn order). However, there is a significant bug that can be exploited very easily. Leaderless armies on ships, i.e., units without a general (while a captain isnt generated, same like when in a settlement/fort) do not lose their movement points at all when the navy is defeated.
    - This is unfortunately impossible to fix directly, although it can be easily enforced by the rules to not allow units on defeated ships to be moved (or other rules...). Or in the case of a solution like the one described before, i.e, the mandatory generals for each army, that would also help with the issue.

    Diplomacy relations bug
    - A pretty annoying bug, especially late in game, is when for some reason the game simply does not let you ally a faction, even though you fullfil all the requirements (not an enemy of the target faction, etc). This is due the fact, that diplomacy relations of destroyed factions are still in place. Therefore, if you were at war with a destroyed ally of the target faction, the game will not let you ally the target faction. Solutions are relatively simple.

    - Solution 1: An admin can simply use the diplomacy_stance command to cancel the relations of the dead faction, or to force the new diplomacy relations. Its very simple from a technical point of view, but potentionally requires lot of work from an admin. And it may be very difficult to track, what the relations were (as you cant see the relation of a dead faction anymore)

    - Solution 2: Make a script that automatically cancells all diplomacy relations of dead factions. This is a bit more demanding from the scripting point of view, but it solves the issue entirely. The sample script is already available thanks to Serious Potato, so you can just use and edit the faction names easily.

    Spoiler Alert, click show to read: 
    Code:
    ;#################### 15. Pacify dead factions ####################
    
    
    ; when factions die, their diplomatic relationships get frozen forever and can prevent alliances between living factions
    ; this script resets the relationships of dead factions to neutral in order to fix the issue
    ; factions with "has_family_tree    no" are excluded because they continue to exist without any characters (in our case: denmark & slave)
    
    
    ;## declaring counters ##
    
    
    declare_counter hre_dead
    
    ;## checking for dead factions & pacifying them ##
    
    
    monitor_event FactionTurnStart not IsFactionAIControlled
        inc_event_counter check_dead_factions_now 1
    end_monitor
    
    
    monitor_event GeneralCaptureSettlement
        inc_event_counter check_dead_factions_now 1
    end_monitor
    
    
    monitor_event CeasedFactionLeader
        inc_event_counter check_dead_factions_now 1
    end_monitor
    
    
    monitor_event EventCounter EventCounterType check_dead_factions_now
        and EventCounter > 0
    
    
        set_counter hre_dead 1                                    ; default to "dead", set "alive" if faction leader exists (0 = alive, 1 = dead)
    
        ; this check works for hording factions as well (I_NumberOfSettlements wouldn't)
        if I_FactionLeaderAttribute hre Magic < 999                ; returns true when the faction has a leader, returns false when not
            set_counter hre_dead 0                                ; set 0 (alive) if faction leader exists, do nothing (aka stay 1) if no leader exists
        end_if
    
        if I_NumberOfHeirs hre == 0                                ; additional fail-safe check for factions that potentially have characters left off-map (I_NumberOfHeirs counts all generals, including the faction leader and non family members, but excluding off-map ones)
            set_counter hre_dead 1
        end_if
    
        if I_CompareCounter hre_dead == 1
            and I_EventCounter hre_dead_already != 1            ; anti console clutter condition, do nothing if pacified already
                ; kill off faction just in case off-map characters keep it alive (can happen under rare circumstances!)
                console_command kill_faction hre
                console_command diplomatic_stance hre venice neutral
                console_command diplomatic_stance hre scotland neutral
                console_command diplomatic_stance hre spain neutral
                console_command diplomatic_stance hre byzantium neutral
                console_command diplomatic_stance hre france neutral
                console_command diplomatic_stance hre russia neutral
                console_command diplomatic_stance hre papal_states neutral
                console_command diplomatic_stance hre kalmar_union neutral
                console_command diplomatic_stance hre denmark neutral
                console_command diplomatic_stance hre norway neutral
                console_command diplomatic_stance hre lithuania neutral
                console_command diplomatic_stance hre novgorod neutral
                console_command diplomatic_stance hre teutonic_order neutral
                console_command diplomatic_stance hre milan neutral
                console_command diplomatic_stance hre aztecs neutral
                console_command diplomatic_stance hre skaven neutral
                console_command diplomatic_stance hre saxons neutral
                console_command diplomatic_stance hre turks neutral
                console_command diplomatic_stance hre moors neutral
                console_command diplomatic_stance hre ogres neutral
                console_command diplomatic_stance hre hungary neutral
                console_command diplomatic_stance hre portugal neutral
                console_command diplomatic_stance hre sicily neutral
                console_command diplomatic_stance hre timurids neutral
                console_command diplomatic_stance hre england neutral
                console_command diplomatic_stance hre mongols neutral
                console_command diplomatic_stance hre normans neutral
                console_command diplomatic_stance hre egypt neutral
                console_command diplomatic_stance hre poland neutral
                log +++ RIP HRE +++
                set_event_counter hre_dead_already 1            ; counter for the anti clutter condition above
        end_if
    ...
    end_monitor

    - This is a sample for one faction. You can download the full version (with all factions), where you could just easily change the factions to the ones in your mod using ctrl f + r.

    Recruitment and Replenishment Glitch
    - There are several bugs related to recruit pools that can be easily exploited, such as when disbanding or merging troops, which in the end may allow many more units than your are supposed to be able to (for that reason, I will not mention details of the exploit here). Bur fortunately, most of these issues can be resolved by a very simple change in the files.

    - Solution: Go to descr_sm_factions_ and add "disband_to_pools no" to every faction. This stops disbanded or cancelled units to be added to the recruit pool of a settlement. Of course, in some cases it makes sense for a unit to be added to a recruit pool (such as when you disband a full unit). Unfortunately, there are many ways to exploit this very extensively, so I recommend to disable this via the solution provided above.

    Crusade/Jihads exploits
    - While the crusades/jihad mechanics offer many interesting features, it is unfortunately possible to exploit this to insane lenghts, such as to get infinite movement points, keep armies with free upkeep, etc. Therefore, by default, they are strictly forbidden in all hotseats. However, there are way so significantly decrease the extent to which the mechanic can be exploited, and thus it could be possible to use it in a hotseat, eventhough some other smaller issues may still remain.

    - Solutions: To avoid infinite movement exploits, you have to change the "movement_points_modifier" in descr_campaign_db.xml to 1.0. This will get rid of all crusading/jihad movement point bonuses, and hence also all the ways to limit the upkeep exploit, you can simply add "crusading_upkeep_modifier 1.0" to every (relevant) unit in export_decr_unit. Thus, the crusading units would cost the default upkeep.

    Generation of missions and the bugged best unit reward
    - Things like traits or mission can be unfortunately reloaded, if a player plays two factions in a row (or an ally is before in turn order). It is therefore wise to make sure that players cant reload for whatever reward or mission type they want.
    - Experienced hotseaters are often able to use missions to spawn elite units "for free". However, the issue is that the mission reward which grants you those units is bugged and gives you the best unit available no matter the cost, even though in the files its meant to be price capped. Thus, players are often able to get large amounts of elite and unique units, which are otherwise quite difficult to get, which may shift the balance in the HS significantly.

    - Solution: Replace all the bugged best unit reward with the the normal unit reward. The reason is the unit price cap doesnt work for the best unit reward, while it works for the normal unit reward. Therefore, you should go to descr_missions.txt and replace all instances of "
    best_buildable_unit" with "buildable_unit", or other type of a reward. By this you can control the maximum price of a unit that a player can get from a mission reward.

    Forts and Watchtowers
    - forts and watchtowers may play an important role in a hotseats, therefore it is important to know how to modify them and limit some ways to which they can be exploited.
    - Exploiting free upkeep on forts - in hotseats when the forts are buildable, it is recommended to set free upkeep of forts to 0 (or a smaller number), as otherwise players could spawn a large number of forts with free armies inside them. This can be done by modifying the
    free_upkeep_forts line in descr_strat.
    - Based on your plans, you can also easily edit the price of forts/watchtowers in descr_cultures. Its not possible to disable watchtowers (you could want to do it, as they are sometimes placed in order to stop forts from being built), but you could increase watchtower prices to high numbers. You can also edit several features related to forts (buildable, permanent, etc) in descr_campaign_db.xml.
    - It is also possible to exploit resources with merchants tremendously by building a fort on top of a resource and filling it with merchants. You can get rid of this easily, just make sure that allow_resource_forts is set to false in descr_campaign_db.xml

    Teutonic factions destroyed bug
    - For factions using the "teutonic" type of family tree, i.e., the leader/heir is selected based on traits (and not based on any family tree), there is a fatal bug. When a leader and heir die in the same battle, the faction gets destroyed. Therefore, this should be known and not allowed to be used. One could also try to fix this from a technical point of view, by spawning back up heirs for such a faction and sending them off map, until the leader dies, but this requires some more scripting.

    ...

    Last edited by Jadli; August 12, 2023 at 03:32 AM.

  3. #3
    Jadli's Avatar The Fallen God
    Gaming Emeritus

    Join Date
    Dec 2013
    Location
    Czech Republic
    Posts
    8,528

    Default Re: [Gaming Staff] Advanced Admin Guide

    Chapter 3 - Expanding Hotseat Features
    - This part includes various suggestions of mine that might bring new hotseating innovations and
    improve hotseat gameplay in general. The suggestions are mostly based on my experience as an experienced M2TW modder, but it may also include things I heard elsewhere. Several of these features are already successfully implemented in hotseats.

    Engine Overhaul Project (EOP)
    - Expands the modding possibilites in many ways. Namely, it adds the possibility to transfer online battles from a campaign (and vice versa), and perhaps even more importantly, it fixes the previously mentioned huge issue of Scripts/events incompatible with hotseats, by enabling all console commands in the scripts.
    - Amongst many other things, it also enables dozens of new commands that admins can use in the console, therefore that itself adds many new possibilities, and especially allows admin to resolve some situations much more easily!
    - It also zips each save, so considering how many saves hotseaters have, it can save you a lot of disk space.
    - The newest version available at https://github.com/youneuoy/M2TWEOP-library/releases
    - Tutorial for online battles hotseat https://youneuoy.github.io/M2TWEOP-l..._TUTORIAL.html

    Modifying the autoresolve
    By changing these settings in descr_campaign_db.txt it is possible to edit various modifiers that affect the amount of casaultaties, prisoners, sunk ships and so on
    Code:
          <min_capture_percent float="5.0"/>
          <max_capture_percent float="30.0"/>    <!-- affects how many prisoners... setting both to 0 means no prisoners -->
          <lopsided_thresh float="1.5"/>  <!-- lopsided - if one side is overwhelmingly more powerful than the other i.e. by this threshold (_thresh), then it takes fewer casualties - 500 men vs 50 men would take fewer casualties than 50 men vs 50 men, generally speaking. -->
          <lopsided_hn_mod float="3.0"/> <!-- _hn_mod if the attacker:defender ratio is bigger than this then it gives the attacker additional attack stats. Therefore, (ratio x a multiplier) would be added to the stats. -->
          <separation_missile_add uint="1"/> <!-- separation_missile is the conceptual distance the missile units start away from the enemy. The higher it is, the more shots they will get off and the lower their own casualties will be.? (values up to 10 should be fine?) -->
          <naval_sink_modifier float="1.5"/> <!--  naval_sink influences the chances of actually sinking an enemy ship: (attacker strength - defender strength) x sink modifier + sink offset) which is ultimately capped at _max.  -->
          <naval_sink_offset float="15.0"/>
          <naval_sink_max float="80.0"/> <!-- reducing gets rid of one sided heroic victories etc? -->
          <sally_att_def_draw_divisor float="2.0"/>            <!-- sally battles are a draw if attacker lost and (number of attacker troops) > (number of defender troops)/divisor -->
    However, the actual autoresolve chances calculation is based primarily upon unit stats (export_descr_unit). So for a balanced autoresolve, one should mainly carefuly modify the stats of faction rosters, and ensure there are no OP units for some factions etc. For the autoresolve, further things can affect it, such as: difficulty level, general abilities (command etc), unit experience, battle type (ambush, flank, rear), presence of elephants, charge bonus and armour level. So for

    Disabling saves during a turn
    If someone wants to limit reloading by players in their tur, this simple script can accomplish it.
    Code:
    monitor_event FactionTurnStart FactionIsLocal
        enable_save
    end_monitor
    
    monitor_event CharacterSelected
        disable_save
    end_monitor
    
    monitor_event SettlementSelected
        disable_save
    end_monitor
    This disables the "save game" button (disables quick saves as well) the moment you select any general or settlement, and enables it at the beginning of a next turn, so that a hotseater can save the game at the moment the faction scroll with a password for next faction shows up. Obviously, the player can always start over from the beginning, but assuming he has to do lot of battles/stuff, it will be pretty effective in not letting him/her, without spending additional hours on it. So essentially, the ability to make saves during player's turn is diminished.

    You easily implement it, just add this to campaign_script.txt (located in /data/world/maps/campaign/imperial_campaign) anywhere between "script" and "wait_monitors" lines. Only admin needs to do this. Also disable autosaves, via your mod cfg file. Under hotseat section add/change "autosave = 0", because otherwise a save would be made each time a player press next turn. (and hence a player could use it to save his progress)

    Economy checks
    - Many times it occurs in a hotseat, that there are several zombie factions, i.e., typically factions with some armies, a massive debt, and a settlement far from the front line given to them by their allies. However from the game point of view, these faction should normally not exist anymore, or at least it shouldnt last very long. Once could introduce simple sccripts that automatically kills of a faction if its in too high debt, or introduce other weaknesses for such factions via the scripts, such disloyalty traits, disbanding of units...
    Code:
    monitor_event FactionTurnStart FactionType venice
          and Treasury <= -25000
    
          destroy_units venice free_upkeep_unit            ; destroy all units with free upkeep attribute 
            ...         ; many options, such as to add a counter based on which the characters get disloyalty trait
    
    end_monitor
    
    monitor_event FactionTurnStart FactionType venice
           and Treasury <= -50000
    
            surrender_regions venice  ; this kills non horde factions
    
    end_monitor


    Zombie factions are often also simply forbidden by the rules, to a certain extent


    Horde factions
    - Adding this type of factions can potentionally add more layers to a hotseat. Basically, such a faction functions like a normal faction when it has settlements. But when it loses its last settlements (and some family members survided), it will turn horde mode. That means it will get spawned some new troops and moved somewhere near by the game. Until the faction settles somewhere again, it doesnt have to pay upkeep for the horde units. When conquering a settlement, the faction can choose to sack, or to occupy. Sacking would afterwards give the settlement to rebels, while occupying would cause the faction to settle and abandon its horde mode. A horde faction can go thruogh this cycle several times, based on the settings.

    To give a faction the ability to be a horde faction, one must add the following entries into descr_sm_factions.
    Code:
    horde_min_units                    10                ; min units of all horde armies combined
    horde_max_units                    20                ; max units of all horde armies combined
    horde_max_units_reduction_every_horde        10        ; reduction of horde_min_units & horde_max_units after each instance of hording
    horde_unit_per_settlement_population        250        ; population required to create 1 horde unit
    horde_min_named_characters            2                ; should be called "horde_MAX_named_characters", each sub-horde gets max 1 named general & the overall horde gets max this amount of named generals
    horde_max_percent_army_stack            80            ; the max size of each sub-horde as a percentage of 20, so: low -> many small sub-hordes, high -> few big sub-hordes
    horde_disband_percent_on_settlement_capture    33    ; disband percentage on first settlement capture (not functional in Med2)
    horde_disband_percent_on_settlement_capture    50    ; disband percentage on second settlement capture (not functional in Med2)
    horde_disband_percent_on_settlement_capture    100    ; disband percentage on third settlement capture (not functional in Med2)


    Shadow Factions
    -

    Emerging Factions

    -

    Information Scrolls for players -
    -

    Interactive features

    -

    Hotseat friendly missions
    -

    ...

    and lastly, time from time, you should always try to use a new different mod, that itself may naturally expand the hotseat gameplay.
    Last edited by Jadli; August 12, 2023 at 10:35 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •