[v1.3.0+] Golem Speed Lock

[Zizzo]

It's the bane of every Alchemist that ever found Silk Current or Feathersteel Amulet or anything that increases your movement speed: waiting at the end of every long corridor for your golem to catch up to you. Thus my new Golem Speed Lock addon. It adds a fortress action (costing 20 energy) that "upgrades" your golem to increase its movement speed as necessary to equal yours. [I've never had cause to give my golem speed-boosting equipment to make it faster than me, but if you do, this upgrade won't slow the golem back down to your speed.]

[Technical notes:]

Code: Select all

Hooks:
  Chat:load [to add our new action to the fortress butler's chat]
Superload:
  mod.class.Actor:
    combatMovementSpeed() [to adjust the speed of our upgraded golem]

[Zizzo]

Frequently Asked Questions:

What if I get more speed-boosting equipment after I upgrade my golem?

Your upgraded golem's movement speed is computed "on the fly"; it will always be equal to the larger of either your current movement speed or its own current movement speed as it would be without the upgrade.

Hey! The upgrade is making my golem's movement speed higher than mine!

Is your global speed higher than your golem's? What this addon attempts to equalize between alchemist and golem is their "effective movement rate", which is global speed times movement speed; as a result, if the alchemist's and golem's global speeds are different, their resulting movement speeds will be correspondingly different.

For instance, suppose your global speed is 125% and your movement speed is 160%; then your effective movement rate is 200%, meaning that you are moving twice every normal-speed turn. If your golem only has 100% global speed, then to achieve the same effective movement rate, the addon will increase the golem's movement speed to 200%. Since its global speed is unchanged in this example, the golem will still be slower than you when attacking or casting a spell, so it may lag behind you in those cases.

[Zizzo]

[slaps forehead] Aaand I completely forgot to take global speed into account. Well, more likely I assumed that Actor:combatMovementSpeed() was already factoring in global speed (which I really should have known better than to assume, since movement speed and global speed are applied in completely different places).

Let me lay out the problem: At base speeds all around, an Actor needs 1000 energy to move and gains 100 energy per tick, and thus moves every 10 ticks. Now, let's say our example Alchemist has, for mathematical convenience, +25% movement speed (thus needing only 800 energy to move) and +60% global speed (thus gaining 160 energy per tick); combined, this means we move every 5 ticks. Our golem, by contrast, has no mods to global or movement speed except for the speed lock, which effectively gives it +25% movement speed; combined with its +0% global speed, though, that means it's only moving every 8 ticks, completely defeating the point of the addon.

Now, there are two ways we could address this problem:

• Have the speed lock also increase the golem's global speed as needed to match the player's global speed. I can see that people might think that's too powerful.
• Have the speed lock compute the appropriate movement speed to give the golem the same effective movement rate as the player. In our example above, for instance, we would have to increase the golem's movement speed to +100% to get it moving every 5 ticks. That could be fiddly in general, though, and could still lead to the golem lagging behind if it does something other than moving.

So. How do people here think I should fix this?

[Frumple]

... probably the first. Don't think golems are strong enough it's going to really break anything.

Second would be more ideal from a least-impact point of view, though, definitely. Maybe do that, and then add some kind of check where if the golem isn't within a certain radius (keyed to the golem's leash distance?) of the player for more than a few turns, it teleports the golem to you? Kinda' like thought forms. Just nix the effect if enemies are visible, extend the yank-back effect timer if the golem's been controlled recently, tried to attack something, stuff like that, so the effect wouldn't be screwing with golem micromanagement. Would think that would catch most edge cases without too much extra trouble.

[Zizzo]

... probably the first. Don't think golems are strong enough it's going to really break anything.

Second would be more ideal from a least-impact point of view, though, definitely.

Yeah, I've just about talked myself into going with the second option. (Turns out it's actually easier, even; the first option would require me to arrange to recompute the golem's global speed every time the player's global speed changed.)

Maybe do that, and then add some kind of check where if the golem isn't within a certain radius (keyed to the golem's leash distance?) of the player for more than a few turns, it teleports the golem to you? Kinda' like thought forms.

I dunno, the goal here isn't really to actually prevent the golem from getting too far away from the player; it's just to keep their speeds matched up, so that the golem doesn't get left behind when auto-exploring or running down a long corridor. There's always Invoke Golem for emergencies.

Just nix the effect if enemies are visible, extend the yank-back effect timer if the golem's been controlled recently, tried to attack something, stuff like that, so the effect wouldn't be screwing with golem micromanagement. Would think that would catch most edge cases without too much extra trouble.

(scratches head) …well, I suppose from a non-coding perspective, that could be viewed as "least-impact".

[Frumple]

Hey, it'd just be the thought forms effect with a couple extra checks, right

Though yeah, the thought was that what it'd do is just kinda' catch the golem if it did start falling too far back during autoexplore or a long corridor. That's what all the check addendum was about, to keep the effect from replacing invoke golem or messing with distant scouting or whatev', while still keeping the golem close even if the movement speed adjustment was hiccuping occasionally. Just something to make sure the mentioned edge cases were caught in some kind of net.

[Zizzo]

Hey, it'd just be the thought forms effect with a couple extra checks, right

Famous last words.

In the meantime, I decided to go the simple way with the second option, as seen here:

speed.png (37.82 KiB) Viewed 4309 times

That just went out as v1a. I also added a new Frequently Asked Question above to cover the change.