RFCE 1.3 Playtest Feedback

Reverted back to SVN 1144 and Prussia autoplay finished successfully in the 1st attempt. On SVN 1155, I tried 5-6 times and every auto-play failed with CTD by 1090 AD the latest.

About the autosaves feature during auto-play which was disabled recently...maybe it's a good idea to bring it back in some level (e.g. less frequent autosaves) to enable recovery points closer to target than starting the auto-play all over again after each CTD?
 
Muscovy's 2nd UHV ("Get 20% of the land") sounds really awkward. Maybe it could be written into something like ("Control 20% of Europe") or something like that?

Okay, will change it

Also, probably related to Lubeck's culture spread, but why does Denmark's starting fleet spawn off Mecklenburg?

The starting spot is semi-randomized
Maybe I will move the area 1-2 tiles north though
 
Novgorod's UB Konets (конец) is really a district, part of the city, not a building! Early Novgorod had 5 districts. Perhaps UB should be called Veche? Obviously Kiev has similarly named building, but most famous and unique Veche was one of the Novgorod's, not Kiev's. Kiev could get some Granary replacement building instead, called, say, Ambar, storing +10% more food than Granary.

Edit: Loading Lithuanian game with current SVN is casing CTD.
 
Another instance of the city conquest crash - this time it's Denmark (me) capturing London. Interestingly enough, I seem to already have culture in London even though I've never owned it or anything close to it (except Norwich, which I captured earlier that turn).

I don't think that is the problem, because you don't need to change the sourcecode if you want to add an unit.

But strangely, I do get a CTD when I try to conquer it with a WB'd Novgorod UU. When I conquer it with a Pikeman, Landsknecht or Dutch UU I don't get a CTD. Do it seems there is a connection between the CTD and the new units.

EDIT: Portuguese UU and Varangian Guard also have the problem. They all share the same KFM file.

This savegame is very useful, as it's directly connected to the players turn
The unit animations certainly worth double checking, that's a good tip merijn
 
Novgorod's UB Konets (конец) is really a district, part of the city, not a building! Early Novgorod had 5 districts. Perhaps UB should be called Veche? Obviously Kiev has similarly named building, but most famous and unique Veche was one of the Novgorod's, not Kiev's. Kiev could get some Granary replacement building instead, called, say, Ambar, storing +10% more food than Granary.

Edit: Loading Lithuanian game with current SVN is casing CTD.

Funny thing, I just read about this 2 days ago (when updated the building art files), and put on my todo list that Veche suits Novgorod more than Kiev :)
So something will be done there, eventually. Not yet sure what it will be the exactly, but will look into Ambar too

Btw, Konets is not that bad, as it can be associated with different type of trade organizations of the city too.
That's why it's a Guild Hall replacement.
 
But strangely, I do get a CTD when I try to conquer it with a WB'd Novgorod UU. When I conquer it with a Pikeman, Landsknecht or Dutch UU I don't get a CTD. Do it seems there is a connection between the CTD and the new units.

EDIT: Portuguese UU and Varangian Guard also have the problem. They all share the same KFM file.

Longswordsman, Maceman and Berserker also causes a CTD
But none of the Cavalry units I tested so far. Neither a musketman nor it's UUs
 
This savegame is very useful, as it's directly connected to the players turn
The unit animations certainly worth double checking, that's a good tip merijn

Some more testing revealed that the problem seems related to the Walls. When I removed the walls from London, I didn't get a CTD. (That's probably the reason why Norwich didn't caused a CTD)
 
Bad news Absinthe! i had a solved ctd where Keshiks were the problem...

Some more testing revealed that the problem seems related to the Walls. When I removed the walls from London, I didn't get a CTD. (That's probably the reason why Norwich didn't caused a CTD)

No
As I said before, all these things are just the symptom
The issue is not with walls, or with specific units. Neither with some unit animations. These might only point us into the right direction, if we are lucky.
For example it won't crash every time you conquer a city with Huskarls. Also won't occur with all the city conquest with non-english accents
The problem is with a strange memory accessing thing. Unfortunately I don't yet understand why and when is this happening.
Then again, if I would, probably I could have solved the bug already

This problem is present in the mod for a very long time, I'm pretty sure of it now.
Also, gilgames reported that he had a similar crash with rev 1092, so before my big commit of the new civs and other base things for 1.3
All the new art, and the recent changes in the fpk files only made these crashes much more frequent, didn't introduce it
 
I hope this piece of info could help: I have never (even while others have already started reporting them) encountered any ctd's, only after the most recent art updates. Then they occur during auto-play, 900ish. Anything I can help with, test-wise?
 
