OMG do not try to catch animals with all your animal "Under care"!!!!

[Aluja89]

I disagree. It would be a common sense move to make room for something, even more so to not have something in care to overwrite. It says right in the caretaking help section how you go about ending the service, but I guess more needs to be spelled out.

Of course you'd disagree, like the good little zealot you are.

https://gyazo.com/7e4f96a1a0c80d1cb6630e0e30125d27
https://gyazo.com/5b482611fd653ab1b19871af288c2b0a

Nowhere. Sit down.

[Packetdancer]

Is it bugged though? literally every time i checked it was there...

It was bugged up until 6.21; if the weather shift happened while you were on the island, there was a chance the critter would not appear. Sometimes it would, sometimes it wouldn't. 6.21 fixes that; if you're on the island and the weather shifts at the appropriate time, the animal will spawn.

That said, Island Sanctuary does not actually persist the catch state... or at least, it didn't last time I checked (which, to be fair, was pre-6.21). In simpler terms, this means that if you enter the Island Sanctuary and the weather/time are appropriate, the critter will be there, even if you just failed to catch it and it ran off.

So if you fail to catch the alligator and it runs off but there's still like 10 minutes left in the weather window, you can go back to Moraby and then return to your island, and the alligator will be there again. Which is a detail that likely comes too late to be useful to OP, alas, but if someone else misses the alligator for the same reason -- e.g., you couldn't release an animal -- you could quickly go free up a slot, leave the island, and return to make another attempt before the window ended.

Of course you'd disagree, like the good little zealot you are.

While I disagree with Deveryn, I will point out the statement made was that the game tells you how to end the caretaker service -- which is true. It does, your screenshots even show that. I just disagree with Deveryn that "how to end the caretaker service" is the relevant issue here, because so far as I can tell no one is confused on how you discontinue caring for an animal.

The issue is that it doesn't tell you that the capture process changes if animals are under care; that an animal being under care cannot be released, meaning that if you have a full pasture and catch a rare spawn you have no way to actually accept it. (As opposed to not having animals under care, in which case you can pick a release from the window.) Moreover, the first time it tries to communicate this is when you get the capture interface pulled up and then it says you can't actually release anything from the list it gives you.

This is actually a recurring issue in the game, where UI will blithely offer you a choice which the system can reasonably know is not viable at a point where it is either inconvenient (or with this particular issue, actually impossible) to remedy the situation.

An untradable minion you already have, or loot after you've already won something for the week in a limited-loot environment? The loot window still forces you to roll 'Pass' on it, despite the game knowing there's literally no other option. You click on 'Greed' and it throws up an error message, and you then have to click Pass. Why does it even allow me to roll on things where the only valid option is Pass?

Free Company submersibles also suffer from a form of this. A submersible will come back, and I can click 'Redeploy' to send it out again with the same route... and then it will tell me the submersible needs repair, forcing me to click Finalize instead, then go to "Repair submersible components", then go back to "View previous voyage log" and now click "Redeploy". The system knows the submersible needs repair; it immediately rejects the Redeploy because of that. It ought to just grey out the button (or even better, replace it with 'Repair') when the submersible can't be sent back out.

I understand why it does this -- the loot window is kept as simple as possible, the submersible log window is kept as simple as possible, etc. You can then offload error handling into something else which can be used from multiple places. I just disagree that it's the right approach; you could make the error handling a yes/no check ("Can you roll on this?") utilized by the UI, rather than a function you call ("Roll on this") which returns an error ("You already have one.").

This isn't quite the same scenario, but it's certainly similar.

[Aluja89]

It was
While I disagree with Deveryn, I will point out the statement made was that the game tells you how to end the caretaker service -- which is true. It does, your screenshots even show that. I just disagree with Deveryn that "how to end the caretaker service" is the relevant issue here, because so far as I can tell no one is confused on how you discontinue caring for an animal.

