Warrior General Games

This has caused me to mis-train an attribute a *lot* of times, and I'm guessing many others.

If you change the attribute, THEN the intensity of training, the attribute selection resets to what it was on your last training.

So if my last train was Stamina Normal and I just rolled over the bar, and I go to train again, I first select "Speed" then I select "Light", click train, and... Stamina + Light trains. Yay?

Don't mean to sound like a rant, I think it's a legitimate bug (or at least bad programming that should be looked at).

I just verified this. Shouldn't default back like that as I'm sure it has caused some issues with some users.

Likely a bug

For some reason I thought this had come up before but I can't find it anywhere.

Moving to QA for verification

BUG - NEEDS VERIFICATION

I know I've commented on this before, but it may not have been a bugs thread.

I'm not sure exactly how fixable this is; this may be a limitation. The problem is that the list of attributes is dependent on the intensity drop down selection. So when you pick the training intensity, the attribute list drop-down is regenerated (so the correct % gains will be displayed).

Now, when it first rolled out, the attribute list was performing the default action of highlighting the first choice in the list - what this meant was if you were training light/agility and you switched to intense, the attribute changed to Strength. This was annoying, so Bort instead coded it to start by highlighting list item #N, where #N is count in the list of how far down the previous selection was. This only works because the attributes populate the list in the same order no matter what intensity training you choose.

I don't know that you can actually read the selection of the box when the upper drop-down is changed, so I'm not sure it's possible to store what attribute you've changed it to. It *might* be, but this might also be a restriction.

I'll mark this as Bug - First Verification, as Bort should make the final call on if this is a restriction or not, but I want to set expectations going in that web interfaces create limitations that suck sometimes.

Isn't this a suggestion? I agree it should be fixed, but I would say its more of a GLB quirk than an actual bug.

Originally posted by Djmr
Isn't this a suggestion? I agree it should be fixed, but I would say its more of a GLB quirk than an actual bug.

i wouldn't say so, just because i've almost accidentally trained something a few times, changing the target first, and then the intensity.

i agree w/ niboris on this one. It's annoying but not sure it can be fixed.

Originally posted by Djmr
Isn't this a suggestion? I agree it should be fixed, but I would say its more of a GLB quirk than an actual bug.

It's borderline, I agree, but it's counter-intuitive enough that I'm okay with calling it a "bug". Except it may be a limitation. Not entirely sure - after all, Multi-train works okay even as it updates the lists while you select downward.

Oh I think Bort can fix it pretty fine just by saving which attribute is currently selected for training and switch to that one when attribute training intensity is switched. I did something similar when I was in college.

I was thinking more about how intended this is, since it's logical to think that a user may of wanted to check the different gains from training other values, then wanting to switch intensities (I don't know but just an example). Maybe if it gets changed, some players may suggest to change it back since they may like the way it is. My personal feelings are that it should be changed though.

IMO, this is a great suggestion, not a bug.

Originally posted by Stray Doug
IMO, this is a great suggestion, not a bug.

Originally posted by robponce
Originally posted by Stray Doug

IMO, this is a great suggestion, not a bug.



shut up you fools it will only get done if we call it a bug!!!!!

Originally posted by Djmr
Isn't this a suggestion? I agree it should be fixed, but I would say its more of a GLB quirk than an actual bug.

I'm sure it could be fixed, but I definitely agree that it's a suggestion and not a bug.

Originally posted by Stray Doug
IMO, this is a great suggestion, not a bug.

To me, the definition of a bug is something that behaves unexpectedly.

Saying "Great Suggestion" means that, to me, that you expect it to behave in some way, and it doesn't. I think the same thing. therefore, i'm fine with calling this a bug and moving it along. If bort can't do it, or if it was done that way for a reason, then it can always get thrown aside.

Second Verification.

Originally posted by RMiller517
To me, the definition of a bug is something that behaves unexpectedly.

The definition of a bug in GLB is something that is not working as Bort intends it. In my opinion, this is a suggestion. (although a very reasonable one)

I am going to raise this with the lead bug mods, and if 2 or more disagree with me, I'll send it up as a bug. Otherwise I am going to move it to ISSUES NOT DETERMINED TO BE BUGs.