Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

raxo2222 · Jun 29, 2019

Toffer90 said:
Maybe the dll code that handles builds in the unit action list mess up due to the improvement being set up as a <bGraphicalOnly>1</bGraphicalOnly> (filters it out perhaps?).
Maybe having <RouteType>NONE</RouteType> in the build xml entry is the problem...

@raxo2222 Try removing <RouteType>NONE</RouteType> and <bGraphicalOnly>1</bGraphicalOnly> from the build and imp xml's in "Assets\Modules\NotSoGood\AnimalPlacing"

I'll test that - maybe some DLL changes broke it.

Removing those didn't fix it.

Toffer90 · Jun 29, 2019

This is the only python code that is related to great farmers in PPIO:

def onImprovementBuilt(self, argsList):

iImprovement, iX, iY = argsList

# Worker placed bonus
aList = GC.getImprovementInfo(iImprovement).getType().split("_")
if aList[1] == "BONUS":

CyPlot = GC.getMap().plot(iX, iY)
CyPlot.setImprovementType(-1)
CyPlot.setBonusType(GC.getInfoTypeForString("BONUS_" + aList[2]))
return

aList should always consist of at least two string elements like so("IMPROVEMENT", "X") when this code is processed.

When it comes to bonus-placing worker builds X=BONUS, and the improvement key should always be like so IMPROVEMENT_BONUS_Y.
aList = ("IMPROVEMENT", "BONUS", "Y") where Y may be DONKEY or HORSE, etc.

Edit: I'll look deeper into this, perhaps there's something I've missed.
EditEdit: I found some code related to great farmers that should have been in PPIO python.
The canBuild python callback is essential for deciding what bonus can be placed or not.
The thing was that the great farmer canBuild code was inactive code (never used) in the core, and since I assumed great farmers worked I just deleted that code in the PPIO file-set.
I'll fix it for PPIO first, then look into core C2C afterwards.

raxo2222 · Jun 29, 2019

Apparently Great Farmer needs resource X in empire to place X somewhere.
"You need to already have access to the resource to place it either in your own nation or via trade."

I'll enable cheat building that gives all resources - I made them for testing - one is for resources like Species Recovery Center, seven gives culture like Ellies Island, and other spawns subdued animal like Biodome (this one needs python code for that).
I was testing it on new map.

Thunderbrd · Jun 29, 2019

strategyonly said:
got an endless loop,

@alberts2, @Anq, @AIAndy

Help!

This appears to get stuck at
void CvCity::completeOrderProcessing(void)

looping through creating the same unit over and over. I don't know enough about the storage method being employed to setup this loop:
for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )
since m_inProcessOrders is not a basic integer loop, I'm not sure what ++itr is actually adding to. I know it's basically saying 'go to the next process item in the list now that we've completed the previous one' but I can't seem to figure out how this list is enumerated to begin with or how to find that information out. It almost seems like it keeps looping the same order over and over and maybe it's doing that but that's because the problem is further upstream and there was an inifinite number of See Invisible Dogs that were queued here - possibly to the point that the game hit the unit limit?

I'm not sure - this is really the deep end of the pool for me. I had hoped this would be an easier fix.

Toffer90 · Jun 29, 2019

Thunderbrd said:
This appears to get stuck at
void CvCity::completeOrderProcessing(void)

looping through creating the same unit over and over. I don't know enough about the storage method being employed to setup this loop:
for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )

Strange that that loop would get stuck, can a vector be infinitely long?
Does that loop have cases where it adds new elements to the vector inside that loop?
The only way that could be as far as I can see is if popOrder is called during the loop within completeOrderProcessing as it is only within popOrder that anything is added to the vector.

More info on the vector iteration applied there: Link Link
Alternate ways to iterate a vector: Link

Thunderbrd · Jun 29, 2019

Toffer90 said:
Strange that that loop would get stuck, can a vector be infinitely long?
Does that loop have cases where it adds new elements to the vector inside that loop?
The only way that could be as far as I can see is if popOrder is called during the loop within completeOrderProcessing as it is only within popOrder that anything is added to the vector.

More info on the vector iteration applied there: Link
Alternate ways to iterate a vector: Link

I'm sure it's not technically infinite, but I'm not seeing how to see a count of which iteration I'm at with each loop.
I don't SEE any way for another popOrder to be added during the loop but it's a fairly complex loop. There's a lot that happens in completeOrderProcessing(&order);

Before it seems to get stuck looping here somehow, it does seem to be creating an endless number of see invisible units, which itself is obviously wrong but I'm wondering what started making this happen to begin with all of a sudden.

I'm not sure if it's truly infinite or not, but

Code:

void CvCity::completeOrderProcessing(void)
{
    for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )
    {
        OrderData order = *itr;

        (*itr).eOrderType = NO_ORDER;
        completeOrderProcessing(&order);
    }

    m_inProcessOrders.clear();
}

