[Religion and Revolution]: Bugs and Todos

Isabelxxx wrote:That's something present in vanilla too, it's strange you are the only one who has noticed this too.

Maybe my 2+ years of experience with Neanderthal and Animal spawn in C2C had something to do with it. ;)

I have yet to take a look into Colonizations Assets folder, and unfortunately I have no Python or SDK knowledge. I can do some simple xml but that's it for modding.

I'm a player/ tester/ suggestor. :)

JosEPh
 
That's something present in vanilla too, it's strange you are the only one who has noticed this too.
I didn't notice that at all. Natives don't seem to develop quickly in Vanilla C4Cin my opinion :dunno:

I thought about this some time ago and I reach to the conclusion that the main problem is how native units are generated.
Oh... :confused:

First we have units and then professions.
I don't understand this part... :(

The native unit has no cost in food or any other yield, so all cities are constantly creating new native units.
:eek:
A native unit costs 50 hammers.:confused: So it does cost something ! You mean it doesn't cost anything but 50 hammers...
When there is no building left to build, Native's will indeed produce Braves. In Vanilla C4C they only have one or two buildings (one if I'm correct). So they will indeed quickly produce only braves. But since they can't choose the Carpenter's profession (;) ), they will only get a brave every 50 turns by this method [That means only 6 units (per city) in 300 turns with this method!]. Of course their population can grow "normally" (e.g. as Europeans).
However, I've tried playing with natives a few times, and when you start a new game in Vanilla C4C, most of your cities are starving, and you can't do much about it since you can't build improvements nor buildings!

But, we have changed a few things... In TAC some natives have food bonuses, and we've added some buildings giving natives extra hammers. This means that natives can develop more quickly. But that's what I was trying to do! :)
I added a yield requirement to the native unit. Food, 50. That way I wanted to relate in some way the amount of units a city can support with the food availability of that city.
We could give braves a higher price, and another requirement... But I would really avoid food. Natives already have a food based mechanism :dunno:

First impression: it works as intended! Natives start with a standard number of units, but now the have to spend more time and resources to create new units. Also due to this system, they now use more population to obtain food; but note that at any moment they can convert population in brave units so there is no bad side of this. Only the grow rate has changed.
I'm not sure I follow you... :confused:
But yes. The more expensive braves will be the slower they will develop. But I would rather add more buildings to give them more choices than do this...
 
We should definitely take a look at these points again:

1. Generation of Terrain Features (Forrests, Taiga, Jungle)
2. Placement of Native Villages (distances / amount)
3. Generation of Native Units (according to our new balancing)

But we should still not forget, that we have topics with higher priority:

1. Bugfixing (DLL, Python)
2. Performance DLL
3. Performance Graphics -> Cleaning up (Graphics, XML)
4. Bringing Python Checks of Event System into DLL
 
@Robert Surcouf:
Well, maybe I speaked too quickly. That's my experience with vanilla and DoaNE. But since RaR has buildings for natives you could be right. I have not tested this in RaR, just adding my opinion seeing Joseph saw that in RaR.

Yes, native units cost hammers but that's all. Why they can convert magically in one turn 10 population units into braves? There is something strange in the way armed units are considered for natives I think.

Also I usually play at the biggest difficulty level so just don't put much attention to my words :p
 
@Isabelxxx:
You definitely gave a good hint. :thumbsup:
(And we will think about this aspect again.)

@Robert:
We will not do any changes here without good consideration.
Let us continue to work on our current todos.
After we have reached a good level of stability and performance, we will come back to balancing.
All team members should then play a long game and then tell their experiences first.
 
@Robert Surcouf:
Why they can convert magically in one turn 10 population units into braves? There is something strange in the way armed units are considered for natives I think.
:eek: Oh yes you're right!
Oh! Sorry ! :blush:
I didn't get that part. I fully agree ! The "profession" part is indeed worse than the "unit" part.
We might have to check that part indeed! And in R&R natives have a higher population so things would be worse than in Vanilla C4C. Thank you indeed Isabelxxx.
Again, I'm sorry, I didn't understand that part! :blush:

Edit: Just saw this part:
@Robert:
We will not do any changes here without good consideration.
Let us continue to work on our current todos.
After we have reached a good level of stability and performance, we will come back to balancing.
All team members should then play a long game and then tell their experiences first.
Sure !
 
Ok, I have gone over and reviewed the python code for all my event triggers - I still can't find a clear indication of how arguments are supposed to be passed to python for all the possible combinations of trigger values, so I changed them all to use the same standard syntax for getplayer calls with <pythoncandoCity> and <pickcity> set in the triggers, to try to clean up and avoid any possible errors or asserts. I'm not sure if this helps but let me know if it did.

In TAC some natives have food bonuses, and we've added some buildings giving natives extra hammers. This means that natives can develop more quickly. But that's what I was trying to do! :)
I like that feature, perhaps Hammers production or Food or Hammers cost can be adjusted if needed for balancing. Wasn't there also a feature at one point for Natives to take Scalps after successful raids or attacks? I liked that idea a lot too; perhaps producing Braves with Hammers could require some Scalps as a balancing mechanism; or Scalps could be used to produce a special unit like a Native Warband.
 
