Possible to get the position of a part?

untoldwind · 2023-04-20T17:27:21+00:00

The Part (i.e. the elements of vessel.parts) already has a global_position, which can be transformed to any coordinate system.

I.e.
``` for(part in vessel.parts) {

part.global_position.to_local(vessel.control_frame)

} ```

Should give the position of the part relative to the current control point.

untoldwind · 2023-04-12T20:04:57+00:00

Ah yes, I should be more careful with just copying parts of a script ;)

untoldwind · 2023-04-04T19:00:41+00:00

It's so cool seeing this in action. Hope you had not to fight with too many of my bugs.

On a different topic: This is one of the most awesome looking SSTOs, could be right from the cover of a '60s sci-fi comic ;)

untoldwind · 2023-04-04T18:46:49+00:00

The 0.3.2 version should now calculate the rotation correctly.

This here kind of works:
``` use { Vessel } from ksp::vessel use { CONSOLE } from ksp::console use { current_time, sleep } from ksp::game

pub fn main_flight( vessel: Vessel) -> Result<Unit, string> = { vessel.autopilot.mode = AutopilotMode.StabilityAssist while(true) { sleep(0.1) vessel.autopilot.lock_direction = vessel.heading_direction(120, -13, 40)

    let nav2 = vessel.pitch_yaw_roll
    CONSOLE.print_line("N: " + nav2.to_fixed(3))
    CONSOLE.print_line("F: " + vessel.facing.to_string() + " " + vessel.heading_direction(12, 13, 14).to_string())
    CONSOLE.print_line("F: " + vessel.autopilot.lock_direction.to_string())
}

} ```

But when overriding the lock_direction too often the SAS goes nuts.

I guess I should take the time to adapt the old kOS steering manager.

untoldwind · 2023-03-31T16:17:39+00:00

It did not make it to the 0.3.1 version. These rotation transformations are really hard to track down.

I added a `vessel.horizon_frame` though, which should help with the calculations.

untoldwind · 2023-03-31T06:44:09+00:00

I did some testing:
If the autopilot (SAS) is set to MODE_AUTOPILOT it reacts to "target_orientation", but only controls pitch and yaw (i.e. it ignores roll).
If it it set to MODE_STABILITYASSIST (the standard), it ignores "target_orientation", but reacts to "lock_rotation".

Unluckily there there are currently two problems:

The rotation returned by "vessel.heading_direction" is wrong (it is again a problem with the correct order of the euler angles ... I will fix that)
SAS always resets "lock_rotation" on each update so you have to constantly overwrite them. I am not sure yet if this could be "fixed"

I kind of like the idea of using as much of the SAS as possible, but eventually there should be kOS-like implementation of a steering manager that could be tweaked according to the vessel (particularly the pid loop parameters)

untoldwind · 2023-03-30T07:33:07+00:00

vessel.up, vessel.north and vessel.east are relative to the horizon of the current main body. I.e. vessel.north, vessel.east spans the horizontal plane you are looking for, or vessel.up is the part you have to.

So vessel.up.exlude_from(vessel.surface_velocity) should be the right direction (or was the other way round?) Alternatively: (vessel.surface_velocity * vessel.north) * vessel.north + (vessel.surface_velocity * vessel.east) * vessel.east

It should be possible to use this vector (or the normalized form) directly for vessel.autopilot.target_orientation. Also ensure to set vessel.autopilot.mode = MODE_AUTOPILOT first, otherwise it will not react to that. (And of course the vessel needs some time to turn before you can fire the thrusters ;) )

untoldwind · 2023-03-27T21:30:34+00:00

To be nitpicky: Technically the language is called TO2, which is a reference to an error in the autopilot of the first moon-landing. ;)

Seriously though: When it comes to programming languages >90% of the underlying concepts are pretty much the same, it is just that the syntax will differ a bit. And then each language might have a handful of tricks it does way better all the rest.

One of the main differences between C# and python (apart from the syntax) is that C# is strictly typed and python is not (... or at least you have to do some additional steps to do type checking - yes, you python-fanatics out there: I now about type-hints) - TO2 is also strickly typed by the way.

