Captain to the Rescue

[blackninja9939]

Hey @Divine we are encountering a bit of an issue with AGOT at the moment where we apprently have so many characters in the world, when new ones that are generated (such as automatically generated barons on start up) they are getting negative character ids and then become un-targetable for things like plots in which when you try to target them a different character becomes the plots target, giving them gifts does not give the opinion modifier bonus etc. Basically any action taken against them fails as the game does not seem recognise them as being proper characters.
Honestly not sure what we can do about this on our end to fix this

 

[richvh]

Sounds like your character IDs in history are too high (>2 billion). The game will start assigning IDs from the highest in history, and since AGOT is a total conversion there is no reason to use very high IDs to avoid collisions with vanilla IDs.

 

[blackninja9939]

Sounds like your character IDs in history are too high (>2 billion). The game will start assigning IDs from the highest in history, and since AGOT is a total conversion there is no reason to use very high IDs to avoid collisions with vanilla IDs.

I knew about the game having an id limit, however I did not know that it went from the highest in the history files and misses out the gaps. Is there a reason that it misses gaps as it is too much of a time waster for the engine or?
Regardless this is going to be an interesting thing to try and fix...

 

[Divine]

When the game asks for a new ID for a new character the engine will just return the highest ID created and add 1. I understand that it will be a pain to co-ordinate new id-range assignments but I think richvh might have nailed the issue.

 

[blackninja9939]

Yeah I get that is the issue, just seems a bit strange that it doesn't fill in the gaps. Although I suppose that would require more processing power to check if an id is already in use as opposed to just keeping track of single number to use and add one to on each character generation.
Ah well now beings the long process of redoing history files and events with them in

 

[Blood Royal]

I'm trying to get the Middle Earth mod up and running again, but I've run into a weird kind of CTD. It's similar to the "divide by zero" CTD that you devs helped us isolate in the Warhammer mod (and Birthright which was suffering from the same), except that this time it happens consistently when you loot the last holding of the province. I ran some debug tools, and it is very much a divide by zero error that is related to raiding.

Here is the mod:
http://www.mediafire.com/download/bwsvpadvxozrdzz/MEP_BR_Version.rar

And here is a save where you just have to disembark your army and go raid that little island's last holding, and it'll CTD every time:
http://www.mediafire.com/download/5ykqi1j3p7xy6jc/test.ck2

I'm pretty sure that like the AI pathfinding CTD that occurred due to province numbers being out of order, this is something in the game code. It crashes without an error message. It would be great if one of you could take a look and let us know if this is something that'll be fixed in the next patch. Any help is appreciated, at least! I've tried looking through the bug report forum, but no one else seems to have reported a repeatable CTD related to raiding a last holding.

 

[Divine]

Yeah I get that is the issue, just seems a bit strange that it doesn't fill in the gaps. Although I suppose that would require more processing power to check if an id is already in use as opposed to just keeping track of single number to use and add one to on each character generation.
Ah well now beings the long process of redoing history files and events with them in

Unfortunately I think that is the current solution you have to aim for. I'm poking and prodding a bit but I'm hesitant to change such an old behavior in the engine.

I'm trying to get the Middle Earth mod up and running again, but I've run into a weird kind of CTD. It's similar to the "divide by zero" CTD that you devs helped us isolate in the Warhammer mod (and Birthright which was suffering from the same), except that this time it happens consistently when you loot the last holding of the province. I ran some debug tools, and it is very much a divide by zero error that is related to raiding.

Here is the mod:
http://www.mediafire.com/download/bwsvpadvxozrdzz/MEP_BR_Version.rar

And here is a save where you just have to disembark your army and go raid that little island's last holding, and it'll CTD every time:
http://www.mediafire.com/download/5ykqi1j3p7xy6jc/test.ck2

I'm pretty sure that like the AI pathfinding CTD that occurred due to province numbers being out of order, this is something in the game code. It crashes without an error message. It would be great if one of you could take a look and let us know if this is something that'll be fixed in the next patch. Any help is appreciated, at least! I've tried looking through the bug report forum, but no one else seems to have reported a repeatable CTD related to raiding a last holding.

