Boop
-
Posts
47 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Boop
-
-
On 8/24/2019 at 11:51 PM, linuxgurugamer said:
New release, 1.3.6.2
- Added support for the ClickThroughFix
Hi @linuxgurugamer! Tried this for the first time today. In my relatively-modded install (~60 mods) it triggered a bizarre issue that made me chuckle:
Kerbals are not visually occluded in the Flight Scene by some (all?) parts (things such as Pods that they literally enter are unaffected).
Steps to reproduce:
1. Create a hollow cube out of Structural Panels.
2. Place a Command Seat inside the hollow space.
3. Assign a Kerbal to the seat and launch the Vessel.
Expected Result: Kerbal cannot be seen.
Actual Result: Kerbal is visible 'through' the solid panel walls.
Spooky!
To be clear, I've verified that this only happens with the mod installed and goes away as soon as it's uninstalled.
I assume that this isn't something I'm missing in the settings, as the mod's UI doesn't appear to have anything interactive I can fiddle with when this happens.
Let me know if you feel the need for screenshots, list of other mods etc. and I'll see what I can do after work.
-
On 3/8/2019 at 5:09 PM, Boris-Barboris said:
Stock KSP LandedOrSplashed Vessel class property must be fixed by ksp devs. You are the second guy that reports it, so I can only advise you to pass the issue to them.
I'm a devoted fan of this mod - it makes just about everything fly 10x better. But if I take-off, land and then take-off again, as soon as I reactivate AA my aircraft always always goes absolutely bananas and crashes violently.
I read this post while I was flying about and I noticed that KER was showing what seemed to be a perfectly accurate 'Vessel Situation' at all times.
I had a poke around that mod's Github and noticed that they're using the ScienceUtil 'ExperimentSituations' rather than vessel.LandedOrSplashed.
I changed the code in your source to use that approach instead, so for example:
ScienceUtil.GetExperimentSituation(FlightGlobals.ActiveVessel) == ExperimentSituations.SrfLanded || ScienceUtil.GetExperimentSituation(FlightGlobals.ActiveVessel) == ExperimentSituations.SrfSplashedI threw the new DLL into KSP and tried it out a couple of times. Now, instead of essentially completely losing control, I get several seconds of slight 'jiggling' before it settles down completely.
Anyway, maybe think about trying it out. It's solved it for me so far.
Thanks for the awesome mod!
-
@Daishi this is just... absolutely sensational work. Oh boy was it worth the wait.
The way the resource containers resize with completely different looks took me by surprise. So good.
The only thing I'd like to see added would be some kind of Greenhouse wedge for life support. Other than that, you seem to have all the bases pretty much covered for me.
Many thanks and congratulations to you and the rest of the team.
-
On 3/17/2018 at 7:54 AM, genbrien said:
because, if its the newest, ''abort'' is not working (know its been reported) and when you reach the ''coasting phase'' outside atmo then the game starts to lag really bad and there is some errors popping
@AndyMt I'm seeing this behaviour on one particular vessel (I think, could have sworn it was working before) with 1.7.7 via CKAN on KSP 1.4.3 (have checked the DLL itself, shows 1.7.7).
Reason for the lag is this being spammed to the log:
[LOG 09:53:04.628] GravityTurn : minorbit 670000, 70000 [LOG 09:53:04.629] GravityTurn : Saving launchDB [LOG 09:53:04.632] GravityTurn : Exception: System.ArgumentException: Illegal characters in path. at System.IO.Path.GetFileName (System.String path) [0x00000] in <filename unknown>:0 at KSP.IO.IOUtils.GetFilePathFor (System.Type T, System.String file, .Vessel flight) [0x00000] in <filename unknown>:0 at GravityTurn.LaunchDB.GetBaseFilePath (System.Type t, System.String sub) [0x00000] in <filename unknown>:0 [EXC 09:53:04.632] ArgumentException: Illegal characters in path. System.IO.Path.IsPathRooted (System.String path) System.IO.Path.GetPathRoot (System.String path) System.IO.Path.GetDirectoryName (System.String path) GravityTurn.LaunchDB.Save () GravityTurn.GravityTurner.fly (.FlightCtrlState s) Vessel.FeedInputFeed () FlightInputHandler.FixedUpdate ()
As this seems to be string-related, the only thing I can currently think could affect it is the vessel name: CUS-2 "Pioneer"
-
@Katten you just saved what little remained of my sanity. Reloading my heavily-modded install was killing my motivation, now I'm free!
One thing I did notice - the 'Rescale' value in my edited CFG still wouldn't visually update without a restart. Don't know if that's something you're already aware of, or if I was missing something (I was switching a Micronode from 1 to 0.5 and back).
-
@linuxgurugamer has given me permission to hint that there is another surprise incoming.
OMG!
SURPRISE!
INCOMING!
P.S. Does anyone know what 'hint' means?
-
@Fwiffo, you've once again gone above and beyond, so megaprops.
I don't know how to physically screen another mod from conflicting with us like this. There's an 'OnGameSettingsApplied' event that might be worth investigating. I tried to avoid any contact with the settings on a 'permanent' basis, for reasons I mentioned, so hopefully we can all just get along!
-
19 minutes ago, linuxgurugamer said:
I'll work on that later, but for now, the current release of EEX is NOT compatible with 1.1.3, and the .version file says that.
I don't have time right now to go regress stuff for 1.1.3, I still have a number of mods to update for 1.2 That being said, if @Boop gets it fixed, I won't mind having a seperate 1.1.3 branch
Unfortunately, it's not a true 'fix' that can happen here. There was a potential drawback to the way I did what I did, but 1.2 stepped in and took away the risk. 1.1.3 doesn't seem to behave similarly, according to @Fwiffo, so all I can suggest is that he sets the hotkeys back to the default ('x' and 'c') on startup if they're null / set to Keycode.None, which is risky in the event that the mod is uninstalled before it gets to implement the change
-
2 minutes ago, Fwiffo said:
@Boop Actually, come to think of it it might be possible another mod (that isn't installed in my 1.2) is triggering a save of the game settings after EER changes the hotkeys.
Yikes - lemme know if that turns out to be the case, could be an important warning for the OP.
-
1 minute ago, Fwiffo said:
I am 99% sure it does not (i.e. works fine under 1.2). I just did a quick test in my "cleanroom" 1.2 environment (virtually no other mods present). I would need do some more testing to rule out interaction from other mods causing my problems under 1.1.3 but given how specific a symptom this is I would be surprised if that's the case.
BTW while I'm here... an unrelated suggestion. Next release we might consider making the NoOffsetLimits feature a user-toggleable option. I remember some complaints about it being bundled, and sometimes I myself would love to turn that off to avoid "cheating", while still using the rest of EER.
My theory on why you 'remember' this bug not happening when testing is that you were testing against 1.2, like I was - you didn't make a 1.1.3 version until after we were done and you probably didn't regression test that one case. As a result, I wouldn't dig too deep, it's most likely that this just doesn't go down well in 1.1.3.
The whole reason I was desperate to avoid permanently overwriting the settings was that, in the case that we had a crash etc, I would be unable to restore them even if I'd persisted them to disk if the user uninstalled the mod before restarting. It was a one in a million edge case, but it gave me indigestion. Thankfully, KSP seems to deal with it for us in 1.2, so I was able to unclench
-
1 minute ago, Fwiffo said:
DANG-it. Yes, still messed up, i.e. the mod causes their bindings to be set to None when entering the Editor. (Didn't even bother to check before; I just assumed you instituted the fix after I made my Sep 18 build and it would come with the new code along with all those other lovely new enhancements I'm hoping to backport). Looks like this might be a little trickier than I thought.
I think the only sensible next step would be for you to backup your game folder, grab 1.2, install the legit 1.2 EEX and see if it still happens. If you confirm that then I'll have to roll my sleeves up, but from current evidence at least, it's limited to 1.1.3.
I will just go back and have a look at that fix code, though...
-
2 minutes ago, Fwiffo said:
I welcome any hints ;-)
For starters, is insta-quit still messing up your VAB controls in this 'new' version?
-
21 minutes ago, Fwiffo said:
Hey @Boop is it possible the tweaks you made cause KSP to loose the Editor_toggleSymMode and Editor_toggleAngleSnap bindings if the game is terminated ungracefully?
I've noticed if I kill KSP via task manager while in the Editor, the next time I load it up the X and C keys are no longer bound. At first I thought it was my own fault due to other stuff I was messing with, but today I noticed settings.cfg is changed as soon as I enter the VAB.
I guess there's no way to intercept and override the game's internal handling of those hotkeys without tampering with the settings.cfg file? A little quality-of-life option in EER to restore those keys next boot if missing would be great (or to just have it handle the hotkeys and leave the ones in settings.cfg permenantly unbound).
I realize the simple workaround is to exit the VAB/SPH first, and that most people don't kill or crash the game while in the Editor. I do all the time, due to the need to reload part weldments.
This is surprising for a couple of reasons. Firstly, I tested Alt-F4'ing when I developed the new handler, because I feared exactly this. In that test the functionality was intact after restart, so I assumed it was handled by KSP and I moved on.
Secondly, fearing that an end-task in TaskManager might be a case I overlooked that does something 'worse', I just tried it. Once again, my tools were fine after restart.
Now, I do remember putting a bit of code in which specifically aimed at this problem, which is mentioned in my writeup of my fixes earlier in the thread. I'm using a (slightly modified) version of EEX in 1.2, based on the latest Github source, the only changes being something new I'm working on. What are you using?
-
2 hours ago, gamerscircle said:
This is available on the Github via? [I am a github noob]
Sort of - I downloaded the source from Github, then fixed it up in Visual Studio for 1.2. I expect @timmers_uk will publish an updated release. Many modders prefer to wait until the new version officially launches before uploading it.
-
1 hour ago, linuxgurugamer said:
Looks great!
I normally don't give special names to released, but this is the Boop release (will be that for final version as well):
https://github.com/linuxgurugamer/EditorExtensionsRedux/releases/tag/3.2.15.1
It was a pleasure, and that's the icing on the cake, so thanks for the opportunity to contribute. Give me a holler if you need anything else, with this or the rest of your ever-expanding portfolio!
-
2 minutes ago, linuxgurugamer said:
I haven't done anything yet, if I recall you said all the changes were in a single file? Can you upload that for me again?
thanks
No problem - here it is with all the changes, plus the updated 'OnMouseIsOver' value: https://drive.google.com/file/d/0B5NCh5cbU4lsM2w2enR6SmxPSFk/view?usp=sharing
-
7 hours ago, linuxgurugamer said:
check the offsets again, I found that the OnMouseIsOver is now 262, but you have it in the file as 255, others are probably off as well
Turns out that was the only one, no other offsets are off. If you've already made that alteration to the source then we're good to go
-
3 hours ago, linuxgurugamer said:
check the offsets again, I found that the OnMouseIsOver is now 262, but you have it in the file as 255, others are probably off as well
Darnit. I see KSP has patched at least twice since I set that up - maybe that's it?
I'll have another look after dinner.
48 minutes ago, PickledTripod said:This is fantastic, it feels just like stock now! Super smooth and responsive no matter how quickly or in what order I press the keys. Thanks a lot @Boop and @Fwiffo!
You're welcome!
-
6 minutes ago, linuxgurugamer said:
Looking forward to the changes, I (and others) really appreciate your work. I've been busy with other mods, so this is very helpful.
Once you get me the changes, I'll get a semi-official build and then compare between 1.1.3 and 1.2 to see if everything is ok.
I think I have enough for a serious final test
Here's what I did to fix the SymMode and AngleSnap responsiveness - note that all changes are made solely in EditorExtensionsRedux.cs, which I've uploaded to Google Drive in case you prefer getting it that way without integrating it all manually: https://drive.google.com/file/d/0B5NCh5cbU4lsNDhTal9kbmN2dnM/view?usp=sharing
1. We need these class-level variables - I personally put them just before "Start()" as that made them handy to see for the next step:
//Boop: Cache the editor hotkeys so we can keep consistency with whatever is in the settings.cfg file. KeyCode HotkeyEditor_toggleSymModePrimary = GameSettings.Editor_toggleSymMode.primary; KeyCode HotkeyEditor_toggleSymModeSecondary = GameSettings.Editor_toggleSymMode.secondary; KeyCode HotkeyEditor_toggleAngleSnapPrimary = GameSettings.Editor_toggleAngleSnap.primary; KeyCode HotkeyEditor_toggleAngleSnapSecondary = GameSettings.Editor_toggleAngleSnap.secondary;I did that specifically so that if the User (or a future KSP version, or maybe another Mod) ever changes those buttons then we still know what we're looking for. Then it turned out to be vital later (step 3).
2. This then needs to go into "Start()", suggest straight after your "Log.Debug ("Start()");" line:
//Boop: Nuke the editor hotkeys so we can hijack them. GameSettings.Editor_toggleSymMode.primary = KeyCode.None; GameSettings.Editor_toggleSymMode.secondary = KeyCode.None; GameSettings.Editor_toggleAngleSnap.primary = KeyCode.None; GameSettings.Editor_toggleAngleSnap.secondary = KeyCode.None;This is how we ambush the (by default) "X" and "C" keys.
3. Now put this in "OnDestroy()"://Boop - restore the hotkeys - without this, the hotkeys fail to work on each subsequent visit to the VAB/SPH after the first. GameSettings.Editor_toggleSymMode.primary = HotkeyEditor_toggleSymModePrimary; GameSettings.Editor_toggleSymMode.secondary = HotkeyEditor_toggleSymModeSecondary; GameSettings.Editor_toggleAngleSnap.primary = HotkeyEditor_toggleAngleSnapPrimary; GameSettings.Editor_toggleAngleSnap.secondary = HotkeyEditor_toggleAngleSnapSecondary;
That fixed the nastiest bug I managed to introduce (and lost nearly 2 hours to)
4. Last but not least, the new SymMode and AngleSnap code needs to go into the "Update()", suggest directly after your "if (!validVersion) return;" statement://Boop: Override stock Angle Snap manipulation if ((Input.GetKeyDown(HotkeyEditor_toggleAngleSnapPrimary) || Input.GetKeyDown(HotkeyEditor_toggleAngleSnapSecondary))) { int currentAngleIndex = cfg.AngleSnapValues.IndexOf(editor.srfAttachAngleSnap); float newAngle; if (Input.GetKey(GameSettings.Editor_fineTweak.primary) || Input.GetKey(GameSettings.Editor_fineTweak.secondary)) { // Decrease snap newAngle = cfg.AngleSnapValues[currentAngleIndex == 0 ? cfg.AngleSnapValues.Count - 1 : currentAngleIndex - 1]; } else if (Input.GetKey(GameSettings.MODIFIER_KEY.primary) || Input.GetKey(GameSettings.MODIFIER_KEY.secondary)) { // Reset snap newAngle = 0; } else { // Increase snap newAngle = cfg.AngleSnapValues[currentAngleIndex == cfg.AngleSnapValues.Count - 1 ? 0 : currentAngleIndex + 1]; } currentAngleIndex = cfg.AngleSnapValues.IndexOf(editor.srfAttachAngleSnap); editor.srfAttachAngleSnap = newAngle; if (editor.srfAttachAngleSnap == 0) { GameSettings.VAB_USE_ANGLE_SNAP = false; } else { GameSettings.VAB_USE_ANGLE_SNAP = true; } lastSrfAttachAngleSnap = editor.srfAttachAngleSnap; last_VAB_USE_ANGLE_SNAP = GameSettings.VAB_USE_ANGLE_SNAP; updateGizmoSnaps(); var gizmos = HighLogic.FindObjectsOfType<EditorGizmos.GizmoOffset>(); if (gizmos.Length > 0) { var gizmo = gizmos[0]; if (editor.srfAttachAngleSnap == 0 && gizmo.useGrid) gizmo.useGrid = false; else if (editor.srfAttachAngleSnap != 0 && !gizmo.useGrid) gizmo.useGrid = true; } return; } //Boop: Override stock Symmetry manipulation. if ((Input.GetKeyDown(HotkeyEditor_toggleSymModePrimary) || Input.GetKeyDown(HotkeyEditor_toggleSymModeSecondary))) { if (Input.GetKey(GameSettings.Editor_fineTweak.primary) || Input.GetKey(GameSettings.Editor_fineTweak.secondary)) { if (editor.symmetryMethod == SymmetryMethod.Radial) { if (editor.symmetryMode > 0) { editor.symmetryMode--; } } else if (editor.symmetryMode == 1) { editor.symmetryMode = 0; } else { editor.symmetryMode = 1; } return; } else if (Input.GetKey(GameSettings.MODIFIER_KEY.primary) || Input.GetKey(GameSettings.MODIFIER_KEY.secondary)) { editor.symmetryMode = 0; } else { if (editor.symmetryMethod == SymmetryMethod.Radial) { if (editor.symmetryMode < cfg.MaxSymmetry - 1) { editor.symmetryMode++; } } else if (editor.symmetryMode == 1) { editor.symmetryMode = 0; } else { editor.symmetryMode = 1; } return; } }
Unfortunately I ran out of brain before I could look at the now redundant code that got left behind. As far as I can tell, it's no longer necessary to hook-in to event handlers etc. Much of your old code just gets ignored at the moment because of the 'unwiring' of the hotkeys, but the fact that much of it is in the "Update()" loop means we should probably tidy that up.
Props to @Fwiffo for testing and explaining what was supposed to be happening. Also a lot of encouragement
-
8 hours ago, Fwiffo said:
I've got to go AFK for a while, so you can have a nice breather without me breathing down your neck ;-)
I noticed a massive bug whereby each subsequent visit to the VAB/SPH after the very first would be utterly broken and took the opportunity to go to bed
Looking at it fresh today helped a lot. Here is the latest version, with the added benefit of having been built against the latest source for the first time: https://drive.google.com/file/d/0B5NCh5cbU4lsaGxLVWtRbm9LV0E/view?usp=sharing
Some notes:
* I couldn't actually reproduce your Fuel Tank symmetry behavior, so I've either accidentally 'fixed' it or I'm doing something wrong.
* There will still probably be a slight 'bounce' when pressing 'R' to change symmetry mode as I haven't hijacked that key with the new method yet.
* The mouse-click on Symmetry Mode and Angle Snap gizmos works for me, although it doesn't work on Symmetry Mode in the 'EER way' - it cycles through stock settings of 1x/2x/3x/4x/6x/8x - not sure if I've missed something there or if that was never addressed by EER. -
12 minutes ago, Fwiffo said:
Nope. Should be "Press X with the Alt modifier to reset symmetry to 1" and "Press C with the Alt modifier to reset angle snap to none".
Right, hopefully last time round the block: https://drive.google.com/file/d/0B5NCh5cbU4lsNjVvZlRveFJ4Yms/view?usp=sharing
-
3 minutes ago, Fwiffo said:
I tried before reporting, and Alt did nothing in Stock, so I assumed either stock lacks the Alt feature or I had a keybinding get screwed up.
Also note while you replied, I was editing my previous response with some more regarding the stock "5 degree" thing.
Gotcha, so with EER, the behavior you expect is:
1. Press and release 'Alt', and only 'Alt'.
2. Both angle and symmetry instantly decrease to the lowest value and stay there until you begin changing them again.
Is that accurate?
-
5 minutes ago, Fwiffo said:
Did you break something with the Alt modifier, or did my keybindings get mucked up? It doesn't seem to reset to lowest anymore, for either angle or symmetry.
Darn. I saw something in the code, but I disregarded it. I was working from the Wiki Key Bindings to establish how stock worked and holding down 'Alt' wasn't listed as having that effect. Can you confirm whether that is in fact an EER thing, or also what stock does?
-
39 minutes ago, Fwiffo said:
Eager for some source!
Last test before I start writing the how-to. Angle Snap now uses the same sort of mechanism. https://drive.google.com/file/d/0B5NCh5cbU4lsZExaQnF5MFdUWjQ/view?usp=sharing
Note that the EER setting of 1° seems to be finer than the default stock "No snapping" setting (the one with the concentric circles). Unless I've screwed something up. Stock seems closer to the 5° setting.
Let me know if it works properly and we can get this ticked off the list.
[1.12.x] Docking Camera KURS Style Re-Adopted (Fixed in 1.9)
in KSP1 Mod Releases
Posted
I'm also away now until Friday night, but I'll do it as soon as I can. I'll grab logs, screenies and mod lists.