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

This wonder comes a bit late in prehistoric era (hunting), and it can not be constructed normally nor by great hunter/general:

View attachment 531905
Tradition - Hunter is outright superior to it, as this one provides free building, that replaces one from Tradition - Hunting.
Other than that no idea why @Dancing Hoskuld didn't assign this building to any unit.
 
SVN 10931

If disabled some religions in MLF_CIV4ModularLoadingControls in Custom religions folder, i get XML errors when loading mod (modules\Thunderbrd\Traits\C2C_TB_CIV4TraitInfos.xml)
 
SVN 10931

If disabled some religions in MLF_CIV4ModularLoadingControls in Custom religions folder, i get XML errors when loading mod (modules\Thunderbrd\Traits\C2C_TB_CIV4TraitInfos.xml)
This was issue since TB added complex traits - anq or billw tried to add depedency file to solve issue between traits and modular religions, but it didn't work.
That is you can't modularize traits - they can't be changed on the fly unlike units (certian stuff isn't modularizable here which breaks custom worldviews)/buildings

That is you can't turn off modular religions for now, as hard depedency can't be changed to soft depedency - traits NEED these religions, as traits speed up researching religions.
 
What happens if you revert those changes then?
Or if you change pBestConstructPlot to pBestMissionPlot on line 18145 in CvUnitAI? Maybe this one confuses exe since its set to no mission?

Its just a hunch :p
Try it out, report what you find out.

But I really think alberts should look into the why and how to fix as he understands the dll far better than any of us.
 
Try it out, report what you find out.
I can't try it out, since I don't have access to game yet (will have access somewhere in Monday).
I would do few commits in past week if I was back :p

I have to use sourceforge website to see what is going on inside.
 
This was issue since TB added complex traits - anq or billw tried to add depedency file to solve issue between traits and modular religions, but it didn't work.
That is you can't modularize traits - they can't be changed on the fly unlike units (certian stuff isn't modularizable here which breaks custom worldviews)/buildings

That is you can't turn off modular religions for now, as hard depedency can't be changed to soft depedency - traits NEED these religions, as traits speed up researching religions.
I haven't looked into this issue at all and I'm really not sure what the problem is - not denying there could be one but I'm not sure why the traits make the religions non-modular. The replacement system might make it difficult to work with other modularizations I suppose. I don't know. Just curious... where were specific religions mentioned in the Complex traits entries?
 
I haven't looked into this issue at all and I'm really not sure what the problem is - not denying there could be one but I'm not sure why the traits make the religions non-modular. The replacement system might make it difficult to work with other modularizations I suppose. I don't know. Just curious... where were specific religions mentioned in the Complex traits entries?
Depedency tags doesn't work for traits.

That is you can't separate trait related tags, that reference things in modules to separate file.
Now if you disable modules, where traits change things you will get XML errors.
So turning off module with religions will cause errors in traits, as religious techs are in those modules (most of them anyway).
@Anq tried to do that in SVN 10916, then reverted things except XML files, where he made inerdepedency file for traits and religions - both of them in modules.
He reverted that in SVN 10919, as that thing didn't work at all - you couldn't disable religious module without launch errors anyway.
 
Depedency tags doesn't work for traits.
Which is to say it doesn't work for replacements I suspect.

I'm curious about something though that may make this a lot more workable...

Actually, given the last comment on the Complex Traits thread, nvm. Unless Anq can figure out how to make dependencies work with replacements, which he well might be able to, we're screwed.
 
The projectile model just stops dead the moment they are created, so some of these fSpeed, fArcValue, fScale and/or fUpdateRate are not being handled correctly somehow.
Looks ugly to have a bunch of big rocks stacking up hovering over your trebuchets during a combat animation scene.
I believe this is caused by a recent dll change.

Edit: {
10703-10910 is OK
10911-10931 is bugged.
@alberts2 : your update broke projectile animations in combat.

That can't be caused by the change I made in the revision. Did you only look at dll changes while searching for the revision which caused that issue?
 
That can't be caused by the change I made in the revision. Did you only look at dll changes while searching for the revision which caused that issue?
I did a clean export every time I updated my SVN folder to a different revision; so there was no file mixing between revisions involved. I tested around a dozen revisions before finding the point where animations broke.

I went past a couple FPK repacking revisions which was annoying as it slowed down the search quite a bit waiting for a long "update 2 revision" process.
 
This wonder comes a bit late in prehistoric era (hunting), and it can not be constructed normally nor by great hunter/general:

View attachment 531905
It looks like we ended up with two when we only need one. (Reads pedia for both). This wonder is only there in case you don't get a Master Hunter building and can build the better one.

It should be available to be built by a Great Hunter.

Perhaps the pedia should be mentioning what buildings replace the one being looked at?
 
It looks like we ended up with two when we only need one. (Reads pedia for both). This wonder is only there in case you don't get a Master Hunter building and can build the better one.

It should be available to be built by a Great Hunter.

Perhaps the pedia should be mentioning what buildings replace the one being looked at?
Both of these give different free building.
One free building replaces other free building.
 
Both of these give different free building.
One free building replaces other free building.
Exactly one replaces the other. They are fine except the Great Hunter should be able to build both and the pedia does not show that a building can be replaced only what it replaces.
 
the Great Hunter should be able to build both
Cool... I was hoping he could be made to build this but then Rax's comment made me shut up cuz I realized something was afoot I didn't understand.
 
Cool... I was hoping he could be made to build this but then Rax's comment made me shut up cuz I realized something was afoot I didn't understand.
It is a rare case that you would need to build the lesser one as it is fairly easy to get the Master Hunter these days.
 
I did a clean export every time I updated my SVN folder to a different revision; so there was no file mixing between revisions involved. I tested around a dozen revisions before finding the point where animations broke.

I went past a couple FPK repacking revisions which was annoying as it slowed down the search quite a bit waiting for a long "update 2 revision" process.

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 did a clean export every time I updated my SVN folder to a different revision; so there was no file mixing between revisions involved. I tested around a dozen revisions before finding the point where animations broke.

I went past a couple FPK repacking revisions which was annoying as it slowed down the search quite a bit waiting for a long "update 2 revision" process.
If anything i think it might be caused by parts of the DLLEXPORT removal @Anq did. Now the exe has no way to even access things like
getProjectileSpeed from the EffectInfos so how should the exe even know about these values now????
Code:
DllExport const TCHAR* getPath() const { return m_szPath; }
    void setPath(const TCHAR* szVal) { m_szPath = szVal; }
    float getUpdateRate( ) const { return m_fUpdateRate; };
    void setUpdateRate( float fUpdateRate ) { m_fUpdateRate = fUpdateRate; }
    bool isProjectile() const { return m_bProjectile; };
    float getProjectileSpeed() const { return m_fProjectileSpeed; };
    float getProjectileArc() const { return m_fProjectileArc; };
    bool isSticky() const { return m_bSticky; };
 
Depedency tags doesn't work for traits.

That is you can't separate trait related tags, that reference things in modules to separate file.
Now if you disable modules, where traits change things you will get XML errors.
So turning off module with religions will cause errors in traits, as religious techs are in those modules (most of them anyway).
@Anq tried to do that in SVN 10916, then reverted things except XML files, where he made inerdepedency file for traits and religions - both of them in modules.
He reverted that in SVN 10919, as that thing didn't work at all - you couldn't disable religious module without launch errors anyway.
Which is to say it doesn't work for replacements I suspect.

I'm curious about something though that may make this a lot more workable...

Actually, given the last comment on the Complex Traits thread, nvm. Unless Anq can figure out how to make dependencies work with replacements, which he well might be able to, we're screwed.
I realize that I misunderstood some perspectives of this modular loading system and wrote the wrong code.
And I was trying too much at that time, to replace the copyNonDefaults methods.
Now I think it is working, with the new update (coming)
 
If anything i think it might be caused by parts of the DLLEXPORT removal @Anq did. Now the exe has no way to even access things like
getProjectileSpeed from the EffectInfos so how should the exe even know about these values now????
If his change was the one before yours, could he have forgotten to compile?
 
Back
Top Bottom