Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

[Dancing Hoskuld]

Make sure obsolete worker actions are not turned off.

 

[Dancing Hoskuld]

Nope, the issue remains for Tactical Fusi at least. Now it says:

PY:Nuke detonated at 8, 7
20:05:51 TRACE: Error in nukeExplosion event handler <bound method NukeAfterEffects.onNukeExplosion of <NukeAfterEffects.NukeAfterEffects instance at 0x1E406B98>>
20:05:51 TRACE: global name 'iLattitude' is not defined


The result is that the Fusi behaves as a regular Nuke (w/o turning tile into water).

Fix is on the SVN. That bit of code only had two variables so hopefully it is now fixed. It is used to decide which type of coast/ocean the plot should be turned into.

 

[george585]

For some reason the strategy for the BeastMaster has been set to the Great General. This is completely wrong. I will set it back or remove as the beastmaster is not a unit anyone can get. It is just a graphics thing with the tamed animals.



edit is is the same bit of code as the Plot problem. It was added in to handle the fact that we have three types of coast and ocean, viz polar, temperate and tropical.

That is a totally different error. I will investigate. As I said before the whole of the PythonErr.Log file as an attachment to the post will help.

Here's the debug file (attached) and the whole of error file:


Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "NukeAfterEffects", line 105, in onNukeExplosion
File "Caveman2CosmosUtil", line 21, in getCoastalType
NameError: global name 'iLattitude' is not defined
Traceback (most recent call last):
File "BugEventManager", line 363, in _handleDefaultEvent
File "NukeAfterEffects", line 105, in onNukeExplosion
File "Caveman2CosmosUtil", line 21, in getCoastalType
NameError: global name 'iLattitude' is not defined

 

[george585]

Fix is on the SVN. That bit of code only had two variables so hopefully it is now fixed. It is used to decide which type of coast/ocean the plot should be turned into.

Oh, I was late in updating my post. Thank you for the fix!

 

[Dreifels]

Make sure obsolete worker actions are not turned off.

you mean it's a double bug?
1) turnend off does not work for AI
2) tunnel isn't obsolete in fact

 

[george585]

Fix is on the SVN. That bit of code only had two variables so hopefully it is now fixed. It is used to decide which type of coast/ocean the plot should be turned into.

Actually there was another bug in Caveman2CosmosUtil.py that I fixed myself locally, but since I am not on SVN someone should add it:

return c.getInfoTypeForString("TERRAIN_TROPICAL_OCEAN") -> return gc.getInfoTypeForString("TERRAIN_TROPICAL_OCEAN") (in 2 places in the file). Now it works correctly.

 

[olduser]

Always Hostile should be set to 1 not 0. That they cannot move into a space with a hidden enemy unit is probably a result of an oversight in some of the changes made to make tunnels work more properly that had the intention of allowing some overlaps that weren't previously allowed. The fact they can't see them should've made it possible for them to overlap but some logic is flawed in there apparently. My apologies.

Those changes also make it impossible to move a unit to a plot with a invisible enemy unit.

But the biggest issue is their performance impact because they cause the huge slowdown in Talin2009 game. That game is huge but before i made any changes it was at least 1 hour additional turn time from those changes that is just to much for a feature like tunnels. I already made some changes in the svn to speed things up again but the impact is still huge. I made some more changes here but i'am still not anywhere near to fix that slowdown and the two movement issues. So if anyone has those issues it might take a while before those three issues are fixed.

 

[Thunderbrd]

Those changes also make it impossible to move a unit to a plot with a invisible enemy unit.

I noticed those bug reports and realized something wasn't quite right. Somehow this condition needs to be resolved so that this isn't an issue... yes.

But the biggest issue is their performance impact because they cause the huge slowdown in Talin2009 game. That game is huge but before i made any changes it was at least 1 hour additional turn time from those changes that is just to much for a feature like tunnels. I already made some changes in the svn to speed things up again but the impact is still huge. I made some more changes here but i'am still not anywhere near to fix that slowdown and the two movement issues. So if anyone has those issues it might take a while before those three issues are fixed.

Honestly this is one of the reasons I'm taking a timeout. I'm really starting to feel quite ignorant here. I can often get things to WORK, but the cost of doing so is often inadvertently so much worse than I imagined. I hope someone smarter than myself can sort this out satisfactorily.

When it comes down to it, I struggled with movement rules because it was originally written in such a restrictively dedicated manner that shortcuts past the way I would THINK we would want to have the code consider it so that other rule options could be introduced - my point being that I was trying to modify an existing structure that was not only complex but clearly not intended to be adjusted to this sort of depth of interaction. I got the sense that it would almost be better to rewrite movement rules from scratch but that the complexity of it left far too much room for much worse error to attempt it.

