Singing Boyo
-
Posts
12 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Singing Boyo
-
-
Hey there.
Someone mentioned a possible bug relating either to having other planet packs, or just Kopernicus. Not sure which it is, but it looks like the stalactites for Pol are causing it. More info here:
Also, thanks for putting the time in for this mod - Kerbin and Minmus at look great! (haven't gone anywhere else yet
)
-
Spectra seems to be triggering this for Pol (with Galileo's OPM, at least):
[LOG 20:30:09]: Exception Was Recorded: Method not found: 'Default constructor not found...ctor() of UnityEngine.Material'. at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] in <filename unknown>:0 at System.Activator.CreateInstance (System.Type type) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectMemberFromConfigurationNode (System.Reflection.MemberInfo member, System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectFromConfigurationNode (System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.CreateObjectFromConfigNode (System.Type type, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadCollectionMemberFromConfigurationNode (System.Reflection.MemberInfo member, System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectFromConfigurationNode (System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadCollectionMemberFromConfigurationNode (System.Reflection.MemberInfo member, System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectFromConfigurationNode (System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectMemberFromConfigurationNode (System.Reflection.MemberInfo member, System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Parser.LoadObjectFromConfigurationNode (System.Object o, .ConfigNode node, System.String configName, Boolean getChilds) [0x00000] in <filename unknown>:0 at Kopernicus.Configuration.Loader.Kopernicus.IParserEventSubscriber.PostApply (.ConfigNode node) [0x00000] in <filename unknown>:0
Looks like it's the stalactite scatter (apologies for awful indentation). The LandControl.landClass.Class.scatters stuff has this:
Scatter { density = 0.10 scatterName = stalactite }and LandControl.scatters has this:
Scatter { castShadows = True recieveShadows = True name = stalactite delete = False collide = False Material { color = 0.6641791,0.6319441,0.4482048,1 mainTex = BUILTIN/distantground mainTexScale = 0.5,0.5 mainTexOffset = 0,0 detail = BUILTIN/rock00 detailScale = 3,3 detailOffset = 0,0 } Experiment { } }So, something either included or missing there is causing this, but I don't know what. (Help appreciated)
I'll let the Spectra author know as well, but can the errors for this be improved at all? Would really help with tracking this kind of thing down (process of elimination is not fast, not with my mod count
)
-
Running this at 4k with AVP repackaged, and it looks great!
One quick question - at least at 4k, things end up looking 'banded', especially at the terminator. It's somewhat visible in other people's screenshots as well, but basically I think something in the interpolation gives me noticeable stripes of color, rather than a smooth gradient. Is there something I can tweak to improve this?
To be honest, I'm not sure if the cause is scatterer, AVP, or something to do with stock, but I figure that if there is a setting that will help it's probably scatterer-related
-
13 hours ago, Epox75 said:
I'm having this graphical glitch since I've installed the version 1.05-4. I never had this problem with all the previous releases of E.V.E. I play on Windows 10, with Half Res Texture quality. Other settings are SM3 Terrain Shader and Terrain Scatter off. 2x Antialiasing, Pixel Light Count 8, Shadow Cascades 4, PPFX on Surface FX on and Underwater FX on. Any suggestions?
Thanks in advance!
I'm seeing this half-white half-black cloud issue on linux (at least, that's what it looks like). 4x antialiasing. I believe my pixel light count and shadow cascades are higher, and PPFX is off (I'd have to double check surface/underwater FX, don't think I've actually seen those anywhere). I do have scatterer and planetshine - not sure if that is part of it, as Epox didn't mention it. Apologies for extra-long-distance shot: I timewarped a while before noticing this.
The really strange part here visually is that the sun is behind and to the left, but the left-side clouds are the black ones.
If anyone has any thoughts on what's causing this, please let me know. Thanks!
-
New planetshine soon?!? Awesome. Might even have to stop being lazy with CKAN and install manually once it hits :D
-
About opening the UI. I'm on linux, and oddly enough need RShift-Alt-F11. Similarly, opening EVE's UI is RShift-Alt-0 (Which should really be Alt-0 or RShift-0). Not sure why this is, but it's what I end up needing, so if you can't open it, maybe try that.
-
So, I just tested Scatterer + EVE + Kopernicus. Interestingly, the black sky issue only shows when disabling stock atmo. If I open the Scatterer UI and enable the stock atmo, the sky looks about right, at least for stock.
Unfortunately, I've never actually used Scatterer before (last time I looked at it it didn't like linux), so I can't say for sure what is actually working here and what isn't, but it doesn't seem like it's completely breaking everything. I do still get the NREs in toggleCoronas, but I can't tell whether that's only with stock atmo disabled or not. -
Pic of the rocket and are you using FAR? ... crash tolerances were bumped a while ago
Hmm. Last time I used these, I was seeing explosions on landing despite truss crash tolerance being 12m/s, but I am indeed using FAR. Is that somehow related? (And if it is, is there a way to fix it?)
IIRC the rocket I saw this with when it landed was an 0.35m truss with parachute on top, and a single experiment, avionics package, and 2 batteries attached. Pretty sure it landed at something close to 4m/s and exploded.
-
So, I'm seeing the random explody-truss problem people have mentioned before. I've even seen the truss enter the ground a bit, then jump back out, but I can't reproduce that one.
It does make me wonder, does the collision mesh follow the model exactly, by any chance? (i.e. a bunch of small struts) Or does it just use a cylinder at the bottom and top? As far as I've seen, all the decoupler collision meshes are just solid cylinders, so if it's done the first way, that might be what's causing the issue.
I'm loving the mod so far, but my rockets exploding for no apparent reason isn't quite the fun I'm looking for
So, anyone have any idea if/how the trusses can be made stronger? -
So, I believe people have mentioned this before, but the chutes (at least the radial ones) don't seem to work with KIS. Have several mods, FAR and KIS being the big ones here. Final Frontier, RemoteTech, and ClampsBeGone print to the relevant log part as well, but shouldn't do anything. Log excerpt:
16624 [LOG 16:55:19.783] [KIS] StartPointer(pointer)
16625 [LOG 16:55:19.783] [KIS] Surface node set to default
16627 [LOG 16:55:20.973] [KIS] Create part & attach
16628 [ERR 16:55:21.010] Actor::setLinearVelocity: Actor must be (non-kinematic) dynamic!
16629
16630 [ERR 16:55:21.010] Actor::setAngularVelocity: Actor must be (non-kinematic) dynamic!
16631
16632 [LOG 16:55:21.012] [ClampsBeGone]: Flight situation change: LANDED -> SUB_ORBITAL
16633 [LOG 16:55:21.012] FF: vessel situation change for RC.radial, situation changed from LANDED to SUB_ORBITAL
16634 [LOG 16:55:21.012] RemoteTech: SatelliteManager: OnVesselCreate(07d6d8d8-e82a-4076-a063-19e3664079ef, )
16635 [LOG 16:55:21.015] [KIS] CreatePart - Waiting initialization of the part...
16636 [LOG 16:55:21.015] [KIS] StopPointer(pointer)
16637 [ERR 16:55:21.021] [RealChute]: Could not find the ModelConfig at the index [-1] in the library
16638
16639 [ERR 16:55:21.021] [RealChute]: Could not find the CanopyConfig at the [-1] index in the library
16640
16641 [ERR 16:55:21.021] [RealChute]: Could not find the CaseConfig of "Radial" type at the [-1] index in the library
16642
16643 [ERR 16:55:21.021] [RealChute]: Could not find the CaseConfig of "Radial" type at the [-1] index in the library
16644
16645 [LOG 16:55:21.022] ModuleAnimation2Value - animation not found: cone
16646 [LOG 16:55:21.023] [ModularFlightIntegrator] MFI Start
16647 [LOG 16:55:21.023] [ModularFlightIntegrator] Start. Current modules coVesselModule :
16648 ModularFI.ModularFlightIntegrator active=True order=0
16649 FerramAerospaceResearch.FARAeroComponents.FARVesselAero active=True order=0
16650 FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI active=True order=0
16651
16652 [LOG 16:55:21.056] [KIS] CreatePart - Waiting initialization of the part...
16653 [LOG 16:55:21.061] FF: vessel RC.radial has reached orbit around Kerbin
16654 [LOG 16:55:21.061] [ClampsBeGone]: Flight situation change: SUB_ORBITAL -> ORBITING
16655 [LOG 16:55:21.061] FF: vessel situation change for RC.radial, situation changed from SUB_ORBITAL to ORBITING
16656 [LOG 16:55:21.091] [KIS] CreatePart - Waiting initialization of the part...
16657 [LOG 16:55:21.121] [KIS] CreatePart - Coupling part...
16658 [LOG 16:55:21.121] [KIS] Attach type : Surface | ID : srfAttach
16659 [LOG 16:55:21.122] RemoteTech: SatelliteManager: OnVesselDestroy(07d6d8d8-e82a-4076-a063-19e3664079ef, Gilrie Kerman Debris)
16660 [LOG 16:55:21.122] RemoteTech: SatelliteManager: UnregisterProto(07d6d8d8-e82a-4076-a063-19e3664079ef)
16661 [LOG 16:55:21.145] Updating vessel voxel for Helios
16662 [EXC 16:55:21.161] ArithmeticException: NAN
16663 System.Math.Sign (Single value)^M
16664 FerramAerospaceResearch.FARPartGeometry.VehicleVoxel.VoxelShellTrianglePerpX (Vector4 indexPlane, Vector3 vert1, Vector3 vert2, Vector3 vert3, .Part part, Int32 invertTri)^M
16665 FerramAerospaceResearch.FARPartGeometry.VehicleVoxel.CalculateVoxelShellForTriangle (Vector3 vert1, Vector3 vert2, Vector3 vert3, .Part part, Int32 invertXYZ)^M
16666 FerramAerospaceResearch.FARPartGeometry.VehicleVoxel.UpdateFromMesh (FerramAerospaceResearch.FARPartGeometry.GeometryMesh mesh, .Part part)^M
16667 FerramAerospaceResearch.FARPartGeometry.VehicleVoxel.UpdateFromMesh (System.Object meshParamsObject)^M
16668 UnityEngine.Debug:LogException(Exception)^M
It's possible to work around this by just using stock chutes, but it'd be nice to have a note somewhere or something like that until it gets fixed.
From reading the log, it looks like KIS may be creating a separate vessel, then trying to attach it, and something is failing somewhere. Let me know if I need to bug Ferram and/or the KIS people instead of blaming the part mod for other people's bugs
-
Do the Useful Space Stations Contracts not take the location of the station into account? If not, that should probably be fixed - the payout just isn't worth it for stations that aren't around Kerbin.
I ask because my solar orbit station is getting a total of ~70k for a resupply contract. While I could probably technically get there with that budget, that's the same amount as what my minmus station gives me, and I think it's what my Kerbin station gets as well. Doesn't quite seem right...
Either way, great pack, so far it's really made stations much more interesting.
-----
So, it appears that useful space stations doesn't respect what body your station is orbiting. This leads to ~80k total kerbucks for a resupply mission to a station orbiting the Sun. Which is doable, but not really worth the effort, and if it were around Jool...
I've got a fix for it locally, as far as I can tell. Unfortunately, I'd rather not put in the effort proper testing would require, since I don't have a setup to make it easy on me. So, it'll just get tested as my game goes on.
I'll probably drop a PR on the official github repo in the next couple of days so this change can be made official if it's wanted, but for the time being if anyone wants to try it out and let me know if it's caused any bugs, my updated version is here. Should work if downloaded as a zip (on the right) and unpacked into GameData/ContractPacks/UsefulSpaceStations.
)
)
So, anyone have any idea if/how the trusses can be made stronger?
[1.12.3] Spectra Visual Compilation 1.6.2 "Horizons" (26th July 2022)
in KSP1 Mod Releases
Posted · Edited by Singing Boyo
I wish I could tell you what it actually changes, but Kopernicus fails out and says (paraphrased) "DON'T LOAD YOUR SAVE" so... I didn't load my save
If you're removing the Pol terrain scatters completely, though, it should fix it - at least, removing just the stalactites fixed the "DON'T LOAD" message and Kopernicus loads OPM properly as far as I can tell.