Bug Reports

[raystuttgart]

So, you prolly have all the quirks worked out of the multi yield system then?

I do think so.
People seem to really like it.

We could just somewhat copy your version then and all the related functions and have a unbugged code.
I have added my own M:C specific code though so we'll have to work around that.

Yes sure, you could try to use it as a blueprint for your version.

Basically all features included in RaR from other mods have undergone improvment.
But of course they have usually also undergone RaR-specific changes.

Also, did you make all secondary produced goods yield half?

Only on Plots.
But there yes, all secondary are half primary.

In Buildings they are the same as primary.

 

[orlanth]

Originally Posted by raystuttgart View Post
You should though.
Multiple Yields Produced (Plot and Building) do unlock very interesting possibilities.

I would also suggest to take a look at Multiple Professions Per Building (original implementation from Androrc).
It is also a very good base feature that unlocks lots and lots of possibilites.

Yeah, the Multiple Professions Per Building would be perfect for smithing weapons and armor - could unlock each profession separately via techs and let them produce & consume whatever yields are desired, with master weaponsmith getting a bonus to each.

 

[Nightinggale]

Actually now that I think about it, maybe we should use the github issues tracker.
https://github.com/Nightinggale/Medieval_Tech/issues
Granted you need a github account to add issues, which is why it can't replace the forum. However it provides a sort and searchable list of known issues. Also an "issue" could be a new feature and it is joined together with Milestones. This mean we can select a number of issues and mark them as needed for releasing 2.1. We can then get a list of open issues for 2.1 and see what needs to be done in order to release the next release.

There is a video here https://github.com/blog/411-github-issue-tracker with the old github graphics, but it explains the idea pretty good.

EDIT: I added two issues for testing purposes.

No replies
Does that mean no objections or no approvals? Personally I would like to keep track of bugs and approved ideas for features with this system. It's way easier to look up stuff there than to browse through forum threads.

I will take a look at the multiple yield code. I just haven't got around to it yet.

 

[Kailric]

No replies
Does that mean no objections or no approvals? Personally I would like to keep track of bugs and approved ideas for features with this system. It's way easier to look up stuff there than to browse through forum threads.

I will take a look at the multiple yield code. I just haven't got around to it yet.

Yeah, I know what you mean about those "round to it's", they are hard to come by for me these days. I checked out the git issues and I like it, we can use that as one way to let us know who is doing what so we both don't work on the same bug for instance. I may have some little extra time next week to work on stuff.

Yeah, the Multiple Professions Per Building would be perfect for smithing weapons and armor - could unlock each profession separately via techs and let them produce & consume whatever yields are desired, with master weaponsmith getting a bonus to each.

I'll check this out when I get one of those "round to its"

 

[mastrude]

I've been able to determine that the following list of assert failures occur in the 2.0g game, by having them come up over and over. Nightinggale, would you please note the version into your list? That's without my going back over the forum posts I made in the past. Here they are:

CvUnit.cpp                965
CvPlayer.cpp            4958
CvUnit.cpp               6486
CvGameTextMgr.cpp   8514
CvGameTextMgr.cpp   9222
CvPlayer.cpp           15109
CvInfos.cpp            15607

I will have a further list shortly of my previous 2.0g posts.

I'm unable to test your development version. Nightinggale, mind if I ask you for a bit of help? I wouldn't mind playtesting it--but not if I'm going to see these same bugs over and over.

It's getting pretty tedious to see these old errors over and over, so I'm going to go back to my database or play TAC until these are gone.

I think it's time to cease development, get a better procedure for versioning, and knock off some bugs, personally. Or lay off Kailric and let him get some personal time.

I think what we would all like best is for you guys to have a published version 2.0 in which bugs get fixed. Then for you be able automatically to reapply the changes comprising the development version over that. I don't know GIT, but I have a feeling we ought to be able to do that. We used to call this having a base version, and a "change deck". After punched cards went the way of the dodo, we had a change tape but we still called it a "deck"

 

[orlanth]

Yeah, I know what you mean about those "round to it's", they are hard to come by for me these days.

I found one

never had one of my own though, guess thats why I havent got much done

 

[Kailric]

I've been able to determine that the following list of assert failures occur in the 2.0g game, by having them come up over and over. Nightinggale, would you please note the version into your list? That's without my going back over the forum posts I made in the past. Here they are:

CvUnit.cpp 965
CvPlayer.cpp 4958
CvUnit.cpp 6486
CvGameTextMgr.cpp 8514
CvGameTextMgr.cpp 9222
CvPlayer.cpp 15109
CvInfos.cpp 15607

I will have a further list shortly of my previous 2.0g posts.

I'm unable to test your development version. Nightinggale, mind if I ask you for a bit of help? I wouldn't mind playtesting it--but not if I'm going to see these same bugs over and over.

It's getting pretty tedious to see these old errors over and over, so I'm going to go back to my database or play TAC until these are gone.

I think it's time to cease development, get a better procedure for versioning, and knock off some bugs, personally. Or lay off Kailric and let him get some personal time.

