Post Feb 1st 2013 - bugs - Single Player

Status
Not open for further replies.
Helps if you don't overwrite the fix with an update of your own that puts it back to the way it was before repaired, goose! :lol:

Anyhow, I just fixed the mlf and (again) the TRAIT_POLITICIAN reference that should've been TRAIT_LS612_POLITICIAN.

Python error message: BarbarianCiv and RevolutionInit

SVN: 4883, No Viewports

Spoiler :
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_VOLCANO_DORMANT
Can't find type enum for type tag FEATURE_VOLCANO_DORMANT
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_VOLCANO_DORMANT
Can't find type enum for type tag FEATURE_OBSIDIAN_PLAINS
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_COMET
Can't find type enum for type tag FEATURE_OBSIDIAN_PLAINS
Can't find type enum for type tag FEATURE_COMET
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_VOLCANO_DORMANT
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_SCRUB
Can't find type enum for type tag FEATURE_DEAD_FOREST
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_MUD
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_OBSIDIAN_PLAINS
Can't find type enum for type tag FEATURE_OBSIDIAN_PLAINS
Can't find type enum for type tag FEATURE_MUD
Can't find type enum for type tag FEATURE_MUD
Can't find type enum for type tag FEATURE_MUD
Can't find type enum for type tag BONUS_DYE
Can't find type enum for type tag FEATURE_EXOTIC_CORAL
Can't find type enum for type tag FEATURE_EXOTIC_MIN
Can't find type enum for type tag FEATURE_EXOTIC_SEALIFE
Traceback (most recent call last):
File "BugConfig", line 110, in unknown_endtag
File "BugConfig", line 334, in endChild
File "BugConfig", line 337, in end
File "BugConfig", line 318, in process
File "BugConfig", line 547, in handle
File "BugUtil", line 651, in callFunction
File "BugUtil", line 630, in lookupFunction
File "BugUtil", line 622, in lookupModule
File "<string>", line 52, in load_module
File "RevolutionInit", line 23, in ?
File "<string>", line 35, in load_module
File "<string>", line 13, in _get_code
File "
  • BarbarianCiv
", line 1501

iDist2 = gc.getMap().calculatePathDistance( capital.plot(), pBarbCity.plot() )

^

SyntaxError: invalid syntax

Goodness I'm bad at this.:rolleyes: I'll go fix these errors now on the SVN.

Edit: I'm not certain what actually is causing that error, that line was unchanged in my most recent commit. :confused: At any rate I'm not good with python so I suppose that's what I get for messing with something I'm not good at. If someone else can see the (probably obvious) error I made somewhere please tell me.
 
But not if the new unit category cant have them... When I ipgrade an archery or melee unit to a gunpowder unit, it lost some promotion


All of the worker's one.

If I can get C2C running again I will check it out in game. Neither should be happening.

But is it something wanted? Mainly for hunters and scout.

The recon class of units was available when Ngai was created, by AAranda, so I assume not.
 
Turns out this is not a bug (though on could argue the functionality is dubious).

The city in question has catacombs or something that give a chance for enemies to find their way in (invasionChance). Every turn such cities with adjacent enemies check to see if they are invaded this way. If they are then they go into an 'invaded' state for a number of turns proportional to the invasion chance (Knossos has 36 turns to go in that state!). When in hat state the WORST defender defends instead of the best one.

All of this is deliberate, but IMO it's overpowered. I think the following changes would be in order:

1) The length of the invasion should be MUCH less. Allowing for game speed this city has a chance of being invaded one in 3 turns, and as soon as it is that invasion will last about 50 turns, which basically means it will hardly ever be out of the invaded state as long as there are enemies next to it. I would go for a fixed 2 turns or so (not dependent on game speed, since the chance is evaluated every turn anyway)

2) Choosing the WORST defender seems to severe. I would change this to being a RANDOM defender

Opinions welcome...

My opinion is that the whole Catacombs thing is a bit weird and not well explained ingame. How about this; The catacombs give a flat 20% chance that an attacker will hit the worst defender in a stack, but that is for each attack. So on average 1 in 5 attackers will attack a crap unit in a city with Catacombs. Does that sound reasonable (or easy to do for that matter, I know that the choose defenders step of combat has a nasty habit of creating null pointers)?
 
