Post Feb 1st 2013 - bugs - Single Player

Status
Not open for further replies.
Also, I'm getting this warning when compiling from the latest sources.

Code:
1>CyTeam.cpp(207) : warning C4244: 'return' : conversion from 'unsigned __int64' to 'int', possible loss of data

I suspect that Thunderbrd's Culture stuff may be causing that.
 
I don't know if it's a bug or intended, but great commanders get always a constant +1 Exp?
Secondly, they don't get any EXP if their siege weapons bombard.
 
Secondly, they don't get any EXP if their siege weapons bombard.

Probably because siege weapons don't get exp from bombard either. There is a mod out there that adds exp for siege units doing their thing, perhaps we need to look at incorporating it.
 
Uh, i have a rather strange bug, which occurred to me when i tried C2C a long time ago, and occurs once again - a few turns in, my civilization is changed! Instead of controlling my original civilization (which continues to exist under AI control), i am suddenly switched and assume control of another civilization, continuing the game. I have admittedly not tried and seen if it changes once again, but from my limited testing i *think* i don't.
 
EDIT: Infact when a NEW forest is built by the core, it now uses the "green" forest one:mad: 3rd pic

Those plastic trees are really hideous - I urge/beg you to get totally rid of them.
 
Also, I'm getting this warning when compiling from the latest sources.

Code:
1>CyTeam.cpp(207) : warning C4244: 'return' : conversion from 'unsigned __int64' to 'int', possible loss of data

I suspect that Thunderbrd's Culture stuff may be causing that.

Yeah, a loose end from last night's fix. I got that warning in one of my compiles but I wasn't sure how to best approach it since its a bit of a funny situation where I'm not sure if I update it correctly if it will cause any potential problems for any python referring to CyTeam.countCultureTotal due to the change in data type from int to unsigned long long. Koshling? AIAndy? Anyone who knows? Would that cause trouble for any python? Can Python even USE such data type? Is it likely python is even using CyTeam.countCultureTotal anywhere at all?

I have a CvTeam:: processedNationalCulture() function that is intended to replace any absolutely necessary calls for an integer (in knowledge that this integer could frequently be returning a completely inaccurate response as this number, when accurate, classically goes beyond our maximum somewhere in the Industrial age.) processedNationalCulture will return max_int instead if it goes past the int limit. So I could use that as the return for the python .countCultureTotal if python can't utilize the unsigned long long type.

BTW: to answer a question you may have already based on this 'fix' and the issue it brought up - I used unsigned long long due to the understanding that long actually doesn't give much more if any range. So according to all references I could find, this is the absolutely largest number we can allow is with unsigned long long (and may only ever be positive). I'm really hoping even that will be enough for a full length Galactic era game end point.

And yes, I'm aware that we can gain a few digits by hedging against the times100 taking place in the calculation of countTotalCulture in CvPlayer and that'll be the next way to hopefully address a problem if another one presents itself. And its something I do plan to go back and smooth out later either way. But from the cultural output per round I saw on the game I was evaluating, I did not think a gain of even 2 digits would've put the problem off for long enough to make it the quick fix for now to opt for.

Anyhow, sorry for the warning popping up there ls... its probably not too critical (not nearly as much so as the fix itself was necessary) and it will soon be addressed. I should've mentioned it but I was rushing off to bed (stayed up way too late trying to get the fix sorted out as it was!)
 
Those plastic trees are really hideous - I urge/beg you to get totally rid of them.

:lol:

You get used to them. Or is this a "fashion" show now? Just sayin'. :mischief: ;)

JosEPh :D
 
Yeah, a loose end from last night's fix. I got that warning in one of my compiles but I wasn't sure how to best approach it since its a bit of a funny situation where I'm not sure if I update it correctly if it will cause any potential problems for any python referring to CyTeam.countCultureTotal due to the change in data type from int to unsigned long long. Koshling? AIAndy? Anyone who knows? Would that cause trouble for any python? Can Python even USE such data type? Is it likely python is even using CyTeam.countCultureTotal anywhere at all?

I have a CvTeam:: processedNationalCulture() function that is intended to replace any absolutely necessary calls for an integer (in knowledge that this integer could frequently be returning a completely inaccurate response as this number, when accurate, classically goes beyond our maximum somewhere in the Industrial age.) processedNationalCulture will return max_int instead if it goes past the int limit. So I could use that as the return for the python .countCultureTotal if python can't utilize the unsigned long long type.