The issue is that it doesn't tell you that the capture process changes if animals are under care; that an animal being under care cannot be released, meaning that if you have a full pasture and catch a rare spawn you have no way to actually accept it. (As opposed to not having animals under care, in which case you can pick a release from the window.) Moreover, the first time it tries to communicate this is when you get the capture interface pulled up and then it says you can't actually release anything from the list it gives you.

This is actually a recurring issue in the game, where UI will blithely offer you a choice which the system can reasonably know is not viable at a point where it is either inconvenient (or with this particular issue, actually impossible) to remedy the situation.

An untradable minion you already have, or loot after you've already won something for the week in a limited-loot environment? The loot window still forces you to roll 'Pass' on it, despite the game knowing there's literally no other option. You click on 'Greed' and it throws up an error message, and you then have to click Pass. Why does it even allow me to roll on things where the only valid option is Pass?

Free Company submersibles also suffer from a form of this. A submersible will come back, and I can click 'Redeploy' to send it out again with the same route... and then it will tell me the submersible needs repair, forcing me to click Finalize instead, then go to "Repair submersible components", then go back to "View previous voyage log" and now click "Redeploy". The system knows the submersible needs repair; it immediately rejects the Redeploy because of that. It ought to just grey out the button (or even better, replace it with 'Repair') when the submersible can't be sent back out.

I understand why it does this -- the loot window is kept as simple as possible, the submersible log window is kept as simple as possible, etc. You can then offload error handling into something else which can be used from multiple places. I just disagree that it's the right approach; you could make the error handling a yes/no check ("Can you roll on this?") utilized by the UI, rather than a function you call ("Roll on this") which returns an error ("You already have one.").

This isn't quite the same scenario, but it's certainly similar.

It's a moot point, unless it says that you can't exchange a animal under care of a mammet, it then doesn't matter because you can't stop the service while capturing a new animal.

[Deveryn]

Of course you'd disagree, like the good little zealot you are.

https://gyazo.com/7e4f96a1a0c80d1cb6630e0e30125d27
https://gyazo.com/5b482611fd653ab1b19871af288c2b0a

Nowhere. Sit down.

Your illiteracy is showing.

I'm a zealot, but you're the one fighting a common sense argument It becomes a matter of just how much hand holding needs to be done with this game and for such a simple feature. The alligator isn't even necessary for anything. It's just an aesthetic. You can get the materials some other way. I already conceded that they could add a little more text, but you want to overlook that to try and take digs at me. Try that petty bullshit with someone else.

So if you fail to catch the alligator and it runs off but there's still like 10 minutes left in the weather window, you can go back to Moraby and then return to your island, and the alligator will be there again. Which is a detail that likely comes too late to be useful to OP, alas, but if someone else misses the alligator for the same reason -- e.g., you couldn't release an animal -- you could quickly go free up a slot, leave the island, and return to make another attempt before the window ended.

I tried for another shot at something post patch and it wasn't there, so that's fixed too.

[Packetdancer]

I'm a zealot, but you're the one fighting a common sense argument It becomes a matter of just how much hand holding needs to be done with this game and for such a simple feature.

Leaving aside it being this game, or another, I firmly believe that any scenario in which you establish a given behavior (call it "Behavior A") and then have some other element which replaces the behavior with some other variant (call it "Behavior B") without calling this out, you have committed a usability fail.

Let's say I have an FPS game. I'm used to 'take cover' being the Control key. Then they introduce some new item you can equip which causes the Control key to be, like, 'fire flare gun', and moves 'take cover' to Control+Spacebar... but only while that item is equipped. And they do not document it anywhere. It is reasonable to assume players will equip the item, intend to take cover during a match, and then find themselves firing a flare gun.

You have established an expected behavior ("control = take cover") and then violated that expectation ("control = fire flare gun") without telegraphing the change to the player. It is not honestly reasonable to expect the player will magically assume this behavior has changed in the absence of any other information.

Now, conveying that information does not need to be done with some giant pop-up box; many FPS or action games will show on the hud a little series of actions, and if you had a slot that showed what 'Control' would do and replaced the 'take cover' icon with a picture of a flare gun, now you've informed the player of the change in behavior.

