Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

I can do a quick review but I think there's a few indirect factors as to why stealthy units are generally better spotters. That said, if you give your hunters visibility promos they can get very good at it... I often throw a second hunter along with a stealthy one to be a spotter.

Thank you for the save. Keep it up there for a bit... that's going to be something I want to fix immediately (assuming it's on the latest SVN that it's taking place.)

Well, no need for a second hunter or upgrading their spotting when I've got stealthy units that can see a lot of the sneaky animals and treat all terrain as 1 movement.

I haven't updated the SVN since two days ago, so it's not the most recent, but five numbers back or so.
 
Well, no need for a second hunter or upgrading their spotting when I've got stealthy units that can see a lot of the sneaky animals and treat all terrain as 1 movement.
Stealth units are more expensive to maintain. Strike teams are very good hunting units, yes, but they aren't as good at subduing by any means. I do tend to get them out there to level them up a bit though.

The save should be recent enough to be valid for that issue then.
 
Stealth units are more expensive to maintain. Strike teams are very good hunting units, yes, but they aren't as good at subduing by any means. I do tend to get them out there to level them up a bit though.

The save should be recent enough to be valid for that issue then.

Well, it's more that they take the role of dogs and scouts in that regard at least. And being better at it unleveled... It just seems unbalanced is all, but it certainly makes them even more useful than they already are, so I'm not complaining. I wouldn't use them to actually attack the animals, just hang around to spot the elusive ones AND earn xp from attacking neighbour units.

Scouts or dogs are worse in that regard that they either can't attack or you don't want to use them to attack, because dogs don't subdue that well. So you don't really level them up at all... It would be great with a small xp increase for spotting hard to find units, like watchmen get small amounts of xp for investigating criminals.


VERY important possible bug I forgot to mention! Also with the strike units, when on "Stay the hand", you can enter an opponents square with a unit in it and pillage whatever's underneath it, roads, improvements and obviously most important of all - forts. Ambushers can't pillage forts, because they don't have the enter city ability.


I'm pretty sure you can use one of my units from the save I gave you earlier and test it with one of the thieves/rogues. The Head Hunters AI has a fort in the desert south of my territory.
 
SVN 9820 with Interface Overhaul 0.5.9.2.1.1, Combat Mod: Quality up Promotions are not retained when upgrading. In the north of the continent there is a unit "Obsidian Axeman 1 (Neuss)" with 10.5 :strength:, 1 :move:, Level 9, Exp. 8/82 and promotions Combat I, Hunter I, Woodsman III, Astonishing Acumen and Exceptional Might II, Status Standout. If this unit is upgraded to Axeman (which can be done immediately), it has 7 :strength:, retaining Combat I, Hunter I, Woodsman III, Standout, but losing both Astonishing Acumen and Excep. Might II without either replacement or retraining options - Experience is still 8/82. After a recalc the unit gains Shock I, and is now much weaker than before upgrading.

The save was originally made with revision 9804, but the error remains with 9820.
 

Attachments

@Thunderbrd I've also noticed this issue (the above post by tmv), but my save was started from before r9802.
I thought that my save was a lost cause due to being already bug ridden, but it seems tmv also suffers from this.
If you want, I can also upload saves (as many as you need) to check the bug in more cases.

For clarification- I think that the quality up had two separate issues:
1) When gaining a promotion, the unit might lose quality up - this was solved at r9802.
2) When a unit is upgraded, it may lose its quality up promotion - seems to still exist.
 
Last edited:
... Quality up Promotions are not retained when upgrading. ...
I always thought that was how it was supposed to be! After all when they are upgrading they are spending the turn getting trained in the new equipment and the tactics and strategy of using them and not doing their normal job.
 
I always thought that was how it was supposed to be! After all when they are upgrading they are spending the turn getting trained in the new equipment and the tactics and strategy of using them and not doing their normal job.
The issue becomes that beside a few special cases, upgrading a unit with quality up reduces the unit's strength considerably, without a valid option to get them back. When a unit that was "earth shattering" 500 power drops to mere 60, well, you don't feel like you bartered a good deal out there.
Personally, I always envisioned the cost of upgrading exactly that- the cost of the new equipment (with the old being sold), and retraining the units to use it.
Otherwise, there should at least be some indication that upgrading will lose the said promotions, and that it's not a bug.
 
