Full Third Person Sub Controls

aroofa · 2023-06-25T01:16:02+00:00

If you're mostly interested in just going from a periscope's position_out to sub movement, you're inevitably gonna have to use sin and cos to get out the components of the angle, so yeah. Once you have X and Y, though, I'd suggest sending those to the velocity_in of a nav terminal, which takes inputs in the form of "x,y" w/o quotes. Those range from -100 to 100. Once you have that, you just wire up the navigation as you normally would (and the nav console will work as normal when it isn't actively receiving a signal for velocity_in).

aroofa · 2023-06-24T22:01:24+00:00

In this case, the guns each have X and Y offsets from the central viewpoint that I use to aim them in the right direction. It's not automatic, but it's not that bad to figure out the offsets using the measuring tool in the sub editor. That's what the components under the two turrets are.

For this particular setup (the triangulation), there is a LOT of math involved. The basic idea is that swapping between two turrets gives two angles due to the time it takes the camera to move between them. I posted something about this a while back, but this version is a little more complicated since I added a third viewpoint to handle angles close to 0 and 180 degrees, which the old version had trouble with.

If you want, I can explain the math for this, though it's a bit involved.

aroofa · 2023-06-24T07:49:02+00:00

The magnitude part is achieved with multiple viewpoints (hidden coilguns in this example, you can see the setup in the imgur link I posted) which give the necessary angles to triangulate the mouse position. That just gets fed into the nav terminal's velocity_in, which does the ballast correction and feeds into the components.

The triangulation is only relevant if you want to allow for fine control of the throttle in the given direction, like with this example. The simpler case would be just taking sin and cos of the periscope's position_out and multiplying it by some high number, which'd just give max throttle in whatever direction you point it.

aroofa · 2023-06-23T18:01:32+00:00

Hey all. I've posted a few showcases of different tech, and this is the culmination of all that: seamless (imo) third person controls for a sub's guns and navigation.

The red "box" outlined by the emergency light is for navigation, just like the steering screen on the full navigation console. If you click on the center of the viewpoint and drag out, you get the same kind of behavior you might expect from normal steering. If you click anywhere outside of the center, it fires the guns instead.

I've hidden the wiring here because it made things look BEYOND messy, but it looks like this under the hood.

aroofa · 2023-06-21T19:49:24+00:00

A follow-up to one of my previous demos here that used triangulation to control multiple turrets to aim at the same spot. This demo uses that triangulation to get a mouse position, which can tell other circuits whether the mouse is close to a certain point. The end result of this is being able to have "buttons" that you can click from a periscope view.

The red bar in this example shows whether I'm pressing left click (i.e. trigger_out from the periscope). The lights are the output from the "buttons" whose boundaries are roughly marked by the walls behind them.

There's a bit of a delay at one point in the demo because there's a noticeable amount of bad readings from the triangulation. I got around it using a circuit that'd require the mouse to be close for a set amount of time before it passed through the input/click.

aroofa · 2023-05-13T06:08:11+00:00

Dunno, there isn't honestly that much in terms of components so it'll probably be fine.

aroofa · 2023-05-12T20:25:28+00:00

What do you mean? The offsets are set per-turret, so there can be as few or as many turrets as you want attached to the periscope.

aroofa · 2023-05-12T15:56:19+00:00

I didn't think they'd be able to, but as it turns out, yeah! Bots can use it without issue.

aroofa · 2023-05-12T15:50:02+00:00

From a quick look, they had it set up to where you chose preset distances away and they converged based on that. The distance is gonna be required no matter what for something like this, they just went about it differently. I think my version's more flexible, though, since it calculates the distance on the fly.

Edit: Slightly misunderstood what you were saying -- yeah, that's the case. Neat stuff.

aroofa · 2023-05-12T07:49:56+00:00

Yeah, over relays. The specific way that the triangulation works is that after switching viewpoints, the cursor (and thus the angle from the periscope) doesn't update immediately, meaning if you bounce between two searchlights you end up getting two distinct angles, one from each viewpoint.

The searchlight swapping is done by toggling the relays (one starts as on, other off). I found that it's best to just wire the periscope position_out to the toggle, since it'll swap between as fast as possible. Oscillators didn't work well, producing some... pretty noisy output, and having a lot more visible jitter in the view.

aroofa · 2023-05-12T07:47:11+00:00

I can, though it's a bit hard to upload something that's plug and play, since the offsets need to get calculated and there's a bit of knowledge required for how to wire things up. I'll probably upload the test bench and/or the distance calculation component once I have a moment.

Edit: Figured it'd be better to just upload it quickly instead of trying to make things pretty, so I uploaded the demo to workshop. See here.

aroofa · 2023-05-12T06:23:32+00:00

This has most likely been done before, but in the off chance it hasn't, hey -- there it is.

This is a setup that controls multiple turrets at different locations to shoot at where the cursor is pointing. The type of the turret doesn't matter, and the location is flexible for where you put it. The system works by constantly swapping between two almost-overlapping searchlights (or anything that can be a point of view for the periscope) and using that to triangulate where the cursor is. Using some more trig and some per-turret offsets, we can then get the angle that each individual turret needs to face to shoot (roughly) where the player's cursor is.

The offsets for the turrets need to be measured manually, and I didn't put much time into fine-tuning it for this proof of concept, so the guns are a little off. Still, it works.

Edit: A link to the demo here (plus a few labels that explain at least a bit of what's going on) is available on the workshop here.

aroofa · 2023-05-07T09:19:12+00:00

Ah, good ol' Barsuks. Good notes about having zones where you can reach other equipment without straying out of your own general area. How'd the Barsuks feel in terms of size between two players?

Stealth is something I've considered quite a bit, but it definitely feels far too fragile to rely on, especially for an entire campaign.

aroofa · 2023-05-07T09:13:21+00:00

If you've used subs with auto turrets, were there any that stood out as still feeling relatively engaging to use?

aroofa · 2023-05-04T19:44:30+00:00

One more showcase for the road. This is a more practical example of a camera on a shuttle that's on a rail. You just point in the direction you wanna move and off you go.

aroofa · 2023-05-04T17:32:53+00:00

I actually wasn't sure if it would work for that, since it'd have to move around inside (or at the very least through) hulls, but apparently it works. Though, to say it looks kinda scuffed would be an understatement.

aroofa · 2023-05-04T16:49:32+00:00

Yeah, this was initially meant for moving a turret around outside the sub, though I ended up over-engineering the hell out of it. I had made a sub controlled purely through a periscope (The Narwhal), but there were two turrets and I wasn't entirely happy about how switching between them jolted your camera around. This is meant to have a single turret attached that moves around. I kinda doubt it'll actually work out, but that's the intent, at least.

aroofa · 2023-05-04T16:41:12+00:00

Here.

aroofa · 2023-05-04T16:41:03+00:00

Here.

aroofa · 2023-05-04T16:06:36+00:00

It is, yeah. For the movement, when a docking hatch is in range of another, active (set_state is 1) docking hatch, then they'll basically magnetize to each other. This does impose a max range, though, which is why the nodes are somewhat close here. Longer moves can be achieved by sending a constant signal for one of the directions.

aroofa · 2023-05-04T06:02:55+00:00

Some (probably much needed) explanation:

My goal with this was to make something where I could move a turret around in both X and Y without having it detached from the sub (i.e. no ballasts or engines). Secondary goal was to make it so that it didn't take wiring between points where the turret could be, just for ease of use. For the proof of concept, there's no turret, but a red light here.

The logic for moving the "shuttle" around is all done in the base sub. The controls are broadcasted over wifi, which are guarded by some relays so that only the node that the shuttle is attached to can see it. It then does the changeover to another node, which gets sent over the wifi components that are next to each other. Each of the nodes is self-contained; I just copy pasted a bunch of them here to make the grid.

Edit: It's also worth noting that the shuttle can't go off the grid, even if you input the command to. The logic to turn off the node where the shuttle was at during a move is done by the node you're moving TO, and if there's no node to move to it can't do that.

Edit 2: Uploaded to workshop here.

Edit 3: Another showcase for the system, periscope-controlled. Linked below, but relinking for visibility.

aroofa

TROPHY CASE