Unofficial BTS 3.13 patch

I find that same problem in all the games I play. Sometimes the enemy units just sit there (in a tile next to my city) doing anything until the war is over or I kill them. They kind of "freeze". But it happens with only some of the enemy stacks, the others behave normally.

Solver's patch for 3.02 seemed to fix this stupid bug, but since 3.13 it's made a return. Doesn't happen anywhere near as much as it did originally but it's still very annoying.
 
I've seen the enemy "park" stacks near my cities too, but usually they continually reinforce the stack until they have sufficient units to attack and take the city. If they aren't reinforcing, and they aren't being prevented from doing that, then it's probably not good behaviour.

Bh

I've noticed this too. Move a few units into position threatening the enemy's stack, and they'll start moving....
 
Ah, yes, I found what's causing the problem....

... the ID still exists each turn to verify the Galley isn't lost (apparently that's a valid way to fail the quest?).

Should be doable.

Bh

Brilliant! Actually, losing the galley is not a valid way to fail the quest, at least as far as the description of the quest that's given when it arrives. You can, of course, find the description of the quest in the log together with the events log etc., at the top left-hand corner of the screen, to verify what are the valid ways of failing the quest.

Thanks so much for fixing this. I've no idea why this bug so bugs me. Perhaps it's on account of the name! ;)

Mind you, it's a real shame for anyone coming new to the game, completing a quest and then finding the quest has mysteriously disappeared...
 
Brilliant! Actually, losing the galley is not a valid way to fail the quest, at least as far as the description of the quest that's given when it arrives.

The description isn't an accurate representation, however, I'm going by the actual quest set up. The quest is given to a specific unit. Therefore the quest is only valid as long as that unit exists. This is true for all quests that are assigned to units, btw, not just this one.

Bh
 
