Requests for new components (and features)

The thing about whipping is that it doesn't cost you anything from unhappiness if you have the happy buffer to use it. Consider a city size 7 or 8 and you are in the middle ages. Typically, your happy cap will be in the order of 13 to 17. At this point, you can whip, whip and whip your size 8 city 3 turns in a row and not even feel the whip anger. Sure, you just killed of a number of citizens, but you anger now reads ...

6 anger, 15 happiness

So, there is totally no need to wait for the whip anger to wear off in these situations.

However, if you are at the happy cap, whip then whip is a bad idea. Much better to whip once and kill off multiple citizens so that the anger wears off as you grow back.

Gee I hope no one other than a civ player reads this thread ... "Much better to whip once and kill off multiple citizens..."
 
Excellent idea. I've already added the overflow :hammers: and :gold:, and this would make a great complement to them. How are these for wording?

  • +100% cost for new build
  • +200% cost for Oxford University
  • -33% cost from Buildings [Kremlin]
I don't really like the first one, and I'm not sold on "cost". I'll have to look in the SDK to see the game mechanics. Perhaps I should add the full calculation of the cost to the hover since the production modifier also affects the cost.

Edit: Wow, the hurry cost penalties are multiplicative! The above could be misleading, though I think prettier. Should I switch to these:

  • x 200% cost for new build
  • x 300% cost for Oxford University
  • x 67% cost from Buildings [Kremlin]
Drop the "x"?

In the espionage list, you can also see the various modifiers to cost. These are almost all multiplicative (except the ones caused by religious bonuses) however, they're all mentioned with +x% and -y% signs which makes it seem as if they're additive. So I would really like to see the multiplyer signs here so that it is clear for the player.

You could also use decimal multiplyers:
x 1.5 cost for new build
x 0.67 cost from Buildings [Kremlin]

etc.

It's actually weird to multiply a value with a percentage. As a mathematician it really annoys me, but I see it at more places in the game, so I have learned to suppress that feeling. ;)

Hehe, and I was editing mine while you posted. ;)

We're both thinking while we're writing.

First, note that I'll use the correct constants variables when I actually do it. These are just samples. Hurrying a new item is governed by NEW_HURRY_MODIFIER which you say is 50. I never hurry a new item, so I was just guessing. :p

Oh and here I thought you just really didn't know what you were doing. ;);)

I was just providing you with the values, but you will of course take them from the variables that define them so that it works well with mods.

While the base :hammers:/population is constant (based on gamespeed), once you add in production modifiers the :hammers: you get varies based on the number of population due to rounding. This is always annoying.

I would prefer a decimal number with 2 decimal value.

Example: Pop/gold rushing a normal building at epic speed while having a forge. The building is at 50/120 :hammers:.

At epic speed, you get 45 :hammers: for each pop point. The forge gives you a 25% bonus (or a multiplyer of 1.25 ;) ).

I'd want the following information:

costs 2 population, 112 hammers

hover info: efficiency 56,25 :hammers: per pop

costs 210 gold

hover info: efficiency 1 :hammers: per 3 :gold:

In this case, there are no penalties, so I would just leave them out. You could choose to show the hammer bonus from the forge in the first hover. That bonus is also clearly visible in the actual production calculation before the construction bar after you've applied the whip.


This dovetails into my original plan long ago (year and a half?) of having a bar that would show the various population points so you could reach a threshold without going over. Yes, I could show how many :hammers: you'll get whipping now, but I also want to see how many :hammers: I'll get for 1 less population so I know how many more I can add before whipping to maximize overflow.

You could indeed show the hammer output for different numbers of population whipped. It could then become a long hover, especially for world wonders. Maybe limit the hover info to: current pop number (the number that would be used now) hammer yield, current pop number -1 hammer yield, current pop number -2 hammer yield.
If you can't whip because of a shortage of population:
maximum pop number (the maximum allowed number of citizens that you may whip) +1 hammer yield, maximum pop number hammer yield, maximum pop number -1 hammer yield.

