[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]
Moderator: Moderator
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]
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.)Frumple wrote:... 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.
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.Frumple wrote: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.
(scratches head) …well, I suppose from a non-coding perspective, that could be viewed as "least-impact".Frumple wrote: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.
Famous last words.Frumple wrote:Hey, it'd just be the thought forms effect with a couple extra checks, right