Single Player bugs and crashes v39 plus (SVN) - After the 20th of July 2019

[Anq]

Ah I did omit compiling the dll in 10907!
OK I will take a close look at 10907 now

CvScalableInfo
{
    virtual bool read(CvXMLLoadUtility* pXML);

   // serialization
   virtual void read(FDataStreamBase* pStream) {}
   virtual void write(FDataStreamBase* pStream) {}
}

I added three virtual keywords here, it could be this!

Edit:: Confirmed, it's this that made the EffectInfo nontransparent to the exe

 

[Dancing Hoskuld]

The plot 2 north of Memphis keeps flipping from owned to unowned and back every turn. Memphis has grown twice. Still doing it many turns later so I am building a palisade on it to stop it. Save attached.

 

[ssmage]

That's not a bug per say, just that's how BTS works. It's trying to auto control a square that your culture controls all tiles around it but has no tile culture on the tile itself, but the realistic culture option says no, you don't have culture on that tile, and removes it on the next turn.

 

[raxo2222]

Ah I did omit compiling the dll in 10907!
OK I will take a close look at 10907 now

CvScalableInfo
{
    virtual bool read(CvXMLLoadUtility* pXML);

   // serialization
   virtual void read(FDataStreamBase* pStream) {}
   virtual void write(FDataStreamBase* pStream) {}
}

I added three virtual keywords here, it could be this!

Edit:: Confirmed, it's this that made the EffectInfo nontransparent to the exe

So there was no need to add back these DLLExports

 

[olduser]

So there was no need to add back these DLLExports

But it was something that made it impossible for the exe to access these values.

 

[Anq]

So there was no need to add back these DLLExports

Thank you all guys @Toffer90 @alberts2 and you helping me find the problem I made. Your information was all very important. Thanks for Toffer's patience at the first place, to try a wide range of revisions to single out the problematic build. Thank you all for your troubleshooting efforts for me! Hope this revision 10940 cures it all!

 

[raxo2222]

But it was something that made it impossible for the exe to access these values.

Well then why it worked fine up until SVN 10910 (would be 10907 if anq compiled and committed dll here)?
Changing these three lines was problematic thing here.

It appears that one DLL export never was changed.

 

[Dancing Hoskuld]

That's not a bug per say, just that's how BTS works. It's trying to auto control a square that your culture controls all tiles around it but has no tile culture on the tile itself, but the realistic culture option says no, you don't have culture on that tile, and removes it on the next turn.

Nope. It used to be that once it flipped it stayed flipped especially ones which are completely surrounded. It is still flipping hundreds of turns later.

 

[JosEPh_II]

Nope. It used to be that once it flipped it stayed flipped especially ones which are completely surrounded. It is still flipping hundreds of turns later.

I've had similar tiles do this too in the past month. It eventually would stop once I had enough Culture built up from surrounding cities. And it almost always involved a hill tile. Realistic Culture spread problem perhaps?

 

[strategyonly]

latest dll wont even process to start a game???

 

[raxo2222]

latest dll wont even process to start a game???

So @Anq didn't test his stuff again.....

Use SVN 10939

 

[strategyonly]

So @Anq didn't test his stuff again.....

Use SVN 10939

tried it again and it works, must have been a weird error some place...

 

[raxo2222]

tried it again and it works, must have been a weird error some place...

Oh so it was false alert then.

I guess this is one of these rare random crashes, where game crashes because it can.
Maybe this minidump will be useful though.

 

[billw2015]

I will say again if you are doing anything more than a few lines change in the DLL you should consider moving to the unstable branch. Other devs would easily catch these various problems before they have to effect everyone.

 

[Toffer90]

Still it can't be caused by the changes i made in that revision. That issue even happens then the code that i changed has not been executed once.
Must be something else.

I was mostly pointing out what specific revision the bug appeared in, not trying to cast blame, and since it was your revisions and you being one of our dll gods I felt like calling upon your grace.

Maybe the dll in rev 10910 does not correspond to the source files in rev 10910, and that you implemented a bug someone else brought into our source files at an earlier point.
May also be a compiler issue, something we need a dll modder to look into. I'm sorry if you felt attacked, it was not my intention, which was only to identify when the issue appeared.

I'm gonna drink some morning coffee and read the two new pages of post that has appeared in this thread now, maybe you've already found the issue and fixed it even. ^^

 

[raxo2222]

I was mostly pointing out what specific revision the bug appeared in, not trying to cast blame, and since it was your revisions and you being one of our dll gods I felt like calling upon your grace.

Maybe the the dll in rev 10910 does not correspond to the source files in rev 10910, and that you implemented a bug someone else brought into our source files at an earlier point.
May also be a compiler issue, something we need a dll modder to look into. I'm sorry if you felt attacked, it was not my intention, which was only to identify when the issue appeared.

I'm gonna drink some morning coffee and read the two new pages of post that has appeared in this thread now, maybe you've already found the issue and fixed it even. ^^

Anq forgot to compile code changes in SVN 10907, now that issue was fixed - he changed few lines which caused that graphical bug after DLL was compiled.

 

[Toffer90]

The fpk's caused the black tiles problem recently so if there's any graphics issues they should be one of the first things to check.

That was the first thing I checked before finding the SVN revision where it broke, I unpacked all loose files and deleted the FPK's, the bug persisted... I even went into the SVN log to find the original loose art files for projectile models and animations that I knew worked for projectile animations; I know a bit about the projectile art stuff as I made a 3D arrow (most archer units use 2D billboard arrows) and texture specific for the llama archer and giraffe archer, which are two units I remade (the originals before my remake were awful in both those cases.).

 

[Toffer90]

So the palace is not appearing in any cities wonder tab build lists.

I looked into it on the python side by making python print out every single building in the dll cache for buildable buildings; like so:

print GC.getBuildingInfo(CyCity.getBuildingListType(iGroup, i)).getType()​

The result was that the palace is never included in the dll's cache of build-able buildings.
So python has to assume that it is currently under construction in one of your cities and is thus not a valid thing to build anywhere at that time.
@alberts2: you recently fixed an issue with group wonders in this very same dll cache, perhaps you could look into why the palace is not included anymore. It is a special case as it is a national wonder that you can always build 1 extra of.

 

[Thunderbrd]

@Anq Lord knows I'm the biggest offender of committing untested changes. Some things can't easily BE tested. But try to keep your commits small and easily trackable and make sure to test as much as you can before committing. It's normal for a commit to potentially be buggy. We all know that. Everyone plays in part to help with the testing so that we don't have to feel like it should take a month of testing before every commit. But when you have repeated issues like this, it's a good sign you might want to slow down and test a bit more if you can. I don't see a point in going to some separate branch - nobody will find the issue if you do that. But keep a good eye on feedback so that you can jump on a problem that you might've introduced as quickly as possible at least. And yes, not compiling and running your code and leaving it for someone else to catch the potential blame from is... well that's just not right. If you change the code, compile and run the dll for a bit before you commit. Even simple and innocent changes can have dramatic effects. Particularly in areas where you may be unsure why something is setup the way it is and you're changing it on a theory that it might not need to be that way just to find out.

Anyhow, I'm only saying all this because I've had a LOT of learning bumps myself and I expect I will in the future. It's more understandable when we at least TRY to avoid causing a problem.

 

[TaylorItaly]

Repeatable Crash at EoT ,latest SVN , just press End-Turn-Button.

Edit : Solved , thanks.