I'm not sure if this helps but let me know if it did.

I will take a look at the weekend. :thumbsup:

... perhaps producing Braves with Hammers could require some Scalps as a balancing mechanism; or Scalps could be used to produce a special unit like a Native Warband.

Guys, please let us not make features complicated without need.
The player would never see this anyways.

So please no new Yield "Scalps".

We have methods to balance this and we will do so, when we find the time. :thumbsup:
 
Has the Team experienced any hangs or freezes in the game on high resolution settings?

Are there actual recommendations for resolutions?

I had another freeze/hang last night on a new game using the Caribbean map. Had settled the West end of a fair sized island with 4 Native cities. I had sent the Cruissaire out to contact the chiefs of each city. On the 2nd city as I was about to enter the city, the popup for Declare war or not of course came up. I hit the no let's reconsider and as the Cruissaire started to enter the city tile the game hung.

Just prior to this move into this city an Event to share food with the natives had popped up too.

There seems to be some lag in the response to popups and I'm wondering if a command is not getting finished before new input is being injected causing the game to kind of lose track of what it's doing. Or there is a loop that is being performed that has a problem like divide by zero. Or it's a Graphical error because I'm using 1680x1050 resolution and Highest 32bit color quality?

If I can capture a save for one of these hangs I will most definitely post it. Because for me it's one of the biggest problems I'm finding with the mod.

JosEPh
 
Hi JosEPH,

recommendations about resolutions:

Do not overexaggerate.
And do not play with extrem wide screen resolutions.

about bugs:

Please understand that we currently do not know what is causing the "random" problems.
Thus we cannot give you better answers.

All I can tell you:
We are constantly checking and improving. :thumbsup:
We simply need time.

I'm wondering if a command is not getting finished before new input is being injected causing the game to kind of lose track of what it's doing. Or there is a loop that is being performed that has a problem like divide by zero. Or it's a Graphical error because I'm using 1680x1050 resolution and Highest 32bit color quality?

Speculations of what could have happened really do not help us. ;)
The only things that would really help are savegames or a clear description that makes a bug reproducible.

Of course it would also help, if we could find more experienced / skilled modders ...

If I can capture a save for one of these hangs I will most definitely post it. Because for me it's one of the biggest problems I'm finding with the mod.

Well yes sure.
But what other should we do than searching, fixing and improving. :dunno:

We have real lifes, are doing this in our spare time and our active team really is small currently.
(I personally cannot spend more than a few hours per week working on this mod at the moment.)

You need to be patient. :thumbsup:
 
So ray, are you saying you do Not want me to post Until I have a savegame showing the problem?

I can do that.

What do you mean by?
Do not overexaggerate.
And do not play with extrem wide screen resolutions.

Then What is the recommended resolution? That is what I Was asking.

And why do you keep posting, "We have Real lifes" I Know This.

Okay I won't post until I have a Savegame. Fair enough.

JosEPh
 
So ray, are you saying you do Not want me to post Until I have a savegame showing the problem?

It simply does not help us if you report "I had another bug I cannot reproduce.". :dunno:
What should I do with this information, other than spend time on replying with "Well ok. But we still don't know what causes it." ?

We know that there are "random bugs" and we are trying to find them. :thumbsup:

What do you mean by?

Simply try to go lower than that and also try to stick to a resolution which is much closer to 4:3.
I cannot tell you an exact resolution now, because I am not at home to tell you the resolution I use.

And why do you keep posting, "We have Real lifes" I Know This.

Because you keep saying "The bugs I encounter are the biggest problem I have with this mod.".
It just sounds a little impatient. :)

It is quite obvious to us that we need to fix and improve things. :thumbsup:

All I want to tell you is:
"Please be patient. We need time."

Okay I won't post until I have a Savegame. Fair enough.

You can post
  • balancing issues
  • problems you see with a feature
  • bugs you can reproduce

But please don't post "I have found another bug which I cannot reproduce." :thumbsup:
 
I went through to test the Events I made about a month ago using Shift-E, they seemed to me to be working except for the KingPleased and KingFurious triggers which I since deactivated; however they could be retested after finding if reworking triggers eliminated any getplayer asserts. The overall Event chance per turn is fairly low in the vanilla game (IIRC increasing iWeight will only affect proportional chances for a given Event rather than absolute chance of an Event happening), if you'd like them more frequent in general you might adjust the base chance for events using GlobalDefines as you'd suggested earlier or perhaps even make the base chance adjustable as a Gameoption. Events with a very specific trigger situation will almost never be seen by players (even with iWeight -1 if the situation is very rare). If added XML event tags are developed in the future I should focus on not using custom Python triggers except where extremely necessary which should be a big help for errors/asserts and general performance.