So if you're hovering over the pop rush button while building the colossus and you don't have enough population to finish the rush (say size 9 city, max pop rush size = 4), you could still get something like:
efficiency 33,75 :hammers: per pop
168 :hammers: for 5 pop
135 :hammers: for 4 pop
101 :hammers: for 3 pop
warning: x 2.00 cost for rushing the Colossus

(using a times 2 cost modifier for rushing the colossus and a times 2,25 production modifier for copper and a forge and a base of 30 :hammers: per pop at normal game speed. I didn't look up the cost modifier for rushing the Colossus, could well be 2,5 or 3.)
 
have an option in the BUG menu to set whip anger count notification.

"Paris whip anger now at 2"

How 'bout a notification when whipping doesn't cause unhappiness, to reduce micromanagement? (when whipping doesn't cause unhappiness to become bigger than the happiness)

I think this would help "players like me" in a lot of cases. I don't know, maybe you more experienced players find this unappealing. I just don't like to flip through all my cities every turn that I'm in slavery. I think it would be a useful option for players who like slavery, but not all the micromanagement involved with it. Setting lots of manual alerts is a big no-no for me...

Maybe this isn't even possible or too hard to do, so if that's the case you can just ignore my ramblings :)
 
Another vote for the x in the costs/penalties/bonuses for whipping. So many things are additive by default that I would like the explicit reminder where it isn't.
 
I was wondering if there would be any way to get just the dotmapping tool out of the BUG mod. I'd love everything else, but my computer simply cannot handle it. I can turn a bunch of stuff off in Options, but that doesn't seem to change the speed the game runs at using BUG. I was wondering if it was possible to simply get the dotmapping without the rest of the mod draining my resources.

Thanks a ton. If this is unreasonable, I understand. The game's original strategy layer option is doodoo though.
 
I'd love everything else, but my computer simply cannot handle it.

I did some testing, and I found that the major slowdown with BUG is the extra stuff we added to the plot list icons (the units in your stack). Go to the options screen, select the Plot List tab, and uncheck some of these:

  • Move Bar
  • Upgrade Indicator
  • Promotion Indicator
  • Mission Tag
And see if that helps. The only other feature that you might notice is Autolog. Everything else should have nearly zero speed impact. You're running BUG right, not BAT? BAT has a ton of extra graphics that could tax your video card's memory and memory bus.

Edit: Oops, I didn't answer your original question. I'm extremely swamped right now, but I promise to take a look at how hard it would be. BUG is fairly complex: all the mods sit atop a custom framework that makes building the mods easier. The downside to this is that pulling out individual features requires rebuilding the framework services they need.
 
@dirtyparrot - Please post that to the Feature Request tracker (SF.net in my sig). I've got a lot on my plate and it'll be a while before I could tackle it. Do you envision that thread being turned into a strategy article in the Sevopedia?
 
It would require an extreme amount of work to generate text from the XML. All the CP/SP do is pull the text from the hovers for units, buildings, traits, etc. There are no hovers for events, so we'd have to build all that ourselves. I can say without a doubt that's not something I want to do.

Now, if someone produces a strategy article from that themselves, I'm keen to put it into Sevopedia as Alerum did for many other strategy articles. It was a lot of work, but not prohibitive.
 
Hey EF, thanks for the help. It runs much smoother when I took out those Plot Indicators. Thanks a ton.
How bit is the stack you are looking at? Can you send (or upload) a save that we can test?

@EF - have we put in that suggestion of yours re internal array to track what is shown / not shown yet? I think I have the ability to do that.
 
@EF - have we put in that suggestion of yours re internal array to track what is shown / not shown yet? I think I have the ability to do that.

No, I haven't done that yet. It would be a welcome addition no doubt, especially when selecting units in really large stacks.
 
No, I haven't done that yet. It would be a welcome addition no doubt, especially when selecting units in really large stacks.
Ok - let me dig up the PLE thread and see if I can find your suggestion (do you have it handy?). I'll post it and then whiteboard how I see the code looking. Then you can laugh, and offer a better suggestion.
 
Hehe, I'll just say it won't be trivial and will be complicated by the . . . intriguing . . . coding of PLE. :mischief: The basic idea was to create a data structure to contain the visual style of each unit. The code already builds a data structure of some data to allow it to sort the units. This would be similar.

Then you compare the structures you are about to draw to those that you previously drew and update the graphical elements with only the differences. I highly recommend creating a simple class in a new PLE module (Contrib/PlotList.py? or add it to BUG/UnitUtil.py?) to hold the data instead of packing it into a list.

Code:
class PlotList:
	def __init__(self, pUnit):
		self.bSelected = ...
		self.eUnit = pUnit.getUnitType()
		self.iDamage = pUnit.getDamage()
		self.iMovesLeft = pUnit.movesLeft()
		self.iMoves = pUnit.getMoves()
		self.bPromo = ...
		self.bGG = ...
		self.bUpgrade = ...
		self.iMission = ...

You can pull all the code to assign values to those fields from PLE itself. The only tricky one is the mission tag. I don't remember if I have created the set of constants for them (orders and missions) yet or not. See BUG/OrderUtil.

Then the draw code will just compare the previous to current PlotList object field-by-field and only change the visual elements where the values are different. For example,

Code:
if prev.bSelected != new.bSelected:
	screen.setState(szUnitIcon, new.bSelected)

You will need to handle the cases where a cell in the grid didn't have a unit and does now and vice versa. You could make this easier by creating functions to draw each individual element.

Code:
if prev is None:
	if new is not None:
		# draw all visual elements using new
		screen.setImageButton(szUnitIcon, getUnitIcon(new.eUnitType))
		...
	else:
		# no unit in both views, nothing to do
		pass
elif new is None:
	# hide all visual elements
	screen.hide(szUnitIcon)
	...
else:
	# test each field in prev to new, drawing the differences
	if prev.bSelected != new.bSelected:
		screen.setState(szUnitIcon, new.bSelected)
	...

Don't forget to remove the code that hides everything before drawing as the point is to only hide/show when necessary.

Hmm, now that I think about it, perhaps an easier pattern is this:

Code:
if new is None:
	if prev is not None:
		# hide all elements
else:
	# change all different elements
	if prev is None or prev.bSelected != new.bSelected:
		screen.setState(szUnitIcon, new.bSelected)
	...
	if prev is None:
		# show elements
		screen.show(szUnitIcon)

Note that some elements are strictly handled by showing/hiding them (upgade and promo indicators), and some may be hidden sometimes (mission tag).

Oh, you also need to deal with the case of options changing. I recommend creating a reset() function that redraws the entire plot list ignoring the previous entries. You can call this function in an onChange handler for most of the PLE options.

Edit: Honestly, this is the type of comprehensive feature that would convince me to rewrite the whole plot list code to integrate PLE with the old style as far as drawing goes. I would keep both types of behavior and visual style, but merge the code that handles the redrawing so that both types are sped up by this change.

You would need a few major function breakdowns:

  • Sorting units. PLE: filters and sorting. Standard: just sorting
  • Placing units into cells. For PLE, apply view mode. Standard, only mode is multiline. This step creates the PlotList objects above.
  • Draw. This code can be mostly uniform since the Standard vs. PLE style differences are applied when placing the original controls (health bar below).
I would also move all this code to a new module. That would be totally freaking awesome. :D
[*]
 
I've seen EF mention this is other threads, but what is BULL?
 
I've seen EF mention this is other threads, but what is BULL?

BULL is the as-yet-unreleased-with-an-installer BUG DLL. You can grab the assets and DLL from the SVN if you're brave.

Note: The version posted is not 3.19 compatible yet. I'll updated it tonight or this weekend.
 
counter-espionage.

Is it possible to figure when a civ runs a counter-mission against you and give an alert? Prices would jump massively, but it would take a little logic. Maybe cache the See Research value, and if it doubles (or more) IBT, then trigger the alert?
 
How bit is the stack you are looking at? Can you send (or upload) a save that we can test?

I'm not sure what you mean by that. My computer was just running slow with everything toggled on so I turned a bunch of stuff off, including the Plot Indicators, which brought me back to speed. I think it's just my computer's fault though. For all I know the changes could be a placebo effect, but it still feels better.
 
Back
Top Bottom