Single Player bugs and crashes v35 plus (SVN) - After the 18th of August 2014

I've attached my save in #1960. The game doesn't crash, but it stops responding just after clicking End Turn. The little running avatar never appears and the game refuses to continue.
 
Ok, I see the problem but its really odd and is very good at dodging evaluation as infinite loops can sometimes be. I have a suspicion but it takes a little time to test it. I can't really explain the depth of strange this is showing but the dll on the SVN doesn't work while the dll I have here does but they're the same dll as far as Tortoise shows. So... a little confused. Again... trying a few things till I get it straight for ya. Oddly, I think it might be a compile or commit issue rather than a code issue.


EDIT: OK, resolved. It may be that you can't build a dll under a file structure with a different name than Caveman2Cosmos and have it work properly. Or I did something strange somewhere. I dunno. All I did was rebuild the dll and it works fine. The weird thing is that the dll I had in both mod files showed they were in sync with the dll on the SVN. Anyhow... baffled as I am, this reset works fine on my end. Please confirm on yours.
 
Stormwind said:
Sadly, no luck with 8606 either. Loading an autosave it stuck at 'Finishing' with close to zero CPU usage. A normal save never finishes the turn and I let it run for about 30 mins, which is 6 times the normal turn time.
Both saves are attached.

View attachment 396293
View attachment 396294
Click to expand...

Sometimes turns can be 3-4 hours, for turn or 2 (on i7-4771 at @4500GHz), after that turn times return to normal.

Just saying.
 
Talin2009 said:
Sometimes turns can be 3-4 hours, for turn or 2 (on i7-4771 at @4500GHz), after that turn times return to normal.
Click to expand...

If a game required that, I'd have abandoned it approximately three hours before then.
 
Arakhor said:
If a game required that, I'd have abandoned it approximately three hours before then.
Click to expand...

Talin's game is rather unique. He's played the same one for a long long time. 30+ AI in the early TH Era iirc, with Really Massive armies too. He posted a save game a few weeks ago. If you look it up D/L it and load it. Good luck though on getting even that save to advance. My i7 2600K worked on it for 17 minutes before it locked up/CTD.

JosEPh
 
JosEPh_II said:
Talin's game is rather unique. He's played the same one for a long long time. 30+ AI in the early TH Era iirc, with Really Massive armies too. He posted a save game a few weeks ago. If you look it up D/L it and load it. Good luck though on getting even that save to advance. My i7 2600K worked on it for 17 minutes before it locked up/CTD.

JosEPh
Click to expand...

He is absolutely right to play such a huge game. Simply because it is possible to do it just like that without any modifications. But if that is not possible because it's too slow even on modern high-end hardware C2C is to blame not the player.
 
Stormwind said:
Sadly, no luck with 8606 either. Loading an autosave it stuck at 'Finishing' with close to zero CPU usage. A normal save never finishes the turn and I let it run for about 30 mins, which is 6 times the normal turn time.
Both saves are attached.

View attachment 396293
View attachment 396294
Click to expand...

I have reverted to 8603 and I was able to continue. Even though I have 68 cities my turn time is still 4 to 5 minutes though, never waited hours... running it @ 4,7 Ghz
I always keep my viewport settings under 2000 tiles (like 50x40), can this be related to having more available memory to process stuff between turns?
 
Stormwind said:
Sadly, no luck with 8606 either. Loading an autosave it stuck at 'Finishing' with close to zero CPU usage. A normal save never finishes the turn and I let it run for about 30 mins, which is 6 times the normal turn time.
Both saves are attached.

View attachment 396293
View attachment 396294
Click to expand...

Ok, this issue has been strange up to now. At this point its VERY strange.

I ran both of your saves just fine. No issues. WTH???

I'm beginning to wonder if its an SVN problem. I'm going to try to delete (or rather rename) the dll in my assets and update to get the one the SVN is handing out. I wonder if this would then show a problem.

Alberts... any theories on what the problem could be here? We're not talking about a slowdown unless its seriously a system issue but the changes haven't caused any further delays on my end and they're fairly basic at that.

EDIT: Nope... no problem on a dll pulled off the SVN either. Testing Dexter's.
 
@dexter:
Your save is not from a file named Caveman2Cosmos. Please, in the future, never rename the file to anything but Caveman2Cosmos. Makes debugging much smoother. Additionally, it is known that some bugs can result simply from the name being different than some files expect.

EDIT: I have a sneaking suspicion that if you have updated to 05, you may need to revert to 04 then update straight to 06 to clear up the issue. I think it MIGHT be that Tortoise sees no difference really in the 05 and 06 dlls and that's a problem if you already have 05's.

EDIT: No problem with dexter's save either. Big game. Slightly slow turn times though better than I've ever seen before for that size game.


Note: I did have a problem specifically with the Camel Rider unit last night that I cannot explain. I can't more fully evaluate it because it took place in an MP environment with simul turns. But when I built the Camel Rider, not only did we go immediately OOS, there was no UI bottom panel for the Camel Rider unit when it was selected. It just adopted all the same command and mission options the last unit selected did. The unit art didn't show in the bottom left window and while I could, oddly, give it the commands from the list of options it gave me from the last selected unit, it was impossible to promote the unit though it was glowing blue.

Has anyone seen anything like THIS happen before and therefore may have a concept why its taking place?
 
So yeah, I need someone who's having trouble to revert to 8604 then update straight to 8606 and see if that clears up the problem. Please.
 
