SRL Archive - MSI Bugs

When woodcutting, MSI sometimes lowers the camera all the way down and detects the normal swaying of the player as animating. It should be fixed by a timeout, and I don't know where stuff is in MSI(and cbf to find atm) otherwise I would do it myself.

Low camera angle image:

The animation (pixel shift) can sometimes change depending on what the player is wearing. If you could post some debug (I think it debugs the pixel shift) we can see what it's thinking is chopping and maybe we can increase the count accordingly.

It was getting the same pixelshift count when it was low and not chopping(around 400) as it was when camera was high and it was chopping.

We just need to adjust the boxes/counts. I can do it tonight if it doesn't get done by then.

I thought it was the same. NCDS changed it a while ago. It's kind of tough because the pixel shift can be very different depending on what the player is wearing.

NCDS, maybe we could try checking for the ANIM_IDLE animation rather than one specific to woodcutting. Obviously, if the player is idle, we're not chopping. That seems to work well for fishing, anyway.

From: Coh3n

NCDS, maybe we could try checking for the ANIM_IDLE animation rather than one specific to woodcutting. Obviously, if the player is idle, we're not chopping. That seems to work well for fishing, anyway.

Definitely worth a shot!

What about when the tree is covering our player, it just spam clicks.

From: mormonman
What about when the tree is covering our player, it just spam clicks.

I've been (slowly) working on an algorithm to move the camera respective to the object clicked. I've been busy with other things recently though.

Woodcutting is very difficult with the new trees simply because they're so big and the leaves aren't "clickable." I'd love to hear some ideas, though. I think our current system can work pretty well, we just need some tweaks and maybe a couple failsafes.

From: Coh3n
Woodcutting is very difficult with the new trees simply because they're so big and the leaves aren't "clickable." I'd love to hear some ideas, though. I think our current system can work pretty well, we just need some tweaks and maybe a couple failsafes.

Does MSI use RedClick to confirm clicks on objects? If so you could have a timeout of like 10-20 seconds as long as the tree exists, and if you get another log the timer resets. If the time runs out, click the tree again. I know when I used to play legit sometimes I would click the tree again for the off chance that somehow it would get me a log faster, so I see no issues with that looking inhuman. Plus if you ever watch people's guides on youtube they OFTEN have this weird, sporadic, multi-clicking tendency when things don't happen fast enough :)

From: mormonman
Does MSI use RedClick to confirm clicks on objects? If so you could have a timeout of like 10-20 seconds as long as the tree exists, and if you get another log the timer resets. If the time runs out, click the tree again. I know when I used to play legit sometimes I would click the tree again for the off chance that somehow it would get me a log faster, so I see no issues with that looking inhuman. Plus if you ever watch people's guides on youtube they OFTEN have this weird, sporadic, multi-clicking tendency when things don't happen fast enough :)

MSI already has all that. :p I timeout is pretty long for Yew trees, though, and the multi-clicking chance could be increased. If you want to test it out, here's the lines to change:

• Line 280 in Objects.simba is the MaxTime (timeout) for a Yew tree. Currently it's 75000ms; you can lower it to whatever you want.
• Line 1760 is the MSI_MultiMouse (Anitban.simba) call. The 10 is the percent chance of multi-clicking, and the 3 is the maximum amount of clicks. This could very easily be made object-specific if needed.

Could you possibly have it randomly click the object again even if its not timed out?

Absolutely. I'll try to work on this more in the next couple days. I have a long to-do list. :p

E: Okay so in today's update, I've lowered the MaxTime for all trees significantly, so no matter what, your player shouldn't idle for more than 30 seconds (for Yew and Magic trees). Yes, I realize this still isn't ideal, but it's all I had time for today. I'll keep working on it.

E2: So I just thought about this a little, and right now it does time out after 30 seconds no matter if the player is or isn't chopping (time is lower depending on the tree). I was going to try and write something that clicks the trees with the camera all the way up, but watching it run, I like that it puts it all the way down. I feel like that's more human-like, don't you agree?

Now, I did notice that the clicking wasn't the best as it hovered a lot of "unclickable" areas. So, what do you think of using the trunk base color (the greenish one) in combination with the trunk color? This way it should only move the mouse over the base of the tree (which is always clickable). This also means we'd have to make the animations more accurate (which is what the thread is directed at anyway).

Thoughts?

E3: So I added a compass angle check in WaitWhileChopping as a failsafe, and updated the Yew tree colours. Things should be greatly improved, but it's still not perfect. From what I've tested, though, it works pretty well.