CH Science posted:

Well that was fast! Thanks for the explaination. Makes sense and works perfectly

Gin_Rummy posted:

Ruzihm posted:

I don't know if you solved this problem already but assuming cylinder's local x axis always points towards the cylinder's right, you can use a cross product to find its "forward" direction, using the world's up as a basis.

code:

Vector3 fwdDir = Vector3.Cross(transform.right, Vector3.up); 

Gin_Rummy posted:

I'm fairly certain I tried something like this already, but it might not have been exactly this. I'll give it a go and report back.

TooMuchAbstraction posted:

My game's been out for ~50 days now and I haven't seen a single cent from it yet.

TooMuchAbstraction posted:

Well, now I'm pissed off at Steam. My game launched in the middle of July. Steam sends payments only once a month, on the 30th...and they also don't send any money that they haven't held onto for at least 30 days. Which is kind of scummy but I can see justifications for it (mostly around refunds). So I don't get any payment until August 30th.

In an astounding set of bad timing, my bank, BlueVine, did a big transition that involved changing their routing numbers, also timed for the 30th. I gave Steam the updated account information and hoped for the best...unfortunately they sent their payment early and so of course it failed. No big deal, I contacted them and asked them to try again. Response: no, we only send payments once per month, you'll have to wait another month. I pointed out that I'm a small dev, the launch money represents a significant amount of income for me, and the payment failed due to factors entirely outside of my control. Response: sorry, no, wait a month.

My game's been out for ~50 days now and I haven't seen a single cent from it yet.

Ruzihm posted:

Good luck, and if you're interested in having the forward be in relation to the surface the cylinder is on, you should be able to use the surface's normal instead of Vector3.up.

Gin_Rummy posted:

A little slow swinging back around to this one, but it does not seem to be having the intended effect, though perhaps I am implementing it wrong.

So here is what I am running for my base position/velocity scheme:

code:

// set csys position = to player object transform's position
csys.position = this.transform.position;
// ensure csys is pointing "forward"
csys.transform.forward = Vector3.Cross(this.transform.right, Vector3.up);
// apply velocity locally in relation to csys (movementY is a float from earlier code; ultimate comes just from Unity's built in input control module)
movement = csys.transform.InverseTransformVector(new Vector3(0.0f, 0.0f, movementY));
// add velocity force to rigid body, speed is defined in the unity hub for the time being
rb.AddForce(movement * speed);

Unfortunately, I am still seeing the same issue... your assumption was correct in that I basically want to lock my csys "right" to the cylinder's "right," but the csys still fluctuates between pointing left and right despite the addition of the cross product. The velocity and position seem to be working properly (csys moves in lock step with the cylinder), but since my csys keeps spinning 180 deg, my velocity essentially keeps alternating between "forwards" and "backwards," thus leading to a rolling stall.

Ruzihm posted:

Ah, I don't expect this will solve the problem on its own but you don't want to use InverseTransformVector here. That converts from world to local. AddForce expects a world space input so you would want to use TransformVector instead.

Ruzihm posted:

For shits & giggles what happens if you skip using csys and use a constant speed?

Gin_Rummy posted:

Although it's wrong, it technically seems to work the way I am intending it to. Translating to world space means that my forward direction is not correlated to the direction of my transform in any way and my object always moves in the same direction, regardless of which way I turn it. I have tried it both ways and InverseTransformVector currently gives the desired motion.

Doing it this way doesn't seem to allow any forward movement. I haven't actually been able to get anything to happen unless my movement value is in the form of a vector with appropriate float values in the i, j, and k directions.

Ruzihm posted:

Aha!! I see the problem! It's the down of your cylinder's transform we should use as its right. Another change I think would be good to prevent issues caused by the cylinder's axis not being exactly horizontal is to use Quaternion.LookRotation[.fixed] to set the rotation of the [fixed]csys exactly:

code:

// set csys position = to player object transform's position
csys.position = this.transform.position;
// ensure csys is pointing "forward"
csys.rotation = Quaternion.LookRotation(Vector3.Cross(-this.transform.up, Vector3.up));
// apply velocity locally in relation to csys (movementY is a float from earlier code; ultimate comes just from Unity's built in input control module)
movement = csys.forward * movementY;
// add velocity force to rigid body, speed is defined in the unity hub for the time being
rb.AddForce(movement * speed);

Gin_Rummy posted:

I think this is all good and better than what I had. I actually had to set movement = csys.right * movementY because of the way the csys is actually pointing (csys.forward gave me side-to-side motion). However, all that being said... my csys still flips around and does not seem to be "fixed" facing one direction. My back-and-forth rolling stall persists.

Gin_Rummy posted:

Only problem is that now my rotation is very jerky and stalls in a similar way to how my forwards/backwards motion had been doing. It will turn X deg, then stall back and forth +/- Y deg.

EDIT: Actually, it works fine before any forward/backward motion is applied, but once the object is on the move everything goes haywire. Sometimes the turning directions will even flip as well... so I'll "turn left," then after moving forward a little bit more, "turn left" has suddenly become "turn right." However, this does not seem csys related, as both the cylinder object and the empty csys track the way they should, regardless of the state of motion.

Ruzihm posted:

The problem there is that you are rotating around the local up which is constantly changing direction as it moves. Instead you could rotate around the csys's up:

FunkyAl posted:

What's a good RPG engine/script that's good for beginners but gives you some wiggle room to do different stuff with the code

TooMuchAbstraction posted:

...maybe I could write an AI mode that is "always stay on this waypoint sequence, but try to travel to the point on it that's closest to where the player is"? It'd be a basic navmesh, more or less, except it's always a line so the graph traversal is straightforward.

roomforthetuna posted:

What's wrong with just following a waypoint sequence to the waypoint that's closest to the player, so it actually follows the player as promised? Is it just that your navmesh doesn't have "find the shortest path" functionality? (Also presumably it should only follow if it can see you, so I would think it wouldn't require a very deep navmesh check.)

TooMuchAbstraction posted:

The current system isn't actually a navmesh, it's literally just "go to waypoint N, okay I reached that, now go to waypoint N+1". It allows me to set preprogrammed paths for ships, but has zero smarts in how they follow those paths.

Tip posted:

Is there any reason you couldn't just have the player start dropping waypoints once they engage with the enemy?

TooMuchAbstraction posted:

\And watching a ship bonk into the terrain, back up a bit, then drive forward and bonk into the terrain again? You want that kind of thing to happen at most once per playthrough.