My opinion is that the whole Catacombs thing is a bit weird and not well explained ingame. How about this; The catacombs give a flat 20% chance that an attacker will hit the worst defender in a stack, but that is for each attack. So on average 1 in 5 attackers will attack a crap unit in a city with Catacombs. Does that sound reasonable (or easy to do for that matter, I know that the choose defenders step of combat has a nasty habit of creating null pointers)?

Anything random is slightly awkward actually, because the method is used in contexts where it is both synchronizable and asynchronous for multiplayer, so it's not easy to decide whether to use the sync or the async rand generator. However, we could generate a deterministic number that is probabilistically going to have the same effect by doing something like hashing the unit id of the attacker, the plot and the game turn together and using that as the 'random' number. If we were to do that then we could easily implement a suggestion such as you propose.
 
Anything random is slightly awkward actually, because the method is used in contexts where it is both synchronizable and asynchronous for multiplayer, so it's not easy to decide whether to use the sync or the async rand generator. However, we could generate a deterministic number that is probabilistically going to have the same effect by doing something like hashing the unit id of the attacker, the plot and the game turn together and using that as the 'random' number. If we were to do that then we could easily implement a suggestion such as you propose.

Sure then. Do you want to do change that in your next commit?
 
Goodness I'm bad at this.:rolleyes: I'll go fix these errors now on the SVN.

Edit: I'm not certain what actually is causing that error, that line was unchanged in my most recent commit. :confused:

I already fixed it on the SVN so no worries. SVN can be a bit funny at times.
 
Latest SVN wild animals are not attacking! My wanderers are wandering around exploring passing by animals which would have a 99% chance of successful attack and they are being ignored.

Edit they are not attacking anything!
 
Latest SVN wild animals are not attacking! My wanderers are wandering around exploring passing by animals which would have a 99% chance of successful attack and they are being ignored.

Edit they are not attacking anything!

Probably my fault. I'll look ambit tomorrow - if yo happen have a save where there is an obvious attack that should be expected to happen post it for me please.
 
Personal mini-dump, not a usual one. CTD SVN 4899

I just need to find out which units(s) i screwed up on, PLEASE hELP:help:

This is one of the reasons why i dont like not being able to do FPK(s) all the time.


EDIT: I believe i have found the culprit.:crazyeye:
 
Don't take me at my word on this but I'm pretty sure a minidump would not be able to find the exact unit that you're having trouble with. Sadly, that'd be a bit tougher to determine as it'd have to be done more 'by hand' so to speak. The minidump would find what's happening in the code, sure but its more of a snapshot rather than a run through like you can get with a savegame that hits a repeatable crash point. And usually with graphic issue crashes, it doesn't take place during the code we can see but rather in the core exe and that makes it next to worthless with a graphics crash. I could be wrong on any of this though and will be looking to see if I'm corrected on this...
 
I just noticed in my latest game that I am not getting any Great people points. I am getting Great general points. As you can see in the images I have wonders that give GP but nothing is showing up on the main screen.

Edit a bit latter they started showing up
 
Barb Civ error messages again?? SVN 4899

Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "BarbarianCiv", line 192, in onEndPlayerTurn
File "BarbarianCiv", line 1335, in checkMinorCivs
File "BarbarianCiv", line 1515, in settleMinorCiv
NameError: global name 'BarbCityRand' is not defined
 
I just noticed in my latest game that I am not getting any Great people points. I am getting Great general points. As you can see in the images I have wonders that give GP but nothing is showing up on the main screen.

Edit a bit latter they started showing up

That's interesting. I was awarded a Great General in my own gam yesterday when it should have been a regular GP of some sort, so I sounds like something is screwed up. This is not an area I have fiddled with at all however - has anyone been changing GPs or GP points recently at all?
 
Barb Civ error messages again?? SVN 4899

Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "BarbarianCiv", line 192, in onEndPlayerTurn
File "BarbarianCiv", line 1335, in checkMinorCivs
File "BarbarianCiv", line 1515, in settleMinorCiv
NameError: global name 'BarbCityRand' is not defined
I think that should have been iBarbCityRand
That's interesting. I was awarded a Great General in my own gam yesterday when it should have been a regular GP of some sort, so I sounds like something is screwed up. This is not an area I have fiddled with at all however - has anyone been changing GPs or GP points recently at all?