placing a breakpoint at m_inProcessOrders.clear();, it never seems to hit that line. Been waiting a very long time in hopes it would.

I've figured out that unfortunately the information that I can get on itr that shows the iterator ID value is in hexadecimal rather than a simply displayed integer. I'm not all that familiar with how to count in that system. Seems to be a value designated as _Myptr and as I track it through 3 iterations, it goes:
0x63debb30
0x63debb40
0x63debb50

Unfortunately I have no idea what actual # those mean.

Hovering over m_inProcessOrders. I see that it shows that the size = 919. This doesn't change through the iterations it's going through, though I would swear I've waited long enough that it would've reached that size easily given how long it takes to go through one iteration. I'll let it run for a while longer...

Three or four minutes later we're at _Myptr of 0x63dec640 and the size of m_inProcessOrders is still 919. Still no further progress.

Toffer90 · Jun 29, 2019

Thunderbrd said:
I'm sure it's not technically infinite, but I'm not seeing how to see a count of which iteration I'm at with each loop.

You could add in some debug code along this line:

void CvCity::completeOrderProcessing(void)
{

for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )
{

std::cout << "Iteration: " << std::distance(m_inProcessOrders.begin(), itr)

OrderData order = *itr;

(*itr).eOrderType = NO_ORDER;
completeOrderProcessing(&order);

}

m_inProcessOrders.clear();

}

Thunderbrd · Jun 29, 2019

Toffer90 said:
You could add in some debug code along this line:

void CvCity::completeOrderProcessing(void)
{

std::vector<OrderData>::iterator first = m_inProcessOrders.begin()

for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )
{

std::cout << "Iteration: " << std::distance(first, itr)

OrderData order = *itr;

(*itr).eOrderType = NO_ORDER;
completeOrderProcessing(&order);
}

m_inProcessOrders.clear();
}

Does cout actually do anything in our code? I've never seen it used...

That said, this does appear to be at least somewhat a false alarm in that it really was iterating through 919 units that were ordered. Then it orders up another 300 something and seems to get stuck again. So far, we're not talking about anything truly infinite apparently. The issue at the root here appears to be a problem with how the game is ordering up 900, 300, and so on+ numbers of units, when only one unit per stack and one unit per city of the types it's calling for is what it really should be wanting. Something is definitely seriously wrong here. And something had to have changed recently about something along these lines to have opened this up. It probably revealed an issue that already existed I would imagine. Or something was working for one purpose and then was debugged to fix another so broke it for this purpose in the process. Might be having an intent tug of war somewhere in the brokerage system. I think I'm going to have to review recent changes there now.

Toffer90 · Jun 29, 2019

Thunderbrd said:
Does cout actually do anything in our code? I've never seen it used...

I have no idea, it's a standard library call though, I would imagine the output for it would show up in a visual studio profiler linked to the dll or something.

Thunderbrd · Jun 29, 2019

hmm... the save actually does eventually process through the round. I think we were witnessing a correction event that took place thanks to some recent changes by Alberts2. As I look around the map, it doesn't seem to be that there's a huge glut of units anywhere, so I'm going to run another turn and see how it goes but I suspect it won't get stuck again.

Edit:
Well it's a long turn again but not as bad. I think the AI has panicked in the discovery of its military insufficiencies and is trying to cycle through how many units it has ordered since waking up from some numbness where it shouldn't have had it all along. Each round will be a bit long at this point but will get better as the cities that are queued to the breaking point are able to start getting on top of those queues. This is a suspicion. Largely, I THINK that this is not likely to happen to a game that was not already in progress when the recent changes were made. Hoping that's the case at least.

Thunderbrd · Jun 29, 2019

I do have to say that I don't feel comfortable packaging a version release when my compiler is showing all these errors, most of which are probably due to the recent compiler upgrade:

Spoiler :

Anyone know what I need to do here to clear all this up?

EDIT: I actually think a few of these may be real problems...

Toffer90 · Jun 29, 2019

All those "cannot open source files errors" at the top are for files found only in

CivIV\Beyond the Sword\CvGameCoreDLL\Python24
CivIV\Beyond the Sword\CvGameCoreDLL\Boost-1.32.0

Do you have those folders (with content) in your BtS install?
Perhaps you have to define some include paths somewhere for the compiler?

Maybe we should include those source files from BtS to our C2C SVN?

Thunderbrd · Jun 29, 2019

Toffer90 said:
Do you have those folders (with content) in your BtS install?

Yes.

Toffer90 said:
Perhaps you have to define some include paths somewhere for the compiler?

That's possible - maybe another modder has them in another place somewhere and updated the paths file to point to where he's got them? I'll have to look at the SVN changelog on that.

EDIT: Although Alberts made some adjustments to the makefile, I don't see anything that would explain this error there.

