Gotmachine

Members
  • Content Count

    147
  • Joined

  • Last visited

Community Reputation

217 Excellent

About Gotmachine

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Runolite Ok so forget about the first edit, revert it to the initial syntax. The bug with Sigma Dimensions is a silly one : SigDim should be applied after SVT, but since the loading order is alphabetical things get screwed up. The fix should come from SigDim but Sigma88 is waiting for BlowFish to implement a :LAST ModuleManager feature so he can fix this. What you need to do is open ALL *.cfg files in the SVT\configs folder and edit the first line : change the "[SVT]" label to "[RSVT]".
  2. @Runolite Try this : Edit this file with text editor : SVT\configs\Kerbin.cfg At the end of the file, change this : SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } to this : %SpaceCenter { groundColor = 0.444,0.494,0.294,0.23 groundTexture = SVT/textures/PluginData/grass00.dds } If this doesn't work, please open your "ModuleManager.ConfigCache" file with a text editor, search for the "SpaceCenter{...}" node and post it here. Also do you have Sigma Dimensions installed ? There is known issue with it.
  3. @lajoswinklerCan you please point me to what exactly doesn't work ? I will try to get back working on the version 2.0 soon, but I will probably do a bugfix release for 1.5 if needed
  4. To me, the most exciting thing in this update is the shiny "VesselDeltaV" class ! As for the shiny parts... not fond of that, I find that it doesn't fit well with the overall "matte" style of KSP.
  5. But then how to get the part at the origin of the action ? This is running from a KSPAddon, not a PartModule... I also managed to get a KSPEvent working, this is easier : private void OnPartActionUICreate(Part part) { // Get the PAW window UIPartActionWindow paw = UIPartActionController.Instance.GetItem(part); // Prevent the button to be re-added once created if (paw.ListItems.Exists(p => p is UIPartActionButton && ((UIPartActionButton)p).Evt.name == "MyButtonID")) { return; } BaseEventDelegate del = new BaseEventDelegate(delegate { OnPawClick(part);}); BaseEvent baseEvent = new BaseEvent(null, "MyButtonID", del, new KSPEvent()); baseEvent.guiName = "My button title"; baseEvent.guiActive = true; baseEvent.guiActiveEditor = true; paw.AddEventControl(baseEvent, part, null); } private void OnPawClick(Part part) { // do something with the part }
  6. As a memo for myself, and as a quick guide for others : Add PAW buttons to all parts from a KSPAddon, using KSPField decoration : [KSPAddon(KSPAddon.Startup.EditorAny, false)] public class MyClass : MonoBehaviour { [KSPField(guiActive = true, guiActiveEditor = true, guiName = "Some boolean"), UI_Toggle(enabledText = "Enabled", disabledText = "Disabled")] public bool someBool = false; private void Start() { GameEvents.onPartActionUICreate.Add(OnPartActionUICreate); } private void OnDisable() { GameEvents.onPartActionUICreate.Remove(OnPartActionUICreate); } private void OnPartActionUICreate(Part part) { // Get the PAW window UIPartActionWindow paw = UIPartActionController.Instance.GetItem(part); // Get the attribute System.Reflection.FieldInfo fieldInfo = typeof(MyClass).GetField("someBool"); if (fieldInfo == null) return; object fieldObject = fieldInfo.GetCustomAttributes(false).FirstOrDefault(p => p is KSPField); if (fieldObject == null) return; KSPField field = (KSPField)fieldObject; BaseField baseField = new BaseField(field, fieldInfo, this); // Add a callback, using the part as arg1 baseField.uiControlEditor.onFieldChanged = delegate { MyCallback(baseField, part); } ; // Add the field to the PAW paw.AddFieldControl(baseField, part, null); } private void MyCallback(BaseField field, Part part) { // Do something with the part when the toggle is used } }
  7. I think this should work : !MODULE[ModuleResourceConverter],* {}
  8. Gotmachine

    KSP Weekly: The Moon Race

    People need to chill out about the update cycle. Compared to most games, KSP is very mod-friendly, the API and codebase is super stable since 1.0. Excluding the super complex mods that deeply mess with physics, the vast majority of mods made in 2014-2015 for the 1.0 version can be recompiled on 1.4.5 with only a few trivial changes. The reason why a lot of mods from this era has been abandoned is most likely because a lot of modders, including me, don't have much time or interest to work on them. Since KSP is very mod-friendly, you can create mods quickly and easily. That mean that a lot of mods get created by a lot of people, then gets abandoned because they move on to other games or activities. To a certain extent, I think this is also happening with the "major" mods that have been supported for 4-5+ years by the same authors. They lost interest. People from Squad is aware of this, and they actually have done quite a good job since 1.3 at being very extra careful not to break anything and making their task easier. And my answer to the "I would prefer to have a finished game" is : you have it, it's called version 1.0.5. A game that is "finished" is a dying game. There is and will forever be bugs to be fixed, performance to be improved, physics to be made more accurate, graphics to be made nicer, features to be reworked or added. We should be grateful that Squad is still adding content and refining the game for free so many years after release.
  9. Gotmachine

    KSP Weekly: The Falcon

    Well, a Dv map in the KSPedia would do. If the "DeltaV" word appear in a few key place, even a player that don't know anything about rocket will soon understand what it mean. The maneuver node tool is a great learning tool : you quickly understand that the more you want to change your orbit, the more Dv you need. Then an enginner's warning when you don't have enough Dv to get to orbit. There is already one for the TWR < 1 situation. You could also have a "Approx. DeltaV to orbit : 3400 m/s" line in the tracking station body info box. As for the fact that a draggy / low TWR craft require more Dv, this is actually something that a new player can understand by himself, by testing different designs and playing the game. It's an intuitive thing. This isn't comparable to the current situation of not knowing your Dv, it's something that is near impossible to guess, especially for a new player. But everyone knows that a rocket has to go fast and has to be pointy. And you can get where you want with an inappropriate TWR or a draggy craft, but you will never reach you goal without enough Dv.
  10. Gotmachine

    KSP Weekly: The Falcon

    The vacuum delta-v value is very simple to understand and use, and roughly valid in all situations. For example, it's widely known that you need about 3400 vacuum Dv to get in LKO. Or 1500 at Duna. Or 8000 at Eve. From that, you know that you need more margin with a low TWR / draggy craft. What is more problematic is the TWR. But this can be simplified down to a situation (body) switch button somewhere near the engineer's report and a double reading when a body with an atmosphere is selected : sea level TWR / vacuum TWR. Excepted in some very specific cases, you don't need more.
  11. A bit of a post necro, but : when loading a vessel, several physics related things are initialized in the first few fixedUpdates. For a lot of things, checking FlightsGlobals.ready is not enough. The thermal handling of vessel is done by the FlightIntegrator class. It's a VesselModule and can be accessed trough the Vessel.vesselModules List. It can be fully initialized rather late after vessel loading. If you have any code that has to do with thermal properties, you need to check those two conditions first : FlightIntegrator.isRunning is equal to true FlightIntegrator.firstFrame is equal to false
  12. I already tried that. It doesn't work in practice because this mean RW are useless if you don't have RCS thrusters onboard, which should be the case on a lot of small sat / probes from a realism standpoint. The problem is that you are able to accelerate your angular velocity above the threesold and then you can't decelerate... This is absolutely not realistic, and would be very annoying. In fact the current version is already doing something like that : RW torque output decrease with angular velocity, but there uis a minimum value so you can't brick your craft. This is already in the plugin, and it's been expanded to allow to target the sun in the beta version. See my previous post : The current default setting is 0.5 % ("realistic" in the settings menu). But this only apply to pilot input. The SAS still has partially access to the default stock torque, this is the main feature of the RW nerf : allow easy cheaty stabilization using the SAS, have a realistic torque output for rotation requests. Judging from the comments, this works well. The part that i'm struggling with is that this 0.5% ratio apply to the stock torque balance which is all over the place. More precisely, the various pods usually have huge amounts of torque given their mass and size and compared to the individual RW parts and probe cores. In the current version my solution was to completely disable the "pilotable" torque from the pods, not very popular and a bit silly TBH. I think in the next version I will patch the pods to something like 25-50 % of the stock value, but I'm also exploring other means of balancing things like the idea above, and possibly a pseudo-saturation mechanism. Well this isn't very realistic... a reaction wheel or control gyro is a basic tech that can't really be improved much in terms of their mass / torque ratio. If someday I introduce some progression it would be based on various attitude control related technologies (magnetorquers, reaction wheels, CMGs...), see this post for details of what I have in mind for the far future. And to be fair I've totally given up on career mode, so not much interest personally.
  13. Note that the reaction wheels are not disabled, they still provide passive stabilization when the SAS is enabled. But they are not "controllable", meaning that they don't react to your input. I explained the rationale somewhere in this thread. In short, it is done so to force you to use RCS thrusters when it would make sense from a realism standpoint, while still allowing you the cheaty stabilization from KSP massively nonrealistic reaction wheels. You can disable the "not controllable" part by changing the ModuleTorqueControllerPatch.cfg to this : @PART[*]:HAS[@MODULE[ModuleReactionWheel],!MODULE[ModuleTorqueController]]:FOR[MandatoryRCS] { MODULE { name = ModuleTorqueController isControllable = True } } For it to be effective, you also need to go into the mod settings in KSP settings menu and check the "SAS & pilot control customization" box. This is on standby for now as I haven't got much free time to work on it, but I've been playing with it a quite a lot. It's kinda playable as it is, but there are a few things that need to be done before release and TBH I'm having a hard time fixing those : The UI is a bit quirky and have some bugs that need to be sorted There are some physics/timewarp/transforms related bugs in the persistant rotation/SAS part that are bothering me and that I don't fully know how to fix The overall structure of the code is a ugly mess, I'm probably at the peak of my "I don't really know what I'm doing but let's try this" motto The RW nerf need to be polished The settings menu need to be redone I need to allow switching between the mechjeb and stock SAS because while being a lot better in space and for rockets in general, the mechjeb autopilot is not so great for planes, there is some work to be done to allow that (wiring the stock SAS to my custom SAS UI). I'm not sure I understand. Do you mean like a tech tree related progression ? The thing is, the plugin doesn't make the RW less effective, it just prevent you from using it in an unrealistic way, only the SAS can do so. The goal is to force you to put RCS thrusters on your (heavy) spaceship, and the SAS part is here so you don't need to pack huge unrealistic amounts of RCS fuel. This also why in the new version I'm integrating the mechjeb SAS and a better SAS UI : to allow you to consume less RCS fuel and have more precise (less wasteful) control. In the end, this is a binary problem. Either you can't turn using only your reaction wheels and you have to add RCS, either you can and RCS are useless. But as many pointed out, the whole controllable/non controllable hack is counter-intuitive. I want to test another idea : the "controllable" available torque could be adjusted in an exponential relation with the vessel mass, something like this : A 1 t vessel with 1 kN of "stock torque" would have 0.1 kN of "controllable torque", resulting in the ability for the pilot to fully control the vessel using only reaction wheels a 10 t vessel with 10 kN of "stock torque" would only have 0.5 kN of "controllable torque", resulting in a very low ability to control the vessel This would automagically balance the available torque so "light" vessels in the 0-5 t range are controllable using a stockish amount of reaction wheels while larger ones would need more, or to switch to using RCS. I also want to experiment something akin to what the (Semi-)Saturatable Reaction Wheels plugin was doing, implementing a basic saturation mechanism with auto-desaturation when the wheels are idle.
  14. Yes, this is a feature that is already in place but there isn't any UI for it in the beta release, I think I will add as an additional state of the "SAS aggressivity slider". Note that the stock PID can't control roll, so this option will be unavailable when using the stock PID. This said, could you elaborate about the specifics of these edge cases ? My own tests show that the mechjeb PID always performs a lot better in non-atmospheric situations, but it doesn't perform well with aero control surfaces, and in aero situations in general. Also, I suggest not to use the roll lock mode in low atmo flight, the extra constraint is just to much for the already struggling in atmo situations MechJeb PID code. I tried to make a few tweaks to the aero control surfaces torque handling, but in its conception the MechJeb PID isn't the best solution for aero situations because he tries to find the theoretical "perfect" response using the theoretical data. In aero situations this isn't good because the external forces acting on the vessel are huge and hard to account for. This result in slow response followed by overcorrections and auto-oscillation issues. In comparison, the stock PID don't rely much on the situation data, use over-aggressive basic responses and depending on the stability situation, enter a special "self-correcting" mode to smooth those response and allow the vessel to reach near-stability. This make it react quick and fast in broader range of situations, but remove its capacity to be exact. This is why it struggle to keep a stable vessel stable but is good at getting out of an unstable situation, and aero flight in KSP is a very unstable situation.
  15. There is some low overhead to every attitude PID controller out there (KOS, MechJeb, TCA...), honestly I don't think this is noticeable. The main overhead is because we are forced to recalculate some basic variables that are borked beyond repair in the stock code (moment of inertia and available torque from RCS modules). If you wonder why the stock SAS is so inefficient with RCS, that's why. About compatibility problems, potentially that could happen since the stock SAS is permanently deactivated. I think it is impossible for a plugin to use the stock PID controller instance to do custom orientations (I tried and failed), so this should be safe. I have a doubt about Principa, this has to be tested. Also, I'm in the process of mapping the stock SAS modes to mines, so theoretically a plugin trying to set the stock SAS to "Prograde" would still work as intended (KOS for example). But there already is the stock "fine controls" mode for that, so it would not add much value and still require me to hook on the the stock RCS modules somehow. I will think about the RCS throttle at some point in the future, because I might try to add an RCS auto-balancer feature. But don't take my word on that because this is horribly complex, and it might prove even more complex to make it work correctly with the PID controller (this thing doesn't like having to deal with dynamic variations in the available torque).