Thunderbrd
C2C War Dog
I hadn't removed them because I'd thought they might be good starts towards similar project plans. Were there any significant bugs within either one and why were the projects scrapped?
-
Our friends from AlphaCentauri2.info are in need of technical assistance. If you have experience with the LAMP stack and some hours to spare, please help them out and post here.
Shared AND/C2C Debug codes
- Thread starter Thunderbrd
- Start date
Dancing Hoskuld
Deity
Dark ages were not fun. Platyping has a Python version. I was thinking the reverse may be a good start on making golden ages useful in C2C.
Thunderbrd
C2C War Dog
What brought them on?
Afforess
The White Wizard
I agree with DH. What myself 3 years ago did not understand was that arbitrarily setting back the player does not make the game fun. Dark ages simply happened if you were not discovering techs fast enough or had too few Golden ages. They did not add any new complexity to the game and just slowed the game pace down.
Thunderbrd
C2C War Dog
I'd had it in mind to have 'Dark Great People' that could, as part of the many things they could do, inflict a Dark Age upon a competing civ. Given the sort of trigger you had them set for I agree they would've lacked enjoyability. But if it was an effect you could inflict upon an opponent... that's something else entirely!
What about the vote mechanism... I've only glanced through it but what exactly were you going for there?
Afforess
The White Wizard
I don't remember exactly - bear in mind much of the code I wrote was 3+ years ago, and:
1.) I barely understood the fundamentals of C++
2.) I did not have much experience designing or maintaining large projects
I might as well be a totally different person, at least in terms of programming ability. Before I would have been daunted by a std::vector and had no clue what a hash map was. Today I could implement them from scratch...
Anyway, the election option, as I recall, was a C++ recoded and more advanced feature to replace the mini-election feature in RevDCM (where when you run civics that enabled elections, you may be forced to be "relected" if you are unpopular). The idea was to give the player more control, have political parties, be able to "alter" the election, etc.
I never finished the feature due to the obvious complexity that it quickly spirals into. In addition, looking back, I realize it's not a good idea for a feature anyway, because losing an election is unfun. Having the AI run your civilization for even 25-50 turns would ruin whatever planning and preparation you might have done, and only a small minority of players would want to deal with that - repeatedly.
</rant>
As an aside, I was bored and looking into compressing the C2C save format, but just applying naive LZMA2 or similar compression only saved about 10% of the size (5mb -> 4.5mb). Not much of a gain. Is there documentation on the save format? I examined a save file and noticied a good part of it is in plain text. Perhaps some brave soul could even write up a save editor application given an understanding of the format. As a side project.
Thunderbrd
C2C War Dog
I'm ok with removing the election portion... I suppose we can remove and potentially at some point rebuild the dark age feature if needed so we don't inadvertently retain some of the elements of it we wouldn't want.
More just misplaced effort, and risk of introducing bugs for little actual gain.
Just the comments in the save wrapper and some old posts about it somewhere on these boards. However, that's just the format of the save STREAM as read/written by the DLL. The EXE adds its own stuff, and also performs some compression, and all of that is utterly undocumented to the best of my knowledge.
Thunderbrd
C2C War Dog
Ok... makes sense. Thanks for the tip!
Thunderbrd
C2C War Dog
In
int CvPlot::movementCost(const CvUnit* pUnit, const CvPlot* pFromPlot) const
there was a problem that prevented double movement (and more) to work properly when applied to a terrain with a base movement cost of 1. This is resolved by this change:
The commenting out is the first part of the fix. Then:
(I removed an #endif I think only we would have.)
I'm sure you can easily see the problem now that it's pointed out. The MOVE_DENOMINATOR adds granularity that allows routes and such to later function but it's assumed here that no terrain with a base of 1 will ever have a unit apply a doublemove ability to it. Presumably this was to simply streamline a bit or was a leftover from adapting to base civ code...
int CvPlot::movementCost(const CvUnit* pUnit, const CvPlot* pFromPlot) const
there was a problem that prevented double movement (and more) to work properly when applied to a terrain with a base movement cost of 1. This is resolved by this change:
Code:
if (iRegularCost > 0)
{
iRegularCost = std::max(1, (iRegularCost - pUnit->getExtraMoveDiscount()));
//}
//if ( iRegularCost > 1 )
//{
if ( iRegularCost > pUnit->baseMoves() )
{
iRegularCost = pUnit->baseMoves();
}
iRegularCost *= GC.getMOVE_DENOMINATOR();
Code:
if (((getFeatureType() == NO_FEATURE) ? pUnit->isTerrainDoubleMove(getTerrainType()) : pUnit->isFeatureDoubleMove(getFeatureType())) ||
(isHills() && pUnit->isHillsDoubleMove()))
{
iRegularCost /= 2;
}
}
//else
//{
// iRegularCost = GC.getMOVE_DENOMINATOR();
//}
}I'm sure you can easily see the problem now that it's pointed out. The MOVE_DENOMINATOR adds granularity that allows routes and such to later function but it's assumed here that no terrain with a base of 1 will ever have a unit apply a doublemove ability to it. Presumably this was to simply streamline a bit or was a leftover from adapting to base civ code...
CMemoryTrack::NoteAlloc had some issues this is the fixed version.
Code:
void CMemoryTrack::NoteAlloc(void* ptr, int size)
{
if ( m_valid )
{
for(int i = 0; i < m_highWater; i++)
{
if ( m_track[i] == NULL )
{
if ( i == m_highWater )
{
if ( m_highWater < MAX_TRACKED_ALLOCS )
{
m_highWater++;
}
else
{
m_valid = false;
return;
}
}
m_track[i] = ptr;
m_allocSeq[i] = m_seq++;
m_allocSize[i] = size;
#ifdef USE_INTERNAL_PROFILER
m_trackName[i] = _currentSample == NULL || _currentSample->sample == NULL ? "<None>" : _currentSample->sample->Name;
#else
m_trackName[i] = "";
#endif
}
}
}
}Afforess
The White Wizard
I recommend you guys take a look at a few of the AI fixes I know alberts2 was interested.
I had a question about the dummy graphics system C2C added. RAND has it disabled by default - is it enabled by default for C2C? What are the advantages/disadvantages of using it?
I've been tracking down a strange CTD related the unit graphic setup, and comparing the C2C code to the BTS code, the disabled dummy graphics doesn't quite line up with the default BTS code. I am specifically looking at reloadEntity in CvUnit.
I had a question about the dummy graphics system C2C added. RAND has it disabled by default - is it enabled by default for C2C? What are the advantages/disadvantages of using it?
I've been tracking down a strange CTD related the unit graphic setup, and comparing the C2C code to the BTS code, the disabled dummy graphics doesn't quite line up with the default BTS code. I am specifically looking at reloadEntity in CvUnit.
I have merged your AI fixes here locally.
One thing i noticed the AI still overbuilds until they have to reduce sience to under 10% then they react until they are out of trouble and the cycle starts again.
I think that dummy graphics system is disabled here too and i have no idea why or if it has any advantages/disadvantages that was built before my time here.
One thing i noticed the AI still overbuilds until they have to reduce sience to under 10% then they react until they are out of trouble and the cycle starts again.
I think that dummy graphics system is disabled here too and i have no idea why or if it has any advantages/disadvantages that was built before my time here.
Afforess
The White Wizard
Wait, can you explain more about the AI? Your AI reduces science all the way down to 10% on the slider!? That is rather extreme. I never saw the AI go below 30%, and that was rare.
If the dummy graphics system is disabled there too, and a source of crashes, perhaps it should be disabled/removed (or at least, turned off by ifdefs?). I know the old BTS code never crashed, in my experience.
Thunderbrd
C2C War Dog
So what's it for in the first place? I've seen some references to dummy graphics... I wasn't sure but had thought they were the added graphics attached to units such as when a Lord or Viceroy joins a unit and shows up during battle as a sort of cheerleader from the sidelines. Are we talking about something else entirely? And if so, what's it supposed to DO (if it's disabled it would be good to determine it's purpose...)
I watched it during 900 turns at snail speed in AI Autoplay sometimes it goes down to 0%. I have to start another one to see exactly what they are doing.
Afforess
The White Wizard
I was under the impression dummy graphics were to reduce memory usage. Right now, each unit gets its own copy of a "graphics" object, which is what you see in-game. Dummy graphics attempts to reduce the number of graphics objects created, by re-using "dummy" graphics, one for each unit type currently around. This reduces the amount of graphic objects created, and thus the amount of video ram used.
At least, that is how I understood it. I have no idea if it was ever finished and if it works.
Afforess
The White Wizard
IMO the two best tools are the BBAI logging (turn on in BUG settings, logging area) and just checking out the menus (like treasury). If the AI is at 0% science, check what it is spending gold on. Units? Shift-Alt-Control combos and hover over cities/terrain. It will list desired defenders & floating defender units the AI wants. I don't about C2C, but perhaps something is making the AI feel it needs much more defense than it really does.
