Single Player bugs and crashes - After the 24th of February 2014

[Pindrul]

Originally Posted by Pindrul View Post
Hello there,

I have a problem with my current v34 game, i have two rebel civilizations that i have killed ( They don´thave any city or unit) but they are still on the game annoying me because of war weariness. Is there any way of get rid of them?. Thanks in advance.

Hello everybody,

The problem with rebel civilizations not disappearing is now resolved. You have to grant them capitulation and in the next turn this civs are gone.

 

[Dancing Hoskuld]

Exactly, and everything was working as expected. Now we are getting XML errors that are meaningless in the game. They can't even be fixed via XML since the dependency will remove the building but not the building class no mater what the dependency!

OK, the actual error check should be something like:-

If after checking for WoC dependencies on the building infos file there is no building left for the building class then the building class is not used and there is no error.

If there are no buildings defined for the building class before the WoC dependencies remove them then there is an error.​

And how could this detect things like typos in the name?

I have a plan how to fix the WoC type dependencies and to make the loading code a bit cleaner. But time is the issue and i can't say how long it takes before i can finish this.

I always come up with a cleaner and clearer explanation after I sleep on it.

This is true for both buildings and units.

To the class object add some variables and methods to support the following.

1) Load all the classes.

2) When loading the infos record on the class
2.1) which infos is there in the class
2.2) if the infos was turned off by WoC

3) After all the infos have been read go back through the class
3.1) If the default was not defined then error (this case can cause CTD for units but does not for buildings)
3.2) If the default was defined but removed by WoC and there are still others infos in the class then error.
3.3) If WoC removed all infos then remove class as well.

A Also noted there's an appallingly minimal amount of animals possible to be produced by that wonder

It was coded when we only had the minimum number of subdued animals. I keep thinking I should go back and gereralise it rather than have it as a hard coded list.

 

[JosEPh_II]

I always come up with a cleaner and clearer explanation after I sleep on it.

This is true for both buildings and units.

To the class object add some variables and methods to support the following.

1) Load all the classes.

2) When loading the infos record on the class
2.1) which infos is there in the class
2.2) if the infos was turned off by WoC

3) After all the infos have been read go back through the class
3.1) If the default was not defined then error (this case can cause CTD for units but does not for buildings)
3.2) If the default was defined but removed by WoC and there are still others infos in the class then error.
3.3) If WoC removed all infos then remove class as well.



It was coded when we only had the minimum number of subdued animals. I keep thinking I should go back and gereralise it rather than have it as a hard coded list.

DH please PM alberts2.

JosEPh

 

[Thunderbrd]

OK i deleted the line above(and replacementID tag) and put it into the CORE and it works fine.
But as soon as the above is placed back, CTD.(minus the ID) and not in modules area.

If you don't have the replacementID AND the replacement condition it won't work. And the game option needs to be turned on of course.

If it's crashing and you have both of those factors in place correctly on all of the replacement entries then it's a problem with the xml in those definitions somewhere else that's causing a crash. It's possible that an ongoing game may not be able to handle some of those changes without crashing and the crash may be like the one before, lurking in the AI which does get some preliminary run throughs when loading the game.

EDIT: Obviously the best way to find out is to run the game without the original handicaps file in place at all and using all the ones you made but without the replacement tag setup on those.

 

[Thunderbrd]

Ok folks, sorry 'bout the peak work issues we were having. My code logic was totally flawed that day. I've found the source of the errors and fixed them completely so that it now tests out to work correctly as intended. I can't commit right away but by the end of the night the fix will be in place.

 

[Thunderbrd]

Exactly, and everything was working as expected. Now we are getting XML errors that are meaningless in the game. They can't even be fixed via XML since the dependency will remove the building but not the building class no mater what the dependency!

OK, the actual error check should be something like:-

If after checking for WoC dependencies on the building infos file there is no building left for the building class then the building class is not used and there is no error.

If there are no buildings defined for the building class before the WoC dependencies remove them then there is an error.​

And how could this detect things like typos in the name?

I have a plan how to fix the WoC type dependencies and to make the loading code a bit cleaner. But time is the issue and i can't say how long it takes before i can finish this.

