Dunbaratu
-
Posts
3,857 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Dunbaratu
-
-
50 minutes ago, alartor said:
Hi, thank you very much for the update and all your work on this awesome, must-have mod!
I have noticed it comes with Module Manager 4.1.4 bundled; I assume it should work OK with the latest version of Module Manager (4.2.2), right?
I also noticed that there are a number of Thumbs.db files in several of the included subfolders... I'm assuming all those just sneaked in, and it is safe to delete them?Thanks again! Cheers to one of the (if not THE) best mod for KSP!
It should be okay to remove them.
And the newer modulemanager should work fine. -
Update: kOS 1.4.0.0 - Catch-up for over a year of little things
It's been 2 years since the last kOS release, and a lot of
small changes have trickled in. None were big enough on
their own for a full release but there's been enough of
them and it's been long enough that a release has been
needed for a while now. Since KSP 2 is about to start
hitting early access, it seemed right to get all these little
things out for kOS for KSP 1 just before that happens.This will also make it so people won't have to keep
overriding the complaints of CKAN for trying to use
kOS on KSP 1.11.x or KSP 1.12.x. (Which it worked for
but CKAN didn't know that. Now it should know that.)BREAKING CHANGES
-
The bugfix to prevent a local variable from clobbering a
builtin name could make existing scripts have to rename
a variable or two.Previously if you tried to create a variable that matches
the name of a built-in variable, it would let you but then
the built-in variable would be permanently masked and
unreachable.Now by default it won't let you. BUT you can get the old
behavior back again if you use the @CLOBBERBUILTINS directive,
if you really want to let yourself do that.
pull request
NEW FEATURES
-
kOS parts are now findable by typing "kos" into the
VAB's part search bar.
pull request -
kOS parts can be placed inside the KSP cargo inventory system.
pull request -
Comma-separated list of LOCAL or SET declarations can
now be parsed. Example:old:
local a is 3. local b is 5. local c is 10.
can now be:local a is 3, b is 5, c is 10.This is similar to how it works with PARAMETER.
pull request -
Added VESSEL:THRUST, VESSEL:ENGINES, VESSEL:RCS.
VESSEL:THRUSTis the sum of the engine:THRUST of all
the engines.VESSEL:ENGINESis the same list returned by LIST ENGINES,
but using a somewhat nicer syntax.VESSEL:RCSis the list of all the RCS parts on the vessel.
pull request -
Added OPCODESLEFT bound variable. This bound variable
returns the number of instructions yet to execute (how
much of CONFIG:IPU's instructions there are to go in
this fixedupdate). Intended to help decide if aWAIT 0.
would be prudent before entering a critical section of
code.
pull request -
Better integration with RP-1's avionics tech progression.
(No longer have to buy into the tech from the R&D building
to cause the kOS cores in avionics parts to get the upgrade.)
pull request -
Better integration with RP-1's avionics lockouts when the
avionics doesn't support the mass. (Previously kOS couldn't
use ANY of the controls when avionics were insufficient, even
ones RP-1 meant to still work with insuficient avionics,
like RCS fore and aft.)
pull request -
kOS parts are now findable by typing "kos" into the
VAB's part search bar.
pull request -
Can now read a binary file as a LIST of numeric values (one
per byte).
pull request
BUG FIXES
-
Documentation: Many small one-line documentation fixes that are
too numerous to mention all of them one by one.
pull request
pull request
pull request
pull request
pull request
pull request -
A change to make it backward compatible with a call
kOSPropMonitor was doing.
pull request -
Cause the mod RocketSoundEnhancement to stop muffling
kOS's sounds. (By explicitly telling Unity those
sounds don't emit from the kOS Part's "location" and
instead are ambient.)
pull request -
Make PART:DECOUPLER behave more consistently with what the
documentation says about docking ports.
pull request -
Reduce excessive repeats of GUI ONCONFIRM calls being triggered
when they werent' supposed to be triggered.
pull request -
Remove legacy old version of kOS's computer from the parts
definition file so it can't appear by accident in the parts bin.
This is no longer needed for backward compatibility like it
was before because this version of kOS cannot run on the
very old versions of KSP that part was for anyway.
pull request -
When reporting the terrainheight of a geoposition, it no
longer returns false results caused by seeing certain
stock parts that put trigger colliders on the "terrain layer".
pull request -
Fix SteeringManager believing RCS blocks were capable of
more thrust than they were (causing steering to be tuned
wrong when steering via RCS). Problem was caused when stock
parts now have multiple alternate RCS nozzle arrangements,
and kOS was summing up all the thrust all the nozzle variants
can do even though only a subset of those nozzles actually
exist in any given variant.
pull request
pull request -
When setting the volume name for a disk drive by copying the
vessel's name to the volume's name, it now strips out
characters that are not allowed in volume names (but are
in vessel names, thus the bug).
pull request -
BOUNDS now does a better job of calculating based on
part's colliders rather than their visual meshes which
don't always agree with the colliders.
pull request -
No longer bogs down as much when someone creates the same
LOCK expression repeatedly in a loop. (Still not a good idea,
but kOS tolerates it better now.)
pull request -
Performance: No longer pays the cost of tracking a stopwatch
when the user doesn't even have profiling turned on so they're
not looking at the timings anyway.
pull request -
A VOICE's volume is now persisting properly after playing a
NOTE. Previously playing the NOTE caused the VOICE volume
setting to get clobbered by the NOTE's volume.
pull request -
Make it so kOS's ModuleCargoPart settings don't break in
older KSP 1.10.x (which doesn't have ModuleCargoPart).
pull request -
Fix a bug when a thing that is locked is used as the
left side of a suffix when setting the suffix.
pull request -
Prevent a local variable from clobbering a builtin name
pull request -
Allow kOS code to "see" a change to a manuever node's ETA
made outside the script, after having obtained the node
in a variable.
pull request -
Fix Compiler exceptions not showing the filename correctly.
pull request -
Fix ALT:RADAR sometimes wrong when high above ground.
pull request -
Fix race condition that caused terminal to spam the log
on scene changes and sometimes spam the log enough to
lag the game for some people.
pull request -
Fix throwing exception when setting SASMODE while the
navball is hidden.
pull request -
Made the doc generation scripts work on python 3.x
pull request
-
-
Why does this always happen? Is the procedural generation limiting the options so only these regions ever show up in contracts? There's lots of Kerbin out there that goes unused because of this.
-
Does anyone else get the problem (only happens to me in JNSQ thus posting here) that the game thinks their comms are out of range for transmitting science, even though the ability to control the vessel is fine, the signal widget in the upper left shows a perfectly fine strong signal, and they're able to control the craft with it? It's only science transmission that believes there's no comms connection. Everything else agrees that there are comms connections.
And yes my DSN mulitplier is set to 4.01 and my antenna range multiplier is set to 1.01 as the instructions say (or as close as possible to what the instructions say - I have it at 1.01 instead of 1.0 because of the slider widget on the difficulty screen not letting me type a number directly and that's the closest it can get. I did also try editing the persistent.sfs file to force it to be exactly 1 just to see if that fixed it and it didn't.
For now I'm enabling the "cheat" of turning off comms when I transmit, then turning them back on. But I'd rather not have to do that if anyone knows how I can fix this problem.
EDIT: I just discovered that, weirdly enough, even though this probe cannot transmit its OWN science back home, other probes CAN use it as a relay through which they transmit *their* science back home. Weird. (Perhaps it has something to do with the vessel being packed and on rails when the focus is on some other vessel using it as a relay - i.e. the transmission works when this probe is on rails but not when it's fully loaded into focus.)
-
On 10/22/2021 at 10:10 AM, Dunbaratu said:
Has anyone run into this problem before?
The stock KSP API call vessel.heightFromTerrain is giving the wrong answer for me in Beyond Home on planet Verna. (i.e. the AGL is being returned as equal to the ASL).
Because of that wrong answer, I get the following bug symptoms:
- Parachutes on planet Verna refuse to ever full-open. [etc snipped]
- Wheels don't work right. [etc snipped]
- EDIT: Additional effect- EVA kerbals instantly go into "ragdoll" [etc snipped]
I did a bit of googling and I believe this is caused by the older version of the Parallax mod that Beyond Home uses. Parallax was doing some kind of tricks with the terrain that confuses parts of KSP's system. If so, then the bug was fixed in a newer version of Parallax itself, but Beyond Home uses the older version that still has the bug.
The instructions for installing Beyond Home are *VERY* adamant about installing exactly version 1.0.1 of Parallax and not the latest version, so I don't think there's much I can do to fix this other than to hope a Beyond Home update eventually happens that moves the dependency to a newer Parallax.
-
Has anyone run into this problem before?
The stock KSP API call vessel.heightFromTerrain is giving the wrong answer for me in Beyond Home on planet Verna. (i.e. the AGL is being returned as equal to the ASL).
Example: Landed base on Verna, Clicking the sea-level altimeter (blue wavy lines button) shows 1294m, And Clicking the terrain-level altimeter (Green mountain button) shows 2m.
In this situation
vessel.heightFromTerrainSHOULD be showing the 2m number, but it's returning 1294.93977.
Because of that wrong answer, I get the following bug symptoms:
- Parachutes on planet Verna refuse to ever full-open. They will partial-open (triggered by atmo pressure) but will never go from partial-open to full-open (triggered by altitude above terrain), resulting in a smashed lander. If I set the chutes' terrain height setting high enough, enough to match the ASL reading instead of the AGL reading, then they will full-open, indicating this is directly caused by the confused API returning the sea-level altitude instead of the ground-level altitude.
- Wheels don't work right. I can't tell if this is because of the altitude confusion or not. But they just don't act like they're getting any traction at all, and they spin in place. This could be unrelated, I don't know. But the same design of base station with wheels drives fine on other worlds like Lua and Rhode.
- EDIT: Additional effect- EVA kerbals instantly go into "ragdoll" mode when I leave the capsule and try to walk on the surface. My controls are locked out and they refuse to respond, slowly sliding along the ground.
- As I was playing using kOS, I decided to have kOS print the ALT:RADAR( which should always match the in-game terrain altitude), and it prints the SEA LEVEL altitude, not the terrain level altitude. Any kOS scripts using this end up doing the "wrong thing". This is where I traced down the problem being that vessel.heightFromTerrain is giving the wrong answer, as that's what ALT:RADAR is reading. Presumably the chutes are reading the same thing which is why they have the same problem.
I never encountered this problem before I went out to Verna, which is the first planet of Kerbol I tried landing on. When landing on the closer-in bodies that didn't require heading out to Kerbol, things were still working fine.
EDIT: Further testing, where I just keep printing out the diff between alt:radar (AGL altitude) and altitude (ASL alttitude), I found that while *in flight* above the ground, it would sometimes be correct (AGL and ASL differ) and other times be incorrect (AGL and ASL look the same), and it would keep toggling back and forth between being right and being wrong. It would be right for a second, then wrong for several seconds, then right for a second, then wrong for several seconds, then right for several seconds, etc. This feels like race condition behavior. As if something (maybe in Kopernicus) needs to keep over-riding a value again and again, and it comes out wrong only when that step doesn't happen "first" like it needs to relative to other things.)
Note, once I landed, then it was consistently wrong all the time. (and wheels don't work right, making it impossible to take off again as they always vibrate and "jam".) When I was flying above the ground in a jet, then it was wrong only *most* but not *all* of the time, exhibiting that race-condition-like behavior.
EDIT EDIT: I should point out that the stock GUI altimeter at the top of the screen was always doing things correctly, where ASL and AGL differed all the time. Even when the API call vessel.heightFromTerrain was wrong, the GUI still showed the right answer for some reason.
-
5 minutes ago, BlackEyedPhantom said:
Ok thanks
but will the 1.10 version of Kopernikus work on 1.12.2 ?
I don't know. It sounds like a question for the Kopernicus dev. I have no idea when the change was first introduced that started making scatter levitate (Where none of the recent changes after that to fix it really seem to fix it). It would depend on when that change was relative to when Koperinicus was updated to 1.12.2.
-
The problem with trees and scatter rocks levitating in midair: Recent Kopernicus changes have this bug:@BlackEyedPhantom I got it to work (I think - it's hard to prove it's fixed just because it stopped happening, since the problem was intermittent in the first place.)
tl;dr:: Use an older version of Kopernicus. Instead of getting the latest Kopernicus release that CKAN claims works for KSP 1.10.1, get whatever Kopernicus release existed *on the date when Beyond Home happened*. That will be the version as it existed when the author of Beyond Home was testing things and released Beyond Home.
Apparently Kopernicus started having this floating scatter problem a while ago, and the most recent changes in the last few months *claim* to have fixed it, but they don't entirely fix it and it's probably dependent on your computer performance whether you still have the problem. I had a brief eyeball scan of Kopernicus's code and it seems to have something to do with the when Kopernicus creates and positions scatter objects versus when KSP populates the final fine-grain terrain polygons. It seems to sometimes be picking where to put the trees based on a low-res approximation of the terrain, before the fully populated terrain is loaded in.
At any rate, whether I'm right or I'm wrong about the actual cause, an older Kopernicus seems to fix it for me.
-
1 hour ago, BlackEyedPhantom said:
Yup same problem! I also have everything on max but yea... Well the best fix so far i found is quicksave and load. I guess we will hope for @Gameslinx to update asap!
At any rate it can kind of be a problem with using airplanes because the midair trees often get in the way of takeoffs and landings (i.e. a levitating group of trees 50 meters in the air at the end of the runway). Also, when I have this problem it sometimes spawn trees right IN the runway. Even when the trees are on the ground, they're often not avoiding the runway space like they should.
It feels like the trees are basing their position on a false notion of where the terrain is. They're either using terrain from the wrong position (i.e. "let's put this tree on the slope of that mountain over there, oh wait we placed it 30 kilometers east of the mountain where the terrain is flat"), or they're maybe using the wrong notion of what the body looks like, like maybe using the stock version of what would be on Kerbin at that lat/lng instead of what would be at Rhode at that lat/lng? I have no idea but it's bizzarre.
-
On 7/12/2021 at 4:21 PM, BlackEyedPhantom said:
Hello. I have this issue where terrain scatters will just spawn mid air or sideways, like fallen trees or both. How can i fix this?
KSP version: 1.12
Beyond home: 1.5.2
Kopernikus Planetary System Modifier: 2:release-1.12.1-55
I have almost the same problem, but for me it happens right away, at Rhode, near the start of the game.
KSP 1.10.1.
BeyondHome 1.4.0, installed via CKAN, telling CKAN to only grab KSP 1.10.x compatible versions of things.
And yes, I have terrain detail on high.
Here's two screenshots:
-
2 hours ago, New Horizons said:
I have one simple question to file format of global files in drive 0. Docs mentions the suffix ".ks", but I get files without any ending when saving them in drive 0.
"When saving them in drive 0" from kOS or from outside the game in some file manager or text editor? I believe when kOS *reads* the files it can accept them without mentioning the .ks but when *writing* them you need to explicitly include it. When in doubt just state it explicitly.
Also, if you are on Windows, be aware of the secret trap where the default settings for its file manager window actively lie to you about the filename by hiding the extension portion of the filename. If you are on Windows, then in Windows Explorer (the file browsing window), open the folder Ships/Script and click folder options in the top of the window and then "view" and there should be a checkbox that hides extensions. It's turned on by default and you need to change that so it will stop hiding the true filenames.
-
"Why" as in "What is the mechanical difference in how the game implements them?" or "Why" as in "What was the reason for choosing the implementation that has this limitation"?
I can answer the first, but the second is harder as that requires dev insider knowledge.
The mechanical difference is that Gilly, being a moon, is modeled as a kind of CelestialBody, while asteroids are a type of Vessel, much like flags are a type of Vessel and Kerbals floating in their EVA suits are a type of Vessel.
The game does not calculate the effects of a vessel pulling on another vessel due to gravity, since most of the time a vessel's mass is so small that the effect isn't worth the computing time it would take to bother. Also, when you go into time-warp mode, the game doesn't *really* use Newtonian gravity from a celestial body to pull on the ship anymore, it instead just uses Kepler's ellipse formulas to decide where along the orbit path the vessel would be at time=t. To do that in the stock game model requires that the body you are orbiting be your sphere of influence center point.
So that answers the first kind of "why". As to the second kind of "why", now I have to speculate about what was in the dev's heads. But I'll do that. I just want to throw the caveat that at this point I'm trying to read their minds and this is not definitive: So here goes: To do gravity with asteroids using the stock system, those asteroids would all have to be modeled as tiny planets with their own little spheres of influence. The sphere of influence model really breaks down at that point, as you have to be SUPER close to the asteroid before it's gravity is strong enough to treat it like its own little pocket reference frame that ignores perturbations from the sun. I suspect they didn't bother because it's an organizational mess to have that many asteroids being modeled as planetary bodies instead of as vessels, especially when for the smaller ones their spheres of influence wouldn't even be above their ground altitude. Imagine if it treated them as planets what the map view would look like with all those little orbit lines. I think before it becomes even possible to do it well, the game would first have to leave behind the sphere of influence model and use an N-body model like Principia mod does. And a change like that is *massive* and breaks some other parts of how the game is meant to be simple for players. -
Update: I found a way to identify which of the thrusterTransforms are actually present in the current part variant and which are not, so I made a PR about it.
-
On 4/2/2021 at 3:42 PM, Dunbaratu said:
I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:
set steeringmanager:pitchtorquefactor to 0.25. set steeringmanager:yawtorquefactor to 0.25. set steeringmanager:rolltorquefactor to 0.25.
@garwel I had some time today to look at the problem and I think I know what's wrong. I don't know how to fix it yet, but I know the cause of the problem.
The problem also occurs in stock, not just restock, BUT it is slightly exacerbated by restock.
But what *is* relevant is that the problem is caused by changes in KSP 1.11.x versus KSP 1.10.x. It was correct before KSP 1.11.0. Specifically it did this:- KSP RCS part modules have an array of all the rcs thruster transforms (position plus orientation) for the part. i.e. the one-nozzle RCS thruster has just one thrust transform for the one nozzle, but the 4-way block has 4 thrust directions one for each nozzle.
- kOS calculated the torque capability of the RCS part by iterating over these thruster directions and summing up the torque they can give based on where they are relative to center of mass
- KSP 1.11 introduced the new feature that RCS parts have variants. For example you can use the version of RCS block that angles the nozzles slightly out, or the variant that has them straight.
- To implement the variants in KSP 1.11, the superset of *all* possible nozzles across all variants are defined in the array mentioned in bullet point (1) above. Presumably there exists a place where it's specified which of them are actually present.
- kOS didn't "know" about this change so it was still assuming all the rcs nozzle definitions in the array are all present at once. So it was calculating torque as if all the nozzles for variants other than the current variant will be thrusting too, and thus getting values much too high.
- It's a bit worse with Restock because it apparently defined more variants. (There are 9 variant nozzle positions in KSP 1.11 stock RCS 4-way blocks, and 18 variant positions in restock RCS 4-way blocks).
The fix will have to involve me finding out where in KSP it defines which of the variant rcsTransforms are the ones currently actually existing in the part, and ignoring the ones for other variants.
-
9 hours ago, John007qwe said:
I'm getting a bunch of errors in the ksp.log
[EXC 15:22:26.836] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) kOS.Screen.Interpreter.IsWaitingForCommand () (at <3ccb18ebae2a49929054690a1a176760>:0) kOS.Screen.TermWindow.ProcessUnconsumedInput () (at <3ccb18ebae2a49929054690a1a176760>:0) kOS.Screen.TermWindow.Update () (at <3ccb18ebae2a49929054690a1a176760>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
This seems to be only happening during scene setup, and only with people who have lots of mods. Once scene setup is done the messages stop. I don't know the cause but it is harmless at the moment. It seems kOS is being told to start running FixedUpdate() before the scene is done being set up, so kOS hasn't initialized everything yet. It may be a race condition that only occurs when there's a lot of mods so scene setup takes longer than normal.
-
13 hours ago, garwel said:
Sorry about that. I haven't played KSP for a few months, so I forgot it got updated meanwhile.
Okay I had a look at this today. First I started by recreating your vessel in pure stock without Restock, to see if Restock was doing anything funny to it. I got the same thing in pure stock that you were getting.
Also, you didn't tell me the reason it was taking 40 seconds was because it overshot the setpoint and kept oscillating back and forth across it. That's relevant. The picture I had in my head was that it was taking 40 seconds to turn agonizingly slowly toward the target, not a mere 3 seconds plus another 37 seconds wavering around before settling down. That's a very different kind of problem, generally caused by kOS thinking there's way more torque available than there really is. (So it thinks it can stop in an instant when it can't.)
I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:
set steeringmanager:pitchtorquefactor to 0.25. set steeringmanager:yawtorquefactor to 0.25. set steeringmanager:rolltorquefactor to 0.25.
This tells kOS "pretend the vessel's torque capability is only 1/4 as big as it's being reported to be, and act accordingly."
How I know the values are bogus - the R1-IX thruster should be doing 0.1 kN of thrust. In any one rotation axis the best case is having 4 of them helping push that rotation (i.e. pitch by having two at the bottom push one way and two at the top push the other way). The entire vessel is only about 5 meters long, so if we assume a Center of Mass halfway between one end and the other, that's a torque of 4 * 0.1kN * 2.5m or about 1Kn*m.
But the torque it was *claiming* was about 2.5to 3 Kn*m. So something is probably wrong with the kOS TorqueProvider replacement code, and I'll have to look into that. But that's a long term thing. In the mean time, try the 3 lines above (put them somewhere temporary you can remove later if a future release of kOS fixes this).
-
On 3/31/2021 at 2:59 AM, garwel said:
You can test it out yourself with this save I've made: https://mega.nz/file/eyJ2mBIY#iblUThD75r7nQX98JbwNurpCRT0RUX11uQU_OAjhPrY
Mods used: kOS (v1.3.2), ReStock, ReStock+, Module Manager. KSP 1.11.1.
I had a brief window of time to test this today but this information wasn't true. The save file is for KSP 1.11.2, not 1.11.1 so I have to re-download a fresh copy to perform the test on KSP 1.11.2, and that means I'll try tomorrow. (I barely had an open window of time today and having to prep a different install of the game with the right mods etc pushes me over the time limit.)
-
10 hours ago, JebIsDeadBaby said:
@Dunbaratu - isn't it the case of this issue?
That should only happen when the total rotation time it takes to get aligned is less than 4 seconds. The description says it's longer than that even in stock SAS.
-
17 hours ago, garwel said:
It's me again, and I'm going to talk about the same issue: latest version of kOS' handling of RCS.
I've done some testing with a simple vessel with RCS controls and no reaction wheels. With weak RCS (I used 8 ReStock's 0.1-strong RV-1X thrusters), stock SAS turns the sample vessel into the desired position in 6-7 seconds using just 1 unit of monoprop. kOS with cooked control takes about 40 s and 3.5 units of monoprop for the same maneuver.
If you install stronger RCS (8 RV-105 thrusters, 1 kN each), things get even worse. Stock SAS works just as quickly and just spends a bit more RCS fuel. kOS, however, never really managed to completely stabilize and spent at least a minute and 15 units of monopropellant to at least get close to the desired direction.
You can test it out yourself with this save I've made: https://mega.nz/file/eyJ2mBIY#iblUThD75r7nQX98JbwNurpCRT0RUX11uQU_OAjhPrY
Mods used: kOS (v1.3.2), ReStock, ReStock+, Module Manager. KSP 1.11.1. Vessel R1-105 uses strong RCS thrusters, vessel R1-1X uses weak ones. I tested by setting SAS to prograde and by using script that did "LOCK STEERING TO PROGRADE." (and a wait loop).
I am pretty certain things didn't look so bad in the older version of kOS steering. I used it extensively and the only problem I had was too small corrections when near the desired direction (and IIRC these mostly happened when the vessel was in the atmosphere). So far, my attempts to play with PID parameters haven't brought any good results.
Is it a bug or WAD? Is there a way to revert to the old system?
I don't see this when I try it in stock so I'm going to have to try your exact mods and your exact save to see if I can reproduce it. I'll try that tomorrow.
-
12 hours ago, Kartoffelkuchen said:
Is there still no support for axis-controlled robotics interaction from the Serenity Expansion?
It was never something I worked on. Not using a controller myself it's not a thing that's really on my radar much.
-
8 hours ago, JebIsDeadBaby said:
Dang, you're right on the money. Your trick does work.
That makes me wonder if it would be worth it to have kOS spend a few clock cycles copying the vectors it receives into a normalized form when doing LOOKDIRUP() and VANG(). With VCRS() and VDOT() the magnitude is relevant so it can't do it there, but for LOOKDIRUP and VANG the magnitudes don't matter. (VXCL() could do it to the first argument (the normal vector of the plane being projected onto) but not the second.)
-
3 hours ago, JebIsDeadBaby said:
I dunno if I'm again having trouble understanding frames of reference but can someone explain to me why do I get results like on this picture:
I want to get a direction pointing along body's rotation axis with up direction set to the Solar Prime Vector. I use BODY:ANGULARVEL to get the direction of the axis. As you can see both Kerbin and Mun return some proper vector. However I get very different results when plugging both vectors to LOOKDIRUP, while they should be almost identical.
The vessel is in Mun's SOI in this case and I use JSNQ.
That is really strange.
Can you try this experiment: normalize the m and k vectors into unit vectors first, before you pass them into LOOKDIRUP(). Is the mun one still zero if you do that?
LOOKDIRUP() is letting Unity do the heavy lifting under the hood, and a lot of Unity's stuff only uses 32-bit floats. It might be that the mun angular velocity is just too small to survive the floating point error in the underlying Unity call. As a rule of thumb, if you are doing an operation where you don't really care about the magnitude of your vectors, only their aim, then getting your vectors normalized before passing them through operations like lookdirup, vcrs, vdot, vang, etc, can help with precision.
(Sometimes even when you *do* care about magnitude, you can make things more precise by first memorizing the vector's original magnitude, then normalizing it and running it through the vector operator, then multiplying the result by a scalar afterward to restore the proper magnitude.)
-
On 3/16/2021 at 10:19 PM, Krauzer said:
It's been a long time since the 1.11 update, but I ran into a problem. I accepted the contract to attach the part to the satellite and it was not credited to me. None of the 2 points. Although the engineer was on board and successfully attached the part. Maybe I did something wrong, but I didn't find any information about how to fulfill this contract anywhere, so I think it's a bug.
The new contracts introduced in KSP 1.11 were quite bugged. They keep consistently having contract parameters with weird wrong values for the ID number of the parts and vessels you are supposed to repair, so that when you repair them it doesn't recognize that as being the correct vessel that went with the contract. Here's 3 issues in the bug tracker about them:
https://bugs.kerbalspaceprogram.com/issues/27308
https://bugs.kerbalspaceprogram.com/issues/27203
https://bugs.kerbalspaceprogram.com/issues/27020
It would be entirely justified to pull open the Alt-F12 menu and cheat the contract as "finished", since it's literally impossible to finish them with the ID mismatches they have. (Alternatively you could risk trying to edit your save file to make the ID numbers match so the contract becomes possible.)
-
6 hours ago, Stone Blue said:
Also, it seems a user wont know this stream of exceptions is even happening when launching craft, unless they have on screen logging enanled, or come across it when troubleshooting or digging into other issues, as game behaviour can seem normal, otherwise.
I get this with every single kOS part.
If anyone else would like to try to confirm, they can see them right after launch, by opening the Alt-F12 menu, or just enable on-screen log messages using it. Just chec the "Show all log errors onscreen" & "Show all log exceptions on screen" boxes.Thanks for the information. I'm taking further conversation to the github issue about it.
but will the 1.10 version of Kopernikus work on 1.12.2 ?
Release KontrolSystem2 (0.4.2)
in KSP2 Mod Releases
Posted
It's wonderful that someone is doing this. As the person maintaining kOS for KSP1, I felt bad that my computer is not up to being able to do KSP2 so I'm not part of the KSP2 hype so kOS for KSP2 isn't really a thing I can be working on.
(Also, I am in a job search where until I land a job it would be irresponsible for me to be shelling out the cash and free time it would take to be doing a kOS for KSP2 right now.)
There's things I'd want to do differently if I did do a kOS for KSP2 and it looks like some of those things are in the mind of the person doing this. For one thing I didn't start the kerboscript language so when I enhanced it with lots more stuff like scoping, function calls, and delegates, it was always piecemeal one new feature at a time and therefore I sided with "keep it looking similar" rather than "do it like normal languages would do it" a lot of the time. That led to, well, the weirdness that is kerboscript.