Fallout: Tame The Wastes

I have a feeling I should stop doing anything in python until I have studied Platypedia.

Good luck with the pedia :D
It is hard to decide which is more complicated, the pedia or the WB, but those are the only 2 works which requires days to complete, packs excluded :mischief:

And I am not fond of commenting everything when it is a complete overhaul.
 
oh man... Platy just did something seriously nice with the city screen

City Screen Update

That basically solves the issue of not being sure of what is what!

Ah Platy is back again!! Shhh don't tell him what I said :p

ok, sad news we won't be able to change the size of the specialist icons, as the table row height is not adjustable...which is a bit of a pig! :D
 
I think I finished this feature. I added reading UpgradeTech from XML, needed handlers for CvImprovementInfo and prevents CvPlot::doImprovementUpgrade() from doing anything if the improvement in question needs a tech the owner lacks. On top of that I wrote a perl script to add
Code:
<UpgradeTech>NONE</UpgradeTech>
after the lines containing ImprovementUpgrade and updated the schema accordingly.

What's left is "just" the GUI stuff and testing. The big problem here is that I can't start the mod on the computer I'm on right now, making GUI coding really tricky (can't see the results). The same goes for testing the result. So far the test says "it compiles just fine".
 
:(
I need to get this working with a debugger then. The fact that it makes it all the way to new turn event is partly successful. It mean the whole XML change ran without failures. Crashing the game is often reading from NULL pointers or reading from a negative index in an array. I thought I took care of that, but I must have missed something.
 
I found the bug. It is in CvPlayer::doDynTraits()

Near the end it says
Code:
if (bLoseTrait)
{
	setHasTrait(eOldTrait, false);
}
eOldTrait isn't set and is a huge negative number. I tried setting it to NO_TRAIT in the beginning of the function and only do setHasTrait() if eOldTrait != NO_TRAIT. That made the game stable. The issue is.... I didn't touch this function. In fact I didn't even touch the file in question :confused:

My "fix" only prevents a crash. It doesn't really solve the problem, which appears to be a deeper problem with that function and somebody needs to investigate this further.

Also the game asserts a few times before turn 2 starts, which indicates that the DLL is more buggy than what I detected during normal gameplay. I know coding new features are more fun, but this DLL really needs some bugfixing attention. That somebody can't be me, at least not within the near future.

The good news is that my changes didn't appear to cause any issues, but I still haven't tested them to tell if they work as intended.
 
Some asserts are not bugs, they are from the way firaxis originally coded things they assert because it is doing something firaxis didn't expect, but it is not actually a bug.

That bit of code, might be something that flitz was in the middle of doing, the last time we talked about it, dyntraits was not losing traits the way it should, this could be flitz half way through fixing that, I haven't heard from him in a little while, but he usually goes quiet and then pops up one day with goodies!

So it could be that downloading the latest version from hub got some bits that weren't ready yet... I don't know, like I said these days I rarely touch the game core..

can you post up the file with the change and I will give it a whirl
 
ok, sad news we won't be able to change the size of the specialist icons, as the table row height is not adjustable...which is a bit of a pig! :D

You can adjust the size, so long as you dont use a table.
The previous version was done, where each icon is a different entity, so the position of each one is done with accurate formulae.

There are also some other formats as seen in the pedia, which can be individual rows or columns and size can be adjusted as big as you like.

Table however, is the easiest one to use for multiple columns and rows, plus the ability to sort if you include the header.

Yet the code to adjust table height is there, but does not work.

Thus, if you really want big icons, use other formats.
 
Yeah, I really like your new specialist layout with the 1 + - and the name at the bottom. I wonder why the table adjustment does not work.. Maybe it could be fixed in the dll, perhaps firaxis forgot to finish it or activate it...

Ok, well sorting isn't really important for the specialists, so if we can work out how to do these 'other formats' when we get your GUI integrated, we could potentially have our dream big specialist icons. Hmmm possible hope there :D

I have posted up a message in our broken code thread with a link to your post NG, so we shall see what flitz makes of it, or what the score is when he comes back around
 
Some asserts are not bugs, they are from the way firaxis originally coded things they assert because it is doing something firaxis didn't expect, but it is not actually a bug.
Asserts are bugs because they mean the code is reaching conditions it isn't designed to handle. The case where it is safe to ignore an assert would be if a function expects a non-negative argument and somebody adds support for -1. However in that case the bug is the assert itself as it checks for incorrect values.
A well functioning code shouldn't be asserting at all.

The only exception I can think of is M:C, which asserts on well functioning DLL code if the XML is set up incorrectly. It was the quickest error popup I could find at the time and it tells XML file and TYPE string where it went wrong. It is an error, but it isn't inside the DLL.

That bit of code, might be something that flitz was in the middle of doing, the last time we talked about it, dyntraits was not losing traits the way it should, this could be flitz half way through fixing that, I haven't heard from him in a little while, but he usually goes quiet and then pops up one day with goodies!
That explains the lack of reply on my PM. Well it isn't urgent ;)

can you post up the file with the change and I will give it a whirl
Done. Except I don't have access to the compiler right now or the modified file. However those few line changes are minor enough to do "blindly" from memory :)
 

Attachments

Spoiler :
PediaPromotion_zps739ef74f.jpg


This is an example of another format.
The Unit Combat list icons can be as big as I like.
But doing in this format means you need 3 of these, since it can only be single column or row.
 
cool, yes those are the kind of 'bugs' I was talking about. It has been a while since i have looked at a debug version, these also could be things coming from a work in progress from flitz.
Makefile 2.3 (starting from 2.0) can make an assert build. It is optimized like like a release build, but it makes all the assert checks anyway. This allows a DLL, which is fast enough to play while the code is checked. Quite a number of bugs have been found and fixed in both M:C and RaR using this. Nobody will play hundreds of rounds with a debug DLL if it takes 5 minutes to get to next turn if the assert one can do it in around half a minute.

I just noticed the python access code is missing from what I uploaded
CyInfoInterface2.cpp said:
python::class_<CvImprovementInfo, python::bases<CvInfoBase> >("CvImprovementInfo")
...
.def("getTraitCounterMod", &CvImprovementInfo::getTraitCounterMod, "int (int i)")
/* /FalloutTTW */

/// Techbased Improvement Upgrades - start - Nightinggale
.def("getUpgradeTech", &CvImprovementInfo::getUpgradeTech, "int ()")
/// Techbased Improvement Upgrades - end - Nightinggale

;
This small piece of code allows using .getUpgradeTech() on improvement infos in python where it returns the index to the tech in question (often -1 aka NONE). I never planned anything with this, but I figure it would be a good thing to be able to access from python. You never know what somebody else can come up with.
 
@Lib
Pretty much whatever I changed all come with scrollbars, though some already had in bts
 
Back
Top Bottom