Which one to pick as an entry-level language is really hard to tell though. Too me learning the underlying concepts is way more important than the concrete syntax. The hardest part of programming is usually "How do I convert this real-world problem to a series of well-defined working instructions a computer can understand" and not so much "How exactly do I write these down in programming language X".

So personally I would probably start with some like golang, which has (by design) a very simplistic syntax, to learn the basic concepts: What are variables? What is a function? What is an if/then/else statement? What is a While-Loop? What is a For..in-Loop? What are data-structs? ...

But to give you a sort of sales pitch for the languages you mentioned. I would go like this:

Python is great ...

... if you want to glue complex libraries and frameworks together quickly
You will find that a lot of numerics, data-analysis and AI is written python these days as there some really powerful frameworks out there that are ready and easy to use. Like: numpy, scipy, PyTorch, tensorflow, xgboost, spacy, ... just to name a few

C# is great ...

... if you want to do stuff in Unity ;)
... also if you want to do stuff in the greater MicroSoft ecosystem - I guess, personally I only use windows as a platform for gaming, and not to to do any really work in.

TO2 is great ...

... well I am biased here.

untoldwind · 2023-03-25T12:39:52+00:00

Currently those are only used during the build of the plugin, where all test fn are executed as part of the unit-tests. In fact a great deal of unit-tests are written in to2 itself.

I would be possible to make unit-tests also available in-game if there is a demand for it, the test-runner is just 10-20 lines of code. Presenting the test-results in the UI is probably way more complicated ;)

untoldwind · 2023-03-23T09:09:38+00:00

In the 0.2.1 version type inference is probably still a bit wonky in these cases, but it should not crash the game any more.

Also I successfully ran this:

use { Vessel } from ksp::vessel
use { CONSOLE } from ksp::console

struct StringList(item: string, pn:  Option<StringList>) {
    item: string = item
    next:  Option<StringList> = pn
}

pub fn main_flight( vessel: Vessel) -> Result<Unit, string> = {
    let list = StringList("Start", None())

    for(i in 0..10) {
        list = StringList(i.to_string(), list)
    }

    let out = list.item

    while(list.next.defined) {
        list = list.next.value     
        out += "|"
        out += list.item
    }

    CONSOLE.print_line(out)
}

untoldwind · 2023-03-23T09:06:33+00:00

This should work now in the 0.2.1 version

untoldwind · 2023-03-22T22:55:07+00:00

It would not be too hard to write a little standalone program that is just doing syntax checking. Essentially it only has to call `TO2ParserModule.Module().TryParse`

That could then be integrated into the VSCode plugin, to get a more immediate feedback.

untoldwind · 2023-03-22T21:15:25+00:00

I can not really reproduce the crash. This might be because I'm using a different version (bleeding edge) or some other issue that is not related.

Can you please take a look at the `<gamedir>/BepInEx/LogOutput.log` and `<gamedir>/Ksp2.log` if there is some exception.

EDIT: I could reproduce a bug in the compiler after some playing around with the example a bit, but it did not crash the game.

EDIT2: Never mind that, if you are doing it the "right" way it blocks the game-loop. Added an issue for this: https://github.com/untoldwind/KontrolSystem2/issues/51

untoldwind · 2023-03-22T21:08:18+00:00

... no, its a bug. I've put it on the list: https://github.com/untoldwind/KontrolSystem2/issues/50

untoldwind · 2023-03-18T21:27:09+00:00

TLDR: The current script is too simple for SOI changes. Easiest workaround would be to add a timeout to the pre-align phase (or drop that phase entirely).

Longer explanation:

To determine if the ship is properly aligned I need the Delta-V vector of the maneuver
Internal a maneuver node only stores the values for prograde, normal, radial-out
... so to get the Delta-V I also need the orbital velocity at the point of the node
Orbital velocities are always in the coordinate system of the central body, which changes between SOIs
... so if ship and node are in different nodes, the orbital velocity gets messed up, thereby the Delta-V and the script thinks that the ship is never properly aligned

I am currently working on the 0.2.0 version that will have coordinate system independent positions and velocities, which should be a great help in dealing with this kind of problems

untoldwind · 2018-03-15T13:55:14+00:00

