Conversation
| }; | ||
| addComponent(beaconBox); | ||
| newComponent = beaconBox; | ||
| text = "Hdg"; |
There was a problem hiding this comment.
For all panel items, default text is in all CAPS. Please change to match.
| return vehicle.autopilotValueVar.isActive ? 1 : 0; | ||
| } | ||
| }; | ||
| text = vehicle.definition.motorized.isAircraft ? "AUTO" : "CRUISE"; |
There was a problem hiding this comment.
I don't think this is right? This is the stuff for the autopilot button, this wouldn't be the text for the heading box.
| BEACON_BOX, | ||
| @JSONDescription("Make this a heading input box, which allows changing the autopilot heading.") | ||
| HEADING, | ||
| @JSONDescription("Heading autopilot on or st") |
There was a problem hiding this comment.
Change to clarify what "st" means.
| import minecrafttransportsimulator.mcinterface.InterfaceManager; | ||
| import minecrafttransportsimulator.packets.components.APacketEntity; | ||
|
|
||
| public class PacketVehicleWaypointSelectRequest extends APacketEntity<EntityVehicleF_Physics> { |
There was a problem hiding this comment.
This packet and the WaypointSelect packet can be one packet as they contain the same data, and just do different things based on if they are on the client or server. Also, you're double-sending packets back. Returning true on a packet sent to a server on the handle method will send that packet to all clients. So you're sending the request packet back to do nothing with it, then sending the new select packet. Just lump both together and return true and check for server/client for processing.
| /** | ||
| * Request waypoint selection update from client to server for vehicle | ||
| */ | ||
| public class PacketVehicleWaypointUpdateRequest extends APacketEntity<EntityVehicleF_Physics> { |
There was a problem hiding this comment.
Same comment as prior waypoint packet set.
| public final ComputedVariable autopilotAltitude; | ||
| public final ComputedVariable autopilotSpeed; | ||
| public final ComputedVariable autopilotVerticalSpeed; | ||
| // private PIDController verticalSpeedController = new PIDController(0.001, 0.000005, 0.01); |
| aileronTrimVar.adjustBy(0.1, true); | ||
| } else if (-orientation.angles.z < aileronTrimVar.currentValue - 0.1 && aileronTrimVar.currentValue > -MAX_AILERON_TRIM) { | ||
| aileronTrimVar.adjustBy(-0.1, true); | ||
| // if (autopilotNavEnabledVar.isActive) { |
| } else { | ||
| verticalSpeedController.clear(); | ||
| } | ||
| // if (selectedBeacon == null) { |
| } | ||
|
|
||
| public void navGPS() { | ||
| // double heading = Math.toDegrees(Math.atan2(autopilotPositionZ.currentValue - position.z , autopilotPositionX.currentValue - position.x)); |
| } else if (output < -45) { | ||
| output = -45; | ||
| } | ||
| // Output = Math.toDegrees(Math.asin(motion.y / velocity)) |
|
@ktokto313 In general, I agree with the changes here. The allowing aircraft to follow waypoints. The flight plan stuff, etc. What gets me is that we're adding virtual waypoints to world data when we have a physical beacon thing that's already designed for such waypoints. I feel that should be upgraded to have the same variables as the existing waypoints. I do get that altitude and such isn't something that is normally defined by beacons, but I feel one could do that here to simply have people plan out routes for general flight this way. Heading also isn't usually defined by single points, but getting it to follow a track wouldn't be hard. Plus then one could have the plane switch to the next waypoint when it gets within 100 blocks or so of the active one. Allows for automatic flying based on waypoint bits, and if we get glideslope to work could allow for automatic landing. I do agree with the bones and maths and such, and I want to keep that. Just want to be conscious of adding a bunch of different systems that interact differently when we already have something physical players can use and will probably understand better. Sure it's not technically the same as a flight plan, but your average MC kiddie knows what height means and know how to click blocks and work with GUIs and such. |
|
The flight plan and virtual waypoint was @Deepseasaltyfish plan, I think he wanted to have a system where plane can follow waypoint without getting to the point manually, placing a beacon and setting it up. I haven't give it much thought as it's within the game design area itself. Personally, I would like to have to follow and change VOR beacon manually but it's only my two cent. The glideslope already works but it's not really an autoland. Throttle autopilot doesn't work with throttle/hotas iirc. That's about the state of this PR right now. |
|
after a few months i have some new ideas, for example we could have custom automatic controller algorithm instead of hard-coded PID controller. |
|
Marking this PR as draft since it's not ready for merge. |
3 participants
No description provided.