RifE 1.20 Download and Changelog

Edit: Don't have a screenshot of the display on the promotion, but it reads: "Leash Range : X". Only description I could come up with that is clear, and accomodates negative values.

Something that gives an idea about where the leash is fixed would be nice too. Even if it's just a number indicating how far the unit is from the fixed point.

By the way, is it manhattan or cartesian distance? And can a promotion have a leash range of 0, thereby working as a Held variant?

Edit: I meant Chebyshev distance or Cartesian distance of course.
 
Something that gives an idea about where the leash is fixed would be nice too. Even if it's just a number indicating how far the unit is from the fixed point.

By the way, is it manhattan or cartesian distance? And can a promotion have a leash range of 0, thereby working as a Held variant?

Not on the promotion (There is no plot the promotion is fixed to, after all) but I'll try to get something working on the unit. Planning to at least show leash range, and with Chipotle enabled (and shift held) show the actual x/y values of the plot it's leashed to.

As for the way the distance is calculated, that I did nothing to; Still the same as Cyther wrote it. Believe it's Cartesian.

Promotions can not have a leash range of 0, as that's the default value; Since the promotion tag works via change and not set, if I were to set the default to -1 then a <LeashRange>2</LeashRange> tag would only let you move 1 tile away, and 1 would be just the plot you're on. Though I supposed I could use Set if you don't have a range already? Not sure how well that will work with removing it, and readding a new one later, though
 
Small update: Rewrote the code that actually accomplishes something (Namely, limit a unit from moving out of it's leash). The new code will allow a unit that has somehow gotten out of it's leash range (Generally, having multiple leash promotions and losing one. Or gaining a new promotion that shrinks the leash) to move, but only to plots that are closer to it's leash. Tested and it's working great. ;)
 
I didn't realize you were that into bondage...
Are you using leather leashes or latex?
 
Alright, slight addition that should make ExMachina happy. :lol:

Units with the bAnimal tag AND the bHiddenNationality tag now display the ANIMAL flag, rather than the Barbarian flag.

In the screenshot, the baby spiders do NOT have the HN tag yet; They are there simply to tell you which Giant Spider is which. On the left, you have Archos. On the right, you have Animals.

Civ4ScreenShot0058.jpg


Why add this? Really, it's 100% for spiders and the Archos. Standard spiders will lose HN, Archos will get spider variants able to upgrade at set population size and HN. An Archos player can actually use these spiders against human players now, if he's intelligent about it. ;)
 
Hehe, I may allow them to promote to HN when not owned by Animals (or Archos... They have UU's for them that carry the tag on the unit itself, rather than promotion. Harder to tell when you mouse over it), we'll see.

Also, the different spider 'races' are now available for the Spider Swarms/Armies, and the artstyles are valid. ;)
 
Two new unit tags have been added... I'll let you all try to figure out why. :lol:

  • iCityPopCostModifier - Increases unit cost by (Tag * CityPop)
  • iEmpirePopCostModifier - Increases unit cost by (Tag * AveragePop)

Both have been tested by making warrior clones.. Granted one clone a CityPop tag of 20, and the other an EmpirePop tag of 20. Base cost is 25 hammers.

With 1 pop in the capital and no other city, both cost 45. With 2 pop in the capital and a second 8 pop city, the first cost 65 (25 + 20*2) and the second cost 125 (25 + 20*((2+8)/2), or 20*5).

Only thing I'm not too sure on is the display text... Tell me what you think, and post any improvements you can come up with. ;) Before it's asked: No, I can not display the exact amount that will be added as it's not being built yet in the Pedia. :lol:

  • Cost Modified by X for Each Population Point in City
  • Player's Average Population Modifies Unit Cost by X for Each Population Point
 
Two new unit tags have been added... I'll let you all try to figure out why. :lol:

  • iCityPopCostModifier - Increases unit cost by (Tag * CityPop)
  • iEmpirePopCostModifier - Increases unit cost by (Tag * AveragePop)

Do they work gracefully with negative numbers?

A number of cities tag might be good too, mostly thinking of settlers.
 
Do they work gracefully with negative numbers?

A number of cities tag might be good too, mostly thinking of settlers.

Hmm, hadn't thought of numCities... Wasn't needed for my application. :lol: I'll try and add it.

And yes, they work fine with negative numbers; Made sure to use a max command, so it uses the highest out of 1 and the production after all modifications; Can never go negative. ;)
 
Would the same kind of modifiers for buildings/projects be worth considering?
 
Used for the new Mechanos leader that is Fallow and can build pop...?:please:

Exactly. Not sure which of the two tags will be used in the end... Have three choices, all of which will be available to the testers.

  1. Each city must build it's own pop, pop is not transferable. This will use the city tag, so that pop is initially cheap and becomes more expensive.
  2. Pop is transferable between cities; This will use the Empire tag.
  3. Two pop units, one for the city that is not transferable, one much more expensive that is and uses the Empire tag.
 