getting trained in the new equipment
In this particular case (Obsidian Axemen => Axemen) that shouldn't be so difficult, especially considering the length of a turn. Besides, the turn is over for this unit anyway.

And Axemen have a lower quality than Obsidian Axemen as a standard value. I'm not asking for the Axemen unit to stay at exceptional ... that would give them an additional quality up promotion (could be nice as an option. although it would certainly exacerbate the steamroll effect).
 
I always thought that was how it was supposed to be! After all when they are upgrading they are spending the turn getting trained in the new equipment and the tactics and strategy of using them and not doing their normal job.
Quality is combat savvy, willingness and ferocity. Has nothing to do with the actual tactics and strategies nor the equipment but rather raw warrior mindset. A tiger, for example, has a very high combat quality.

This is a bug - often the base quality may change on a unit when it upgrades, but IF it does, then it tallies up how many quality up shifts it should take after the upgrade (or rather during it) and will assign applicable quality upgrade promotions to equal the amount of shifts up the unit previously had. How this has stopped working after working all this time I cannot say...maybe had to do with fixing the previous issue somehow.

I will fix it by v38.

In this particular case (Obsidian Axemen => Axemen) that shouldn't be so difficult, especially considering the length of a turn. Besides, the turn is over for this unit anyway.

And Axemen have a lower quality than Obsidian Axemen as a standard value. I'm not asking for the Axemen unit to stay at exceptional ... that would give them an additional quality up promotion (could be nice as an option. although it would certainly exacerbate the steamroll effect).
More crude humans were more savage and ready to fight. As they began using more and more refined weaponry and adopting specialized roles in a community rather than all needing to be ready to fight at all times, as well as earning a more complex social structure, they began to slip a little in their overall ferocity but made up for it with greater numbers and organization and strength of weapons. It goes to show that as we develop technology, it quickly goes from being a wondrous new discovery to a relied upon need.
 
I realised afterwards that I was talking about "build up" promotions not "quality" promotions.

However this does bring up the question of when does the unit doing whatever it is doing to get the build ups actually do its thing? Does it use up one or more of the units movement points? All I assume. The reason is that if you have used all the moves for a unit that turn you can't upgrade it and if you upgrade it that uses up all the remaining movement the unit has. Arte we getting double use of these units if they do their ting eg investigate crime and are upgraded?
 
I realised afterwards that I was talking about "build up" promotions not "quality" promotions.

However this does bring up the question of when does the unit doing whatever it is doing to get the build ups actually do its thing? Does it use up one or more of the units movement points? All I assume. The reason is that if you have used all the moves for a unit that turn you can't upgrade it and if you upgrade it that uses up all the remaining movement the unit has. Arte we getting double use of these units if they do their ting eg investigate crime and are upgraded?
There's a few questions here, not just one.

Build up promotions are immediately gone as soon as a unit is wakened. They are very touchy that way. If a unit moves, all buildups are gone as soon as it does (though the promos hang on until arrival at the move destination. Thus they can count for battle, which is why the fortify build up is now a defense modifier rather than a combat modifier - but set for charge, for example, still works for an attack.) An upgrade will wipe out all build up promos. Investigation, however, is a passive ongoing effort and takes place between the rounds.
 
The mission adding a population to a city is uses a default Event not Python code so the problem is that the mission on all the units is being done based on the initial city population not the population as units are added.
Code:
                <Action>
                    <MissionType>MISSION_JOIN_CITY_POPULATION</MissionType>
                    <ActionOutcomes>
                        <Outcome>
                            <OutcomeType>OUTCOME_JOIN_CITY_POPULATION</OutcomeType>
                            <iChance>100</iChance>
                            <EventTrigger>EVENTTRIGGER_ADD_ONE_POPULATION</EventTrigger>
                            <PlotCondition>
                                <IntegrateOr>
                                    <RelationType>RELATION_ASSOCIATED</RelationType>
                                    <GameObjectType>GAMEOBJECT_CITY</GameObjectType>
                                    <GreaterEqual>
                                        <Constant>7</Constant>
                                        <AttributeType>ATTRIBUTE_POPULATION</AttributeType>
                                    </GreaterEqual>
                                </IntegrateOr>
                            </PlotCondition>
                        </Outcome>
                    </ActionOutcomes>
                </Action>