I think what we would all like best is for you guys to have a published version 2.0 in which bugs get fixed. Then for you be able automatically to reapply the changes comprising the development version over that. I don't know GIT, but I have a feeling we ought to be able to do that. We used to call this having a base version, and a "change deck". After punched cards went the way of the dodo, we had a change tape but we still called it a "deck"

Don't lay me off please!! It takes time to produce anything and considering this is just a hobby it's gonna take even longer. After you pointed out a bunch of failed asserts sounds like you should sit and wait a while for the next version. Besides, all you have to do is hit "Always Ignore" on the failed asserts or don't play with the Assert Version if it hasn't been fixed yet because you are going to get the same results. Most of those you have pointed out don't even have a noticeable effect for the player while playing so they are not on a priority list to fix. When you post a crash that's when I stop what ever I am doing and investigate.

 

[Kailric]

I found one
never had one of my own though, guess thats why I havent got much done

Thanks orlanth, I'll have a dozen. I actually found one when I was a kid that just said "tuit". Took me years to figure out what that meant

 

[Kailric]

That was the problem I mentioned in your last crash mastrude, somehow a Wily Trader while waiting in Europe to be picked up actually purchased some goods. Then when he was picked up it created an error of a Transport carrying a Transport that is carrying goods and the code didn't like that. I fixed your saved game by creating a Failed Assert that will pop and then delete any such goods being transported. I figured that was faster than trying to make it so that transports carrying transports that are carrying goods want crash the game.

Nope, I was wrong, as my new Assert popped. But I do believe I have finally traced down this bug. If a Wily Trader with Trader Profession ever ends up on a ship there is nothing in his AI code that ever tells him to get off the ship. So the little guy just rides around having a good ole time until he is able to purchase some goods, when he does that's when crashes starts. I didn't realize that it was the AI of the Cargo that told them when to unload, not the AI of the ship carrying them. Anyway, I have added unload AI for Wily Trader's. I'll push my recent changes to Git soon and then upload a new 2.0h version.

 

[mastrude]

I located the source of a bunch more asserts in 2.0d. They are:

00,997 CvTeam.cpp
01,252 CvUnit.cpp
08,285 CvGameTxtMgr.cpp
14,645 CvPlayer.cpp

I don't know whether any of them have been fixed between 2.0d and 2.0g.

For double-checking, the remaining ones I didn't locate the source for are:

00,024 CvPlayerAI.cpp
00,086 CvUnitAI.cpp
05,097 CvPlayer.cpp
11,298 CvUnit.cpp

So, only 4 I couldn't locate. Maybe you know that they are development version.

 

[mastrude]

After installing the module you mentioned, I'm getting this XML load error:

"Failed Loading XML file xml\GameInfo/Civ4GameSpeedinfo.xml
[.\FXml.cpp:133] Error parsing XML File -
File:
xml\GameInfo/CIV4GameSpeedInfo.xml
Reason: The element 'TradeRouteTrmipLength'
is used but not declared in the DTD/Schema.

Line 72,32
Source <TradeRouteTrmpLength>

I'm guessing this was a module from the development version, and backing it out. [EDIT:] Nope that didn't work. I maybe screwed up somehow?

 

[Kailric]

After installing the module you mentioned, I'm getting this XML load error:

"Failed Loading XML file xml\GameInfo/Civ4GameSpeedinfo.xml
[.\FXml.cpp:133] Error parsing XML File -
File:
xml\GameInfo/CIV4GameSpeedInfo.xml
Reason: The element 'TradeRouteTrmipLength'
is used but not declared in the DTD/Schema.

Line 72,32
Source <TradeRouteTrmpLength>

I'm guessing this was a module from the development version, and backing it out. [EDIT:] Nope that didn't work. I maybe screwed up somehow?

Are you referring to the DLL I posted for you to try with one of your saved games that I fixed? Anyway, ill post a new update today so that we are all back on the same page again. Also, with failed asserts its good to know which one's have already been found and talked about but with any knew one's we still need a saved game that has the failed assert happening in order to track down the reason for the FA.

 

[Kailric]

A note on failed asserts: Some asserts I have been added purposely in order to track the AI's movement and such. I'll make note of these in red in the main post.

EDIT: added Nightinggales link to first post for git version failed asserts

 

[Nightinggale]

A note on failed asserts: Some asserts I have been added purposely in order to track the AI's movement and such. I'll make note of these in red in the main post.

EDIT: added Nightinggales link to first post for git version failed asserts

It's your own debug code. I'm not sure it's such a good idea to add it to the general assert build. You could do something like

if (AI_extra_assert)
{
[INDENT]FAssert();[/INDENT]
}

AI_extra_assert should then be a global bool or something, possibly a define meaning you can easily access all those asserts yourself while everybody else will not consider those to be bugs. Technically it's a wrong way to use asserts, but I have done it too. However I never committed and of those "false" asserts.

 

[Kailric]

It's your own debug code. I'm not sure it's such a good idea to add it to the general assert build. You could do something like

if (AI_extra_assert)
{
[INDENT]FAssert();[/INDENT]
}