This is a usability failure of that sort on SQEX's part.

The previously-established behavior ("Behavior A" in our example) is "if you successfully catch an animal and your pasture is full, you are given an interface to release one of the animals". Players have thus now established an expectation that given an action ("capture an animal"), the game will react with Behavior A ("if your pasture is full, you can release an animal"). Changing a factor -- especially one which is not directly connected to the capture ("I would like this mammet to feed the animals.") -- replaces the established/expected behavior with a new variant, namely "you must release the animal manually before attempting to capture the animal" ("Behavior B" in our example).

There's no messaging which conveys that this change in behavior has occurred; it is likely, from a pure usability standpoint, that players who have made use of Behavior A in the past will expect Behavior A still applies. It's made worse because Behavior B in this case has no recovery state; you cannot successfully complete the capture, period.

And the fact that there's no recovery state (e.g. put the captured animal in a temporary holding pen until you go manually release one) elevates the severity somewhat. If it's just a 'tripping hazard' -- like my examples of the loot window or the submersible deployment -- it's annoying but does not overall affect gameplay other than "oh, right, I need to repair this thing first/click on Pass manually". In effect, you trip for a moment but can continue on.

A UX failure that you cannot continue on from -- if what the player is trying to do is no longer possible -- is a much higher priority in my opinion. Especially if the thing they're attempting is time-sensitive or otherwise limited (as with the rare spawns, which might not be available again for several days).

If I had to pick a 'zealotry' for myself, it would be 'good UX/UI design'. And I love this game, don't get me wrong, but this is one category where they consistently fall short. And this is a case in point; it's not game-breaking or the end of the world, no, merely an inconvenience. (Albeit one I'd consider high-severity by my own standards, as it's an unrecoverable state.)

But make no mistake... it is a UX failure.

[Deveryn]

My view is they established a pattern where you always have to make room for stuff before you can replace it (tomes, items). There are one or two exceptions, like squadron members, but I believe even there you wouldn't be able to replace a member if they were out on a mission. Leaving stuff in the care of mammets has clear limits. You likely wouldn't interact with anything in their care otherwise (be it crops or animals), so I don't see how it's a failure on the dev's part to not allow you to replace an animal in care. Again, I said they could probably use a little more clarification, but that's it.

[Packetdancer]

My view is they established a pattern where you always have to make room for stuff before you can replace it (tomes, items).

I would argue that people do not tend to approach animals with the idea that they're akin to tomestones. You're not wrong that they're similar; you have a cap to how many you can hold (2000 tomes, 20 animals), and failing any other element you cannot obtain more beyond that limit. But they are presented in a fundamentally different manner.

And more to the point, when discussing "establishing a pattern", you initially start with a very low cap on how many critters you can catch. People will quickly exceed that cap when initially hunting critters (whether common or rare). Crucially, at this point when you first catch an animal in excess of that cap, it is extremely likely that you will not have unlocked caregiver mammets.

It is not super likely that a player will have gone "oh, I have five animals in the pasture, I want to catch a new one that I see right here in front of me and I can only have five" and have gone back to the Homestead to release an animal. They may not have actually noticed what the initial limit was. They certainly are going to be more likely to want to capture the animal right in front of them right now.

So they capture it... but they have no slots free.

If you want to argue that people should assume the same patterns hold true as with tomestones and inventory items, it would say "You have no pasture slots free, and must release an animal before trying to catch a new one." Ideally it would do this as soon as you tried to click on the animal to capture it, thus preventing using traps or scaring the animal away. But either way, a user catching a rare animal in the future would have already been primed with the expectation that you must release an animal manually and then go catch a replacement.

Instead, the game presents an interface showing your pasture and asks "which animal would you like to release".

At this point, it no longer matters what the rest of the game does with other systems, because you have now established a pattern specific to this system; there's now an expectation of this being the functional behavior. "If my pasture is full when I catch an animal, it offers me the chance to release it."

