CiVUP - CiV Unofficial Patch

[Thalassicus]

Civilization V Unofficial Patch (CiVUP)

I believe things should be intuitive to use. Civup improves this for the Civ 5 interface. It adds more useful information for players, and greatly expands tools for modders. There are as few "gameplay" changes as possible. Civup follows the footsteps of unofficial patches like Civ 4 BTS Unaltered Gameplay and the Skyrim Unofficial Patch.

This is part of the Civ V: Communitas Expansion Pack. Communitas is a collaboration of work from 26 mod authors and an incredible community of forumgoers on CivFanatics.com.

Spoiler for Feature Overview:

News - Features - Discuss - Bugs - Credits

[mattpilot]

I don't know what i would do without your mods. Simply amazing work. All your changes should of been in the vanilla version!

Oh and thanks for updating your combined file all the time <3

[ByblosHex]

You know, I never even thought about building units just to disband them for money generation. :P

[Thalassicus]

Yeah, it's rather broken in the vanilla game... better than Wealth yet totally inobvious and tedious.

[Drawmeus]

Originally Posted by Thalassicus

Yeah, it's rather broken in the vanilla game... better than Wealth yet totally inobvious and tedious.

Speaking as a game dev (nothing to do with Firaxis or Civ-anything), this is totally the kind of issue that designers would miss, just assuming that it wasn't broken in so obvious a way. QA should have caught it, for sure, but it doesn't necessarily say that balance testing wasn't completed. It's a clear bug, not something that their balance guys would really be looking out for.

Their fault either way, but I don't think it's necessarily indicative of a larger problem.

[Thalassicus]

You've got a point, even with 100% coverage and extensive balance testing you can't find everything. I agree with you entirely, can't always make assumptions about what the project lifecycle was like. I was admittedly being too cynical in my post.

I think the main problem is the current methodology of software development. Object-oriented design is thankfully, finally replacing function-oriented design (and very popular in the game industry), but it's still lacking in many areas. Requirements are often poorly done or overlooked, a major source of project failure in a lot of situations I've been involved in. It also can often overlook critical domain issues, great example being the questionable Patriot missile system deployment two decades back - got all the functionality right, but didn't properly account for domain issues regarding human operators. The problem with OO or function-oriented development is it can get bogged down in the details and overlook the big picture. I feel the emerging methods of goal- or agent-oriented design could help with this somewhat.

One example of this in CiV is how gold maintenance costs seem logical from a low-level gameplay perspective, yet in a broader sense limit player choice (passive drain on gold, which can be used for much more decision-making now in V) and maintenance feels like it's penalizing the player after spending all that time building something.

There's always something to be said for outside perspectives, too. Even some testers directly involved in the dev and testing process, like Valkrionn, still feel the game could use some adjustment.

Another issue is how the majority of fault localization techniques rely on a single-fault assumption. Encounter a bug, balance issue or something else you might think is broken, go look for the likely cause. It assumes a one-to-one relationship. I've been involved in research using clustering techniques for multiple-fault localization, many-to-many situations in programs to hopefully alleviate this some day and provide more automated tools. I'll admit that even I'm using a single fault ad hoc approach for Civ V right now, whack-a-mole style, yet broader or semi-automated approaches typically have to be built in through each iteration of the whole development cycle though.

This is basically what I think the problem is - yes, they had unit testing and balance testing done, but those sorts of things can get too focused on small issues and narrow scopes, and overlook integration and how things work together on a larger scale. I know they likely did plenty of integration testing too in this regard. Still, there's always room for improvement, and I've just been trying to improve the 1% of the game I feel is still "not quite there" yet, little things here and there.

I'm not sure any of this make sense... somewhat caught me rambling there! Well, off my break so back to work.

[Ganja]

I dont see this available on the mod browser, all the others are there.

[Thalassicus]

Yes, sorry about that, realized it as I was heading to sleep yesterday. It was when I was attempting to upload this mod that I ran into the critical ModBuddy issue described here:

http://forums.civfanatics.com/showpo...5&postcount=65

I've uploaded Balance - Fixes to the browser now through my workaround solution.

[Lazy Knight]

The Tooltip for the Monastery is strange and IMO deserves fixing:

It currently sais something like:

+3, adds +2 from Incense and +2 from Wine

where it should be +2 from Wine