In finding bugs, perhaps its helpful to turn on logging in _Civ4Config and then look at the logs after a crash to see if those show what may have caused it (ie contents of the _Civ4logs link in the game folder). But Ray would know better whether that would be helpful, perhaps its just best to just continue to use Autorun using debug DLL which can continue to find bugs more directly. Keep in mind its being developed by volunteer team of amateur modders in their spare time, most of whom such as me are not experienced programmers at all :blush:; the process of bug fixing and improving stability will necesarily be gradual, but it seems to me that stability is improving and should continue to improve; and turntimes seem to also have improved with the recent revisions made by Isabelxxx and Ray.
 
I went through to test the Events I made about a month ago using Shift-E, they seemed to me to be working ...

Great. :thumbsup:

... except for the KingPleased and KingFurious triggers which I since deactivated;

Maybe you could try to get them working again ? :dunno:

The overall Event chance per turn is fairly low in the vanilla game ...

We already have doubled it. (CIV4EraInfos.xml)
Let us leave it like this for now. :thumbsup:

I simply wanted to make sure, that all our events are working and do not contain useless / wrong code that causes Asserts.

If added XML event tags are developed in the future I should focus on not using custom Python triggers except where extremely necessary which should be a big help for errors/asserts and general performance.

Yes, if we are sure that all our events work, we could start the "Enhancement" of the XML. :thumbsup:

In finding bugs, perhaps its helpful to turn on logging in _Civ4Config and then look at the logs after a crash to see if those show what may have caused it (ie contents of the _Civ4logs link in the game folder).

The logs have helped me almost nothing so far. :dunno:
(Except finding some errors in XML references, which should not be the problem at the moment.)

... perhaps its just best to just continue to use Autorun using debug DLL which can continue to find bugs more directly.

I will do that, this weekend. :thumbsup:

... the process of bug fixing and improving stability will be gradual, but it seems to me that stability is improving and should continue to improve.

Exactly. :thumbsup:
 
This is the resolution I am currently playing / testing with:
(Basically I have chosen a low resolution, since our graphics are not cleaned up and packed in an FPK.)

1024x768
Graphics Level: High
 
Then What is the recommended resolution? That is what I Was asking.
My screen resolution is 1024 * 768 too!
I think you should try one or two resolutions lower than the resolution you usually try when you play Vanilla Civilization...

I simply wanted to make sure, that all our events are working and do not contain useless / wrong code that causes Asserts.
I'll check this tomorrow hopefully!
I've found a python exception. I'll try to fix it:
Spoiler :
Code:
[B]Traceback (most recent call last):

  File "CvRandomEventInterface", line 1746, in canDoNotInRevolution

IndexError: tuple index out of range
ERR: Python function canDoNotInRevolution failed, module CvRandomEventInterface[/B]
 
I've found a python exception. I'll try to fix it:

Ok, thanks.

Please let me know when the Python is cleaned up. :thumbsup:
(I will wait with debugging until then and try to do further code improvements.)
 
It looks like one of the old TAC events called TheRoyals has made a call to candonotinrevolution using PythonCanDo with a different set of xml values - I don't know why that would be, did someone else add this at some point? :confused: I uploaded a new revision to SVN, try it with that.
 
I
t looks like one of the old TAC events called TheRoyals has made a call to candonotinrevolution using PythonCanDo with a different set of xml values - I don't know why that would be, did someone else add this at some point? :confused: I uploaded a new revision to SVN, try it with that.

When we did introduce the methods, we (or better I) did set the method in the TAC events to check for the conditions.
(The according checks were missing in the TAC events.)

I simply wanted to make sure, that those event would not be called when not fitting.
 
Hi guys,

This Assert is still triggered.
And the function is only called from Python.

Code:
CyPlayer* CyGlobalContext::getCyPlayer(int idx)
{
	static CyPlayer cyPlayers[MAX_PLAYERS];
	static bool bInit=false;
	if (!bInit)
	{
		int i;
		for(i=0;i<MAX_PLAYERS;i++)
			cyPlayers[i]=CyPlayer(&GET_PLAYER((PlayerTypes)i));
		bInit=true;
	}
	[COLOR="Red"]FAssert(idx>=0);[/COLOR]
	FAssert(idx<MAX_PLAYERS);
	return idx < MAX_PLAYERS && idx != NO_PLAYER ? &cyPlayers[idx] : NULL;
}

Code:
.def("[COLOR="Red"]getPlayer[/COLOR]", &CyGlobalContext::getCyPlayer, python::return_value_policy<python::reference_existing_object>(), "(iPlayer) - iPlayer instance")


So somewhere there is still at least one getPlayer(-1).

There are a lot of getPlayer() calls in Python ... :(
However, it is surely not one of the Screens, because they are not triggered by AI in Autoplay.

So I believe (and might be wrong) that it is still very likely in one of the functions for the event system.

-------

I also found 3 other Asserts (probably caused inside the DLL) so far and will analyze them.
 
Top Bottom