Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

@Toffer90

It seems that some special characters where messed up across all text files in revision 9679.

 

This sounds buggy and I'd need a save that shows it.

As DH said, some units with this ability are using a different method than others so yeah there may be a slight inconsistency there.

As Joseph explains, the plot and the city both maintain their own property levels and there is diffusion between both. If the city has more than the plot it's on and the plots around it, every round some of the crime in the city will leak over to those 'adjacent' plots. If the plots have more than the city, some will leak from the plots to the city. A crime producing unit will add both to the city and to the plot (criminals add much more to the city than to the plot - but of course they'll add to plots wherever they are, even if they aren't in a city, and Ruffians, as a rule, add a lot more to the plot than to a city, quite a bit to plots actually, enough that even if they are just hanging around outside an opponent city, they can poison the plots with a lot of crime that may leak into the city and challenge the city with crime.)

But what you read in the city display is a projection of final numbers for the next round. When you add say a -10 crime source, that source may actually bring -10 crime for a round but it's very unlikely. The final amount that -10 crime source actually brings depends on how much crime is already in the city (because the farther from 0 crime is, the more effective the sources that are trying to push it back to 0 - meaning if you have 1000 crime, a +10 source might actually be giving +5 while a -10 source is giving -15) etc. Then, too these sources also adjust the 'point of balance' that the values are trying to decay back to so if you have a +10 crime source, that 0 axis that decay is trying to push towards may actually be about 1 instead. I'm telling you I'm simplifying it to explain it here in the way I am. There are some threads around here where the formula is given mathematically but I'm trying to impress that these numbers do not work and tally and display like anything Civ has ever seen. They are designed to be organic and impossible to player audit in its entirety. But a positive source does push towards positive numbers and a negative source will push towards negative numbers.

Yeah, I figured this was the case because this is how it works for the game options. It made sense for me eventually here. I haven't had any trouble at all enforcing this rule for the game options and I'm happy to make sure it gets enforced for missions as well. The way I see it, once missions have been defined and worked with in modules or just in the xml alone for a while, they should eventually be adapted into the dll just to make sure we can more easily audit the two lists against each other now and then and make sure that the enumerations aren't going a little off somewhere. Adding some more self-regulating code could be helpful, yes, but if we all understand the simple rules involved here, it shouldn't be absolutely needed I don't think.

Testing showed that saves weren't broken when the enums were reordered to match the xml order. So I believe we DID do some remapping magic there.

You realize this is the kind of thing I still have to rely on guys like you and Koshling for right? lol... I'm still not that good yet.

So it's unnecessary - noted. But is there any downside to including them, as a rule? Are all those missions that are defined given this in the mission info? If they were, why were these lists setting up strings even here? Did someone add the ability to put them in the xml later or was that in place first and another reason emerged to link hard-coded strings to the missions in the DLL?

Yes, good point. This makes a huge difference in making debugging efforts easier.

EDIT: @alberts2: THAT is why we need you my friend! I would never have been able to get a bead on that bug report and was super hoping someone else would look into that one. Thank you!

 

dont know of this is intended or not, but the "so called" fishing boats have turned "Brown" for some reason, only thing i can think of is that an art changed some place, eventually they will change back, but looks really bad as brown, impo . .

 

That looks like someone saved those files as UTF-8 (that will make all characters that are not in 7-bit ASCII use two characters instead of one).

Did you reorder any missions that take up more than one turn and might be active in the save at that point or were any other reordered missions queued up in that save?

Nothing fancy, just hard coded checks that what you get from the map with the XML id values is the same as the enum values for each mission.

I assume it is just an ancient remnant from early in the development of Civ4.

 

Right, I thought I fixed all the times I messed up that (my notepad++ has a tendency to mess it up without me touching the encoding settings). I've spent so many hours fixing messed up encoding that I've caused that I'm close to a tipping point mentally about it. ^^

I'll look into that revision again, do you have any tips on how to fix it other than to compare it to the earlier version and copy paste one entry at a time?

 

I'm not sure. It was admittedly a pretty simple setup scenario. I'll have to keep an eye out for incompatibility factors cropping up now that it's been committed.

Fancy or not, I'm not really envisioning how or where that would be done. Also seems a little unnecessary in light of the rules to follow being pretty simple, and I feel there are much more immediately pressing things to focus on. I could put such a task on a project list and try to fit it into a priority sequence but if I did that it would quickly be buried into obscurity.

 