I did a quick check and this define is causing a crash because of a fault from our side.
NDefines.NMilitary.LOOT_HOLDING_DESTRUCTION_ODDS = 0 in mod\MiddleEarthProject Beta\common\defines\00_dummy.lua

This define is used to do a random roll with a 1/x chance of destroying the holding. Which resulted in a divide by zero. It should be fine to have the define as zero to negate the mechanic entirely in my opinion so I'm doing a fix for that but in the meantime I would suggest to just use a high number (I think a number up to 2 billion should work) or to try and set NDefines.NMilitary.LOOT_HOLDING_DEST_MIN_SAFE to zero (which should also negate the destruction of holdings since all holdings should have at least the zero buildings required to be safe) for testing purposes in the meantime.

 

[Blood Royal]

I did a quick check and this define is causing a crash because of a fault from our side.
NDefines.NMilitary.LOOT_HOLDING_DESTRUCTION_ODDS = 0 in mod\MiddleEarthProject Beta\common\defines\00_dummy.lua

Thanks for your quick assistance, and during the summer vacation even! Changing that did indeed work.

Fault is partly mine too, I might have spotted that divide by zero too when I was poking around in the defines.lua, but I had no idea someone on the team at some point had actually used that 00_dummy.lua file So I was working on the original in /common the whole time.

 

[Alphathon]

Did some small investigations. Apparently the title_prefix defined in landed_titles only works for titles that has a culture set as well. I didn't have time to investigate if there's a good reason for that so I've not changed something in that regard but a work-around would be to add cultures to all of the titles that should receive title_prefix.
About the set_name, reset_name issue I didn't see anything blatantly wrong with it at first sight but I'll take a closer look on it when I have more time.

This is sort of a follow up to my previous question. Is it possible to have culture-specific custom title prefixes using title_prefix similar to the culture-specific variants of normal prefixes, e.g. kingdom_of_arabic. For example, something like title_prefix = grand_duchy_of in landed_titles and grand_duchy_of_arabic in the localisation. I'm sure that I was able to do this in the past but it doesn't currently seem to be working. (Perhaps this was changed at the same time as the culture thing.)

 

[Divine]

This is sort of a follow up to my previous question. Is it possible to have culture-specific custom title prefixes using title_prefix similar to the culture-specific variants of normal prefixes, e.g. kingdom_of_arabic. For example, something like title_prefix = grand_duchy_of in landed_titles and grand_duchy_of_arabic in the localisation. I'm sure that I was able to do this in the past but it doesn't currently seem to be working. (Perhaps this was changed at the same time as the culture thing.)

Do you mean that as culture-dependent on the current holder of the title?

The title_prefix in landed titles seems to have been untouched for quite a while in code. However I guess the title_prefix in government isn't totally fitting your needs?

 

[M@ni@c]

The on_settlement_construction_start action trigger doesn't seem to be working. The following events fires under on_settlement_construction_completed but not under on_settlement_construction_start.

character_event = 
{
    id = Maniac.136
    desc = "EVTDESCM136" #Shall we build this temple with piety instead of gold?
    picture = "GFX_evt_council"
   
    is_triggered_only = yes
   
    trigger = 
    {
        #always = no
        ROOT = 
        {
            OR = 
            {
                AND = 
                {
                    piety = 500
                    ai = no
                }
                AND = 
                {   
                    piety = 750
                    ai = yes
                }
            }
        }
        FROM = { holding_type = temple }
    }
   
    option = 
    {
        name = "YES" # 
        ROOT = 
        {
            piety = -500
            wealth = 500
        }
    }
   
    option = 
    {
        name = "NO" # 
    }
}

 

[Alphathon]

Do you mean that as culture-dependent on the current holder of the title?

The title_prefix in landed titles seems to have been untouched for quite a while in code. However I guess the title_prefix in government isn't totally fitting your needs?

Yeah, its the landed_titles one I'm talking about. For what I want to do it needs to be used on a per-title basis, not per-government, so the government type one is a no-go.

 

[theStormWeaver]

Would you be willing to look at separating the "hide this religion from the ledger" effect of pre_reformed = yes into a different attribute? Perhaps something like in_ledger = no (defaulting to yes)?

It's a real pain for any mods looking to make pre-reformed pagans playable for them to be hidden.

 

