Unaltered Gameplay Mantra

They will be able to put BULL into their Program Files Assets folder to be used with BUG, just as they can now with the UP.
oh - good point - I keep forgetting that because it is something that I just wouldn't do ... too many PBEMs going that would force me to keep swapping DLLs.
 
Sounds like you need a Civ4 DLL Switcher utility. :mischief:
funny you say that but ... I did have one. I lost it somewhere along the way. It was only tiny so I could re-write it.

BTW: solver isn't gone - he is at WePlayCiv.
 
I still don't understand how the River Tile over desert becoming floodplains fix is almost UG, and thus acceptable, but fixing the AI's calculation of rival closeness is not. If one of these is UG, and thus untenable for a strict UG build, the other must be as well... At least my little mind can't tell the difference here. In fact I find the AI closeness bug more of an obvious dev oversight....
 
I still don't understand how the River Tile over desert becoming floodplains fix is almost UG, and thus acceptable, but fixing the AI's calculation of rival closeness is not. If one of these is UG, and thus untenable for a strict UG build, the other must be as well... At least my little mind can't tell the difference here. In fact I find the AI closeness bug more of an obvious dev oversight....
I don't think it is clear either. However, the map start tweak (ie floodplains) is a once only at start of game fix. Players might tweak it themselves via the WB. The 'closeness' is on going and every turn so it is much bigger.
 
Roland - you keep saying that and everytime you do, I reply that the plan is to have 1 single option that will enable / disable the UP if we can do it. Not 1 option per individual UP item ... 1 global option that will turn ALL of the UP either on or off.

And all of this assumes that we can actually put in such a switch.

Yes, in the other discussion, your view of the future BULL was very clear. However, when I read Emperorfools posts, then he seems to be going for a somewhat less clear division with various options configurable. I could of course be misreading his intentions. I'll quote him here so that you can see why I was interpreting things slightly different; his last post in the other thread:

I already have code working that calls out to BUG's Python code from the DLL to check which options are enabled. For UI features, this is fine. However, some of the UP changes will be executed frequently while the AIs take their turns. I don't want to negatively impact performance, but I have a work-around for this as well.

In short, it won't be difficult to have each feature of the UP be optional, except for one. ...

and his long post in this thread, post 72 where he splits up the UP in several sections. It really sounded like he wanted to use the most UG parts of the UP and leave out the rest of the UP or make it optional.

So sorry if it's not all clear to me, but you two are not saying exactly the same. Of course, you could be meaning to say exactly the same and I'm just interpreting it differently.

At least, it was not my goal to antagonise you as seems to have happened.
 
So sorry if it's not all clear to me, but you two are not saying exactly the same. Of course, you could be meaning to say exactly the same and I'm just interpreting it differently.
EF and I never say the same thing - that is why we get on so well :D. EF is the coder of the DLL, so if he wants to get really micro - more power to him. My stance is to take the path of least resistance and / or just do what I like which often leads to 'the user can go hang - they will like what they get or ...'.

At least, it was not my goal to antagonise you as seems to have happened.
Sorry Roland if you got that impression - just ignore me somethings :D.
 
None of my rantings here should be taken as 100% gospel "I believe this to be right and you are all wrong" statements. My opinion changes as new facts come to light as I'm sure most people's do. I first thought the UP was only straight-up bug fixes where you can see in the code that clearly X was meant by Y happened. I also thought it involved fewer changes.

Now that I've begun going through more of the DLL code, I am finding there is a definite gradation in the intent of the changes. My goal is to a) reduce the amount of work for me, b) reduce the options overload for users, and c) produce a good product in a timely manner. These three things are often at odds with each other.

When I said that each UP feature could be optional, I didn't mean to imply that each one would get their own option. That is of course possible, but it's more work for everyone, including the player, with arguably little gain. What I'm hoping to do with this line of questioning above is to categorize the changes so that I can pick some to make mandatory, some collectively optional, and others individually optional.

But as I looked at more of the changes, I have come to feel that some are more UG than others. Yes, this is a gray area. Why do I think the map-generation fixes are more UG than the gold overflow (the closeness fix isn't the best example, but it's the same)? First, anyone can write their own map script; are these anti-UG? I don't think so. Like Ruff said, one is about gameplay rules and the other is about how maps are set up. Is running MapFinder to get a start with 3 Gems anti-UG?

Whereas changing the rules of gold overflow or AI war declaration, these will definitely alter gameplay: how the game plays out will be altered. Yes, altering the rules of how rivers are added to start locations will affect the game, but not in the same way. How you play the game and what rules apply don't take effect on every turn. It's splitting hairs as I said.

I don't think any one change is more "correct" than any other. I'm just working toward some agreement so when I make the decision before release, it's not completely arbitrary.
 
EF and I never say the same thing - that is why we get on so well :D. EF is the coder of the DLL, so if he wants to get really micro - more power to him. My stance is to take the path of least resistance and / or just do what I like which often leads to 'the user can go hang - they will like what they get or ...'.

