Home Trending Latest threads New posts Developer diaries

Suggestions for Improved Moddability

Jump to latest Follow Reply
  • We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Crusader Kings II 69947 Bug Reports 19719 User Modifications 10606 Suggestions 5969 Tech Support 6376 After Action Reports
Show only dev responses
fishface60 said:
  • A way to copy a reference to an earlier scope onto the scope stack.
    Using PREV = {} and their ilk moves the stack pointer back, which means you can't refer to a scope you put on the stack later. So the following doesn't work for generating a unique identifier:
    Code: 
    ROOT = {
    any_title = {
        limit = { check_variable = { which = title_id which = PREV } }
        PREV = { set_variable = { which = title_id which = PREV } }
    }
    change_variable = { which = title_id value = 1 }
}
    Substituting ROOT={ for PREV={ would work here, but I don't always want to do it for the target of the decision.
    I've ended up doing the following, which is far from ideal, as it makes setting the ID polynomial on the number of titles:
    Code: 
    ROOT = {
    any_title = {
        limit = { check_variable = { which = title_id which = PREV } }
        any_title = {
            limit = { title = PREVPREV }
            set_variable = { which = title_id which = PREV }
        }
    }
    change_variable = { which = title_id value = 1 }
}
Click to expand...

Can't you use PREVPREV to compensate for the fact PREV is a scope change ?
Code: 
PREV = { set_variable = { which = title_id which = PREVPREV } }
 
Romulien said:
Can't you use PREVPREV to compensate for the fact PREV is a scope change ?
Code: 
PREV = { set_variable = { which = title_id which = PREVPREV } }
Click to expand...

You'd think so wouldn't you, but from what I could tell, using PREV jumped me back to that scope, rather than adding PREV on top of the scope stack.
Which is unfortunate, since ROOT and FROM add the scope on top of the stack as you'd expect/
Code: 
ROOT = { # <title:ROOT>
    create_title = {}
    new_title = { # <title:ROOT>, <title:new>
        any_title = { # <title:ROOT>, <title:new>, <title:potential>
            limit = { check_variable = { which = title_id which = PREV } # Titles with higher title ID
            PREV = { # <title:ROOT>, <title:new>
                # Expected <title:ROOT>, <title:new>, <title:potential>, <title:new>
                # PREV here is actually ROOT
                set_variable = { which = title_id which = PREV }
            }
        }
    }
}
 
If you try scoping to PREV when you're already in a PREV scope, it actually skips the current scope and goes to the scope two before the current one, instead of the one before. Very annoying, I agree.
 
Unfortunately, changing PREV={ to behave like FROM={ and ROOT={ would probably break things.
I know I had some scripts that accidentally worked before I understood this behaviour because it happened that the nested PREV happened to refer to the right title.
 
DC123456789 said:
If you try scoping to PREV when you're already in a PREV scope, it actually skips the current scope and goes to the scope two before the current one, instead of the one before. Very annoying, I agree.
Click to expand...
PREV does indeed behave kind of strange. Looking at the crusade CB, there's a weirdness that may do what you want. In very abbreviated form, it does this:

Code: 
on_success_title = { # title scope.
    most_participating_crusader = { # character scope.
        PREV = { conquest_culture = THIS } # PREV refers to the title, THIS inside the PREV refers to the character.

take_spouse_out_of_hiding decision does a similar use of THIS inside PREV.

On the other hand, pillage_settlement decision uses a PREVPREVPREV inside a PREVPREV that appears to work as expected. And PREV inside PREV seems to work as expected in the raise_tribal_units decision. :confused:

Also recall that you can use a save_event_target_as to hang on to the scoped character. This works in events, decision, and CBs, at the least. It may work in any effect blocks. I know that event targets can be at least characters, titles, and provinces, possibly also wars, sieges, and units. But saving event targets inside an any_* scope that matches more than one might be problematic. But if you can save the target outside the any_*, you can use it inside the any_* with no problem.
 
When an isolated section of an ocean is only connected the rest via a 'river' type sea province, Trade Posts default to a minimum distance cost as it cannot pathfind to the location, presumably. So everyone in that ocean can build Trade Posts for ~150g, no matter how far away they actually are. Is this at all fixable?
 
Npg, I do not believe that is a bug, more it is something that was never thought of. That said, It might be worth crossposting the report on the behavior in the Captain to the Rescue thread as I suggested earlier Shade, as the behavior you describe it there does seem like it might be WAD but not WAI.
 
I was told that the following things could not be completeted in the current Modding framework, which will damage our team's production of the Super Mario Mod.

1. Catholic religious items should be addable to custom religions without giving the whole shabang over. For example, I should have a means where the Head of Religion can nominate temple vassals a la the Pope without having all the other Papal mechanics.
1.2. I should be able to mix and match all religious features (autocephalacy, free or papal investiture, etc. etc.) with all other features with few exceptions (like a ban on more than one Papacy, obviously).​

2. A "REQUIRES BRIDE PRICE" modifier that I can add to a culture, religion, or government type (etc. etc.) so that non-Republicans can use them.

3. A secular ruler that can still always exist in custom religions if AI. In the Mario Mod, several religious mechanics are based on lifestyles persued with religious devotion. Just because an AI religious head is removed shouldn't automatically mean the head ceases to exist.

4. I should be able to add modifiers for traits to each religion. For example, a "Pirate religion" should give church opinion modifiers to those who are Deceitful and have the Intriuge Trait, while the Tengri religion should have a negative malus to the Zealous Trait.
 
Korbah said:
- Enable the use of ifs in scripted_effects. Right now scripted_effects are little more than container for a list of effects, you can use random_list and random but that seems to be it, this greatly limits the usefulness of this feature.
Click to expand...

IIRC Gars stated that any command should be usable as scripted effect, so maybe this is sorth reporting in the Captain to the reacue thread?
 
One thing I would really like to see, is some way to call a diplomacy menu from a decision. Let me choose multiple targets for my targeted events. Surely it is not hard to let us have a court/diplomacy scoped diplomacy menu from a decision?




Oh and one final thing, the ability to apply the command_modifier effects to a personal modifier. It should be possible to be able to cause temporary boosts to speed or to damage or to morale without having to do complex sequences of events to add and remove temporary traits.
 
Last edited:
Zarathustra_the said:
One thing I would really like to see, is some way to call a diplomacy menu from a decision. Let me choose multiple targets for my targeted events. Surely it is not hard to let us have a court/diplomacy scoped diplomacy menu from a decision?
Click to expand...
That is already on the list I believe titled as third part decisions to simulate the selection of a third person when using targeted decisions.
 
  • 1
Reactions:
I just added the suggestion "Remove the ledger-hiding effect on the prereformed = yes command and create a new command hide_from_ledger = yes to do it instead. That way, hellenic can be seen in the ledger if a mod has expanded on it or someone could hide catholic if they want Catholicism to be hidden in their mod without losing the maintenance events associated with the Pope."

That way, mods like Ancient Religions Reborn can have Hellenic appear in the ledger or a mod that takes place before Christianity don't have to worry about rewriting a bunch of events.
 
  • 1
Reactions:
JGBeagle said:
I just added the suggestion "Remove the ledger-hiding effect on the prereformed = yes command and create a new command hide_from_ledger = yes to do it instead. That way, hellenic can be seen in the ledger if a mod has expanded on it or someone could hide catholic if they want Catholicism to be hidden in their mod without losing the maintenance events associated with the Pope."

That way, mods like Ancient Religions Reborn can have Hellenic appear in the ledger or a mod that takes place before Christianity don't have to worry about rewriting a bunch of events.
Click to expand...

I fully endorse this idea!
 
A really powerful effect would be the ability to dynamically call an event id save somewhere else in the event chain. This would effectively enable the writing of more modular events, and cut down significantly on event bloat. Currently you can sorta do this, but in parsing the code back, you need to use an if switch, and in a worst case scenerio of having a thousand flag event switch it strikes me as potentially impossible for the game engine to not throw a wobbly at. so let us declare an event id as a variable early in an event chain, and then let us call it from any event in the chain dynamically.
 
  • 1
Reactions:
You must log in or register to reply here.
Top Bottom
Back