[Divine]

The on_settlement_construction_start action trigger doesn't seem to be working. The following events fires under on_settlement_construction_completed but not under on_settlement_construction_start.

character_event =
{
    id = Maniac.136
    desc = "EVTDESCM136" #Shall we build this temple with piety instead of gold?
    picture = "GFX_evt_council"
  
    is_triggered_only = yes
  
    trigger =
    {
        #always = no
        ROOT =
        {
            OR =
            {
                AND =
                {
                    piety = 500
                    ai = no
                }
                AND =
                {  
                    piety = 750
                    ai = yes
                }
            }
        }
        FROM = { holding_type = temple }
    }
  
    option =
    {
        name = "YES" #
        ROOT =
        {
            piety = -500
            wealth = 500
        }
    }
  
    option =
    {
        name = "NO" #
    }
}

I think I made a fix for that issue recently, I did a quick check in the log and it seems like my changes should make on_settlement_construction_start fire properly. So hopefully it should be resolved in the next patch.

Yeah, its the landed_titles one I'm talking about. For what I want to do it needs to be used on a per-title basis, not per-government, so the government type one is a no-go.

I did a quick hook-in on the other system for localisation. However the title_prefix needs to be placed first but after that it should be compatible with the optional variations in the same order as usual (which I can never remember). Eg _female, _<culture>, _<religion>.

Would you be willing to look at separating the "hide this religion from the ledger" effect of pre_reformed = yes into a different attribute? Perhaps something like in_ledger = no (defaulting to yes)?

It's a real pain for any mods looking to make pre-reformed pagans playable for them to be hidden.

That sounds like an annoying thing. I've made sure to add a task for it. Time will tell when I have the time to look into it however.

 

[Alphathon]

I did a quick hook-in on the other system for localisation. However the title_prefix needs to be placed first but after that it should be compatible with the optional variations in the same order as usual (which I can never remember). Eg _female, _<culture>, _<religion>.

I'm not sure I understand what you mean. Are you saying that it should work in a future patch or that it should work now? Also, when you say "the title_prefix needs to be placed first" do you just mean it needs to be in the format <prefix>_<culture>? (If so, that's what I would have expected.)

 

[Divine]

I'm not sure I understand what you mean. Are you saying that it should work in a future patch or that it should work now? Also, when you say "the title_prefix needs to be placed first" do you just mean it needs to be in the format <prefix>_<culture>? (If so, that's what I would have expected.)

Yes it will work in a future patch. It's a bit of a quick solution I pulled together so it might have some issues but with the minimal testing it seemed to work. And yes it's the format you have but I always forget in what order we then evaluate the variations of; _female, _culture, and so on.

 

[richvh]

I believe it's (<government>_)<title>(_<female>)(_<religion/culture>)

 

[starwarsfan541]

I noticed when making a law adding things like pagan_opinion = 10 does not seem to work in laws, is this a bug or could it be fixed? I need my one law to give postivie opinion bonus to other specific religions

 

[Hotl3looded]

I'll copy paste my question from another thread:

I made a settlement decision to enable pillage to non-nomadic rulers. I want to be able to use it ONLY for occupied holdings (after a successful siege) and NOT for holdings that I own. The decision has "is_high_prio = yes" because I want an alert to pop whenever I occupy a holding that satisfies all my conditions for pillage. The problem I have is that the alert won't pop up.

The vanilla decision for pillage has the condition "controlled_by = FROM". Since the condition "controlled_by" also applies to holdings that I own, I added this piece of code to the potential section of the decision:

controlled_by = FROM

# New condition
holder_scope = {
   NOT = {
      character = FROM
   }
}

Without the new condition the alert pops up but the decision is enabled for holdings that I own. With the new condition, I can only pillage occupied holdings during war but the alert won't pop.

What can I do if I want to pillage ONLY occupied holdings during war AND have an alert?

 

[Divine]

I'll copy paste my question from another thread:

I'm assuming that you use the 'filter = all' in the top of the decision.
But it seems that there might have been a possible issue with the exact combination of filter = all for settlement_decisions that could result in it not evaluating all of the decisions when updating the alerts. I've made a fix for it now.