Fallout: Tame The Wastes

Isn't the mod built over K-mod which utilizes BUG. It might be kind of hard to rip out K-mods guts and replace them.
 
It has been done, it doesn't actually require a removal of any .dll code.

The problem is that there is something different about this mod to other K-mod based mods, my friend keldath has been able to do several platy replaces, for some bizarre reason it just does not seem to work with this one..

We have been looking over it together the last few weeks to see if we can figure out why.

Like I said, everytime I am about to give up, I do something the results in something resembling progress, then it goes wrong again!

I have now put so much time into it that I am just desperate for an answer as to why!?!

Why does it crash?
Why does it sometimes work?
Why does it seemingly randomly go from something that works to something that doesn't?

The actual result of it working is almost less important to me now than just the simple understanding as to why!?!?:D
 
hmmm...

Yes K-mod is another mod that this was built on top of.

It should work if you put the Fallout TTW folder (the one in the zip) into the BTS mod folder... it is strange that it doesn't. Can you explain what you mean by not work?

For example:
Does it crash?
Does it not load at all?
Does it not appear in your mods list when you play Beyond the Sword?

I have never used the steam version, so I am not sure if it has a quirk to it..

It just doesn't even show up in the mod list. My game works fine, it just doesn't load it. I can't run the game as administrator as it doesn't give me the option like all my other games do.
 
hmmm...

have you tried any other mods?

Do the mods that come with Bts show up?

Did you put it in the folder that has those base mods (did you even find the folder that has those base mods?)

I am not sure what will happen without admin permission as BUG needs admin permission to work, no idea how it works with steam..

have you got any mods to work?

If not I suggest asking in one of the tech help threads about installing mods with steam version, as I can't help with that for Bts.
 
hmmm...

have you tried any other mods?

Do the mods that come with Bts show up?

Did you put it in the folder that has those base mods (did you even find the folder that has those base mods?)

I am not sure what will happen without admin permission as BUG needs admin permission to work, no idea how it works with steam..

have you got any mods to work?

If not I suggest asking in one of the tech help threads about installing mods with steam version, as I can't help with that for Bts.

I haven't tried any other mods. I put the fallout mod in the base mod folder with the default mods. I found out how to run as admin(had to go to the install folder and run the exe in there) and still nothing showed up.
 
hmmm...

I really don't know then, you have done everything right (it would also show up without admin, it just wouldn't work properly)

All I can suggest, like I said is ask around on some steam specific tech help, either here in the tech sections, or maybe on the steam forums.

I can't help with getting it to work on steam as I don't have a steam version, but putting it with the base mods, should have been the thing that made it work..

I think you said you uncompressed it, so I assume you didn't just put the .rar file in there.
 
I haven't tried any other mods. I put the fallout mod in the base mod folder with the default mods. I found out how to run as admin(had to go to the install folder and run the exe in there) and still nothing showed up.

Did you put the fallout mod in:

C:\Program Files\Steam\SteamApps\common\Sid Meier's Civilization IV Beyond the Sword\Mods

or this?

C:\Program Files\Steam\SteamApps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods
 
after searching i found our culprits

For python error : assets\Python\Screens\PlatyHelpers\MirrorImage.py

For xml error : assets\xml\GameInfo\CIV4GameOptionInfos.xml
 
i trying to isolate bugged py file. it come from more places then it first seems.
 
CvMainInterface.py

class CvMainInterface:
def __init__ (self) :
self.iSelectionLayer = 2
self.iSelectedSpecialist = 0
self.iFreeSpecialistRow = 0
self.iIconSize = 28 ## Specialist Icon
self.iNumSpecialistColumns = 3
self.iMaxSpecialistRows = 5
self.iMaxPromotionColumn = 5 ## Max number of columns for unit promotions
self.iScoreRows = 0 ## Score Board
self.iScoreWidth = 100
self.iBonusClass = -1 ## Resource Filter
self.bPrereq = False
self.lAdvisors = [0,0,0,0,0,0]
self.iCombatLayer = 0
self.lGreatPeople = [] ## Great People Bar
for iOption in xrange(GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES, GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES + 4):
CyUserProfile().setGraphicOption(iOption, gc.getGraphicOptionsInfoByIndex(iOption).getDefault())

self.m_iNumPlotListButtons = (1024 - (iMultiListXL+iMultiListXR) - 68) / 34

If you comment this python error will disappear :)
 
That line looks quite wrong.