BTW: to answer a question you may have already based on this 'fix' and the issue it brought up - I used unsigned long long due to the understanding that long actually doesn't give much more if any range. So according to all references I could find, this is the absolutely largest number we can allow is with unsigned long long (and may only ever be positive). I'm really hoping even that will be enough for a full length Galactic era game end point.

And yes, I'm aware that we can gain a few digits by hedging against the times100 taking place in the calculation of countTotalCulture in CvPlayer and that'll be the next way to hopefully address a problem if another one presents itself. And its something I do plan to go back and smooth out later either way. But from the cultural output per round I saw on the game I was evaluating, I did not think a gain of even 2 digits would've put the problem off for long enough to make it the quick fix for now to opt for.

Anyhow, sorry for the warning popping up there ls... its probably not too critical (not nearly as much so as the fix itself was necessary) and it will soon be addressed. I should've mentioned it but I was rushing off to bed (stayed up way too late trying to get the fix sorted out as it was!)

I don't know if (this version of) Python supports 64 bit integers, so you're probably right that Python cannot cope. Using the same approach you suggested elsewhere (return MAX_INT for anything above that) in the Python interfaces would be best, so the code that is giving the warning would probably be best replaced with a text for MAX_INT and appropriate return (and if it's less than MAX_INT explicitly cast it before returning it so as to suppress the warning)
 
No you never do.



Nothing to do with fashion. You have perfectly natural looking trees in the mod already, what on earth is the need for plastic ones????!!!:crazyeye:

About Aesthetics and beauty of game, i suggest a small canoe. The canoe are so huge and so large that enters the graphics of land when in coast.

i suggest a reduction of 40% in size of canoe.
 
I don't know if (this version of) Python supports 64 bit integers, so you're probably right that Python cannot cope. Using the same approach you suggested elsewhere (return MAX_INT for anything above that) in the Python interfaces would be best, so the code that is giving the warning would probably be best replaced with a text for MAX_INT and appropriate return (and if it's less than MAX_INT explicitly cast it before returning it so as to suppress the warning)

Thanks for the advice. That was exactly what I was thinking and is also what I've done in the code on this end that will be updated to the SVN once I've found a few real problem bugs I'm hunting for here.

So in the meantime, its probably perfectly ok to ignore any warnings on that matter when compiling. (I'll only be a day or two before I can get the update in.)
 
So in the meantime, its probably perfectly ok to ignore any warnings on that matter when compiling. (I'll only be a day or two before I can get the update in.)

No offense to the coders here, but isn't a problem really another problem, that will eventually turn into "alot" of problems, if unsolved soon? I'm just sayin':rolleyes:
 
Probably because siege weapons don't get exp from bombard either. There is a mod out there that adds exp for siege units doing their thing, perhaps we need to look at incorporating it.
In my c2c they get experience by bombarding.
 
No you never do.



Nothing to do with fashion. You have perfectly natural looking trees in the mod already, what on earth is the need for plastic ones????!!!:crazyeye:

There are no plastic ones (trees) in the game! It is just the way they are being displayed to support multiple features per plot. I think that if the code did some sort of forced redraw of the plot it would come out fine since the "plastic" trees don't stay around long when I play.
 
No offense to the coders here, but isn't a problem really another problem, that will eventually turn into "alot" of problems, if unsolved soon? I'm just sayin':rolleyes:

In this case no, it will only do anything if national culture is more than 3 billion or so.
 
Out of the sudden, the game stopped cycling to other units when the currently selected unit finalizes its moves. I have to press enter every time, and when on the last unit end the turn with the button in the corner of minimap. Quite annoying, really.
 
Out of the sudden, the game stopped cycling to other units when the currently selected unit finalizes its moves. I have to press enter every time, and when on the last unit end the turn with the button in the corner of minimap. Quite annoying, really.

That sometimes happens, just select a different unit (in a city maybe) and do something (like move it), and that will normally clear up the issue.
 
In this case no, it will only do anything if national culture is more than 3 billion or so.

Not even necessarily then... Its really only an issue IF and only IF any python is referring to the team's total culture count. Even then, it would only pull up, at worst, a zero. But I should be able to update tonight given that I've discovered that the 'bug' I was hunting for was actually an intentional design change ... :crazyeye:
 
Workers again not working correctly. (Automated)

I have had 5 now workers(all one by one) just walk out into OPEN tiles and then the animals just devour them.

SVN 4734, No viewports,

Logs if needed here: Includes the Random Logger ones.

http://www.gamefront.com/files/22922909/Logs.zip

EDIT: Workers are still lagging waay behind on building improvements?? See attached of the cities they have?(All screenies) Some have some but some not so much??
 
Status
Not open for further replies.
Top Bottom