I have seen it too. There are some wonders that provide points towards a Great General in the same way as other Great People. This probably should not be, but I am not sure what to change them to.
 
Koshling said:
That's interesting. I was awarded a Great General in my own game yesterday when it should have been a regular GP of some sort, so I sounds like something is screwed up. This is not an area I have fiddled with at all however - has anyone been changing GPs or GP points recently at all?
Been some discussion about making some changes there but nothing I've touched on myself in the coding.
 
I took another swing at this mod (version 2.8, downloaded without Dasura), but unfortunately, ran into crashes again. The minidumps are attached. In the first case, it happened about the time I researched Prehistoric Dancing. In the second case, it happened around the time of some barbarian (animal) battles about 7500 BC. The first one did not recur when I loaded it up again; the second one I haven't reloaded to try yet.

My specs include:

- 8 GB RAM
- Windows XP x64
- ATI 6870 with 1 GB video memory
- 3.9 GHz Intel Core i5 CPU

The map size was Gigantic with the default number of civs for that map size (either 19 or 25 I think, I'd only met one, however). A viewport of 40x40 was enabled for the first crash, and viewports were disabled for the second crash. I'd checked shortly before the second crash, and Task Manager reported memory usage of a bit under 2 GB, so I don't suspect this was MAF-related.

The error appears to be, "The thread tried to read from or write to a virtual address for which is does not have the appropriate access", according to Visual Studio. It resulted in an immediate crash to desktop. Fortunately, I'd figured out how to make Civ4 auto-save every turn, so the losses were pretty minor.

While playing I noticed at least two other apparent bugs:

- The Hunting 1 promotion gives +50% against animals twice, and +35% against sea animals twice. I think the bonus is only applied once in practice, but it's confusing as to why it would list it twice.
- I let the AI automate itself in a Blazing game while I was grabbing some food, and the timescale for blazing is not working right. The turns slow way down starting at 35,000-something B.C., and by my estimate it probably never gets past 35,000 - definitely not past 34,000. I'm sure there aren't a ton of people playing on Blazing, but I'm glad it wasn't my real game where that happened.

There also were some graphical issues:

- Whenever the map was zooming around to show battles when I was attacked (fairly often, being out hunting), the graphics were really jerky.
- Battles that happened outside of the viewport I was on at the end of a turn were not shown at all.

Could turning down graphical settings in the regular options help, or is that unlikely? In the regular game (with no mods) it tends to be smooth, even late game.

Is Gigantic simply too big of a map? I like the idea of the Gigantic map since it allows maps of a similar size to really big ones in Civ3 (and it was a lot of fun to explore that big of a map, too). But like when I tried with version 2.5 last fall, I'm running into issues. What's the largest size map you'd recommend for ensuring a smooth, crash-free experience?

Other than the graphical issues and the occasional crash, it's been a fun prehistoric era, just like before. So many more options than the base game! So I'd certainly like to get it to the place that I can play a game on a pretty big map, but actually make it to the Classical Era!

(also, I might forget to check back, if so, you can PM me with follow-up questions... I still have at least the most recent save for the second crash dump, though it probably won't be reproducable)
 
- Battles that happened outside of the viewport I was on at the end of a turn were not shown at all.
I think they are never shown, and that is the way it should be. Please don't change that. Current case: I've just sent caravels on automatic ocean scouting, they are getting all kinds of animal attacks, and switching viewports on end turn would add 4-5 minutes to a turn time.
 
I think they are never shown, and that is the way it should be. Please don't change that. Current case: I've just sent caravels on automatic ocean scouting, they are getting all kinds of animal attacks, and switching viewports on end turn would add 4-5 minutes to a turn time.

That is correct. Things that happen outside of the viewport still generate the text messages that scroll past and can be retrieved from the log, but do not cause a video-switch since that can be very time consuming on large maps.
 
Only one problem with that: If one worker gets pillaged by a rogue outside of viewport, and you have lots of workers, you get no clue on the next turn where did that happen and where do you need to send dogs & replacement workers. Nice to have: nearest city in the text message: instead of "worker 61 was killed by..." to put "worker 61 near Montreal was killed by..."
 
Status
Not open for further replies.
Back
Top Bottom