for iOption in xrange(GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES, GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES + 4):
CyUserProfile().setGraphicOption(iOption, gc.getGraphicOptionsInfoByIndex(iOption).getDefault())

Say we have 10 graphics options (I don't know the actual number, doesn't matter)

The first line sets the upper limit to 10+4=14. The lower limit is 10. In other words the loop will run 4 times with iOption set to 10, 11, 12 and 13.
The next line calls the info from the game vector. This vector has the same length as the number of options, which mean valid arguments are in the range 0 to 9. Any arguments outside that will cause problems.

It is possible that somebody added more options without updating GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES, but that would be really bad coding. Now the question is what is it supposed to do and how can it be made to do as intended. Clearly the current code is quite broken, both by design and by what it does.
 
after i commented out listed lines, game started without python errors but in-game i you trying to open options it pop-up that error so it is connected to options.
i see 4 options only in platy tab.
 
That line looks quite wrong.


Say we have 10 graphics options (I don't know the actual number, doesn't matter)

The first line sets the upper limit to 10+4=14. The lower limit is 10. In other words the loop will run 4 times with iOption set to 10, 11, 12 and 13.
The next line calls the info from the game vector. This vector has the same length as the number of options, which mean valid arguments are in the range 0 to 9. Any arguments outside that will cause problems.

It is possible that somebody added more options without updating GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES, but that would be really bad coding. Now the question is what is it supposed to do and how can it be made to do as intended. Clearly the current code is quite broken, both by design and by what it does.

Nope, it is doing what it is intended to do.
Clearly, updating GraphicOptionTypes.NUM_GRAPHICOPTION_TYPES is only doable via modifying the dll, and there is no way you can do that via pure python.
It is neither broken by design nor by what it does, because it is designed precisely that way for pure python mods, as mac users cannot have modified dll.

However, I overcome that obstacle by coding it this way, which does what it is supposed to do. Obviously if lib copied the codes blindly without adding the extra graphic options which were added, the codes will fail.
 
It is neither broken by design nor by what it does, because it is designed precisely that way for pure python mods, as mac users cannot have modified dll.
That's actually a pretty good argument for coding like this. I was right that it was due to a broken design, but it was the broken mac DLL support rather than this piece of code.
Still a comment about it would have been nice.

Obviously if lib copied the codes blindly without adding the extra graphic options which were added, the codes will fail.
I wouldn't be surprised if that is precisely what happened here. It would be nice if it could be checked somehow and fail with a proper error message. However it doesn't look like vanilla has any getNumGraphicOptionsInfos(), which mean a proper python only test could be quite tricky.
 
the .dll error, is the question I put to platy in his thread.

However this does not in and of itself cause the game to break, as keldath has successfully used platy in his kmod based mods, he gets the same error, but a working game.

This graphic options error seems to be another one of these errors that does not effect the gameplay or break the game it just asserts.

This is not the issue that causes the game to crash without an error message at the point of starting a new game.

If it was then no mod would work..

The point is it is something else that is not working between platy and this mod specifically.

As other mods with similar .dlls work with platy.

I am fairly certain that it is something missing/wrong/etc. in python, that something working specifically in FTTW, is not working with the platy display code, or is otherwise missing in my merge attempts.

However, because the game crashes without any error messages, I have no way of knowing what the issue is..

and going back to my early questions.

why do I sometimes get it to work, only to have it fail again later?

what is it that is going specifically wrong with some part of the mods python, when combined with platy?

Or perhaps 'uncombined' from BuG?

Or perhaps a combination of the 2.
 
Compile a debug DLL, start in window mode, attach the debugger and make it crash. It will tell where in the DLL the game crashed. Python itself can't crash the game, but it can send corrupted data to the DLL and exe, which can crash. A crash can be something as simple as dividing with the number given from python and then python gives a zero.
 
771A2D94 mov dword ptr [eax],esi
In C++, that would be written
Code:
esi = *eax;
Presumably eax is a null pointer and as we all know (or should know), using null pointers have to crash the game due to OS security reasons.

The question is how did you end up with a null pointer. It's impossible to tell based on what you posted here. This mean the debugger is more or less useless for this crash unless there is something interesting in the stack.

Also it crashes in ntdll.dll. Clearly that file is working, which mean it is called with incorrect arguments. If the crash had been in our DLL, then the debugger would have displayed the C++ code rather than assembly.

Maybe I should take a look. However I don't know anything about this crash or even which branch to use.
 
Back
Top Bottom