I reverted back to 8604 and loaded my earlier posted autosave fine. Updated to 8606, loaded the autosave and having the same problem as before. For good measure I deleted the cache in appdata/local/<etc>... to no effect.
From this morning I distinctly remember SVN downloading the DLL again between 8605 and 8606 in any case.
 
Thunderbrd said:
Alberts... any theories on what the problem could be here? We're not talking about a slowdown unless its seriously a system issue but the changes haven't caused any further delays on my end and they're fairly basic at that.
Click to expand...

You have to revert the marked change that you made here!!!!!!!!!!
Code: 
template <class T>
T* FFreeListTrashArray<T>::getAt(int iID) const
{
	int iIndex;
	T*	result = NULL;

	if ((iID == FFreeList::INVALID_INDEX) || (m_pArray == NULL))
	{
		return NULL;
	}
	
	EnterCriticalSection(&m_cModifySection);

	iIndex = (iID & FLTA_INDEX_MASK);

	assert(iIndex >= 0);

	if ((iIndex <= m_iLastIndex) && 
		(m_pArray[iIndex].pData != NULL))
	{
		if (((iID & FLTA_ID_MASK) == 0) || (m_pArray[iIndex].pData->getID() == iID))
		{
			result = m_pArray[iIndex].pData;
		}
	}
[COLOR="Red"][B]	else
	{
		return NULL;
	}[/B][/COLOR]
	
	LeaveCriticalSection(&m_cModifySection);


	return result;
}

You are skipping the LeaveCriticalSection(&m_cModifySection) call that is causing those issues. Your change is pointless because result is initiated with NULL as value so
Code: 
return result;
already does the same as the code that you added.
 
alberts2 said:
You have to revert the marked change that you made here!!!!!!!!!!
Code: 
template <class T>
T* FFreeListTrashArray<T>::getAt(int iID) const
{
	int iIndex;
	T*	result = NULL;

	if ((iID == FFreeList::INVALID_INDEX) || (m_pArray == NULL))
	{
		return NULL;
	}
	
	EnterCriticalSection(&m_cModifySection);

	iIndex = (iID & FLTA_INDEX_MASK);

	assert(iIndex >= 0);

	if ((iIndex <= m_iLastIndex) && 
		(m_pArray[iIndex].pData != NULL))
	{
		if (((iID & FLTA_ID_MASK) == 0) || (m_pArray[iIndex].pData->getID() == iID))
		{
			result = m_pArray[iIndex].pData;
		}
	}
[COLOR="Red"][B]	else
	{
		return NULL;
	}[/B][/COLOR]
	
	LeaveCriticalSection(&m_cModifySection);


	return result;
}

You are skipping the LeaveCriticalSection(&m_cModifySection) call that is causing those issues. Your change is pointless because result is initiated with NULL as value so
Code: 
return result;
already does the same as the code that you added.
Click to expand...

1)Why would it be causing issues on some machines but not mine nor my wife's?

2) This was a debug to avoid a crash that was taking place because result was unevaluatable when returned.

3) It worked to avoid the crash I was having.

Still, I'm sure you understand more about this portion of code than I do (not being sarcastic here - I really don't fully understand this FFreeList business!) Happy to revert it. Hopefully we can find the crash again and I can let you look into it. I would've done that initially but the problem came up in an MP game.

Again, don't get me asking questions to mean that I think you're wrong... I suspected this spot. But I couldn't verify it was causing any problem on my end at all.



EDIT: In retrospect, I believe I may have misread the actual crash spot in the minidump. I see the problem you're pointing at. Strange it causes trouble on one system and not another but yeah, clearly this was not a correct modification to solve anything.
 
alberts2 said:
He is absolutely right to play such a huge game. Simply because it is possible to do it just like that without any modifications. But if that is not possible because it's too slow even on modern high-end hardware C2C is to blame not the player.
Click to expand...

:confused:
Not sure where you got it that I think Talin Shouldn't play his game?

Or perhaps you are replying to Arakhor's post that I responded too, but quoted me? :dunno:

JosEPh
 
Dancing Hoskuld

In Build 1608 I tinkered with my infamous Lizards setup and determined that no, the vicinity bonus for mountain mines is not working as of current build.


Cheers!
-Liq
 
Liquidated said:
Dancing Hoskuld

In Build 1608 I tinkered with my infamous Lizards setup and determined that no, the vicinity bonus for mountain mines is not working as of current build.


Cheers!
-Liq
Click to expand...

Thanks for that. I'll try one more thing ;) At least at the moment you can't build mountain mines anywhere!
 
It is no good. I can either make the mountain mine available anywhere there is a resource or I can make it valid only on Peaks but not registered as vicinity bonus. The XML is fine at it is currently.

So expect it is something in the vicinity code, t is probably relying on the bonuses making the improvement valid.
 
You must log in or register to reply here.

Similar threads

raxo2222
  • Sticky
Single Player bugs and crashes v43 plus (SVN) - After January 2023
55 56 57
Replies
1K
Views
80K
tmv
T
raxo2222
  • Sticky
Single Player bugs and crashes v43 download - After January 2023
2 3 4
Replies
78
Views
11K
Korbin
K
raxo2222
Single Player bugs and crashes v42 plus (SVN) - After April 2022
30 31 32
Replies
628
Views
49K
Somebody613
S
raxo2222
Single Player bugs and crashes v42 download - After April 2022
2 3
Replies
51
Views
7K
ATARi144kHz
ATARi144kHz
raxo2222
  • Sticky
Multi-Player Bugs and Crashes, v43 & SVN after January 2023
Replies
4
Views
2K
Thunderbrd
Thunderbrd
Back
Top Bottom