That said, I'm pretty sure I found some other erroneous spots and corrected them but apparently introduced some new ones. It's a mess indeed. I presume the main problem here with the delay is that there's simply too much evaluating of what can or cannot be seen and interacted with going on because it's taking place more at a unit by unit level rather than a player level. Very frustrating. Initial tests actually showed a speedup after these changes, probably due to some of the things corrected, but I wondered if more complex games, if clocked, would show slowdowns, perhaps dramatic ones, instead. Apparently what I was afraid of was correct. My apologies.

Keep in mind as you look into this though that I was hoping to set us up for more interesting things than simply tunnels - I wanted to make it possible to have a number of individual reasons that units that would be able to see each other and be hostile towards each other could still overlap without combat.

 

[Dancing Hoskuld]

Actually there was another bug in Caveman2CosmosUtil.py that I fixed myself locally, but since I am not on SVN someone should add it:

return c.getInfoTypeForString("TERRAIN_TROPICAL_OCEAN") -> return gc.getInfoTypeForString("TERRAIN_TROPICAL_OCEAN") (in 2 places in the file). Now it works correctly.

Thanks for that I will put it on the SVN. It took me over a minute to see the difference in the statements you posted. Dyslexia is a pain when you program

 

[george585]

Thanks for that I will put it on the SVN. It took me over a minute to see the difference in the statements you posted. Dyslexia is a pain when you program

My bad, should have made it clearer!

 

[olduser]

Honestly this is one of the reasons I'm taking a timeout. I'm really starting to feel quite ignorant here. I can often get things to WORK, but the cost of doing so is often inadvertently so much worse than I imagined. I hope someone smarter than myself can sort this out satisfactorily.

When it comes down to it, I struggled with movement rules because it was originally written in such a restrictively dedicated manner that shortcuts past the way I would THINK we would want to have the code consider it so that other rule options could be introduced - my point being that I was trying to modify an existing structure that was not only complex but clearly not intended to be adjusted to this sort of depth of interaction. I got the sense that it would almost be better to rewrite movement rules from scratch but that the complexity of it left far too much room for much worse error to attempt it.

The main problem is that C2C is just too big.

The size and the times of rapid expansion in the past caused lots of hidden issues so it often happens that you end up trying to fix all kinds of stuff before you can start to do what you really had planed to do. Simple changes become a nightmare because you have to consider too manny other things with all the various settings, playstyles and so on..............
If you really want to test even smaller changes with all the different settings it would take weeks of fulltime testing. Nobody with a fulltime job plus overtime plus family and such things has the time to do that and if you try it it just sucks you dry.

 

[Rwn]

The main problem is that C2C is just too big.

The size and the times of rapid expansion in the past caused lots of hidden issues so it often happens that you end up trying to fix all kinds of stuff before you can start to do what you really had planed to do. Simple changes become a nightmare because you have to consider too manny other things with all the various settings, playstyles and so on..............
If you really want to test even smaller changes with all the different settings it would take weeks of fulltime testing. Nobody with a fulltime job plus overtime plus family and such things has the time to do that and if you try it it just sucks you dry.

Maybe it would be worth reducing a bit the number of game options (merging some, making some always active, etc.)? I think there are also a number of options that are currently considered broken or at the very least not maintained (advanced start, traits, etc.) that could be deactivated by default and set to invisible - up to anyone to work on them one day, but in the meantime they don't confuse modders and new players.

 

[strategyonly]

fixed

 

[Thunderbrd]

The main problem is that C2C is just too big.

The size and the times of rapid expansion in the past caused lots of hidden issues so it often happens that you end up trying to fix all kinds of stuff before you can start to do what you really had planed to do. Simple changes become a nightmare because you have to consider too manny other things with all the various settings, playstyles and so on..............
If you really want to test even smaller changes with all the different settings it would take weeks of fulltime testing. Nobody with a fulltime job plus overtime plus family and such things has the time to do that and if you try it it just sucks you dry.

Very true.

 

[strategyonly]

One of these events are PINK, they disappear before I can click on them or read what happened??

 

[Sparth]

EDIT: I know almost ALL of the Great General's btns being born are turning up PINK, at least for the natives??

For this need save or at least screenshot.

 

[Sparth]

One of these events are PINK, they disappear before I can click on them or read what happened??

Any more info? Save or screenshot?

 

[Sparth]

techs that have the WRONG words in them . . .

EDIT another few:

Fixed all four.

 

[Furoncrypto]

I am missing my interface. This started back a few days ago. I thought updating to the SVN would fix it but no.

Here is what I saw recently when I started a new game on the updated SVN. It doesn't always show up. I already tried ctrl + I and alt + I.
When I load old games sometimes they have the issue, other times they don't.

Thank you for your time.

Update: Started new game and now it works. I don't know if the issue will persist though.

 

[Dreifels]

there are two kinds of whaling ships available, not only different language (German/English) but also with different bonus
edit: txt string failure