Ah, yes, I found what's causing the problem. Each unit has a unique ID. The event code saves the ID of the Galley when the quest is started, and then checks to make sure the ID still exists each turn to verify the Galley isn't lost (apparently that's a valid way to fail the quest?). But when you upgrade a unit, it generates a new ID. So the game tries to find a unit matching the previous unit, fails to find it, and assumes the galley has been lost.

Fixing the problem on the other hand... I'll probably need to do a manual cycle through of all active quests when upgrading a unit to see if that unit is the target of a quest, and then save the new ID if that's true. Should be doable.

Bh

I was under the impression that you weren't supposed to upgrade these special quest units. That was part of the point. Perhaps not though...
 
The description isn't an accurate representation, however, I'm going by the actual quest set up. The quest is given to a specific unit. Therefore the quest is only valid as long as that unit exists. This is true for all quests that are assigned to units, btw, not just this one.

Bh

This leaves me a little confused (not that I have a problem understanding that a quest may be given to a specific unit!), but when the quest arrives it is addressed to the civilization. (It's the civilization that has to build cities on different continents, not the galley.) Other quests at least manage to appear as if they work this way; for instance, your civilization must build a certain number of libraries or stables and you will get a choice of benefits.

How strange to find that all quests, instead, are attached to units! I hope that with the others the loss of the unit in question doesn't lead to the withdrawal of the quest for the entire civilization. I imagine that there must be some kind of distinction between how the quest appears to the user (as addressed to the civilization) and how it is coded to work (as attached to a unit but managing to appear addressed to the civilization).
 
I was under the impression that you weren't supposed to upgrade these special quest units. That was part of the point. Perhaps not though...

Well, experience has shown me that I shouldn't upgrade the galley, but there's nothing I can see anywhere to say that units shouldn't be upgraded. There is no mention of 'not upgrading' when quests are given. It would seem rather odd if this were the case.

Actually, I have to say, also, that this bug was confirmed as being a bug in the bugs thread.
 
I was under the impression that you weren't supposed to upgrade these special quest units. That was part of the point. Perhaps not though...

Well, part of the problem is that lack of clear documentation on how the quest is supposed to work. It's assigned to a unit, when there doesn't seem like a clear reason for it to be. It fails if that unit is destroyed without mentioning that as a fail condition. It also fails if you upgrade the unit, which is also not mentioned as a fail condition. More specifically, it'll fail if you upgrade the unit to another unit type that still matches the types allowed for the quest.

I must admit that I was misled by the thread in the bugs forum. I hadn't read the full thread, so going by the title, I assumed it refered to this issue, when instead it refered to Industrialism vs Industrial Era. So it might be possible this is a "works as intended" situation, just without the corresponding documentation.

On the other hand, I still don't think you should fail quests if you upgrade the unit, unless the quest is tied to a particular unit type. For example, the farm bandits quest where you "dispatch troops" to guard the farm - and you end up with a unit that can't move for 2 turns. It doesn't make sense that if you upgrade that unit, that would "fail" the guarding. At least, it doesn't to me.

Anyway, this one probably requires a bit more thought (it'd be nice to know what the original intentions for this event were, and whether the unit requirement is an oversight, or deliberate).

Bh
 
How strange to find that all quests, instead, are attached to units!

No, that's not true. If you re-read what I wrote, I said that it's true for all events that are assigned to units. Not all events are.

Actually, I have to say, also, that this bug was confirmed as being a bug in the bugs thread.

No, what was confirmed is that the quest failed with the Industrial Era, not Industrialism. That's a separate bug.

Bh
 
[*]Improved worker threat assessment from units able to move multiple squares
@ Bhruic

Thanks for the great fixes so far Bhruic, great work!

I have noticed in a few games since the above feature was introduced to the unofficial patch that Settler units are 'seeing' potential threats (such as wolves and panthers), even when said animals are within fog of war. Thus, when dispatching Settlers on automated journeys, they will stop their movement even though the threat is not technically visible. This removes the element of risk when sending out Settler units, and I assume is not an intended game mechanic.

I was wondering why my automated Settler moves were being interrupted occasionally, and was surprised when I discovered my adventurous citizens possessed latent psychic abilities. :lol:

Has anyone else noticed this new behaviour? And I assume that it is not an intended side effect of the fix (even if it is sometimes welcome! :) ).
 
Well, part of the problem is that lack of clear documentation on how the quest is supposed to work. It's assigned to a unit, when there doesn't seem like a clear reason for it to be. It fails if that unit is destroyed without mentioning that as a fail condition. It also fails if you upgrade the unit, which is also not mentioned as a fail condition. More specifically, it'll fail if you upgrade the unit to another unit type that still matches the types allowed for the quest.

I must admit that I was misled by the thread in the bugs forum. I hadn't read the full thread, so going by the title, I assumed it refered to this issue, when instead it refered to Industrialism vs Industrial Era. So it might be possible this is a "works as intended" situation, just without the corresponding documentation.

On the other hand, I still don't think you should fail quests if you upgrade the unit, unless the quest is tied to a particular unit type. For example, the farm bandits quest where you "dispatch troops" to guard the farm - and you end up with a unit that can't move for 2 turns. It doesn't make sense that if you upgrade that unit, that would "fail" the guarding. At least, it doesn't to me.

Anyway, this one probably requires a bit more thought (it'd be nice to know what the original intentions for this event were, and whether the unit requirement is an oversight, or deliberate).

Bh

It strikes me as odd that, in quests given to specific units, if that unit is uprgraded to a unit of the same type the quest should fail. Logically, the upgraded unit ought to be able to accomplish its task better.

On the Blessed Sea Quest, I can't really see any good reason why it should be linked to a specific unit. The game certainly also lacks the documentation to make such a condition clear. The 'sense' of the quest is that it is something that the civilization is challenged to achieve, and so it fails if the civilization doesn't reach the objective. In this case, even if the initial unit were lost, the quest ought to remain valid.

(... unless, of course, not knowing the original intentions, I am missing something! But then, the documentation really ought to make the full story clear!)
 
About the blessed sea quest.

I don't think a quest that is on the level of city building should be linked to an individual unit, especially if this fact is undocumented. Maybe it was an easy way to program it, I don't know, but I don't think it is desirable.

Can anyone produce a valid reason why the success or failure of a quest with the objective to colonise several different continents should be linked to the existence of one single unit?

I think this might be the kind of change a community as large and diverse as the civilisation community would agree upon...

edit: or exactly what Aquatic said.
 
I don't think a quest that is on the level of city building should be linked to an individual unit, especially if this fact is undocumented. Maybe it was an easy way to program it, I don't know, but I don't think it is desirable.

I don't know either. As far as I can tell, it's the:
Code:
<iNumUnits>1</iNumUnits>
that's doing it. Because if I remember correctly, it gives the quest to a unit that happens to have spotted new land or something like that. It's been awhile since I've seen it. But none of the Python code seems to reference this "unit". And I can't see anything that the unit is supposed to do, beyond exist. So I guess the easiest "fix" would be to change that line from 1 to 0 - as long as the quest still triggers properly, then everything is fine.

The problem there, of course, is checking to make sure it triggers properly. It's easy to manually run the python code, but that doesn't help here.

Bh
 
I was wondering why my automated Settler moves were being interrupted occasionally, and was surprised when I discovered my adventurous citizens possessed latent psychic abilities.

It's funny you posted that now, I just finished noticing it in the game I was playing. I couldn't understand why my settler kept interrupting his move orders. At least, until the Bear ate him. ;)

(I'll be looking into that)

Bh
 
I don't know either. As far as I can tell, it's the:
Code:
<iNumUnits>1</iNumUnits>
that's doing it. Because if I remember correctly, it gives the quest to a unit that happens to have spotted new land or something like that. It's been awhile since I've seen it. But none of the Python code seems to reference this "unit". And I can't see anything that the unit is supposed to do, beyond exist. So I guess the easiest "fix" would be to change that line from 1 to 0 - as long as the quest still triggers properly, then everything is fine.

The problem there, of course, is checking to make sure it triggers properly. It's easy to manually run the python code, but that doesn't help here.

Bh

What if you just set <iWeight> to -1? shouldn't the quest then trigger as soon as you had constructed the requisite units (and if you had the appropriate state religion)? It looked to me as though the only triggers were either a galley, caravel, or galleon, and either Buddhism, Confucianism, or Taoism.

Solver's tutorial mentioned this:

UnitsRequired- if non-empty, contains information about required units to trigger. So, if specified, events can only be triggered for the listed unit classes.

and:

iNumUnits- is a number. Specifies the amount of unts that must be on a plot for the trigger to activate &#8211; used for events which pick a plot. If used in conjunction with <UnitsRequired>, only units of the listed classes will be counted.

iNumUnitsGlobal- is a number. Specifies the amount of units that the player must have for the trigger to activate. If used in conjunction with <UnitsRequired>, only units of the listed classes will be counted.

Perhaps instead of iNumUnits, the value "1" should be given to iNumUnitsGlobal? The Blessed Sea quest doesn't really seem like it should require a specific naval unit assigned to a specific plot, just a requirement that you have built at least one of the early naval units. (UNless I'm totally misunderstanding what iNumUnitsGlobal is supposed to do....)
 
I agree with jkp1187's comments about global units. And according to Solvers tutorial that he/she referenced, the weights setting at -1 should work for testing purposes.
 
I agree with jkp1187's comments about global units. And according to Solvers tutorial that he/she referenced, the weights setting at -1 should work for testing purposes.
you should also set the probability to 100. When I tested the triggers I was not sure about from the code for my list I just made a mod with the event I was looking at
set to:
iPercentGamesActive = 100
and
iWeight = 100 (you can use -1 or any positive value - it does not really matter...)

and all other events set to iPercentGamesActive = 0 so that they don't interfere with testing...

you might also want to make sure that an event occurs every turn so that you really get the event triggered the turn after fulfilling all prereqs by setting
iEventChancePerTurn = 100 in each era for Civ4EraInfos.xml...
 
Top Bottom