Yaar Podshipnik
-
Posts
58 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Yaar Podshipnik
-
-
1 hour ago, Kerbart said:
Why don't you give it a try? I've always flown with the navball pushed as far to the left as possible, to keep the center of the screen, where my ship is, unobstructed. I really don't see what the issue is.
I did give it a try, got the game the moment it was available on steam, and I didn't like it. I always organize my workspace with the most important thing right in the center of my field of view. I would really like if it was possible to customize the UI more.
It's not a dealbreaker, and not something that needs to be fixed right here and now (as the game is EA), but would be nice to have.
-
It's such an important thing to use during the flight, and yet it's tucked to the left side. Please, pretty please, let it be moveable to the centre of the screen.
-
Also missing the Micro-Dawn. I see the MicroDawn.cfg config and it looks ok to my inexperienced eye. There is no miniIonEngine listed under Database/Parts in debug console. It looks like MM does pick it up, as MMPatch.log says:
[LOG 14:31:44.128] Applying copy UniversalStorage2/Patches/MicroDawn/+PART[ionEngine] to Squad/Parts/Engine/ionEngine/ionEngine.cfg/PART[ionEngine]
I've also spotted that ReStock (which I have installed) does a lot of things to ionEngine. So tested without ReStock, and Micro-Dawn is there. Which means, that if you edit first line of GameData\UniversalStorage2\Patches\MicroDawn.cfg to read
+PART[ionEngine]:After[ReStock]
then you will have Micro Dawn. However, my understanding of MM syntax is that with this patch if you DON'T have Restock, you won't get the engine. So no idea how to express "if you have ReStock, apply this patch after Restock". The only solution I can think of is to copy-paste the whole block, and have one with :NEEDS[ReStock]:After[ReStock], the other with :NEEDS[!ReStock].
Seems ugly though, which is why I haven't done a github patch.If it's rubbish, it won't get merged, if it's ok, I saved you some typing: https://github.com/linuxgurugamer/universal-storage-2/pull/1Anyway, @linuxgurugamerhope this helps solving.
-
You can also add automation to your antennas. Configure at least one of them to extend on connection lost.
-
Kerbalism, and all other mods with radiation, could definitely use a proper shadow shield. Thing is, for that to work radiation has to have a source from which it propagates, so that line-of-sight can be used to determine if something is shielded or not. AFAIK radiation in kerbalism is just a number used in some equations. Nertea was working on it at some point (not as part of Kerbalism though) - see
-
This still doesn't show as compatible with 1.3.1 but loads up fine when force installed.
-
-
Does the same >1yr apply to Scouts or are they completely immune?
-
I have MKS and USI-LS installed. From what I can see in the docs, Pilots should be immune to habitation running out turning them into tourists. All my pilots, both veterans and regular, do however turn into tourists as soon as hab timer runs out (they have plenty of supplies left). Is that a bug or intended behavior?
-
The version that's in CKAN works perfectly fine with KSP 1.3 English. Don't know if something could break in other languages.
-
It looks like the 1.2 version crashes 1.3 (not too surprising). I did a quick recompile for 1.3 and that seemed to do the trick. Won't upload the DLL as this doesn't really look abandoned. It's easy to build yourself if you really want to.
-
Got to Vessel config when in flight scene, switch to cfg tab, make sure a little red X is displayed by the messages you don't want to interrupt your warp.
-
Latest release has the internal stock antennas on probes. Is that on purpose?
-
Don't think it's silly TBH, and I don't want to interfere with default balance as I think @ShotgunNinja is doing excellent job on keeping it right where it should be.
Reason why I disagree is that the pod is just part of the spacecraft. You are expected to have more bits on it. I'm perfectly fine with pod being only able to sustain the crew for a limited time, like during the re-entry and landing phase.
Saying that, I do think that this mod lacks some external life support parts. If you use KPBS I recommend taking the circular cargo thingy and attaching some life support modules there.
-
I think it would be nicer if larger capsule meant more space for ECLSS systems like scrubbers. So the new 7 kerbal pod from NFT would get twice the ECLSS slots as the 3 kerbal pod. Unfortunately that requires some explicit mod support work. I will be doing a pass over life support config on the mods I'm using in near future, and will share my patches via a pull request (unless someone does this before me ;))
-
Could be something related to how the model is set up, though I can't really help you with that. Parts, animations, and textures are a bit of a black magic to me.
-
You commented out just one line, leaving rest of the module config just hanging - the properties themselves probably wouldn't be a problem (as they would be attached to the part itself, though name might cause a conflict), but that closing brace is definitely throwing off the parser. To properly disable light comment out ALL the lines starting from MODULE { and ending with the line with corresponding closing }.
//MODULE {
// name = ModuleLight
// lightName = Spotlight
// useAnimationDim = true
// lightBrightenSpeed = .3
// lightDimSpeed = .4
// resourceAmount = 0.04
// animationName = jrdockingport
// useResources = true
// }Or just delete the whole thing.
-
11 hours ago, Daniel Prates said:
I read you use 90 mods with Ckan. Does it not cause 'memory leak' crash problems? How do you deal with that? Merely reducing graphics?
No memory problems. I run KSP 64bit, have 32GB of RAM, and the only memory hog in my mod list is Stock Visual Terrain and Stock Visual Enhancements (off now due to Scatterer being broken). I play with very little mod parts, and with lots of quality of life improvements. Biggest mods I use are Kerbalism, pretty much everything by Nertea except Spaceplane Mk IV (I can't fly planes), KIS, KAS, KPBS, Feline Rovers, Surface Experiment Pack. Also used to play with Ven's Stock Revamp but that got problems in 1.2 - there's a new release so I'll probably give it a try again (love that inflatable habs for Kerbalism!).
I don't use USI mods or Pathfinder, even though I really want some nice (more Kerbalism-style) way to have permanent colony somewhere.
11 hours ago, Daniel Prates said:Interesting: HULLCAM conflicts with KERBALISM (or so Ckan says). I wonder if KURS DOCKING CAM also conflicts. I am about to install it manually (it is not available in Ckan). Anyone knows if this is unadvisable?
Hullcam is not really in conflict - both mods do very different things. The whole thing is explained in https://github.com/ShotgunNinja/Kerbalism/issues/66 If you install Hullcam manually it will work, you'll just get some exceptions and some things MIGHT break in strange ways. Don't seek support on the forum if you do that though.
KURS is in ckan, it's just not marked as compatible with 1.2.whatever we have now. There is an option in ckan ui to enable installing mods marked for previous revisions. Can't point you exactly where as I don't have the UI in front of me.
-
You really need to list all the mods you are using for anyone to be able to help you. I run with around 90 ckan mods and have no problems
You can see the list of supported mods in https://github.com/ShotgunNinja/Kerbalism, but there are tons of additional patches in https://github.com/ShotgunNinja/Kerbalism/tree/master/GameData/Kerbalism/Support You can see what changes are done to mods when Kerbalism is installed by reading those.
Mods that implement similar mechanics to Kebalism are most likely to cause an issue, off the top of my head: USI-LS, USI-MKS, RemoteTech, Snacks! (maybe)
-
You can change what happens when an event (like out of power) happens in the vessel monitor window. You need to click on the "CFG" thing at the bottom. See https://github.com/ShotgunNinja/Kerbalism/wiki/GUI for more instructions.
-
@APlayer thank you! I'm a noob to KSP modding, mostly learn stuff by looking at cool patches in big mods like Kerbalism, USI, NFT, and Ven's Stock Revamp. IRL though, teaching other people to code (MM is not coding though) is a large part of my job, so hopefully I do something right
-
@alaxandir not difficult at all. Let's dissect the JX2Antenna patch as example. All explaining comments are after // (which indicates a comment) and in green (as it's simply the best). You can actually copy-paste the whole stuff below to a cfg and it should work. All 3rd party support patches for Kerbalism go into Support directory, with one .cfg per mod. https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax are docs for MM, and have some pointers below.
Quote@PART[jx2LDA]:NEEDS[FeatureSignal]:FOR[Kerbalism]:AFTER[JX2Antenna]
//@PART[jx2LDA] means edit part named jx2LDA. You find the name of the thing you want to edit by looking at the config files in the mod directory, OS 'antennas' seem to be in DMagicOrbitalScience\OversizeScience, find the top-level 'PART{}' block and then find the 'name' attribute. So if you want to edit 'Oversize Signals Intelligence Satellite' you would look into SIGINT.cfg and use 'dmSIGINT' here
//NEEDS[FeatureSignal] is a mechanism to 'read' kerbalism config. What this bit is saying is 'only apply this patch if FeatureSignal is enabled'.
//FOR[Kerbalism] is technically unnecessary - it marks the patch as part of the Kerbalism mod, but in our case it is redundant as it lives in a subdir of Kerbalism. If you have your own folder with tweaks you can use FOR in combination with BEFORE and AFTER to patch things at various stages.
//AFTER[JX2Antenna] means 'execute this patch after all the patches for mod JX2Antenna have been applied'. It also means that if that mod is not installed it won't try to do anything.
{
!MODULE[ModuleDataTransmitter] {}
!MODULE[ModuleDeployableAntenna] {}// Every part in KSP composes its behaviour out of modules. What !MODULE does is remove a given module from part config. Here in particular we remove the stock KSP antenna code (ModuleDataTransmitter) and stock KSP antenna deployment code (ModuledeployableAntenna). We'll replace that functionality with Kerbalism-specific stuff. For OS antennas you don't need to delete ModuleDeployableAntenna - they don't have it. That animation is handled differently.
MODULE
{
name = Antenna
type = high_gain
cost = 1.98
dist = 1.0e12
rate = 0.256
}// This MODULE bit means 'add this module to the part I'm editing'. 'Antenna' is the Kerbalism module that you need to have on your part in order for it to be considered an antenna for Kerbalism Signal purposes. See https://github.com/ShotgunNinja/Kerbalism/wiki/Modules#antenna for detailed explanation. Also check existing patches to get a feel about balance.
MODULE:NEEDS[FeatureReliability]
{
name = Reliability
type = Antenna
title = Antenna
redundancy = Communication
repair = Engineer
mtbf = 108864000 // 12y
extra_cost = 3.0
extra_mass = 0.5
}// This is actually a really cool bit - the whole patch will only be applied if FeatureSignal is turned on, but this additional module will only be applied if FeatureReliability is on as well. That means that if somebody plays with profile without Reliability, they can still use your antenna and won't see any stuff that doesn't make sense in their game. In recent MM versions you can have :NEEDS pretty much everywhere.
MODULE
{
name = ModuleAnimationGroup
deployAnimationName = deployHexes
moduleType = Antenna
}// This re-adds a generic way to deploy an antenna - it's just an animation player. It uses the same animation name as the original mod. So for our SIGINT you would use 'dishDeploy'. I'm not entirely sure if you need that bit in case of OS, @ShotgunNinja could probably explain how Kerbalism detects whether antenna is deployed or not.
@description = An enormous High-Gain antenna, powerful enough to maintain contact with DSN even from the farthest outskirts of the system. It has been built from the highest quality components available, thus ensuring a long and reliable service.
// Here I just edit the description of the part to better reflect its new role
}When you look at most antennas, you'll see that pretty much everything but the part name and actual stats is boilerplate config - you can get away with copy-pasting one of the patches and just pointing it at the right mod/part ;).
Once you're happy with the results of your work share it with the community! Best way to do that is to make a pull request on github, as it allows easy code review and a conversation between ShotgunNinja and you if something is not entirely right. I think some patches were posted here as well, but it's more work to integrate them if you have to copy paste from a forum post.
One thing you should keep in mind - Kerbalism is 'free and unencumbered software released into the public domain.' see https://github.com/ShotgunNinja/Kerbalism/blob/master/LICENSE. If you're submitting any work to that mod it will be released under that licence. So if you don't like your work to be in public domain, don't submit it.
-
15 hours ago, alaxandir said:
Is there a way to get the same type of data transferring utilizing some of the DMagic Orbital Science pack? It has some ridiculous OP antennae and I want to either nerf them or make them work with this mod.
I started working on support for OS antennas, don't know when will submit a patch. I don't really like the stats on those antennas in base mod, as they are very, very light compared to the advertised range. What I'm doing is making them have high range but low bandwidth to compensate for low weight.
You can always write your own MM patches to add support of course.
If you want a nice long range antenna, that's balanced ok on mass/range/bandwidth see JX2Antenna
Kerbalism already has full support for it.
-
@ragusila you can't edit profiles via MM patches. See https://github.com/ShotgunNinja/Kerbalism/pull/56#issuecomment-271663949, with relevant bit here for your convenience.
QuoteThe profile is parsed before MM apply the patches, because it is used to determine features to enable, that are then injected as MM patches themselves. That is why any MM patch targeting a profile will be ignored. Not only that, but in the profile itself no MM directives can be used.
It is a limitation that is not desiderable, but I don't know if that can be improved in future without rethinking the whole MM patch injection system.
Easiest way to achieve what you want seems to be making a copy of default profile, adjusting the values you want using a text editor, and simply using that profile instead of the Default one.
First Impressions UI Feedback
in KSP2 Suggestions and Development Discussion
Posted
Also want to add that manoeuvre planning seems very cluttered. Doing a moon intercept I see so many labels (things sticking out of the icons right there on orbit) it's hard to see what actually is going on. I also found it not possible to right-click an apsis to get the readout to stick, so I could fine-tune the burn.