Sorry Roland if you got that impression - just ignore me somethings :D.

Good to hear that it was just a misunderstanding. :) I do sometimes argue about stuff, but I mean the arguments to be constructive.

What I'm hoping to do with this line of questioning above is to categorize the changes so that I can pick some to make mandatory, some collectively optional, and others individually optional.

Ok, then I do think that I had interpreted your intentions somewhat correct. Some players might react a bit alarmed at your earlier post because they might think that you're removing the option to have the full UP while that does not seem to be your intention. It is one of the various options.

r_rolo1 mentioned that the changes to the production to gold conversion of hammer overflow is one of the less accepted changes of the UP. I don't know whether he is right, but if he is, then that could be a candidate for optional inclusion. I do remember significant discussion about the changes to collateral damage and that's probably harder to make fully optional as it includes DLL and xml changes. But the length of the discussion is probably not the best indicator as a small minority can already be extremely vocal.

On the other hand, whether the AI is capable of recognizing that 'changing its civics during a golden age is better than another time' is probably not going to rise a lot of discussion. Yes, the AI plays a bit better and thus it changes gameplay a tiny bit, but most people just won't care either way. Players typically care most about changes that effect their own gameplay fairly directly.

So if you want to limit the number of optional UP additions, then I would suggest that you look at making those UP effects optional that limit player options or limit some exploits. Those are most likely to cause dissent when they're not optional. You could group these together and make them optional as a group or individually optional.
 
Some players might react a bit alarmed at your earlier post because they might think that you're removing the option to have the full UP while that does not seem to be your intention.

This is probably the source of the confusion. It is not my intention to block the inclusion of any of the UP changes. The issue is that to maintain hardline UG I will likely need to make a non-UP version. I thought originally that most of the UP stuff was just bug fixes without rule changes. I was going to release a UP+BULL first and then make a non-UP version available.