I'm going to have to step away and wait for some further guidance on that I think.

MattCA · Jun 29, 2019

If you open up your .vcxproj file with a txt editor there are a couple paths to that stuff.
It's set wrong on my pc by default.
dunno if that'll fix.

Anq · Jun 30, 2019

Thunderbrd said:
for( std::vector<OrderData>::iterator itr = m_inProcessOrders.begin(); itr != m_inProcessOrders.end(); ++itr )
since m_inProcessOrders is not a basic integer loop, I'm not sure what ++itr is actually adding to.

You can picture the vector iterator as the pointer to its array. An array is a contiguous block of memory, and exact space of memory it takes is: Number of elements, times the Size of the individual element, such as char (1 byte), int (4 bytes), and so on. The pointer to an array references the first element, and as you increment the pointer, it then references the next element of that array, whose address offset will depend on the size of the individual element.
There is no builtin way (of C/++) to stop iterating at the end of array if we use pointer. Therefore the STL vector class provides the end pointer to help you iterate through its contents. The three for loop statements are:

Give me the begin-of-array pointer to work with this vector.
Until our pointer compares the same as the end-of-array pointer,
Increment it. (points to the next element on that array)

This is the standard way to iterate through vectors. Although the iterators are confusing at first sight, you'll praise this design as it adheres to the pointer arithmetic (this term describes the ability to increment, decrement, and compare two pointers as we work with arrays).

Secondly, when you dereference your pointer, written as *ptr, it lends out the value of the element at that address, whether as an L-value or R-value; that is, you can both assign the element some value if you use *ptr on the left side of an assignment operator (equal sign, =) and otherwise read the value if you use *ptr on the right side.

Thirdly, the dereferencing operator * takes lower precedence than member access operators, which are the dot (.) and the arrow (->). Thus you have to write (*ptr) when you intend to call some member function of that referenced element (can be a class object/instance, or even a pointer to them, if they are not stored in-line on the vector but in somewhere else), or else the member-access operators are first resolved, then the dereference asterisk at last, which only makes sense, of course, when the innermost member accessed is a pointer. Cf. https://en.cppreference.com/w/cpp/language/operator_precedence

PS. Writing (*ptr).something is the same as writing ptr->something. The arrow operator existed for this exact purpose. It is the member-access operator for a pointer variable. Thus the second line in the block:
(*itr).eOrderType = NO_ORDER;
can be easily rewritten as
itr->eOrderType = NO_ORDER;

sunrisereader · Jun 30, 2019

a fishing boat is unable to be placed at one of my cites

raxo2222 · Jun 30, 2019

sunrisereader said:
a fishing boat is unable to be placed at one of my cites

Disable "Hide Obsolete/Unavailable Worker Actions" BUG options - they are pretty buggy.
That is they can hide certain actions, that shouldn't be hidden.

Without those I can place fishing boat.

Anq · Jun 30, 2019

Toffer90 said:
In C2C(VS2017).vsxproj [...]

@Thunderbrd Problems I see in VS2017 vsxproj file:

Remove redundant target Final_Release2
WindowsTargetPlatformVersion not necessary
~~Remove device-specific paths, they are not useful because you already specify them in the makefile~~

As Alberts pointed out in a following post, the paths defined in the project file is needed for IntelliSense, so everyone should configure their project file correctly, even if that means local change that's different from what's on the server.

I made a point (edited out) where you may use new compiler (cl.exe and link.exe), but Alberts says even newer compiler versions are incompatible, even if you use the same old Visual C++ 2003 headers.

This means you're never using a new "compiler" by switching to a newer version Visual Studio.
What Visual Studio does is only provide the missing piece, nmake.exe, along with its dependencies, to let you build the project with a makefile.

I removed the attachment in this post.

MattCA · Jun 30, 2019

Anq said:
Remove device-specific paths, they are not useful because you already specify them in the makefile

better if that stuff uses the makefile. 1 more thing for your first update.

olduser · Jun 30, 2019

Anq said:
Remove device-specific paths, they are not useful because you already specify them in the makefile

Those are actualy needed for Visual Studio itself for things like Intellisense the makefile has nothing to do with that.

Anq said:
Edit: You'll be creating dlls that are essentially the same with the old compiler, if you use the cl.exe and link.exe from a new version of Visual C++ tool set, by editing the makefile. It is the included VC++2003 headers that matters.

Wrong you need the 2003 headers and the 2003 compiler, because the newer compilers aren't binary compatible.

Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

Time Traveller

C2C Modder

Time Traveller

C2C War Dog

C2C Modder

C2C War Dog

C2C Modder

C2C War Dog

C2C Modder

C2C War Dog

C2C War Dog

C2C Modder

C2C War Dog

Prince

Prince

Warlord

Attachments

Time Traveller

Prince

Prince

Emperor

Similar threads