Each city must build it's own pop, pop is not transferable. This will use the city tag, so that pop is initially cheap and becomes more expensive.

This seems like it should be a ritual instead. Why build a unit that cannot move and will instantly be added to the population of the city anyway?

Possibly so you can queue up several units at a time. Would it be much harder to rewrite the city interface to allow several copies of the same ritual to be queued at the same time?

I think this model would encourage a fairly normal looking empire, with each city roughly the same population.

Pop is transferable between cities; This will use the Empire tag.

Then what will the empire look like? Probably a few megacities surrounded by little suburbs whose main contribution to the empire is bringing down average city population. Sounds exactly like D'Tesh and Scions.

Two pop units, one for the city that is not transferable, one much more expensive that is and uses the Empire tag.

What will the empire look like? I don't think it will be a hybrid of the two previous ones. More like the player can choose either.
 
This seems like it should be a ritual instead. Why build a unit that cannot move and will instantly be added to the population of the city anyway?

Possibly so you can queue up several units at a time. Would it be much harder to rewrite the city interface to allow several copies of the same ritual to be queued at the same time?

I think this model would encourage a fairly normal looking empire, with each city roughly the same population.



Then what will the empire look like? Probably a few megacities surrounded by little suburbs whose main contribution to the empire is bringing down average city population. Sounds exactly like D'Tesh and Scions.



What will the empire look like? I don't think it will be a hybrid of the two previous ones. More like the player can choose either.

The first method is my own preferred implementation; The second is the one ExMachina argued for, so you could have one or two cities building pop and others doing other things. The third is an attempt at a hybrid.

The issue is with rituals is the ability to queue production. Which is important. For reasons that I shall not go into, but should be obvious to some of you. :lol:

I'm not sure how much work it would be to be able to queue multiples of the same ritual, and honestly would prefer just the unit; Easier, and with the use of a pyReq in a 'spell' you'll never see the unit; he'll be added to the city immediately.
 
Done a bit more with leashes, in response to feedback from Odalrick (0-range leash) and Sylvain (Variable-range leash).

Here's a writeup for the leash system as a whole:


  • Promotions have two new tags, iLeashRange and iLeashChance. Will go into detail on these later.
  • A unit that gains a promotion with either of these tags is considered 'Leashed'. This has several effects.
    • Upon becoming 'Leashed', a unit gains a 'Leash Plot'. This is whatever the plot the unit happens to be one when it becomes leashed.
    • So long as the unit remains Leashed, it will be unable to move more than it's LeashRange from it's Leash Plot. This range is calculated in the same manner as city culture, so corner tiles for the last ring are not valid.
    • If a unit gains a new Leash promotion, it's LeashPlot will not be affected; However, the ranges will stack. This means you can have a unit gain a slowly-widening leash, or a shrinking leash.
    • Once a unit loses ALL Leash promotions, it will no longer be considered 'Leashed'. At this point, it's leash plot is cleared, leaving it able to receive new leash promotions later on without issue.
  • As stated, a unit that is 'Leashed' is unable to move out of it's leash range. However, if that range shrinks (or python is involved with moving him), the unit will be able to move to plots that are either the same distance from it's leash, or closer to the leash. Never further away. Unfortunately, there's not a whole lot to be done concerning an intervening Mountain Range or Ocean; So occasionally a unit may get stuck. :p
  • The two leash tags function much like FirstStrike and FirstStrikeChance.
    • iLeashRange
      • Standard leash. Default is -100, so any other values are valid, including 0.
      • Range of 0 is treated as held.
    • iLeashChance
      • Variable leash. Default is 0, this one may not be negative (Ignored if < 0, so setting it negative in XML won't do anything). Mostly because if you end up with a LeashRange (on the unit) of less than 0, the unit is no longer considered 'Leashed' and the leash plot is reset.
        • Negative values are unnecessary anyway; Can accomplish the same thing by having a lower LeashRange and a positive LeashChance.
      • Each turn, a random number is calculated from the unit's total LeashChance, and this is applied to it's LeashRange. It is removed from LeashRange and wiped next turn before repeating the process.
  • The display is a bit different between Unit and Promotion, and I'm open to adjusting it.
    • Unit:
      • When you mouse over a unit, it will display 'Leash Range : X'. It does NOT display how much of that is random, which is something I'm willing to change if deemed necessary.
      • When Chipotle is enabled and Shift is held (which displays AI info, art info, climate, etc), the unit's LeashPlot and randLeash values are displayed.
    • Promotion:
      • If a promotion contains JUST the iLeashRange tag, it displays as 'Leash Range : X'
      • If a promotion contains JUST the iLeashChance tag, it displays as 'Leash Range : 0 - Y'
      • If a promotion contains both, it displays as 'Leash Range : X - Y'. Same as first strikes on a unit.
So, I'm fairly sure I've got all our bases covered at this point, aside from possibly the display. Any other abilities the Leash system needs? Thoughts on how we can use it? (Obviously, we have ideas, but still, some of you come up with interesting ones. :lol:)
 
Back
Top Bottom