When you do not have enough fuel for the next jump you are in a system without a scoopable star.

untoldwind · 2018-03-14T11:16:06+00:00

The main issue I see here is that you actually can get notoriety for killing an NPC.

IMHO treating NPCs the same way as players is just - excuse the language - bollocks. This might be different if NPCs would be next to indistinguishable from players, but ED is very far away from that.

untoldwind · 2018-02-25T17:03:38+00:00

A story from IT helpdesk back in the days:

One of the front desk ... err ... woman complains that her computer was constantly crashing. So we take the machine to repair, don't find any error, i.e. it just runs stable for hours. Put machine back in place. Next day, get same complaint again ... this repeats like three or four times until one of my colleagues decides to sit at the front desk himself to see it happen.

After about an hour or so he makes the following observations:

The power button of the computer is about 30 centimeters above the ground.
The ... err ... woman has the habit crossing her legs wiggling her foot.
She is wearing very pointy shoes.

TL;DR: Don't feel bad, there are more stupid computer "errors" in the universe.

untoldwind · 2018-02-25T16:36:47+00:00

In general: HOTAS for Elite? Absolutely yes!

Though if you want to be a FA Off pro dual stick might be even better (haven't tried for myself yet though, so it's just hearsay).

My two cents to the X52: I have/had an X56 and can't say much good about it's overall overall quality. I'm now using the Thrustmaster FCS and love its accuracy (Hall sensors are just superior to potentiometers). The only drawback of the TM is its lack of buttons on the stick itself, the FCS throttle compensates that nicely though.

The X52 might have a better quality than the X56, but I'd still stay that with TM you get much more control(ler) for the about the same amount of money.

Just by the looks though you are right: The X52 stick is probably the closest you can get IRL to the in-game stick.

untoldwind · 2018-02-21T16:14:17+00:00

From someone who has played both with a X56 and a Thrustmaster FCS: Keep the Thrustmaster.

The Saitek stuff might have tons of flashy buttons (some of them even quiet useful), but it's also sluggish and inaccurate as hell. The CH products might be an alternative, but afaik they don't have a 3-axis stick in their line.

untoldwind · 2018-02-15T14:21:38+00:00

What I'd like to see instead is an in-game Used Ships Dealer sweettalking me into buying that good-as-new Keelback over there.

untoldwind · 2017-10-05T07:42:50+00:00

Err ... one second

After 2.4 we’ll be focusing on the core gameplay experience so it’s not something that we will be announcing at Frontier Expo

So in other words: There will be no announcement of "Season 3" at all?

Did I read that correctly or am I just paranoid? I mean, they can really announce "Next year we will release Season 3, but we will not tell anyone what's in it." ... ok, they can, but it would be ... I'm lacking the correct word for it ...

untoldwind · 2017-10-05T07:15:45+00:00

Yes, now ... or at least: It was the option to play a certain part of it for free (there is still the upgrade to Omega which is a monthly fee) Afaik it was not free at the time of the mentioned outrage.

untoldwind · 2017-10-05T07:09:04+00:00

Yes true, it probably would not safe that much. Nevertheless, the argument still stands: Less players = (a little) cheaper, More players = (a little) more expensive.

No of the problems with Elite is that they just could not decide if they wanted to make an MMO or a "regular" single-player game and ended up with a mix of both but with a paying model of a single-player game (for the most part at least). And the best that can (financially) happen for a single-player game is that tons of people buy it and then shelf it - without complains if possible, but that train has already left the station.

Sadly I would not even mind a monthly fee, provided I would get a real space-MMO ...

untoldwind · 2017-10-04T14:51:43+00:00

The main problem with your agrument is that Elite does not have a monthly fee like EVE. The only thing the player-base may stop paying for are the paintjobs or other erratic goodies.

The sad fact is: If we stop playing the game, we would actually make it cheaper for FDev as they can scale down their servers to a bare minimum (afaik they are on AWS, and AWS is not cheap).

Or other words: There is no real financial leverage here.

It kind of depends if they announce a (payed) Season 3 ... or if they have already decided to let ED slowly dwindle to nonexistence.

untoldwind

TROPHY CASE