Changing the behavior because an animal is under mammet supervision is a violation of that expectation, because it happens without notice. This could be addressed by a simple note on the pasture window that says "Animals must be removed from mammet supervision before being released into the wild."

Where this is a problem rather than merely an annoyance is that, as I said, it's an unrecoverable error. To wit, by the time you receive the error, it is too late to do anything to resolve it.

And that is the bigger usability sin commmitted here.

Where I think we disagree is that you feel that while the notice in the window would be a good idea, you also seem to believe the player should have intuited from other systems in the game that putting an animal under mammet supervision would inherently change this behavior; I just can't find it in myself to agree with that.

My every experience in game design and systems engineering leads me to believe that you must assume the end user will -- in the absence of any additional information -- assume that the result of Action A will continue to be Behavior A. Changing the result of Action A to something else without communicating it to the end user is never a good idea.

(I have very strong opinions about UX/UI in general, as well as accessibility in particular. I've made no secret of this.)

There are one or two exceptions, like squadron members, but I believe even there you wouldn't be able to replace a member if they were out on a mission.

You're correct, but crucially, so far as I recall attempting to accept a new recruit while someone is out on a mission is a recoverable error state. It says "You cannot replace <X> while they are on a mission." You cancel, you wait until the mission ends, and then you accept the recruit.

A usability failure that leads to an error state is unfortunate, but no game is going to be perfect. Where you want to try to be really careful is that the error states should, wherever possible, be recoverable.

As an example, if there's a rare item I'm rolling on and I win it but my inventory is full, ideally it should prompt me "what item would you like to discard" rather than just going "LOL NOPE" and throwing the item into the void. The former (allowing me to discard an item and then obtain what I wanted) is a recoverable error; laughing at my pain as you hurl the item I wanted into the digital void, forever lost to me, is not.

A usability fail that's recoverable is an annoyance. A usability failure which causes user action to fail with actual loss of something -- an item, an opportunity, whatever -- is going to cause a lot more potential ire from end-users. Even if the thing lost is largely valueless.

Because it's often not the loss of the item that annoys an end-user most, but the fact that the loss happened in a fashion that felt unexpected and out of their control.

(Again: strong feelings about usability and accessibility.)

[Deveryn]

These are fair points, but in the end I feel like people shouldn't put too much trust in the system to catch all potential scenarios. Sometimes you need to stop and look at everything before you proceed. It's kinda nice that they even let you release animals remotely. I never knew about it until this thread came along, but maybe that shouldn't have been put in place to avoid the latter scenario. I don't see it as something they can fix, as it involves working with the NPC, where the pasture is just part of the whole "decoration" system.

[Packetdancer]

I don't see it as something they can fix, as it involves working with the NPC, where the pasture is just part of the whole "decoration" system.

You're right that it's almost certainly got some factors on the back-end which make it difficult to let you release an animal that's in a mammet's care. But that isn't actually the only way you can fix a usability issue like this.

For instance, what I'd probably do is to make a check as to whether or not your pasture is full when you first attempt to catch an animal. Rather than immediately using the item, have a popup that says "Your pasture is currently full; attempting to catch <animal> will require you to select an animal to release an animal back into the wild. (If an animal is under a mammet's care, it cannot be released.) Do you still want to try? [Yes] [No]" (Obviously, if you click 'Yes' it doesn't prompt you again until you try to catch a different animal, to avoid the dialog popping up repeatedly and driving a player insane.)

If you click 'No', you do not try, you can go remove an animal and then come back; if the one you were trying to trap is a rare spawn, you don't chase it off or lose it. And if you click 'Yes' and catch it and then cannot put it in the pasture because you cannot release any animals, you at least cannot say the game did not warn you.

[TaleraRistain]

If you can do this with a full pasture outside of caretaking, it seems odd to not be able to under caretaking. Have you submitted a bug ticket somewhere? It may just be a corner case that got missed in testing.