IE the mission test is happening on all the units before the event is triggered for any of them.

I will need to change the code a lot to get the differing thresholds but we will no longer be able to use the event if it acts this way
I looked into what's happening with this and it is seriously worse than I thought. At first I thought I'd found the bug and it had to do with the plot condition only being checked when we were simply looking to see if the mission button should be visible or not. THEN, repairing that, I find out that portions of the mission definition are calling to the wrong mission entirely. There is so much messed up with these missions that I'm surprised any are working at all or that it's even doing what it should do. It's, at least in some places, defined as MISSION_BARBARIAN_ENVOY, which has no plot requirements at all.

Have you been having trouble with these Action Outcome Missions not working as designed in general? I may really have to consult with AIAndy on this. I suspect that the ID references to missions are going haywire due to a conflict between hardcoded ID definitions and extra ones that get added later. I may be a little in over my head on this. It even looks like the code only allows for one mission that can be defined this way for a given unit.
 
I've noticed that the doctor's building (the +5 health... forgot the full name), surgeon office and water treatment plant doesn't seem to give as much as indicated. doctor and surgeon should give -80 disease, water treatment should give -100, but the actual effects didn't seem as high (didn't test it directly, but it seemed that it wasn't as effective as expected.
In addition, I think the shaman (or druid?) building that prevent unhealth from buildings works on diseases, too. I doubt diseases should be exempt due to implementation.
 
I looked into what's happening with this and it is seriously worse than I thought. At first I thought I'd found the bug and it had to do with the plot condition only being checked when we were simply looking to see if the mission button should be visible or not. THEN, repairing that, I find out that portions of the mission definition are calling to the wrong mission entirely. There is so much messed up with these missions that I'm surprised any are working at all or that it's even doing what it should do. It's, at least in some places, defined as MISSION_BARBARIAN_ENVOY, which has no plot requirements at all.

Have you been having trouble with these Action Outcome Missions not working as designed in general? I may really have to consult with AIAndy on this. I suspect that the ID references to missions are going haywire due to a conflict between hardcoded ID definitions and extra ones that get added later. I may be a little in over my head on this. It even looks like the code only allows for one mission that can be defined this way for a given unit.
You can have the plot condition on the Mission or the Outcome or the ActionOutcome. It all depends on how general you want each to be. Joining a city (Mission) was used for a number of different units but has different outcomes depending on the unit and so on. This means that the only plot condition on the mission is that it needs to be in your city, well actually a friendly city I expect, as I think you can add an immigrant to a team member's city or even a city of someone you have Open Borders with. The point is that Missions were supposed to have many possible Outcomes and each Outcome may have one or more ActionOutcomes.

The only problems we have had with them going haywire is when we moved them into core. The Cannibal and Sacrifice ones are not working any more.

As far as I know it is the units Actions that are looked at to see if the Mission is visible. Or at least the Unit Action Outcomes, then Unit Actions, then Outcomes, then Missions not the other way around. This is why the plot conditions are on the Action Outcomes rather than the missions.
  • Mission determines the button and text before you press text.
  • Outcomes determines the result text.
  • Unit ActionOutcomes determines which Outcome happens.
 
You can have the plot condition on the Mission or the Outcome or the ActionOutcome. It all depends on how general you want each to be. Joining a city (Mission) was used for a number of different units but has different outcomes depending on the unit and so on. This means that the only plot condition on the mission is that it needs to be in your city, well actually a friendly city I expect, as I think you can add an immigrant to a team member's city or even a city of someone you have Open Borders with. The point is that Missions were supposed to have many possible Outcomes and each Outcome may have one or more ActionOutcomes.

The only problems we have had with them going haywire is when we moved them into core. The Cannibal and Sacrifice ones are not working any more.

As far as I know it is the units Actions that are looked at to see if the Mission is visible. Or at least the Unit Action Outcomes, then Unit Actions, then Outcomes, then Missions not the other way around. This is why the plot conditions are on the Action Outcomes rather than the missions.
  • Mission determines the button and text before you press text.
  • Outcomes determines the result text.
  • Unit ActionOutcomes determines which Outcome happens.
How do you figure we're getting any reference at all to MISSION_BARBARIAN_ENVOY in the way the Captive-Civilian is setup?

@AIAndy If you can hear me... I may need your help debugging this one.
 
Back
Top Bottom