AI_extra_assert should then be a global bool or something, possibly a define meaning you can easily access all those asserts yourself while everybody else will not consider those to be bugs. Technically it's a wrong way to use asserts, but I have done it too. However I never committed and of those "false" asserts.

Yeah, I don't always think to remove those things, I don't claim to be an expert coder just a hobbyist, so I have a lot to learn still. That's a good idea though. If its not technically right then what is? Using break points is helpful but you can't always stop the code under the right circumstance without an if this do that statement.

 

[Nightinggale]

Yeah, I don't always think to remove those things, I don't claim to be an expert coder just a hobbyist, so I have a lot to learn still.

Everybody makes code to test their code and everybody forget to remove it once in a while. Why do you think I look through the entire diff file before I commit?

Also why do you think there is a whole page on github about how to remove stuff, which shouldn't have been committed? It's because nobody is perfect. I like the reason for deleting a wrong commit "if you say committed your password in plain text".... how do you do that even by accident?

That's a good idea though.

It should likely be a define to set it to 0 or 1. The compiler will go "if (0)" and skip the check and everything in the {}. A variable will work too, but then the check is done at runtime. On the other hand if it's a variable, then you can add it to XML.

If its not technically right then what is? Using break points is helpful but you can't always stop the code under the right circumstance without an if this do that statement.

I should have chosen my words better. The computer is completely ok with it and you are right about how it helps you. The wrong part is that failed asserts mean the code contains a bug by definition. It's kind of like driving a car. We have defined rules saying you should drive on the right, which mean left is wrong. However the car is perfectly ok with driving on the left. It will not break down or anything if you do it. You only violate human made laws, not physical ones.
Yeah yeah some smartass will go "Australia drive on the left". They are land down under and do stuff mirrored

 

[Kailric]

Everybody makes code to test their code and everybody forget to remove it once in a while. Why do you think I look through the entire diff file before I commit?

Also why do you think there is a whole page on github about how to remove stuff, which shouldn't have been committed? It's because nobody is perfect. I like the reason for deleting a wrong commit "if you say committed your password in plain text".... how do you do that even by accident?


It should likely be a define to set it to 0 or 1. The compiler will go "if (0)" and skip the check and everything in the {}. A variable will work too, but then the check is done at runtime. On the other hand if it's a variable, then you can add it to XML.


I should have chosen my words better. The computer is completely ok with it and you are right about how it helps you. The wrong part is that failed asserts mean the code contains a bug by definition. It's kind of like driving a car. We have defined rules saying you should drive on the right, which mean left is wrong. However the car is perfectly ok with driving on the left. It will not break down or anything if you do it. You only violate human made laws, not physical ones.
Yeah yeah some smartass will go "Australia drive on the left". They are land down under and do stuff mirrored

I thought you was meaning that but wanted to be sure I wasn't missing something that could help me. Now, the only thing with making a global define is to remember to set it to 0 when I make my commit Or is there a way I can add a global that will only effect my version?

 

[Nightinggale]

Or is there a way I can add a global that will only effect my version?

There will be in the next version of the makefile.

 

[Nightinggale]

Or is there a way I can add a global that will only effect my version?

I just committed Makefile 2.2.
In addition to being better to search for boost and python it also adds Makefile.settings every time it builds or cleans (unless it's already present). In there you can overwrite the settings entered in the top of the Makefile without messing with a file, which is committed. You can also add your own CFLAGS and LDFLAGS.

You edit Makefile.settings to show this

CUSTOM_CFLAGS = [COLOR="Red"]-D[/COLOR][COLOR="Blue"]ENABLE_KAILRIC_AI_ASSERTS[/COLOR]

The black part tells that you set your CFLAGS. The red part tells you define something and the blue part tells what you define.

In a cpp file you can then write

#ifdef ENABLE_KAILRIC_AI_ASSERTS
[INDENT]FAssert();[/INDENT]
#endif

You can only have one CUSTOM_CFLAGS line, but you can add as many -D as you like if you separate them with space.

Just remember that while you will not commit Makefile.settings, you will commit the DLL you compile with those flags. I'm not sure if there is an easy way out of that, at least not right now. Maybe we should ignore CUSTOM_CFLAGS if some flag is set when compiling, We can then define that flag by making a new target in the project file. Actually now that I think about it, that would likely be the best option. I think I will make that now. I will only add this for Assert-fast as this is the only one we need this feature for. The list shouldn't get too long with stuff we will not use anyway.

EDIT: committed a new target to ignore CUSTOM_CFLAGS. This target is called Assert-upload. Just remember to switch to this one and rebuild. If you just build you risk reusing some of the compiled cpp files being reused, which mean the DLL will still have the asserts enabled.

 

[Kailric]

Hey, thanks for all that. I'll get that figured out soon.

Ok, I have a question for you. When you are debugging say in CvCity.pp, is there a way to get the attributes of that city. Like if you hover or LoopCity you can view that cities attributes, like it's X and Y coordinates. I stepped out until I found where LoopCity had called a function in CvCity.pp in this case but I was wondering if there is a way to do this without stepping out of the current code.