If the dll reads the XML names and parse them from string to int, I believe I could use the names directly to give them the correct number as the enums (or a higher, if there are more/different XML values from the enum names). While it should allow reordering and adding unique elements, I'm not sure if it's needed. Worse, I have no idea where will I need to plug this fix.
Implementing a rule of keeping both enum lists in sync like you intend to do should be just as good, though.

 

I'm at the same place with this. No idea where would be the most optimal place to position such a check. The load sequence is still something I haven't studied well enough to know where it should really go... and should it be in the load sequence at all or better at the beginning of an initialized game or even at loading a save? Perhaps best the last one so that if something has changed it gets realigned. I would know WHERE that would be but then the HOW to go about it is still syntax-wise something I'd really have to think through. I can't say I've ever fully understood how the code sets up some of this kind of thing to begin with.

 

I thought the city display for properties was the current value and in () the value of change since last turn.

The cost of putting in the predicted change made things too slow. Has this changed?

Didn't someone just redo some of the German translations so that they were better German? Wont that be lost?

 

If the messed up text maps uniquely to the correct umlauts, you can do a "replace all". From what I'm seeing in the example, it might be (like ü => ü).

Edit: Another (easier) possibility: Encoding -> convert to ... (in Notepad++)

 

Truth be told, I'm not sure which narrative is true and reading the code doesn't help me to figure that out much. It's one or the other. I don't really know which.

 

There are various ways to achieve this, with different assumptions/changes to code.
I think that in our case, we got the source cpp files close at hand. We could parse the enums from the file (treating it as a text file) for the enums as strings, and allocating them an integer (or the enum itself) in a hashmap.
When we convert an xml enum in the dll (assuming we get it as a string) we could directly get the correct value from the hash-map (this allows reordering). If it's not in the hashmap, we could assign it a new number or set it into a default number. The first option will help with debugging as we can see what is the number's key in the hashmap, while the second will allow us to keep working with the compiler's enums.
In general, I believe this solution should be very behind the scenes for everything but the xml->enum generation.
From what we've seen in the bug earlier, it's quite possible that the current code assumes both lists to be the same.

 

I'll make sure that any later change is preserved. (Edit: there was no later changes to preserve.)

I've tried that before, but never with success, seems to me like the original data was lost when the text issue was introduced. Maybe I'm just doing the convert wrong, I dunno.

 

Mind though that if you reorder missions, you also need to add a REMAPPED_CLASS_TYPE_ for missions and reference it at the right point of the savegame reading/writing.

 

Finally looked into this fully and I don't think there IS a problem here. The gold comes from the affected building, not the guild itself. It may not be displaying properly in the city list for that building and if not, that's a python screen setup issue not taking that into account. It is being added properly to the city according to the code. It sends the value to a player tally of influences on that building and wherever the building is the added gold is being given to the city total pre-modifiers. If the 'guild' building is removed, the player tally of influences on the noted buildings is removed and the cities are all updated to reflect that. If the building being benefited to add this much more is removed or added, it does check to see if there's a player level value for that and includes that in the update for the removal or addition of the benefited building.

I believe when cities are captured, all buildings process out for the player it was owned by and are then all processed in for the capturing player, therefore it would naturally also update this value then as well. I can't think of any way that it might not.

So if there's a bug here, it's on the python side in the building hover display in the city's building list... the building being benefited by the guild may not be showing the additional income thanks to the guild. However, I think, based on what I've seen here, that it SHOULD show on the construct button for that building in the city selection bar and on the hover help at least. We'd have to explore a bit to see where it may not be showing properly.

 

What era benefits are you referring to? I'm not sure exactly which tags you're talking about so I need more clarification.

 

For each era transition after the nasca lines is built the building get through python some boosts to random yields and/or commerces.

 

Ah... no wonder they are stored in such a manner that they are lost during a recalc. Makes perfect sense then. And really is unfixable unless we want to do a deep multi-disciplinary effort to correct it or I want to reprogram it completely into the dll. Might be interesting to do some day but as a quick fix, nothing's going to work. Well, no way I'm aware of anyhow.

 

Used C2C SVN rev.9831
I have no more interface
Why?

Please help

 

Folder name must be Caveman2Cosmos, place it in Beyond the Sword/Mods folder.
Do you have 3.19 version of BTS?
Make sure mod folder isn't nested.