Jognt
-
Posts
1,076 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Jognt
-
-
On 12/18/2020 at 4:18 PM, kari1393 said:
Hey, love the mod, been using it for pretty much all my fairings. I noticed a bug (?) however. The fairings don't obey the 'Decoupler: Disable staging ' button from the right click menu when building (the action stays in the staging sequence).
I second this. Not sure why nothing changes when that button is pressed.
-
13 hours ago, Trung said:
i have a question, put Kopernicus1731TempFix.cfg into KSP/GameData or KSP/GameData/new folder
KSP/GameData/Kopernicus1731TempFix.cfg or KSP/GameData/folder/ Kopernicus1731TempFix.cfg
thanks to read this
That workaround hasn’t been needed for over a year. Do not use.
-
On 11/10/2020 at 2:25 PM, MarsUltor said:
Isn’t that kind of the point? If squad is not developing KSP2, and they do not appear to have any new games coming down the pipeline, it seems like continued support (and perhaps more expansion/parts packs) would be the obvious road; this is especially true if they want to maintain revenue, because it’d be reasonable to expect us rabid fans of the game to buy the expansions without question.
If Squad goes SaaS, I’m blaming you.
-
On 10/22/2020 at 5:32 PM, pandaman said:
Basically yes. Move your cursor over the icon and wait a second or so, it will sort of 'reset' it so that it works again. You can then use your mouse normally. You will then need to click windows to activate the transfer in the usual way. It is a bit inconvenient, but it works.
Cool, thanks. I'll give that a try until a proper fix has been done.
9 hours ago, DeadJohn said:That's an unrealistic expectation. If a game can do that, it means "maximum" isn't very high quality.
Let's be honest here.. it's not the game that can't do it.
-
6 minutes ago, pandaman said:
Try hovering the mouse over the resources tab (top right). Not a 'fix', but quick and easy work around for now.
What do you mean? Just mouse over the icon, mouse over the bars (all?), and it’ll work again when no longer mousing over?
-
8 hours ago, Lewie said:
Hey guys...I’d just like to say that Squad definitely knows about the fuel transfer bug (amongst others!) and that they are probably working very hard to fix it. Every update we see bug fixes, there is no need to clamour for such fixes. Squad knows about these, that’s why we get change logs with all the fixes. Just hold tight, and don’t get upset. After all, ksp was completed years ago. The continued (and FREE!) updates are not something that they have to do. Like I said, just be patient.
Cheers-
Lewie
I think we can expect them to unkerbal the things they kerballed in those free updates.
We’re not talking about niche use cases here. Every freaking time I fuel transfer I have to do a dance with quicksaves and quickloads. That gets old real quick when you’re using reusable landers and stations.
-
1 hour ago, OnlyLightMatters said:
Even if I am a bit of a creator myself and even if good feebacks & the opportunity to do better is a good incentive to me, I don't. I would have liked a bit of an explaination, if it is a time or ressource problem, a lead-design relative decision... I am willing to give a hand if possible, even if I have to learn many things on the subject before I can produce a thing.
If you do things very well for long enough you start to realize that you have to draw a line and say “Not doing that.”
Because people will keep trying to get you to do more work for less money. Especially when modding in your free time.
At some point “It should be an opportunity to do better!” starts sounding like “We’ll pay you in exposure!”
It’s in the FAQ for a reason.
-
11 hours ago, m4v said:
I'm ending this hiatus, new version!
== Version 1.0 * Update for KSP 1.9 and 1.10. * Improved plugin performance. * Add support for parts with multiple ModuleRCS and ModuleEngine. For modded parts like those from SSTU mod. * RCSBA now remains active while in Crew Screen. Can be disabled in settings. * TWR readout in translation mode, disabled by default (See settings). * DCoM Offset readout, disabled by default (See settings). * Redone documentation.
Many thanks to @linuxgurugamer who keep the plugin in working condition these last 4 years, for the time being I'm going to keep the plugin updated.
I have no clue how CKAN works these days, so the update is not available there yet.Made a pull request so sometime soon it should be in CKAN.
You sir, are a legend.
-
15 hours ago, Krazy1 said:
I'm having similar problems but it's getting worse as I add more craft in my savegame. Every time a craft crosses into a new SOI, the orbit changes. Worst case, in a polar orbit at Moho, I warped from 1x to 5x and the ascending node jumped about 15 degrees east/ west every time I warped or stopped warping.
Yep. I still can't bring myself to pay for the DLC.
The orbit line changing during warp and jumping back to where it should be after warp is normal afaik. I'm talking about the orbit being different permanently.
-
12 hours ago, Geryz said:
Now I properly installed CTB, it didn't work, have tried deleting reinstalling it and its dependencies via CKAN multiple times, but I have noticed every time I start KSP with this setup, this shows up (ZeroAVC is one of CTB's Dependencies, so maybe this is causing a problem?)
I mean by this point you're probably thinking I'm trolling and I don't blame you, but I'd really appreciate if I somehow got this modpack working eventually
That’s normal. It’s just zeroavc’s way of letting you know it’s doing its thing.
-
16 hours ago, aradapilot said:
I also can't figure this out, any takers?
Hold ALT while pressing the < or > key if you want to use physics warp instead of on-rails/spaceWarp.
-
6 hours ago, Entropian said:
Yep, bugtracker page here: https://bugs.kerbalspaceprogram.com/issues/25761
It's been around for years, as far as I know.
@KerbalKiller2000 and @Jognt , got anything to say on the issue?Lost my first Eve mission because I used "Warp to Maneuver" to warp to my 105km Pe burn to circularize and found myself to be a hot flaming mess inside the atmosphere.
I've now installed a mod to auto-quicksave every minute. This game's bugs are ridiculous. *looks at non-discounted price & rolls eyes*
-
On 8/14/2020 at 3:28 PM, Daishi said:
I'll get a few models made for the next update
Yeah that's weird, been an issue for a while. I'm not sure we have a way to fix it :\
Anecdotal: I noticed last year when I was troubleshooting another problem by removing mods from GameData that the ‘all models show at once’ problem was gone after removing one half of my GameData. (Keeping dependencies present best I could)
I never found out what caused my other problem and quit playing for a while, so unfortunately I never dug further with regards to the model thing, but maybe this can help those currently affected.
-
On 7/17/2020 at 10:57 AM, Iodyne said:
Just wanted to post this in case anyone finds it useful. MkIV was not working with RealFuels because of the tankSwitching and an outdated? config for RealFuels. So I changed the RealFuels config (in the RealFuels gamedata folder) to something like this (repeated for each part):
@PART[mk4fuselage-1]:FOR[RealFuels]:AFTER[MarkIVSystem] { MODULE { name = ModuleFuelTanks volume = 80000 type = Fuselage } !RESOURCE[*] {} !MODULE[InterstellarFuelSwitch] {} }and then for each of the part files in MkIV I just changed the
tankType =to
tankType:NEEDS[!RealFuels] =I also removed the addedMass and addedCosts as RealFuels should be able to handle that. You could probably use a NEEDS[!RealFuels] for that as well but I didn't bother.
Additionally I also made the changes described here just while I was at it:
You’re better off creating a patch for that config or creating a pullrequest to make changes to the file in the actual mod distribution.
Just in case: If you do make a separate patch, use NEEDS instead of FOR.
-
2 hours ago, Lisias said:
Unless you are suggesting that Kopernicus should ditch MM and do the things itself on the code - what, frankly, it's tempting sometimes.
There you go, that's indeed one of the other options.
When I was reading up on ModuleManager and its passes I did a lot of searches and came across several posts in this thread that detailed the reasoning behind adding passes, and the official guidance that came from it.
When RTB posed his question he was unfamiliar with MM syntax. So repeating "It is recommended to not use FINAL in distributed software" should not be a surprise.Even a patch using FINAL can ruin games if someone else distributes their own FINAL patch on solar panels after Kopernicus. So if Kopernicus wishes to truly be safe from it, then an alternate solution would be recommended.
These solutions can be anything from 'Assume other modders use the FOR pass for their mod and utilize the earliest pass that isn't FINAL to overwrite those changes' to 'Backup a user's savegame before loading it.' or even 'write completely new modules from scratch and ignore any existing solar panel modules.'
All have their pros and cons.
QuoteThat said, IMHO is more than OK to ask people why they are using :FINAL. It really should be the a last resort measure to solve things, otherwise the fickle gentlemen agreement that holds all together will fall as a castle of cards. But we must learn how to recognise when a "best practice" is hurting and even potentially destructive.
The guys that made MM what it is today put in a LOT of hours and a LOT of thinking to get it where it is today. I think it's a better idea to learn and understand where the best practice came from.
I'm honestly baffled by the tone of your comments, so since I have said what I wanted to say: I wish you a good day and I'll let @R-T-B decide for himself.
-Jognt
-
5 hours ago, Lisias said:
So you didn't understood it at all - otherwise the logical consequence of understanding it but not agreeing with it is thinking that it's OKEY to trash users' savegames.
You will have way more than annoyed users when some 2.5 years old savegame someone is nurturing just get corrupted beyond salvage due something someone else did, but ended exploding under your nose because there's no standard mechanisms that would allow me to prevent it.
You and I both know that there are always plenty of options in programming.
Ive read a few solid reasons to use final so far, but your comment is not one of them. I’d appreciate it if you did not make this personal.
Programming allows for the creation of just about anything you can imagine. While not wanting to spend the time to write a solution is understandable, it’s a poor excuse for skirting guidelines IMO.
In short: Its not okay to thrash a save. There’s just a LOT of ways to deal with that. FINAL is just the easiest. If RTB decides to stick with FINAL despite now knowing the ins&outs of it, then that’s his choice.
Until then: He asked for feedback on his patch and got it.
12 hours ago, TranceaddicT said:I started this entire debate and was where you are on this specific issue.
The question needing answer when employing :FINAL , particularly as a mod-creator, is "Is it's use a necessity or a desire?"
In Kopernicus, it is a necessity. The desired result is to ensure all Solar Panels (via specific patching of a specific MODULE[ModuleDeployableSolarPanels]) is COMPLETELY controlled by Kopernicus ... AND NO OTHER. The only way to truly accomplish complete control as such, beyond introducing additional complexity to MM pass process, is to process a :FINAL pass on the specified module. (But, even this is subject to a mod alphanumerically after "Kop" ("Kopernikus" or "Kopernicus-like").)
Key phrase being “beyond introducing additional complexity.”
Look, RTB asked for feedback which I provided. That feedback can then be disregarded or ignored.
But please don’t equate “It would take more time and effort to smooth this out than I have.” with “There’s no other choice!”
Because the first is understandable, but the second is a lie.
-
@Lisias I understand the whole "Others are already/still ignoring the best practices, so we cannot be sure we beat even them unless we also ignore the best practice." intention. However: As long as all mods are treated equal there will be no way to 100% guarantee any one mod will always be last in any pass (though LAST and FINAL are both well after FOR/AFTER). So while one achieves less annoyed users at his/her doorstep by joining the racers, the race also continues, causing more annoyed users at others' doorsteps.
I can understand where you're coming from, I just don't agree with it.
Good luck with what is undoubtedly little work to leave as is, and quite a bit of work to find an ideal fix for. o7
My idealistic €0,02.
-
1 hour ago, R-T-B said:
It was chosen in last release for 1.8.
https://github.com/Kopernicus/Kopernicus/commit/c0b092e35eda0c83d3081ed5131c4c0503c3b4a9
Anyways, if this is a big deal I am not opposed to changing next release. The first CKAN already shipped this way though and that's unlikely to change because I don't have a time machine, heh. I was really just defering to "past authors wisdom" (or maybe lack thereof?) here.
However, at the moment, I feel I am swayed by this argument:
Change my view, I suppose.
Use whichever you wish. I would however like to point out that LAST happens once FOR and AFTER are alphabetically 100% done. Lisias’ concern could be valid if this was not the case, but even then: FINAL is also processed alphabetically.
Both will work. Having said that, I’d prefer following best practices. In this case: ‘use the first pass that produces the desired result’ and ‘try and avoid FINAL.’
In this case LAST would still cover every part/module that is altered in legacy/first/before/for/after passes.
To see the order of patching passes: Check your local MM log.
-
Discussion about LAST versus FINAL for use in Kopernicus: GO!
As far as I know LAST exists to ensure patching compatible with BEFORE, FOR, and AFTER passes without having to resort to FINAL. This in order to prevent another 'race to FINAL' occuring.
-
5 hours ago, Lisias said:
On a rule of thumb, don't use :LAST[Kopernicus]. It will not work for you, you need to replace every single Solar Panel on the game by Kopernicus ones, and not only the ones from AddOns those name is less than "Ko". (MM applies patches on alphabetical order on each phase).
And you really need to replace every single Solar Panel on the game to use Kopernicus, because since you are extending the stock Solar Panels class, the ModuleDeployableSolarPanel will be ignored on all parts and any part not patched will simply not work anymore (and Kopernicus will end up taking the heat, because by uninstalling it that parts will work again).
If in doubt, stick with :FINAL . it's safer for now.
FINAL is safe, yes. But LAST exists to fix the race to FINAL. The LAST pass happens after all of the other passes have alphabetically been completed.
14 hours ago, R-T-B said:We've discussed that internally and decided that since those lines are only there to enforce the behavior of the solar panel disabling parameter, to leave it alone (it was done originally by the Kopernicus devs who came before us, actually).
Any modification to that property would lead to undefined behavior anyways, is my logic. Or am I misunderstanding? Since this is the second time that was suggested, I am open to changing it to a :LAST in next release. I'd just need good reasoning to do so, and I'm listening.
LAST probably didn’t exist when FINAL was chosen.
I recommend moving this to the MM topic though. There’s more knowledge there and we’re threadjacking the NF thread at the moment.
Edit: Let's go here:
-
On 8/16/2020 at 6:34 PM, R-T-B said:
Just FYI, I got some helpful help with the above syntax, and it is now generalized in case Nertea needs to add more modes to b9partswitch or something.
Final result that will ship with Kopernicus:
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL { // This cfg will enable KopernicusSolarPanels // to allow support for multiple lightsources // // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node // That will stop Kopernicus from changing the behaviour of SolarPanels @useKopernicusSolarPanels,* ^= :F:f: @useKopernicusSolarPanels,* ^= :A:a: @useKopernicusSolarPanels,* ^= :L:l: @useKopernicusSolarPanels,* ^= :S:s: @useKopernicusSolarPanels,* ^= :E:e: } @PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL { // Hijack the first ModuleDeployableSolarPanel @MODULE[ModuleDeployableSolarPanel] { @name = KopernicusSolarPanels } } //B9PartSwitch support @PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL { @MODULE[ModuleB9PartSwitch] { @SUBTYPE,* { @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]] { @IDENTIFIER[ModuleDeployableSolarPanel] { @name = KopernicusSolarPanels } } } } }Thus, to turn off panels, one need only have a cfg like follows:
@PART:HAS[@MODULE[ModuleDeployableSolarPanel]] { %useKopernicusSolarPanels = false }That is all. Thanks for helping me learn the in's and out's of KSP's MM syntax.
I’d replace :FINAL with :LAST[Kopernicus] to honor the “Please don’t use FINAL in distributions.” request. (LAST is effectively the same but allows for modifying modifications down the road.)
On 8/16/2020 at 7:09 PM, TranceaddicT said:See, caaaafffffffiiiiiiinnnne.
I operate from the position that :FINAL is a conditional best left solely for the end-user unless absolutely necessary (see TweakScale). If a mod is going to host a MM patch, it should be via :NEEDS.
You're absolutely right. I shouldn't have said JNSQ. (That's just my current focus.)
I believe it should be :NEEDS[Kopernicus].
Pass specifiers like FIRST/BEFORE/FOR/AFTER/LAST/FINAL are separate from conditional specifiers like NEEDS. Though AFTER functions like a NEEDS too.
There is no reason to ship a mod with a patch that has NEEDS[thisMod] because it’ll always be true. NEEDS is for patches distributed in a way where it is uncertain if the conditional mod is present.
-
3 hours ago, R-T-B said:
Kopernicus has been submitted to CKAN. We are awaiting the bot grabbing it to index it.
Here are the final release notes:
New in this version (1.9.1-1)
1.) Particle support restored.
2.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1
3.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.
4.) Stock asteroid generation enabled for SENTINEL contracts (can be shutdown for planetpacks or by user, see below)
5.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable stock asteroid generation. Easy to edit, just look inside!
If you want it NOW and not later, you can grab what the bot will eventually index here:
You guys are rockstars
-
3 hours ago, R-T-B said:
The latest release also has a fix for that bug, in both stable (here) and bleeding edge.
Never heard of it happening in 1.9.1, but it's fixed either way in the code now.
Sorry for missing your post @HawkEngineer
And just so no ones confused, when we go CKAN, the numbering of releases will start over at 1 again. It's weird I know, but CKAN releases are going to be few and far between, hence the release candidate above is correctly numbered at 1. Sort of like old Kopernicus.
Might I recommend sticking to the usual incremental numbering? Precisely to avoid confusion.
People *will* google with version numbers.
People *won’t* read the context.
People *will* get confused. -
6 hours ago, maja said:
BonVoyage update
1.1.1 (for KSP 1.9.1) and (1.2.0 for KSP 1.10.1) - New path
Changes
-
Pathfinder optimization - it's quicker
-
New configuration value for pathfinding timeout was added. Default value is 10 seconds. You can change it in config.xml of BonVoyage by changing the value on this line:
<double name="pathfinderTimer">10</double>
You can find it on usual places:
Thanks a bunch!
-
Pathfinder optimization - it's quicker
[1.12.1] JNSQ [0.10.0] [23 Sept 2021]
in KSP1 Mod Releases
Posted
The few heating problems I encountered (mostly with the 1.875m pod) were ‘fixed’ by setting SAS to Surface mode instead of Orbit mode after selecting retrograde.
2000k is already ridiculously hot, so I doubt that that is the culprit.