0002411: Add an ability to ask only specific allies to follow you to the 't' menu

Notes
(0007669) OG17 (reporter) 2010-08-30 16:56	Any companion-user would find this wonderful, as ally control is consistently the worst part of the crawl interface, I'd think, and the current necessity of splitting things off with LOS or stairs here is basically awful. And for another specific use, this'd also be very handy for getting rid of still-friendly spell-summoned greater demons (as common as that is!), as right now there's no good way of handling the things. Also, there should be a similar mechanic to set item behavior for specific allies, as then you could prevent some plain orcs from grabbing gear that you're trying to give to a knight (ie, tell all allies to pick up nothing, then tell the knight to grab stuff). This could also be used to command a permanent intelligent ally to drop its equipment, which would also be incredibly welcome (though Beogh's item-boosting may need to be revisited). This may or may not be more control than some players ever want to think about using, but as the current general commands would remain and make using these specific commands entirely optional, that's no concern at all.

(0007677) jpeg (manager) 2010-08-31 08:12	We have _no_ intention of allowing the player to micromanage your allies. Yes, I know it can be fun sometimes, but Crawl is simply not aiming to be that kind of game. For Beogh, we are planning some way to select only the twelve highest-level followers ("apostles") to fight along with you. If one of them dies, the next highest-level follower would travel towards you. See https://crawl.develz.org/wiki/doku.php?id=dcss:feedback:god:beogh [^] 2410 is a bug, yes.

(0007685) OG17 (reporter) 2010-08-31 17:38 edited on: 2010-08-31 17:40	The lack of "micromanagement" just means that a player's forced into ridiculous behaviors. You need to dance around with recall, LOS, and staircases in order to give out different commands and leave certain allies behind. If an ally picks something up you don't want it to have, you have to do the above to isolate it, then write it off as dead since you need to find something that's able to kill it so you can loot the thing back. If allies decide to make some ridiculous decisions concerning their ranged weapon and ammo priorities, as they often do, you just have to accept that they (and by extension, you) are going to be subpar for the rest of their lives, as you can't take the items away so they pick up something "better." This all just encourages the constant toggling of pick up/don't pick up, which is both micromanagement in itself and very clumsy, uncontrollable, and ineffective. A Beogh band-aid does nothing to address how the game has no system for such basic companion actions. Design goals that result in jumping through hoops are a bit questionable, I'd think, and giving players the option to direct specific companions isn't going to turn anything into "that kind of game," unless "that kind of game" is one where common behaviors can be done easily and directly.

(0007697) dpeg (administrator) 2010-09-01 08:52	Everyone agrees that ally play is not ideal and that ideas for improving are needed. However, "...ally control is consistently the worst part of the crawl interface" (OG17) is a bit rich. By the face of Beogh, this is not a rhetorics seminar. The interfaces for Nemelex, transmuters and ranged combat (to name a few) were all much more cumbersome until someone came up with good ideas on how to improve on them. So my main point is: if you all can come up with for allies is to ask for per-monster commands (a la "give", "take", "follow", "stay here" issued to a single ally), then we will simply not do this. These proposals are just not good enough. I can put this another way: Beogh is to a large extent my invention. I would rather support deicide than the micromanagement you are asking for. (I absolutely realise that the current implementation encourages micromanagement of its own sort. The problem is that you are asking for micromanagement to be established as design.) If the upshot is that permanent monsters are a pain interface-wise and we cannot improve matters, we will just remove permanent monsters (this mostly affects Beogh and TSO). I have been adding a note to https://crawl.develz.org/wiki/doku.php?id=dcss:planning:wont_do [^] "...but as the current general commands would remain and make using these specific commands entirely optional, that's no concern at all." (OG17) This is a hollow statement. Nobody has to use Elberereth in Nethack, it is fully optional. Still, ideal play needs it, so you are crippling yourself by avoiding it. Same if we allow control over individual monsters. That said, the following changes are not controversial: * allies should drop items they cannot use (once they become allied) -- what about temporarily enslaved monsters? * allies could follow stricter rules about what they will use (e.g. if an orc starts with a mace, we could make him use only maces) "...and very clumsy, uncontrollable, and ineffective." Beogh, I hear your last breath...

(0007699) galehar (administrator) 2010-09-01 10:06	I totally agree with dpeg that we don't need to have individual "follow" and "stay here" command. We don't want to turn crawl into a wargame. That being said, I do think that having a command to ask a single orc to drop his stuff could be nice. Playing Beogh, I was mostly annoyed to have to constantly change the ally pick up behaviour, so that they don't steal the best stuff, but still upgrade their equipment. Having a "give me your stuff" command would allow you to keep the behaviour to "pick-up anything you need" and if you notice one has found something you might be interested in, you can get it. A consequence of this is that it would be much easier to get a +9 orcish plate mail (blessed by Beogh). I don't know if that's a good or a bad thing. You can already pick one from the dead body of one of your long standing followers. Maybe this could also be solved with a global "bring me the loot" command. All orcs would bring you what they have recently found, and when you're done picking what you want, you tell them to "keep the rest". Also, I love the idea that each orc can use a single weapon type. I always found it unfair that I have to train a single weapon skill, but they can easily switch from a long blade to a polearm. It would also make them more distinctive. And to finish this long comment, I'd just say: please, don't remove Beogh! The interface need some polishing but I'm sure we can make it awesome!

(0007700) OG17 (reporter) 2010-09-01 10:12 edited on: 2010-09-01 10:13	If a Yred player doesn't want to lose a geared-up skeletal warrior to V:8, why is simply letting him say, "You, stay behind," a problem? What's undesirable about being able to tell an orc to lose a distortion or draining weapon, or to gently remind it that consumables, evocables, and equipment are often better in the player's hands? If a player doesn't care what his companions are doing or where his items are going, he'd be free to ignore these commands entirely. If not, he currently has to bend over backwards to try and play under an intentionally nonfunctional system. This isn't at all comparable to features like Elbereth, as the player is already able to mimic such proposed ally control under the current system, albeit in an unintuitive, wasteful, and time-consuming manner. What exactly would be lost by improving this? It's incredible to claim (or threaten) that dropping gods is the preferred alternative. What is everyone so afraid of here?

(0007701) KiloByte (manager) 2010-09-01 10:17	A crude but simple solution: what about simply blocking all ally auto-pickup altogether?

(0007702) dpeg (administrator) 2010-09-01 10:19	kilobyte: interesting idea. Would definitely help on the short term and is better than removing Beogh. galehar: I am sure something can be found. I am trying to convince people of the design paradigm, so they come up with something better than individual control commands. OG17: You haven"t understood my point at all. "You don't have to do it" is never a good answer.

(0007704) OG17 (reporter) 2010-09-01 11:04	Kilobyte, are you suggesting that allies simply don't use items? It's pretty clear that manually equipping them is out of the question (and unnecessary), and the only other way of giving them anything is letting them pick it up themselves. Removing this would lose a great deal of power and fun. Dpeg, I don't get you. You say "Nobody has to use Elberereth in Nethack, it is fully optional. Still, ideal play needs it, so you are crippling yourself by avoiding it. Same if we allow control over individual monsters" - and the solution is to leave everyone with a comparatively crippling system? You know that it's already possible to have individual allies wait, and also to "disarm" them, and that the means are severely lacking - and yet by your own argument, doing so would be necessary for ideal play. There are very obvious holes in the current interface, and again, it'd be nice to understand why you're so strongly set against filling them. And for what it's worth, just having individual "wait" and "drop" would cover the bases - there's no need for the others you list, and these two wouldn't even see regular use, as leaving a specific ally behind and disarming are very situational actions. But regarding those two "not controversial" suggestions, it doesn't make much difference if temporary enslavements keep their unusable items or not - I'd have them drop it just to be consistent with permanent enslavement. Limiting allies to specific weapon types wouldn't address anything here in any sense; not sure what you're aiming for, but all it'd do is make the player feel arbitrarily constrained and like items are going to waste.

(0007707) jpeg (manager) 2010-09-01 12:07	> if an orc starts with a mace, we could make him use only maces AFAIK, something similar is already in the code. Weapons get a slight value bonus if they are of the same time as the to-be-replaced one, so that the choice between two weapons of equal +Dam value will be skewed towards the current "skill". (This is similar to the racial value bonus for armour even if it has less AC than plain armour of the same type.) Said bonus could be increased a bit, but I wouldn't raise it too much, because that will just lead to complaints along the lines of "My orc knight won't switch to this awesome triple sword and instead keeps using morningstars." As for monster pickup in general, that was a fairly recent addition (0.4, I think) that went a huge way to make monsters seem smarter. I would be sorry to see it go. As already said elsewhere, I think that a pickup mode restricting monster pickup to only weapons/ammo/armour could be useful to keep consumables out of monsters hands, or alternatively, simply keep allies from picking up any consumables at all. If this is implemented, making permanent allies drop such items makes sense, but I wouldn't include temporary allies in this.

(0007711) minmay (reporter) 2010-09-01 16:07	A pickup mode restricting monster pickup to non-consumables would be excellent. An order for allies to drop items would also be very nice; note that this would NOT need to be targeted at an individual ally, although it would be quite a bit less clunky if it were, and the same applies to ordering them to drop specific groups of items (e.g. only consumables, only weapons, only armor).

(0007713) Lemuel (updater) 2010-09-01 17:48 edited on: 2010-09-01 18:17	Seems to me that equipping individual allies never involves a strategic tradeoff. (As it would e.g. if monsters could carry only a melee or a missile weapon but not both.) It's simply a matter of getting better equipment to allies, where there is no real question what better is. Given that, seems like the direction to be heading in is more intelligent code for monster item choice, not more commands for the player. Ideally, allies would simply be making the right choices so there would be no need to give them specific orders. Also, if monsters with ranged weapons could carry multtiple ammo stacks, one set of problems would be avoided. I would suggest that rather than propose new commands for allies, we instead come up with a detailed list of allied behaviors that are problematic currently.

(0007716) OG17 (reporter) 2010-09-01 19:53	Lemuel, it's certainly a tradeoff if you have an item on an ally that'd be useful for your own character, as well as if they're using potentially undesirable item. But hey, have a list: - allies picking up items means that they're gone until they're dead, which takes items away from the character and, depending on severity, makes the player want to kill off allies. It's very hard to imagine how this could be handled through AI - an ally could shout at the player if it comes across something that may be better than what the player's currently equipped with, taking skills into account, but then what? Having to pick up and drop such items (as well as evocables and consumables) before allies would take them would work, but be similarly clumsy to the current interfaces, and the game's idea of value rarely matches the player's anyway. Also, outright disallowing picking up potions and wands would remove a good bit of fun - if a player wants companions to use such items, I'd think there should be a way of doing so. It certainly looks like a "drop" command is required here. - allies taking items that would be better used by more powerful/survivable followers. Grouped allies could trade items among themselves (perhaps by radius, not adjacency) with this goal in mind, which I imagine would work very well, if not result in more message spam (which is a general companion problem, not a failing of this mechanic specifically). It'd also be possible for an ally to not pick up an item if a stronger ally would be interested in it, which would be quieter but much less effective, as the former leaves every ally suitably-equipped no matter who picks the item up, whereas the latter require a lot of shuffling and would often leave upgrades behind. - allies using distortion/draining/chaos/dispersal. Barring them outright isn't ideal, as players have different opinions about draining and even chaos, and distortion and dispersal may be wanted for fun or for something like attempting to rush the orb. - specific allies following into places where they're not wanted, such as the previously-mentioned veteran skeletal warrior and V8, where the player may want to leave the certain-to-be-lost skeleton behind but gladly squeeze some use from the half-dozen wraiths he's collected. If there's a way of doing this through AI, I'd love to hear it - such decisions are very much up to the individual player. A specific wait command appears to be necessary. - I haven't mentioned this, but pickup behavior is also poor - if there's no enemies around (tension?), allies should actively head towards nearby items (jelly-like?), particularly spent ammunition. If a monster appears, they'd of course drop what they were doing and engage it, and they should also prioritize staying within a certain smallish radius of the player. It'd likely be helpful if allies shared item knowledge as well, so that if one finds a weaker item than it's using, a less well-equipped one would walk over and pick it up. Currently needing to physically lead an ally over an item's square is slow and inexact. - As in 2418, ally ranged weapon/ammo priorities are completely divergent from a player's priorities, but that's entirely an AI issue, I'd think. I'm liking a variation of Galehar's idea (0007706 and 0007715). There may be other issues, but these are the ones I've noticed. This should maybe just be pasted into the wiki, at this point.

(0007723) Kate (developer) 2010-09-01 21:11	I agree that this issue should be closed and the discussion taken back to the wiki. I've done what I can by winning a Beogh game and making FRs on what I think would specifically fix his issues, and if these proposals are "not good enough" then so be it. To clarify though, the issue that this FR was meant to fix was "you have a huge crowd of weak orcs but only want to take a few strong ones with you" - a lot of the discussion here is about item management and (although it could certainly be improved) that was much less of an annoyance than the simple problem of getting your allies to go where you want them to. Another way of fixing the problem that I think could work would just be to drastically reduce the number of followers you can gain with Beogh at any one time, so you'll never run into the issue of having a huge number of popcorn orcs getting in your way.

(0007725) OG17 (reporter) 2010-09-01 21:29	I'd like to stress that ally management isn't Beogh-specific, and though there's likely room for Beogh-specific fixes (as on the wiki), it's a separate issue that wouldn't address the general interface holes. (also who doesn't like having a huge number of popcorn orcs getting in the way)