Minor thing but it bugs me.

[Tyrael]

Disabling certain promotions fixes the superunit problem but disables desirable and functional aspects of ruins. Maybe a more elegant fix would to give each unit a "upgrade flag" of some sort, where after a unit gets an upgrade its upgrade flag goes up. While the flag is up the unit cannot get an upgrade from ruins. After X turns (50 on normal maybe?) the flag goes down and the unit can upgrade again. This allows upgrade chains, but only over a certain period of time. This way we won't get broken chains of upgrades, but can still upgrade normally as the game was originally designed.

The monastery thing where it doesn't show the purple symbol bugs me too, it's inconsistent.

[Thalassicus]

I'll fix the monastery thing, thank you for pointing that out.

I agree some waiting time would be optimal, yet some of these upgrades were problematic on their own too, especially when you compare them to the other ruins rewards (map reveal, barbarian camps, 30 etc). If you go from an Archer to a Crossbowman (or worse a Cho-ko-nu) while still in the early ancient era, that's a dramatic jump in power for a game that focuses on fewer military units. That single ancient ruin could let you kill 1 civ before tech levels can equalize, since most will have only one city, or at the very least choke the civ's development. It's arguably even more powerful than the free tech reward.

The upgrades to Riflemen are even more of a leap. It could upgrade to Muskemen instead, but that would still be overpowered for civs like the Ottomans, who could go from a Civil-Service slingshot newly-built Pikeman to a Janissary in just the first 60-80 turns with a little luck.

Some of these upgrades are not as bad of course, but this was part of the motivation. It was also much simpler to implement. A limit on #upgrades over a duration of time would require lua coding and so on, or (much easier once we can do so) an edit to the c++.

[spiffamoo]

Just wanted to thank you for the great work, Thalassicus! Thoughtful balance changes throughout. Will be following your mods throughout!

[Lazy Knight]

Angkor Wat: Reduces cost of acquiring new tiles by 75% in every city.

This propably works as intended, but not as described: It only applies to the city it is built in.

[nightbringerggz]

I was wondering if you had considered further tweaks to ancient ruins. I like the way they add a bit of randomness to the early game, but I think many of the bonuses are just too powerful. The upgraded units problem was one, but free techs can be just as problematic with the slimmer tech-trees.

Personally, I would prefer the bonuses to be more along the lines of a fixed amount of extra research points over a free tech (scaled with game speed), 10 XP to a unit, instead of an instant upgrade and so on.

[Thalassicus]

I agree with you, made this particular change since it was so simple and obvious. I'll see what I can do, though might take a while.

[nightbringerggz]

Ya, I just met Bismark's new Spearmen and Scout Archer (which are insanely OP if used correctly). He was kind enough to offer me a treaty of Open Borders. And it's turn 22 (Marathon speed).

Heh, I'm not sure how much scripting Civ games allow, as I've never modded one before (stuck to Bioware & Bethesda games for that). So long as it allows a bit though, I think I'm going to give replacing the Free Tech bonus a try this weekend.

[The_J]

Nice to see such a work done .

Edit: Do you look at the bug list? Some things like issues with Macchu Picchu and the opera house should be easy to fix.

[Porges]

I think you messed up the monastery text a bit, it no longer mentions the +3 bonus.

[player1 fanatic]

You could put fixes to minuteman and helicopter movement here.

Since Helicopter currently moves like scout (both ignores terrain and uses roads), while Minutemen ignores any terrain (including roads).

[Thalassicus]

@The_J
I read through the list, most of the bugs unfortunately require C++ access. I'll fix Macchu Picchu... what's the problem with Opera Houses?

@Porges
The standard way buildings display base culture is on the primary building information. There's no need to include it on the tooltip too, like the Monastery had, as that just duplicates information. The overall format is now consistent with other cultural buildings, and the tooltip matches the format of the Mint.




@player1 fanatic
I'm not entirely certain whether that issue is a bug or intended. Precedent from earlier versions of Civ does seem to indicate the promotions should be switched, but how can we know for certain that's what the developers intend for V? Though the promotions are ambiguous and it's easy to see how a developer could accidentally use the wrong ones. There's the question of the color formats of each promotion correctly matching the unit domains...

I'll switch them and add it, though, since it does seem logical the ground unit can use roads, and the air unit cannot.