The bad character encoding has been reported for the svn version ?
It's realy sad for non english player.
@Toffer90
It seems that some special characters where messed up across all text files in revision 9679.
The bad character encoding has been reported for the svn version ?
It's realy sad for non english player.
This sounds buggy and I'd need a save that shows it.3) Captive in an old city -> cannot boost (regardless of the "next turn" rule)
As DH said, some units with this ability are using a different method than others so yeah there may be a slight inconsistency there.4) Production merchant in a city -> can boost (regardless of the "next turn" rule)
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.)I was under the impression that there are two types of reduction, direct and from the plot. A building granting -100 disease should show -100 in the city viewer. On the other hand, -100 disease on the plot will, in some form, get a reduction in the city.
If that's not the case, it's extremely unclear. Most buildings such as the LE buildings did seem to grant the correct -property immediately.
Is it possible that the said buildings grants the effect to the plot instead of the city, thus indirectly affecting it?
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.In general what is in the enum needs to be at the start of the XML in the same order while the opposite is not true. You can have mission infos in the XML that are not in the enum as long as they are after the last enum XML entry.
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.Koshling suggested there to add missions to the enum remapping but I think that was never done so reordering missions will break savegames that have ongoing missions of those types.
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.You might want to add code that verifies that all enum entries have the same IDs in the XML.
Having strings for those missions in the DLL makes little sense as you have the mission info in the XML for that.
The strings for the chipotle cheat should be pulled from the mission info, not hard-coded into the DLL, then it will work for any mission.
But yes, debugging is a reason to add them to the enum.
Yes, good point. This makes a huge difference in making debugging efforts easier.An upside is that dll debugging will report what mission was running using the mission name instead of numbers for all the missions.
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).@Toffer90
It seems that some special characters where messed up across all text files in revision 9679.
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?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.
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.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.
I assume it is just an ancient remnant from early in the development of Civ4.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?
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. ^^It seems that some special characters where messed up across all text files in revision 9679.
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.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?
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.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.
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.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.
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.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 thought the city display for properties was the current value and in () the value of change since last turn.But what you read in the city display is a projection of final numbers for the next round.
Didn't someone just redo some of the German translations so that they were better German? Wont that be lost?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?
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 ü => ü).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?
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.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?
There are various ways to achieve this, with different assumptions/changes to code.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'll make sure that any later change is preserved. (Edit: there was no later changes to preserve.)Didn't someone just redo some of the German translations so that they were better German? Wont that be lost?
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.Edit: Another (easier) possibility: Encoding -> convert to ... (in Notepad++)
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.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.
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.It's unclear if guilds really give gold as intended. From my understanding, each guild should give +5 gold for each building of that type, in the city the building is built. However, I don't seem to get the gold in the city, so I'm wondering how it works.
What era benefits are you referring to? I'm not sure exactly which tags you're talking about so I need more clarification.I built Nazca Lines world wonder in Kyoto. All era benefits are lost when I do a recalculation.
For each era transition after the nasca lines is built the building get through python some boosts to random yields and/or commerces.What era benefits are you referring to? I'm not sure exactly which tags you're talking about so I need more clarification.
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.For each era transition after the nasca lines is built the building get through python some boosts to random yields and/or commerces.
Folder name must be Caveman2Cosmos, place it in Beyond the Sword/Mods folder.Used C2C SVN rev.9831
I have no more interface
Why?
Please help