I always come up with a cleaner and clearer explanation after I sleep on it.

This is true for both buildings and units.

To the class object add some variables and methods to support the following.

1) Load all the classes.

2) When loading the infos record on the class
2.1) which infos is there in the class
2.2) if the infos was turned off by WoC

3) After all the infos have been read go back through the class
3.1) If the default was not defined then error (this case can cause CTD for units but does not for buildings)
3.2) If the default was defined but removed by WoC and there are still others infos in the class then error.
3.3) If WoC removed all infos then remove class as well.

Ok, so catching up on this I think that neither of you are wrong.


DH is trying to say that if a reference to a gameobject doesn't exist because it's been disabled by WoC then the gameobject making the incorrect reference should thus have a NONE reference fill the gap rather than be an error. Makes sense.

Alberts is saying if we do that then how will we know when an error exists. Makes sense.

However, if you turn the module on that has the dependency within it and the offending gameobject is then included THEN it will properly detect any error that may exist in that tag.

sigh... WoC itself is an overcomplicated mess imo. It also doesn't surprise me that others before Alberts may have erroneously disrupted some of its odd behaviors since trying to read it is... nearly unfathomable in its self complexity. It's barely fathomable in the way it needs to be worked and it's commendable that DH ever even came to understand it in the first place. Then, on top of that, compounding the issue is that while it was written to perform in an incredibly complicated manner it was not coded to do so with the greatest of organizational clarity in the first place as Alberts points out.

So let's try, both of you, to understand that your frustrations with this situation have nothing to do with the actions of the other. NOTHING. DH is trying to make something work that apparently at one time did and Alberts is trying to make something work that apparently at one time did (error messages properly displaying via loading the core dll) and the reason both of those efforts are running up against each other is not the fault of the actions OF each other. And in fact, ironically, both of you want to sort out how to smoothly make things work on both ends and I think agree on the general principle that it needs to be made more functional (and repaired correctly) all around.


If Alberts does continue with us on this it'll take time to get it sorted out properly. I know DH wants to be able to more clearly delineate his modules and this is for a bigger reason than just an immediate impatience to organize things - a major project of his requires this be possible - I get that.

I'd just urge us all to show some patience. If we need to wait on the other for a bit to get the code behaviors we want then that's what we have to do. At the same time, being clear on how the behaviors should work IS important to clarify and I'd ask us not to get frustrated with one another but make our cases, listen to the cases made by the other without resorting to 'fit throwing' and while patiently asserting our position on things remaining open to understanding the reasons for the other's position.

I think if we all do this the both of you may find you're actually arguing to achieve the same things and the frustration is that we're not there at the moment and for some reason we think we should be but hey... we aren't. But we'll get there if we're patient and diligent and SUPPORTIVE of each other!

Nobody here is trying to undercut or sabotage another and let's be honest... between the both of you if we lose either one we lose a MAJOR skillset this mod team desperately needs!


So... DH: put off what you're trying to do with your modularization - we've managed to go this far without it - or work it another way that does work. You've got plenty of projects to address without having to get stuck on one issue right? And understand that Alberts is working towards a better solution that will probably help to make what you're trying to do more possible (but won't be if we start throwing a fit about what he's already done so far.)

You say the error doesn't have any effect in-game but it very well could when objects are looped and references made in the code to an object that doesn't exist (CRASHes happen this way! You know this right?)

And
Alberts: Try not to take it personal because DH's frustrations, whether he knows it or not, aren't really at you. You know this but I also understand that it must be frustrating that your VERY HARD WORK is receiving this level of respect from others. Also, please try to understand what he's trying to accomplish with his modularism before accusing him of preferring there to be errors ignored than having them reported correctly. He's not asking the game to be carrying a potential crash - he's asking it to be more advanced than it currently is because of damaging tweaks made before you got here.


Honestly... I often wish that core loading processes had never been messed with from the beginning and often wonder how we've really benefited from them at all but then I remember our caching system upgrades and mod loading speed upgrades and memory thinning upgrades and yeah... it's all a worthwhile process as invisible as it may be to players.

 

[Dancing Hoskuld]