I hope this piece of info could help: I have never (even while others have already started reporting them) encountered any ctd's, only after the most recent art updates. Then they occur during auto-play, 900ish. Anything I can help with, test-wise?

Yeah, it's the same on my older computer, with an old 32 bit OS.
I'm doing a different fpk (art pak) setup currently, will be uploaded in a couple hours
All these new crashes are different from the previous one. (and were introduced with one of the recent fpk updates)
I mean, i'm pretty sure that this is the same-type memory crash, but there is a new and much more common thing initializing it, most likely connected to units.

After the next commit is up, I'm really curious if it still crashes on your computer or not
So it would be great if you could run some starts ASAP
 
Funnily, my machine runs Win 7 64bit with 4 GB of RAM.
 
My comp runs 8.1 64 bit with 8GB of RAM, but seems to crash as much as, if not more frequently than, everyone else's. Maybe the newer the comp the more crashes it causes?

It could well be something OS related, although I've tried running in Vista and XP compatibility mode and it seems to make no difference.

I dunno, I'm just throwing mud at the problem and hoping something sticks ;)
 
Yeah, the computer I do most of my modding is windows 8.1 with 64 bit as well
But since Civ IV isn't the newest game, and wasn't really coded too well memory handling wise (just think of all the MAFs), it can't really use most advantages of 64 bit systems, as far as I know.
 
Yeah, what I'm wondering is whether the way more recent Windows versions handle memory could be linked to the cause of the problem.

I'm running a Dutch spawn with the new version on my Win 8.1 laptop now, so will report how far it gets. But I'm also dusting off my 2007 vintage Inspiron (and I mean dusting off - it's got a cover about an inch thick) and will see how that handles the latest SVN as well.
 
Ok, latest version CTD at 996AD

The test on my old laptop is probably going to take a while - I'm going to have to update AVG and Windows and wait for it to chug chug chug like a steam train before I can even get the latest SVN...
 
Yeah, what I'm wondering is whether the way more recent Windows versions handle memory could be linked to the cause of the problem.

I'm running a Dutch spawn with the new version on my Win 8.1 laptop now, so will report how far it gets. But I'm also dusting off my 2007 vintage Inspiron (and I mean dusting off - it's got a cover about an inch thick) and will see how that handles the latest SVN as well.

Here is an interesting - and very disturbing read - if you are interested:
http://forums.2k.com/showthread.php?254251-Crash-on-launch
It's about Civ V, but the memory exception message about the bug is the same for us too: "Unhandled exception at <xyz> in <minidump file name>: 0xC0000005: Access violation writing location 0x00000032"

Some imprtant parts of the comments:
I've managed to identify the issue as a buffer overflow triggering a segmentation fault response from the OS, terminating the process
C0000005 is not specific to overflows - it's a segmentation fault (or that's what it's called in POSIX, Windows seems to have a range of names for it). It means code attempted to access memory it doesn't have access to. It's highly generic. Overflows, uninitialised pointers, and null pointers are the three common causes.
If you google for APPCRASH 0xc0000005, you'll find a host of times when that happens. Solutions are practically always found by playing around with drivers and windows updates. Sometimes even drivers which do not seem related (example: http://www.techsupportforum.com/foru...sh-680450.html).

So another tip is to check your other drivers as well (besides GPU) and try to update those. My first guess would be the audio drivers.

In this specific case some drivers were the issue
Now for us I highly doubt drivers can be the cause, as it happens on so many different computers, furthermore on different operating systems.
But the whole thing still tells a lot about how dangerous and difficult those memory segmentation faults are...
 
In this specific case some drivers were the issue
Now for us I highly doubt drivers can be the cause, as it happens on so many different computers, furthermore on different operating systems.
But the whole thing still tells a lot about how dangerous and difficult those memory segmentation faults are...

I dunno - drivers could have something to do with it if there was a general Windows update across 7 and 8.1 which affected the OS of everyone. I think many of the security updates are similar across the supported versions of Windows if they identify the same weakness, and that could affect a lot of PCs.

The fact gilgames reported a CTD with 1096, when I don't remember anyone reporting a similar issue over the past couple of years when 1096 was the current SVN version indicates that something may have changed with the OS over the past few months.

I'm going to try the AMD beta drivers for my graphics card and see if that makes any difference - current drivers were released in December whilst beta drivers were released in April, so that might do something. And if not it will keep me busy trying and seeing! ;)
 
Back
Top Bottom