SolarStrike Software

Would it be possible to include the Y-axis in a waypoint? It would come in handy for navigating watery environs.

Yes this would definitely be helpful when navigating through water, I tried using player.Y before but that doesn't work lol.

I modified rom/getpos to show the Y position of my player so I had a number to go off of, but it would probably involve more code to adjust the angle of the camera to move you up or down in water. Kind of the way it does now to rotate you right or left.

I think it would be A LOT MORE effort than it's worth considering that you can only use it in water and having a y value would probably cause trouble when on land.

rock5 wrote:I think it would be A LOT MORE effort than it's worth considering that you can only use it in water and having a y value would probably cause trouble when on land.

Would it be too hard to simply accept a "Y" value from the XML file and when moving including that too? (and if y==nill use regular move)

Because other than water just I know this may be really usefull if you're in a cave! Try setting a return path to the myrmex cave's bottom! the bots goes freakish because he's actually standing closer to the end points than to to return path! (not considering Y ofc)

I also realized just now it'd make sense to redo distance function in this context, but it's a small math change no biggie there.

jduartedj wrote:Would it be too hard to simply accept a "Y" value from the XML file and when moving including that too? (and if y==nill use regular move)

If we include the y value, createpath would have to add it to all waypoints automatically. There shouldn't be any nil ones unless using an old waypoint file.

jduartedj wrote:Because other than water just I know this may be really usefull if you're in a cave! Try setting a return path to the myrmex cave's bottom! the bots goes freakish because he's actually standing closer to the end points than to to return path! (not considering Y ofc)

I also realized just now it'd make sense to redo distance function in this context, but it's a small math change no biggie there.

That's a really good point. Even if it's just for correctly finding the closest waypoint, it would be worth adding the 'y' value. It may even be useful to detect when you've fallen off a ledge.

I'm not totally sold on the y axis movement and to tell you the truth I don't think it's something I would do but I think we should add the y values primarily so we can correctly find the nearest waypoint. That, at least, wouldn't be that difficult to add.

What if you had a function to add into the onload of the waypoint file for it to use y axis, so you can load it only for waypoint files that could benefit from a y axis. Could add in another option on createpath to add y-axis.

That way you won't have y axis on everything which would make things even more complicated then they need to be.

I like the idea of detecting if you fell off a cliff but it wouldn't help you get back up though, so would be just to stop bot from running constantly into a cliff face for hours, which I've had happen to me before lol

Edit:
Had a rethink, instead of just creating a new option in the existing createpath, I'd be more inclined to make a createpathy.lua and give that lua the ability to use y-axis and also have it to include onload y-axis usage as default.
That way only the people who actually want to use y-axis can if they wish and you won't get a flood of posts from people having issues with bott using y-axis because they hit the wrong option when creating a waypoint path.

I think the best approach you be to include Y as optional. If no Y is provided then we assume the "standard" Y we use right now.
This way it would make it more compatible and not confuse people that don't use Y axis! and as for distance calculation if you don't use Y axis it won't matter much as if Y=Constant the calculation will be based on the ZX plane alone.

In regards to createpath, adding the y axis value would be a simple matter. It would also be relatively easy to to include the y value in distance calculations if it is available. In this case there is no need for options. The hard bit would be changing the bot movement functions to include y axis movement.

rock5 wrote:In regards to createpath, adding the y axis value would be a simple matter. It would also be relatively easy to to include the y value in distance calculations if it is available. In this case there is no need for options. The hard bit would be changing the bot movement functions to include y axis movement.

Yes but you can only do that When you're on water otherwise a lot of stuck errors could occur.

Y-axis movement should be limited to swimming. I cannot imagine it being useful in any other situation. Also, it would be good to be able to perform altitude calculations for the purpose of avoiding the "bot falling off ledge and being oblivious and looking ridiculous" problem.

Does micromacro use 'Q' and 'E' for moving the camera left and right? If there isn't a key that moves the camera up or down then I'm guessing that would be a problem.

Alkaiser wrote:Y-axis movement should be limited to swimming. I cannot imagine it being useful in any other situation.

So what we need is to be able to set the movement to 'swim' move at a given waypoint, then when you exit the water, you would change it back to normal movement.

Alkaiser wrote:Also, it would be good to be able to perform altitude calculations for the purpose of avoiding the "bot falling off ledge and being oblivious and looking ridiculous" problem.

Maybe if checking the y value shows that we fell off a cliff we can see if there is a closer waypoint at our level and move to that before continuing. Useful for meandering paths on the side of mountains.

Alkaiser wrote:Does micromacro use 'Q' and 'E' for moving the camera left and right? If there isn't a key that moves the camera up or down then I'm guessing that would be a problem.

I believe if quickturn is off then it uses Q and E, otherwise it writes the angle directly into memory. I guess with the y value we cold use memory writing in either case.

I have include 'Y' axis data in revision 558. It does not include 'y' axis movement. It just includes Y data and uses it in distance calculations. If someone else wants to try and incorporate y movement, the y values are at least there now.