Modules used to be optional, with the change to that particular error message many stopped being optional. A lot of my existing work is wiped out. Not future stuff, current stuff. I normally play with it all on anyway but we have had requests to make it fully optional and I was just testing stuff we knew was optional.

 

[nanovirus]

Hi

New game, new problem.

In the save i've added the next turn is an endless turn.

i'm at SVN 7633

Could you have a look ?

 

[olduser]

Modules used to be optional, with the change to that particular error message many stopped being optional. A lot of my existing work is wiped out. Not future stuff, current stuff. I normally play with it all on anyway but we have had requests to make it fully optional and I was just testing stuff we knew was optional.

The error messages i put in are gone now from the Release and Final_Release dll's, i'am sorry for causing you all this trouble.

 

[Thunderbrd]

Modules used to be optional, with the change to that particular error message many stopped being optional. A lot of my existing work is wiped out. Not future stuff, current stuff. I normally play with it all on anyway but we have had requests to make it fully optional and I was just testing stuff we knew was optional.

The way they were setup was erroneous and only now is revealed to be (or was). Yes, without the error messages, the game can continue through and go for a while before it crashes if they aren't fixed to be optional correctly.

The error may not be yours in that you set it up the way it perhaps was supposed to allow but it's now something that you or I can't actually fix as it would've been a change in the way the loading process works by AIAndy or n47 who tinkered extensively with that for many other benefits we've derived.

So the only difference with the error messages being on is that you were being told you were setting the game up for a crash and not being allowed to run the game if you'd done so. Now, with them off, you may set it up to crash out as much as you wish, merrily believing the changes are safe.

If you sense me growing irritated it's because you or I cannot fix it and you're pissing off the one person who would've been willing to by blaming the error message as if it were the problem when the problem is that WoC doesn't load the way you expect it to.

 

[Dreifels]

I built no bunkers, when I upgraded units - so far possible - to trenchcoat-, next turn game build bunkers allover the world (within my area) see screenshots: as it was and a turn later

Edit:

also, there is very old grafic failure with Melons and Resin (if plantage), was in ROM already, never fixed:

Edit2:
trench infantry - grafic failure if idle. Screenshot shows all trench infantry, if idle and if active

 

[strategyonly]

Sparth

something you did is crashing all games???

There is no sparth folder?? and there shouldn't be unless your changing every single file path and deleting old buttons??

 

[Thunderbrd]

He probably needs to add the file to the SVN... easily overlooked when committing.

 

[Sparth]

Ok there was problem with SVN update.
Assets/art/Interface/Buttons/Units/sparth directory was not send

check now please

 

[Thunderbrd]

What you should get in the habit of when adding new files that aren't already on the SVN is to right click on the file and go to the Tortoise Hover panel and select the Add button (the plus sign). Doing this will make the next commit assume you did intend to add that file to the SVN and it lessens the likelihood of forgetting to add it. Just a helpful tip.

 

[Sparth]

I built no bunkers, when I upgraded units - so far possible - to trenchcoat-, next turn game build bunkers allover the world (within my area) see screenshots: as it was and a turn later

Edit:

also, there is very old grafic failure with Melons and Resin (if plantage), was in ROM already, never fixed:

Edit2:
trench infantry - grafic failure if idle. Screenshot shows all trench infantry, if idle and if active

Fixed Trench Infantry and Melons
should be ok now

And for the Risen files looks ok hmm strange

 

[Sparth]

What you should get in the habit of when adding new files that aren't already on the SVN is to right click on the file and go to the Tortoise Hover panel and select the Add button (the plus sign). Doing this will make the next commit assume you did intend to add that file to the SVN and it lessens the likelihood of forgetting to add it. Just a helpful tip.

Normaly I click Commit, click all files, add desrcitpion and then start uploading. I must be more careful in future.

 

[strategyonly]

Normaly I click Commit, click all files, add desrcitpion and then start uploading. I must be more careful in future.

Also make sure you do an upgrade before committing also, thx.

 

[Dancing Hoskuld]

latest SVN, I can't build a Stone Tools Workshop even though I have the tech.

 

[Thunderbrd]

latest SVN, I can't build a Stone Tools Workshop even though I have the tech.

Damn... that's right I had a theory regarding that I forgot to test before commit. I'll fix.