One thing to keep in mind (which I hadn't actually been doing lately) is that the UG is about us not adding spells or new units or buildings or traits. How you play the game is unaltered--not coding errors. Some of the UP fixes are very clearly bug fixes when you look at the code. Some are more dependent on the author's reading the coders' minds.

For example, the espionage spread culture mission description doesn't match the code. This is an easy fix.

When the map script puts a river next to a desert, it becomes a flood plain. However, when rivers are added to improve a crappy starting location, the same code isn't used so this part is bypassed. It seems pretty clear that it was intended, but you can't know for sure.

Not having some production multipliers apply to overflow gold is a little tougher. Those multipliers don't apply when building wealth, but overflow from production isn't based on building wealth. It's a mechanism to avoid building up a bunch of overflow :hammers: that can be instantly applied to a newly available item upon researching a tech. There's no clear rule here--it's an attempt to fix an exploit. The UP change is an attempt to fix the exploit it opened up.
 
And to say the truth, the UP solution to the overflow gold issue is far from consensual or even being a majority position in some player circles ( like in CFC , where even now it is happening again a heated discussion of the feature, again because of the Pro walls in a thread about how to "fix" Saladin...... :/ People there seem to think that whipping walls to get cash is a part of the Pro trait :( ). I am not oposed to Dresden solution per se ( in spite of this being a issue , like EF hinted, where the fix will never be consensual unless it cames from the original programmer ), but there is a good group of people that does not think that way. My issue there is that BUG does not need to ( and in fact IMHO shouldn't ) enter in that kind of wars and acepting the UP as a bulk is taking a side in there :(

This , unfortunately spills to other sides of the UP, as everything is subject to interpetation. For a example, when the description of a game feauture doesn't match what the code does, what does need correction: the description, the code or both? if you see the more heated discussions on possible UP features, the more discussed were situations where it is not clear what is more right: the description or the code ( the missionary gift to theo civs, related to the bad wordiing describing the civic ( atleast compared to what the code really does ) and the patrol function ( aka can of worms ) ). Most of the other features of the patch , fortunately are clear bug fixes, but not all ( like in the forest code in start BFC beautifying, that had his share of discussion in Bh patch thread, with 3 or 4 alternative code fixes sugestions, all with diferent philosophies behind )

Unfortunately, making all features disable-able ( :D ) would be extremely taxing for the game performance, so a compromise has to be acheived.....
 
UP is not unaltered gameplay. However, there is something to be said about improving the quality of the game experience via AI/bug fixes, even if they do alter gameplay.

With that said, since I have not gotten any reply on the UP forum, would you be interested in the code to make fractional trades count? That is, if you have 4 trades at 1 commerce each with a +75% modifier, this code would give the proper +7 commerce instead of the only +4 commerce. I developed the code for a FFH style mod, but it will work in the base game.
 
Would you be interested in the code to make fractional trades count? That is, if you have 4 trades at 1 commerce each with a +75% modifier, this code would give the proper +7 commerce instead of the only +4 commerce.

That would require changing getTradeRouteYield() to be getTradeRouteYieldTimes100(), adjusting every call to it to divide the sum by 100, and change the Python that uses it as well. Perhaps that's something to consider in a future version. It definitely aligns with the changes made in BTS (or was that Warlords that added fractional commerce values to cities?).
 
UP is not unaltered gameplay. However, there is something to be said about improving the quality of the game experience via AI/bug fixes, even if they do alter gameplay.

With that said, since I have not gotten any reply on the UP forum, would you be interested in the code to make fractional trades count? That is, if you have 4 trades at 1 commerce each with a +75% modifier, this code would give the proper +7 commerce instead of the only +4 commerce. I developed the code for a FFH style mod, but it will work in the base game.

Since the BetterAI Mod and the Unofficial Patch Mod had a period where they influenced each other and used each others game improvements, the BetterAI Mod might also be interested in that code. A pity that the UP is not being developed anymore as this sounds like something that would have been integrated even if it is not UG.
 
That would require changing getTradeRouteYield() to be getTradeRouteYieldTimes100(), adjusting every call to it to divide the sum by 100, and change the Python that uses it as well. Perhaps that's something to consider in a future version. It definitely aligns with the changes made in BTS (or was that Warlords that added fractional commerce values to cities?).

I actually created a separate function called that and made the proper references in CvCity, Cycity, the maininterface python file, cycityinterface, etc... And even added a text key so the tooltips will show the amount of trade generated with the decimals.

To accomodate the BUG changes it probably would be best to change all references of GetTradeRouteYield to the times100 variation for any interface enhancements where the function is called. And the total yield could also be a decimal, to account for other cases where the value gets multiplied (like converting to, say, 80% commerce for research, and then the +25% bonus for a library, etc).

So my changes might not go far enough!
 
Well, since I play with better AI, I'd rather see the BULL be BetterAI then strict UG, otherwise I'll have to stick with regular BUG, but I want the BULL!!!
 
I'm still hoping someone will step up to produce a merge of BULL + BAI. I think the files they each change are fairly disjoint, making a merge a little easier.
 
Well, since I play with better AI, I'd rather see the BULL be BetterAI then strict UG, otherwise I'll have to stick with regular BUG, but I want the BULL!!!

I tend to agree. I doubt my opinion carries much weight, as I am far from a well-known player, but I favor a more nebulous definition of "Unaltered Gameplay" than many here.

Perhaps the BAG idea expressed earlier in the thread is the way to go. Just as BUG rides very close the the edge of unaltered, BAG could be a very conservative mod that only crossed the line in very specific places. Most of these issues could be solved this way, but poor EF would have to do the work.

At the end of the day it is up to him, but I would love to see a BAG mod. An editable INI file letting you choose how BAGGY you wanted to go would be more than adequate user control.
 
These are difficult issues... So I'll just to throw my insignificant little opinion into the mix.

I'd like to use BUG with better AI, because although BAI does alter the game, it doesn't alter the rules of the game.

I would not like to see any kind of info related to WFYABTA, or hidden relations, because this information is not available in a normal game and I think that a little bit of mystery can improve the gameplay. As a rule of thumb for that kind of stuff I'd say that if a non forum-reading player wouldn't know how to find certain information then BUG shouldn't provide that information. I'd even suggest that BUG should not keep a tally of how many techs you have traded, because that could lead a non forum player to wonder "why is this information important?" and thus risk spoiling the mystery.

I think that there are already some "grey area" features in BUG, such as the more detailed combat odds and the culture victory countdown on the victory conditions screen. This is information that is not available anywhere in a non-BUG game - but can be gained by doing some calculations. In the case of the combat odds, I don't even have the knowledge required to do the calculations myself (because I don't know the details of how combat works); to me, this seems to be on a par with hidden relations information. -- I wouldn't have put either of these features into BUG if I was in charge, but it isn't a big deal for me.

As for the unofficial patch... that's a grey area for me. I learn towards having it included, because there are some good bug-fixes - but on the other hand, some of the 'fixes' are a bit controversial and so maybe the unmodified gameplay ideal should just rule that patch out completely.

Ideally, BUG, BAI, and UP would each be installed individually and somehow be compatible with one another in any combination... but obviously there are technical problems with that ideal.
 
@karadoc - thx for your comments. We try to keep BUG as unaltered as we can. You mentioned a few areas where we haven't (strictly speaking). I don't think that we have discussed the ACOs but we certainly did with the cultural count-down ... the clincher for that was when someone pointed out that you could work out the number of turns by just looking at F8 from turn to turn and a little high school maths.

Regarding your 'non forum reading player' rule of thumb - that is interesting ... but are there that many non forum reading players that use BUG ... a mod that is only available via a forum. Please post here if you are a non forum reading player and give us your opinion.
Spoiler :
:lol: :D
 
Top Bottom