This topic contains 9 replies, has 4 voices, and was last updated by 
-
Posts
-
Is there a way to adjust the waypoint distance tolerance, as you can with stealth?
I need to be not close but right on top of the waypoint I make to select the right npc for a teleportNpc() function.
The waypoint distance tolerance is just too far away to select the correct npc when there is three of them close to each other.Yes, I have tried many angle() and vangle() functions but no matter the angle of the camera if you are not right on top of the waypoint then sometimes the wrong npc gets selected and the bot gets stuck continuously selecting and deselecting the same wrong npc more or less breaking the scenario.
I’ve noticed that this is the only problem I have with Miqo.
deliverCollectables()
deliverGCGear()
repairNpc()
teleportNpc()
These 4 functions require you to be closest to the correct npc.The easiest solution I can think of would be to have a
targetNpc(“Name of Npc”) Function
IE: targetNpc(Entrance to the Barracks)
Then use teleportNpc() and so on
or let us have an option to adjust the waypoint tolerance which in my opinion is the wrong way to go about it. It would look to bottish to go to exactly the same spot every time. That’s “I Guess” is why the waypoint distance tolerance is there in the first place.This is not a QoL suggestion it is a flaw that needs to be addressed. This is the only thing that breaks my scenarios. Most of the time being close to the waypoint to select the npc is fine but even if the waypoint is in the guys face the waypoint distance tolerance puts me to close to the wrong npc.
There is nothing worse than testing a scenario for days with no problems then running it overnight to find the bot stuck selecting and deselecting the wrong npc.
Many people can attest to this “I’m Sure” to being a problem.
Please give us the ability to select the correct npc every time and not break the scenarios at random times,
just because of a waypoint distance tolerance design flaw.Yep same here, but few and far in between it still happens
the worst spot I’ve seen is the Entrance to the Barracks in Gridania
I’ve spent four hours testing, adjusting waypoints and camera angles
just to enter the barracks.
If we had a targetNpc() function Grids would be much quicker and easier to create.
less than 15 minutes to create the Scenario and grid and 4 hours to adjust a simple correct targeting solution suks. lol
but I think i finally have it.
If you dont mind Lyfox can you give it a few tests to see what u think?I created it in a way that you can start it with chapter:
1 Enter Barracks
4 Repair
5 Turn in GC Gear
no matter were you are in gameand chapter:
2 Start Command Mission
3 Leave Barracks
if you are already in the barrackschapter 2 is the only chapter users have to worry about settings.
1-were their food is on hotbar or to even use it at all
2-Set FullClear
3-Set Dungeon
4-Number of RunsI’ve learnt how to do scenarios, grids from using, tweaking many of yours.
So hearing your input would be awesome.Looks pretty solid. I dont have a character in Twin Adders so cant give it a full test drive but yea i can see what your problem is. Theres another NPC standing uncomfortably close to the entrance. But since youre already using angle() functions theres a very simple solution.
Waypoint(2) Angle(0.50) vAngle(-1.48) holdKey(w, 0.4) // <- this teleportNpc()It will push your character into the door just enough to get past the annoying NPC.
Yes, Scenario Engine is still in Beta stage and we are grateful for the constructive feedback you provided.
Both of your requests are relatively easy to implement.
However, targeting NPC by name would make scenarios incompatible between different game languages and create additional problems for Import / Export feature.The purpose of waypoint tolerance distance is to avoid extreme camera jolting when traversing through a long pathway and reduce delays between path segments. But it shouldn’t be a problem when arriving at the final destination.
So in addition to the solution you have already discovered we will implement a function that will allow precise arrival on the destination waypoint. And if it’s still not enough to address this issue, we will consider alternative ways to solve it.
It should be available in the next beta version.
Thank you for your feedback very much!The title of this post made me think of something I’d really like to see for gathering grids, a new type of waypoint…a “guideline” if you will. This would be a 3-5 yalm 3d area (marked by a waypoint) that Miqobot aims at like any other waypoint and will pass through but will never stutter/pause in the way she does with the current waypoints. Currently, she does this even if the points are in a straight line and I edit every grid I download to remove this as much as I can…but really it’s not something you can completely get rid of.
An alternative to this would be if Miqobot used the 2/3/4 trips left and didn’t release the movement key upon arrival at a point until there was only 1 trip left. I realize this might create more camera movement steps and be a variable that could create issues, so maybe an optional toggle tied to each grid would be best for this.
Hopefully one of these can happen, it would do wonders to make the bot look less botty. 🙂
Yes, the system you describe is already implemented for battle navigation 🙂
You can find screenshots of upgraded navigation grids we use for combat in the development section: Combat | DevelopmentAfter the core battle system is stabilized, it will be adapted for common navigation as well.
You must be logged in to reply to this topic.