(0007730) dpeg (administrator) 2010-09-01 22:25	The problem is essentially only with permanent allies (which is almost exclusive to TSO and Beogh followers). Permanent allies are also a threat to balance, so perhaps it was unwise to add them. OG17: Encore une fois: I mentioned that the current system has problems. Everyone here is aware of that. What you don't understand is that while one solution (namely addressing individual followers) would solve the problem and appears to be quite natural, it does have other drawbacks. You disregard these drawbacks by saying "nobody has to use these new commands" but for some of us they make the solution too bad. That's it. To stay with the Elbereth analogy: once you agree that Elbereth is problematic (for example, because Elbereth encourages players to spend lots of real time writing ElberethElberethElbereth into the dust), one obvious solution is to provide a command that writes Elbereth for you. But that's a pretty bad solution and one should think harder to get a better one. MarvinPA: Hey, I know about your intentions and it's good to get the FRs. There's also definitely something positive coming out (namely the bits about unusable items). Note that I also thought about restricting orcish followers. However, I don't think you can make "no more than ten followers" (or similar) fit the theme, and that is why I came up with the Apostles. (Who would be the most devout followers and only they would accompagny you.) Comments welcome, as ever. Also see next comment in this FR.

(0007733) StudioMK (reporter) 2010-09-01 22:38	Stop allies wandering when you tell them to wait (eg. restrict them to a few squares around when you issue the command). Have allies ascend stairs even if they're out of LOS (around a corner for instance) but connected to an ally and have them follow you for a number of turns when they leave LOS (to prevent them getting stuck around corners). As for item management, how about you don't let them pick up items and instead have them generate with whatever (and keep it forever). Ranged allies are restricted to picking up only plain ammunition. Also make !D prevent allies from picking up said item and have them respect exclusions (to prevent them going somewhere you don't want them to go). As for removing permanent allies, bad bad bad bad. I have yet to play Beogh but when playing Yred, the allies certainly are fun. Because something needs improving shouldn't mean you say "I can't be bothered let's just remove it".

(0007742) OG17 (reporter) 2010-09-01 23:12	>What you don't understand is that while one solution (namely addressing individual followers) would solve the problem and appears to be quite natural, it does have other drawbacks. Dpeg. I don't know why I'm still trying, but these drawbacks. What are they. What are the drawbacks. Describe the drawbacks. You use them to dismiss the FR, you accuse me of disregarding them, and you've yet to hint at what they might be. Replacing manual "elbereth" with an "elbereth" button sounds like a good idea. Replacing contortionist commands with direct ones sounds like a good idea. Why is it a bad idea? Who knows. Or is "bad" the extent of this? Tell us, please.

(0007744) StudioMK (reporter) 2010-09-01 23:14 edited on: 2010-09-01 23:32	Seriously, if people add suggestions and get a "we'll remove the feature instead" then people will stop suggesting things altogether. You say you want people to contribute but raising issues seems to make things get removed. We make suggestions because we like something and want it to be better. If we didn't like it we couldn't care less. Anyway, I've made my suggestions in regards to better improvement of the interface. Maybe I should start learning the source and implement a new interface myself. Ring-fencing 'new interface' entirely seems like the way to stop good things happening. If you don't want micro-management then you make an interface that doesn't require micro-management, or make the allies behave in a way that doesn't require it. Not being able to think of a good interface is not justification for saying "we won't change it" or "we'll remove it entirely".

(0007747) rob (developer) 2010-09-01 23:38	OG17: as dpeg stated above, the main drawback is increased micromanagement.

(0007750) Lemuel (updater) 2010-09-01 23:46 edited on: 2010-09-01 23:52	Can we make a distinction here? Ally equipment management concerns, ISTM, can be entirely addressed with better ally AI. There is no need to change player commands at all. The specific issue raised by Marvin is a somewhat different story. The question of what allies to bring with you is a real strategic choice, and there's no obvious automatic way of handling it. So improving the 't' functionality seems more promising here. On the other hand, one could go in the other direction, and have intelligent allies always join you on your current level (perhaps with a delay), whether they were adjacent when you took the stairs or not. Then there would be no more micromanagement as to which allies to bring with you. EDIT: If one result of this is that Beoghites really don't want to do the Swamp, that would be a feature not a bug, IMO.

(0007752) Lemuel (updater) 2010-09-01 23:50	(Also, just to reinforce Dpeg -- the game has to balanced for optimal play. As a matter of logic, either (a) giving orders to specific allies gives no benefit, so it's pointless; or (b) giving order to specific allies will give a big advantage, making the ally game too easy; or (c) giving allies specific orders will give a big advantage, so it will be accompanied by a nerf to allies in general, making ally play without specific orders too weak.)

(0007753) StudioMK (reporter) 2010-09-01 23:51 edited on: 2010-09-01 23:53	If they always joined you then making sure they live becomes a pain (ie. they don't live). Micro-management isn't a bad thing. If a player can't be bothered then they don't do it. Thing is, the majority of player will do it. The more effort a player spends on an ally, the more valuable the ally becomes. If there's no management at all then the player will see no value in trying to keep it alive, since it's just a piece of meat. I'm opposed to specific commands. As I said before, a new inscription that forbids an item is all you need. Then you add an autoinscription to your config file and you're done. And this wouldn't take long to implement since !D already exists. What's the draw-back? There is none. Editing a config-file isn't micromanagement. It's changing the settings; for optimal play, of course.

(0007756) Lemuel (updater) 2010-09-01 23:54	"If they always joined you then making sure they live becomes a pain (ie. they don't live)." This is silly. It just means you'll pick the branch to do next taking into account its survivability for your allies. Which is a good thing IMO. "Thing is, the majority of player will do it." Well, I won't do it. Too much work. So an ally game that's balanced for micromanagers, will mean an ally game that's crippled and unfun for me.

(0007759) StudioMK (reporter) 2010-09-02 00:02 edited on: 2010-09-02 00:05	Micro-management is part of the ally game. Allies shouldn't come without effort. If they're 'freebies' that require no work on part of the player, then it's not a game is it, you just walk around and let them smash things. Micro-management is a difficulty that the player should overcome, and that is what balances it. I'll say it again: autoinscriptions. Autoinscriptions makes the corpse game easy. It will make the ally game easy. All you do is let someone else make the autoinscriptions and c&p to your config file. Not hard. Add one that is "Allies will pick up items inscribed with this". That's it. If you accidently inscribe an item you want tough luck. I accidently transmuted my weapon into a snake, so, that was tough for me.

(0007760) rob (developer) 2010-09-02 00:06	I like the idea of having friendlies always follow you. I.e., remove the "wait here" command, and introduce some way for allies to follow the player, either immediately or with delay. It would solve a lot of other problems, like players losing their permanent allies somewhere. One issue that might need to be addressed is that this would allow safely escaping up stairs with your allies even if they've wandered. Another is that this would reduce consistency with non-allies unless those also chose to follow you if not adjacent. That's already broken by the way that large groups of allies follow you right now, though. A minor issue that I had with the introduction of the "wait here" command is that enslavement became a safe way to escape from monsters. This would also be solved by removing the "wait here" command.

(0007761) StudioMK (reporter) 2010-09-02 00:09	Also, you're saying it's not fun for you. That's natural. Everything isn't fun for everyone. I find Spriggans boring, for instance. I like ally micromanagement. So saying that "it's not fun for me" is not justification enough to change it if it would make it less fun for others. The point is: everything isn't for everyone. If it was there'd be only one race and only one starting class with only one spell. Get the idea?

(0007763) OG17 (reporter) 2010-09-02 00:11	Lemuel, how would you have allies handle equipment so that players wouldn't need a "drop" command? Rob, it's understood that new commands would cause no new micromanagement, but only improve current micromanagement. Which seems to be a problem. Lemuel, changed "balance" isn't an issue, as everything's already there. If you've ever played Beogh or Yred and haven't gone to all the above-described trouble with faking commands, you've already proved that you'd be fine if actual commands were put in and you ignored them. The only change is the interface. Rob, "wait" is one of the most fundamental commands imaginable - just because you have allies doesn't mean that you shouldn't be able to get away from the things. I don't see how enslavement is a problem, either - confusion and hibernation are similar "safe" ways to escape, and much more useful to begin with. MK, inscriptions are a poor choice here, as they're complicated, inflexible, and outside of the game; it's bad enough that Nemelex needs the things.

(0007764) rob (developer) 2010-09-02 00:12	Closing since the discussion is getting out of hand. (Studiomk, I'm looking at you.) There's some good stuff in there that should make it to the wiki.

(0007765) dpeg (administrator) 2010-09-02 00:17	Okay, perhaps it is time to discuss what we actually mean by "good ally play", Could turn out that the ideals are quite different, so here is what I want: a) Tactical choice of the player whether he wants to fight alongside the allies or stay behind. In the case of permanent/longterm allies, the player will want to keep allies alive. b) Global commands to tell all allies whether to follow or to stay behind. This is necessary because only the player can evaluate which areas allies are useful. IDEA: Could have a note on the Ctrl-O screen "Parked [which] allies here." IDEA: Could make G (go to level) another global ally command. It would take some provisions (they should probably not appear there before you) but it could solve quite some issues. c) Commands to tell allies which enemy to attack is okay (this is a legimite tactical choice, akin to choosing a target for firing or spells). Issuing individual targets is also a legimite tactical choice but is too cumbersome interface-wise, so won't be done. This makes allies a bit weaker but without crippling them. d) What I don't want: the ability to check every individual ally (e.g. what they carry). Simply being able to do it will encourage players to actually do it. And no, micromanagement is always bad. We don't want it. The idea to balance gameplay feature via the interface is strictly bad. In particular, I don't want players to give and take items to/from allies. The allies use certain stuff and that's okay. That said, there is no point in allies carrying items they won't be able to use. So I support that idea of orcs dropping their gold once they follow you (for example). I can also understand that a player is vey keen on that awesome randart eveningstar the orc just picked up, so here is an IDEA: a global drop command. All orcs will drop items they think are noteworthy to the player. This could include scrolls of blinking and outstanding armour/weapons, but not mediocre items. The point is to allow greedy players to get stuff, not to allow perfectionist players to kit out their army. It might be a good idea to have such a command come with a liability -- e.g. an orc might decide to go wild if he has to give away some item. Apart from this, I think that Lemuel is spot on: ally AI is the way to go.

(0007766) dpeg (administrator) 2010-09-02 00:24	Changing status to feedback and assigning to myself. I will move some ideas to the wiki unless someone beats me to it. (rob was absolutely spot on about closing. It is one thing that some players don't understand what others want. But we have spent a lot of effort to try to explain our point of view, and you are close to shouting. I am looking at OG17 (please try to understand that "you don't have to do it" is not a solution, okay?) and StudioMK (yes, fun is different for everyone -- if a couple of developers take their time in explaining to you their point of view, please don't come back telling us that our notion of fun is wrong), but not at MarvinPA -- the original FR is absolutely acceptable.)

(0007769) OG17 (reporter) 2010-09-02 00:44 edited on: 2010-09-02 00:46	>d) What I don't want: the ability to check every individual ally (e.g. what they carry). Simply being able to do it will encourage players to actually do it. Dpeg, you don't think that players enjoy seeing the progress their followers are making? This is basic gamer psychology - there's no reason at all to blind people to this. What's the point of having an army if you can't ever stand back, tap ^x, and look at it? Also, what good is a drop command if you can't see what they're holding? Said global drop would be a massive improvement over having no drop, but it'd result in making everything pick its stuff back up afterwards, and maybe I'm way off here, but that doesn't really seem too hot compared to having a single ally drop his stuff instead. But micromanagement is always "bad," I guess! At any rate, the gear-swapping I suggested second in 0007716 would help this a lot, as would the smarter pickup behavior at the bottom of that post. Thanks for coming back to this, anyway.

(0007770) dpeg (administrator) 2010-09-02 00:55	I absolutely agree that seeing your allies become stronger is a large part of the fun. But you do that without any changes: you see what they are wearing and using (for example with Ctrl-X, but for weapons also simply from battle messages); they get names and new professions (for orcs). For the first bit (allies use better equipment), it is only necessary that they are allowed to pick up items at their own discretion (provided that ally AI is clever enough). Denying the player to give (particularly useful) items to an orc might make him slightly weaker, but does not really spoil the fun: they will end up in awesome gear either way.

(0007773) StudioMK (reporter) 2010-09-02 01:16 edited on: 2010-09-02 01:21	Well sorry. dpeg: That's not what I was saying, nor is what I was saying some kind of personal insult. If it was taken that way then I apologise. I was stating that "fun is unique to everyone so naturally you might not like it when someone else done". I thought that was pretty standard. What I wanted to imply was that a majority > minority thing. But that would require more people giving their opinions. I personally find it fun if they pick up whatever they want, the player unable to explicitly choose. Makes them seem like they have a mind of their own and encourages the player to see what they like (ie. get to know them!). Could be nice if the RNG generated their preferences (eg. one might only like short blades and the other polearms) so they don't go around swapping weapons at random.

(0007775) dpeg (administrator) 2010-09-02 01:21	StudioMK: It's okay. Just accept that there's a verdict by some higher (arrogant, if you will) being that individual commands are bad. Still, everyone here wants to improve on ally play, and there are ways how to do that, within the verdict.

(0007776) StudioMK (reporter) 2010-09-02 01:22 edited on: 2010-09-02 01:23	Sure. And alot of the game that I enjoy, you guys made. Even if I don't express gratification, you should be aware that it's there.

(0007813) dpeg (administrator) 2010-09-03 01:14	Completely remade https://crawl.develz.org/wiki/doku.php?id=dcss:brainstorm:interface:ally_management [^] Will close this FR soon.

(0007944) jpeg (manager) 2010-09-05 16:34	Closing.

Issue History
Date Modified	Username	Field	Change
2010-08-30 16:28	Kate	New Issue
2010-08-30 16:56	OG17	Note Added: 0007669
2010-08-31 08:12	jpeg	Note Added: 0007677
2010-08-31 17:38	OG17	Note Added: 0007685
2010-08-31 17:40	OG17	Note Edited: 0007685
2010-09-01 08:52	dpeg	Note Added: 0007697
2010-09-01 10:06	galehar	Note Added: 0007699
2010-09-01 10:12	OG17	Note Added: 0007700
2010-09-01 10:13	OG17	Note Edited: 0007700
2010-09-01 10:17	KiloByte	Note Added: 0007701
2010-09-01 10:19	dpeg	Note Added: 0007702
2010-09-01 11:04	OG17	Note Added: 0007704
2010-09-01 12:07	jpeg	Note Added: 0007707
2010-09-01 16:07	minmay	Note Added: 0007711
2010-09-01 17:48	Lemuel	Note Added: 0007713
2010-09-01 18:17	Lemuel	Note Edited: 0007713
2010-09-01 19:53	OG17	Note Added: 0007716
2010-09-01 21:11	Kate	Note Added: 0007723
2010-09-01 21:29	OG17	Note Added: 0007725
2010-09-01 22:25	dpeg	Note Added: 0007730
2010-09-01 22:38	StudioMK	Note Added: 0007733
2010-09-01 23:12	OG17	Note Added: 0007742
2010-09-01 23:14	StudioMK	Note Added: 0007744
2010-09-01 23:15	StudioMK	Note Edited: 0007744
2010-09-01 23:28	StudioMK	Note Edited: 0007744
2010-09-01 23:31	StudioMK	Note Edited: 0007744
2010-09-01 23:32	StudioMK	Note Edited: 0007744
2010-09-01 23:38	rob	Note Added: 0007747
2010-09-01 23:46	Lemuel	Note Added: 0007750
2010-09-01 23:50	Lemuel	Note Added: 0007752
2010-09-01 23:51	StudioMK	Note Added: 0007753
2010-09-01 23:52	StudioMK	Note Edited: 0007753
2010-09-01 23:52	Lemuel	Note Edited: 0007750
2010-09-01 23:52	StudioMK	Note Edited: 0007753
2010-09-01 23:52	StudioMK	Note Edited: 0007753
2010-09-01 23:53	StudioMK	Note Edited: 0007753
2010-09-01 23:54	Lemuel	Note Added: 0007756
2010-09-02 00:02	StudioMK	Note Added: 0007759
2010-09-02 00:03	StudioMK	Note Edited: 0007759
2010-09-02 00:05	StudioMK	Note Edited: 0007759
2010-09-02 00:06	rob	Note Added: 0007760
2010-09-02 00:09	StudioMK	Note Added: 0007761
2010-09-02 00:11	OG17	Note Added: 0007763
2010-09-02 00:12	rob	Note Added: 0007764
2010-09-02 00:12	rob	Status	new => closed
2010-09-02 00:12	rob	Resolution	open => suspended
2010-09-02 00:12	rob	Fixed in Branch	=> 0.8 development branch
2010-09-02 00:17	dpeg	Note Added: 0007765
2010-09-02 00:24	dpeg	Note Added: 0007766
2010-09-02 00:24	dpeg	Status	closed => feedback
2010-09-02 00:24	dpeg	Resolution	suspended => reopened
2010-09-02 00:24	dpeg	Assigned To	=> dpeg
2010-09-02 00:44	OG17	Note Added: 0007769
2010-09-02 00:46	OG17	Note Edited: 0007769
2010-09-02 00:55	dpeg	Note Added: 0007770
2010-09-02 01:16	StudioMK	Note Added: 0007773
2010-09-02 01:17	StudioMK	Note Edited: 0007773
2010-09-02 01:18	StudioMK	Note Edited: 0007773
2010-09-02 01:19	StudioMK	Note Edited: 0007773
2010-09-02 01:20	StudioMK	Note Edited: 0007773
2010-09-02 01:21	StudioMK	Note Edited: 0007773
2010-09-02 01:21	StudioMK	Note Edited: 0007773
2010-09-02 01:21	dpeg	Note Added: 0007775
2010-09-02 01:21	StudioMK	Note Edited: 0007773
2010-09-02 01:22	StudioMK	Note Added: 0007776
2010-09-02 01:22	StudioMK	Note Edited: 0007776
2010-09-02 01:23	StudioMK	Note Edited: 0007776
2010-09-03 01:14	dpeg	Note Added: 0007813
2010-09-05 16:34	jpeg	Note Added: 0007944
2010-09-05 16:34	jpeg	Status	feedback => resolved
2010-09-05 16:34	jpeg	Resolution	reopened => won't do
2010-09-05 16:34	jpeg	Status	resolved => closed

Relationships