SpaceNomad
-
Posts
102 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by SpaceNomad
-
-
@DMagic I just got a contract to perform a long-term orbital reconnaissance survey of the Mun in a 117 by 118 km orbit, which is a high orbit. Is it intentional that it asks for performing the experiments in low munar orbit, though (i.e. below 60km)?
-
I just updated To CapCom 2.0 via CKAN and it seems this version broke the sorting by remaining time (for both offered and active contracts). They are sorted in no recognizable order. Sorting by other criteria seems to work properly, though.
-
7 minutes ago, FreeThinker said:
I haven't created this part. Please tell me how to correct it
Well, as I already said, it's probably missing the "PLUME" before the opening braces. This is only an educated guess based on the fact, that the first such block in the file is a PLUME node. I don't know for sure what it actually does (If I had to guess again, based on the name I would say it's responsible for the engine effects) The cited node should probably be
electric_qvp { PLUME { name = Hydynelox-A7 transformName = TT localRotation = 0,0,0 localPosition = 0,0,1 fixedScale = 4 energy = 1 speed = 1 } @MODULE[ModuleEngines*] { @name = ModuleEngineFX !runningEffectName = DELETE %powerEffectname = Hydynelox-A7 } }And the remaining nodes in this file are also missing the "PLUME".
If there was a github repository, I could have just sent you a pull request.
-
And another syntax issue:
In WarpPlugin/Patches/KSPI_CTT.cfg:
// adjust positions of lower tree ============== @RDNode:HAS[#id[actuators]]The "==============" should be in a comment.
-
When testing a little script that was supposed to parse the ModuleManager cache, I stumbled over a few errors in config files of this mod:
In WarpPlugin/RealPlume/Quantum Vacuum.cfg there are a lot of compound nodes without a name. From the context, I assume they are all missing "PLUME" before the opening brace, only the first one has it. Though ModuleManager does not complain, it seems to get confused by this nevertheless, as I see literal "@MODULE[ModuleEngines*]" in its config cache after those erroneous nodes. For example:
electric_qvp { { name = Hydynelox-A7 transformName = TT localRotation = 0,0,0 localPosition = 0,0,1 fixedScale = 4 energy = 1 speed = 1 } @MODULE[ModuleEngines*] { @name = ModuleEngineFX !runningEffectName = DELETE %powerEffectname = Hydynelox-A7 } } -
3 hours ago, Buster Charlie said:
All these suggest Kerbal are the victim of some kind of cosmic joke, their creator must be some kind of space obsessed God or gods whose enjoyment involves the creation of a space fairing race of expendable crew.
Very close: They are brought by the Kraken, of course! The Kraken gives, the Kraken takes.
-
First of all: Thank you for the great mod.
I was just wondering why the docking helpers are not surface attachable. I think they should be attachable wherever docking ports are and those are surface attachable.
For the moment, I helped myself with the following MM sniplet:
@PART[NBdockingHelper*]:Final { @attachRules = 1,1,1,0,0 }Note, that I also disabled allowSrfAttach instead, because it became kind of fiddly to attach the docking ports to it without.
-
3 hours ago, Tfin said:
Ah, so the wiki is VERY wrong.
Not VERY
. At least the page on Kerbin states the correct current numbers (it's even mentioned in the "Changes" section). The Wiki is filled with content by users (so you and me 
), so if you find a place, where it is still wrong, just fix it!
In defense of the Wiki: At some time Squad claimed it was fixed (0.24 apparently), but it wasn't. And this time they weren't very vocal about it. It's hidden deep in the Changelog and I'm not even sure that the sentence really refers to this change, it's really cryptic:
Quote========================= First Contract (v0.24.0) =======================================================
- Kerbin's Solar Day is now exactly 6 hours long (sidereal day is now 59 seconds shorter).
=================================== v1.0.5 ============================================================
* Fix issue with solar day length not being calculated correctly when setting Kerbin's rotational period.
On another topic: I've actually looked into the Kerbal Alarm Clock source code a few weeks ago to find out how hard it would be to hack another calendar into it. I had assumed it would be quite easy and I just had to add some code converting the number of seconds into a date string. But the date/time code is overly complex and spread over several classes. So, not that trivial.
-
10 hours ago, Tfin said:
I hadn't considered that, but we have the fact that the kerbals observe sidereal days (sunrise being later every day until a sunrise is skipped) as evidence that they might well not observe synodical months.
Not anymore. It has been that way for a long time. But in 1.0.5 in fact the synodical/solar day was changed to 6 hours. So sunrise is now at the same time every day, at about 4:12 at the KSC (I have repeating Kerbal Alarm Clocks running for sunrise and sunset at KSC). The sidereal day is now a bit shorter (6h 59m 9.4s).
-
4 hours ago, BloodDusk said:
Higher precision numbers means more complex math, therefore, more time and processing is necessary to do calculations.
The 64 bit vs. 32 bit version is not about double vs. single precision floating point numbers. It's just a coincidence that they are 64 vs. 32 bits long as well. Both double and single precision floating points exist on 32 bit architectures and 64 bit architecture. So, I don't expect there will be "higher precision numbers" in the 64 bit version.
-
Funny. I just recently were also pondering a Kerbal calendar. I also came to the conclusion that the lacking axial tilt, and neither an inclined nor eccentric orbit would make the astronomical year quite irrelevant.
The Mun on the other hand would cause quite substantial tides (given its closeness and the fact that tidal forces scale with 1/r3 instead of 1/r2). It also causes regular eclipses.
So, the calendar I invented was also based on the (Mun-) month.
On 12.2.2016 at 2:29 PM, Tfin said:The Mun orbits Kerbin every 6 days, 2 hours, 36 minutes, 24.4 seconds. (138984.4 s)
This is the sidereal month. I would expect the synodical month (i.e. full Mun to full Mun) to be more relevant for a calendar. According to my calculation it is 141,115s (6d 3h 11m 55s). The value in the Wiki seems to be slightly off.
Based on that I came up with the following calendar:
- A month is either 6 or 7 (Kerbal) days. It would play the role of the working week.
- A (Mun-)year or Mun-cycle is a cycle of 15 months: A cycle starts with a 7 day months, just alternates between 7 and 6 days and thus also ends with a 7 day month.
This basic pattern gives you an average month of 6d 3h 12m (98 days for 15 months), so just 5s too long.
- Every 288 cycles, the last month would have only 6 instead of 7 days (and this would be called the Month of the Kraken, due to the Stolen Day).
- Thus, we get exactly 6d 3h 11m 55s
Now, what we need is names for the 6/7 days in a week (month) and for the 15 months.
-
2 hours ago, FreeThinker said:
As a mod developer of one of the most complex mods for KSP, I foresee a lot of problems. Not only because KSP 1.1 will break a lot of mods , but also after they have been fixed. The 64 bit version will open a new frontier as player will no longer be limited by memory restriction. Therefore there will be no more restraint of limiting the amount of mods loaded which can cause incompatibilities. Already the biggest problems I face are interactions with other mods that cause all kinds of unexpected behavior, bugs and crashes. After 1.1, I expect these problems to increase exponentially.
It's actually not as bad as you might think. I'm playing the Linux 64-bit version of KSP with >100 mods installed and bad interactions between mods are astonishingly rare. There is another problem, though: Performance. The lots of mods I have installed lower my FPS quite substantially. Uninstalling a group of 40 mods raises my FPS in a certain situation from 12 FPS to 26 FPS. I'm now in the process of finding out which mods are the worst offenders to decide if they are worth their cost.
It might well be that people find that after installing lots of mods in 1.1 their performance to be worse than in 1.0.5.
-
@Diazo, I tested your DLL shortly in my heavily modded main-installation with the original savegame and ship. So far, I wasn't able to trigger the bug. So, I would say bug fixed. Thank you!
BTW: If you want a little fun after the hard work, try flying the test craft. At least with stock it has a very "interesting" dynamics
Now, I understand what "Space Noodle" is referring to.
-
19 minutes ago, Diazo said:
Wow, thanks for that, makes figuring this out easy.
Then the time was well spent after all. And it's still me to have to thank you for the months of work that went into your great mods.
-
2 hours ago, Snark said:
I would have thought that the easy way to tell would be to look at the config file. The node_stack_top and node_stack_bottom give the Y coordinates of the top and bottom connector nodes. Take the difference between those, multiply by the scale, and I would think that that would be the vertical separation between the nodes. So, in the case of the FL-T200, that would be (4.442 - (-4.442)) * 0.1 = 0.8884 m. Which seems low to me... if it's 1.25m in diameter, that would imply that it's significantly shorter than it is wide, and it sure doesn't look that way to me, just eyeballing it.
When hovering over the part in the editor (VAB/SPH) there is also a small scale in the picture, which in the case of the FL-T200 is 1m. Since the part seems to be a bit shorter than that scale, 0.8884m seems about right.
And you're right that the part appears to be higher than wide (I just measured it on the screen when attached, 7cm height by 6.4cm width). But I think, that's just the perspective distortion, as the part already has its full height at the closest point to the camera, but reaches its full width further behind.
Edit: When zooming further out the distortion becomes less, as expected (e.g. 1cm by 1.1cm, so already wider than high).
-
9 hours ago, inigma said:
fresh new install on a new computer. ckan is not showing the latest ETT. you might want to raise a support issue with the CKAN folks if you haven't already.
If I'm not mistaken, the version string format changed between 20160112 and 2016-01-15, note the added dashes. I assume, CKAN considers dashes to be lower than the numerics and thus considers the 20160112 version to be the highest in this year.
It seems, CKAN has the epoch field which can be increased to tell it "we have changed the versioning scheme and consider all versions with higher epoch newer than those with lower epoch". There is also the related x-netkan-epoch field, I'm not sure how CKAN and NetKAN interact exactly.
In general, it's better to keep the versioning scheme stable to avoid trouble.
-
On 5.2.2016 at 5:49 AM, Snark said:
My personal favorite launch window planner is http://ksp.olex.biz . It doesn't have the fancy colorful chart, but it's extremely easy to use, and has a really nice graphical display of the angles involved.
The combination of Kerbal Alarm Clock and Transfer Window Planner also has a great visualization of ejection angles since the newest KAC version v3.5.0.0 (see this post for a demonstration).
-
@DiazoPhew, I finally managed to reproduce the bug with just AGExt and ModuleManager installed. The used craft file is in the following GIST. And here is a log (first load of the craft was successful, second one had the bug).
To reproduce, just start a new sandbox game, move the craft file to its Ships/VAB folder and load it from the VAB. Repeat loading until the action groups mess up. The "Big Dish" groups should only have two actions each, the "Dish" groups only one. It seems to be "all or nothing", i.e. it doesn't matter which action group you watch. After one load they suddenly all have their symmetry parts added.
If you can't make it work after several loads, try adding more
boosterssepatrons. As you said, the number of parts seems to have an influence, and maybe your computer is faster than mine. -
18 hours ago, Garibaldi2257 said:
is that possibly the ability for kerbals to climb up things?
I thought so, as well. But my Kerbals were able to climb when my Astronaut's Complex was still at level 2. And now that it's at level 3, I don't see them doing anything differently. So, I suspect the game is just ignoring that flag.
Maybe it was planned to restrict climbing with the Astronaut's Complex, but then it occurred to the devs, that climbing is something that Kerbals learn at the playground not in the Astronaut's training
-
2 hours ago, Diazo said:
However, there is no LoadFinshed flag that I could find so I'm using a timer to reset the flag. Is this a large vessel that takes a significant time to load? The timer might be expiring early.
That would somewhat fits to what I'm seeing when trying to reproduce it in my test installation. While I was able to replicate it there with the original vessel (but not with a very small vessel built from scratch), it's also much less reproducible than in my real installation (which has a lot more parts installed and thus might make the editor slower). Also, the more I strip down the test vessel to exclude mods, the rarer the event. I already started spamming stock parts to counter it
So, I was already suspecting, there might be some race condition involved. One thing I just noticed: When the issue is happening, I'm seeing a lot of
QuoteAGX New Load Okay IRHingeOpenScaleable:MoveNextPresetAction:5
messages after
QuoteBuggy 0 -SP-RT-PF-NFS+Parts loaded!
I think, in the cases, where the bug didn't happen, those messages only appeared before the "Ship name loaded!" message. Would the timer firing before the load finished explain what I'm seeing?
-
32 minutes ago, Diazo said:
@SpaceNomad I can't replicate your error but my test rig is pretty simple.
I'm using the solar panels to test, this is after several loads in a row and things look as expected.
Can you get me a more detail reproduction step, log file, craft file, any other info that might help? Until I can reproduce the error I won't be able to fix it.
D.
Okay, I'll try to find a minimal reproducer. I hoped, it would be easy to reproduce. If it's an interaction with one of my 130 mods, that might take some time
Though, only a very small fraction of them should affect the editor, so it's probably not as bad as it sounds.
Any hint, what was the reason for this bug the first time (a technical explanation will do, I'm software developer)? Might make the hunt for a reproducer a bit easier.
-
I suggest installing KerboKatz FPSViewer and KerboKatz PhysicalTimeRatioViewer (see here) for experimenting with this setting. They let you see and edit the parameters ingame.
For example with maximumDeltaTime of 0.02s I currently get 24 FPS and a physical time ratio of about 50% (which means, that per second real time only 0.5s of ingame time elapse, so slow-motion
).
With maximumDeltaTime of 0.08s I get about 13 FPS but my physical time ratio is about 100% (so I get real-time instead of slow-motion, but the display is more stuttery due to lower FPS).
-
Haven't really looked at the code, but it might be worthwhile to change it, so it can write MM-compatible configs and read it back (not general MM patches but just the ones it writes). This way, the user has only a dependency on ModuleManager, which you pretty much need for any mod anyway
Have you had a look at the TechTree editor included in KSP? I haven't used it, so can't really vouch for it, but might be worth a try. It's accessible when opening the debug screen (Mod+F12) while being in the R&D building.
-
On 1.2.2016 at 5:34 PM, Probus said:
After using YongeTech's Tech Tree Editor and Converter this weekend I have decided to convert the ETT to the Yonge model. This will greatly improve maintenance and addition of part packs while reducing errors and oversights.
Way to go @yongedevil!
You are aware that it doesn't seem to be actively maintained? The author of the plugin hasn't posted since last July and not even logged in to the forums in the last 3 months. So, be prepared to have to solve problems with it yourself; if something breaks in future KSP updates, for example. (Well, at least it should be trivial to convert it back to MM patches if all else fails.)
. At least the page on 
), so if you find a place, where it is still wrong, just fix it!
[1.8.x] DMagic Orbital Science: New Science Parts [v1.4.3] [11/2/2019]
in KSP1 Mod Releases
Posted
Ohh, stock trained me to ignore the description texts
(They normally pose more questions than they answer.)
Sorry to say that (since other than that, I really love your mod(s)), but I'm not that happy about the decision to invent extra situations and extra biomes for single experiments. There's already a lot to remember, about which experiments are possible in which situation and when they are biome-specific, and the altitude limits for different bodies (for the latter at least mods like KER help a lot). Experiments making up their own rules don't really help with that.
For the contract you could just let the experiment fulfill the requirement in high or in low orbit (you have to enter the required orbit anyway, so not much room for cheating, or just require the orbit to be entered before enabling the criteria about performing the experiment).
At least the Windows version contains the build number. My KSP Linux Version identifies as 1.0.5.0 in-game. That makes the "silent patch" really sneaky
(well, at least, the README contains the build number).