Jump to content

Firov

Members
  • Posts

    302
  • Joined

  • Last visited

Everything posted by Firov

  1. I recently discovered this problem myself. I believe it to be fixable at this point, and it's certainly irritating. However, I'm having to go through the code to better understand how the staging works in the smart parts mod, as that's not something I've actually had to work with yet, since all of the smart parts use a utility class that handles the action group firing and staging. It's my hope that I'll have a fix for it sometime this weekend. Keep an eye on the smart parts thread Smart Parts. Once I get it fixed and tested I'll probably end up posting a hotfix over there to tide everyone over until the next full release. Thanks for the report!
  2. Good catch. Though this was actually something I was aware of. In fact, no smart part can directly activate the gear action group. When I asked Dtobi about it he mentioned that he experienced problems in getting the gear action group to fire properly when he first created the mod, and so dropped it. This is actually something you have probably already experienced, if you've ever had to hit the gear key twice for it to actually do what you want. I have some ideas on how to get that fixed, but I was too busy with the altimeter and timer improvements to really look into it for the last release. I may have something for the next release, but at this point it's too early to make any guarantees, since it's really a bug with stock KSP. For now, I'd just assign your landing gear to an action group and use that.
  3. It actually is possible to get around this annoyance as a plugin creator, though the solution is, admittedly, a bit of a hack. Set the start point for the KSPField slider to the negative value of the lowest point you can go to on the slider before it jumps to the start point if the endpoint is 0. Then simply use a check in onUpdate() that checks for negative values of the slider and sets it back to 0 if detected. Hmm. Looking back at that, it may not make much sense. In other words, in this case, the KSPField slider's start point would be -0.36. That way you can smoothly go all the way to the desired start point, in this case 0.1. To prevent a negative value from actually being used just have it check for that and reset it to 0 regularly in onUpdate(). I used that on the altimeter in the latest release of the smart parts mod.
  4. It's mentioned above, but I'd just like to reiterate that you'll want to replace any altimeters on saved ships with the new and improvedâ„¢ altimeter part. Since the logic and even variables changed so much from the old altimeter part (it's basically a complete rewrite) using old parts is going to result in all kinds of oddities, most of which surely won't be pleasant. Also, I'd welcome any feedback on the altimeter or suggestions on possible improvements. Also, just one other other minor clarification on the above patch notes, as some of you may have realized, true staging was added to the timer part in v0.3. In v0.4 I improved upon that by allowing you to remove (or add) it's staging ability(and icon) with tweakables at which point it operates just like the old timer. Anyway, that's it on my part. I hope everyone enjoys the new parts. If you run into problems or have suggestions on new features or parts, I'd like to hear them.
  5. I think you'll be pleased with the updated altimeter, as this was one of my major priorities with the new altimeter. The altimeter can now be used during both ascent and descent, and it supports auto reset. So for example, lets say you want your solar panels and antennas to automatically deploy at 50KM during ascent and then stow during reentry at that same altitude, you can do both with the same altimeter. Also, naturally it now works over water, and is a lot more accurate in general, even taking Kerbal space center building height into account. Oh, and it's tweakable scale has been redone as well so it now supports altitudes of 0 to 1000 meters, and 0 to 100 kilometers. I decided that was a lot more elegant than implementing the decameter scale that was brought up in the smart parts thread.
  6. I'm afraid that's my fault. We discovered a minor bug with my new and improvedâ„¢ altimeter smart part that could result in it not triggering at extremely high velocities at high physical timewarp. Since SSE and Smart Parts are currently linked, a delay in one results in a delay in both. However, I'm pleased to report that the bug has now been thoroughly squashed and so, barring any other issues, we should be set for release tomorrow.
  7. Airblader, that's not a bad idea. Though so far I can't find any way to do that either. Unfortunately the documentation for the new tweakables system seems... well, non-existent.
  8. Very clever move on the part of NASA. Oh, sure they spin it as a "community outreach" program. I think we all know their true intentions though. They're pressuring SQUAD to add asteroids so they can use KSP to plan their future asteroid missions for a fraction of the cost. Very clever indeed.
  9. As someone who reads a lot of sci-fi space operas, Earth might technically be correct, but I have to say, "Terra" sounds much cooler. What would you rather be called, a Terran or an "Earther". Personally, I've seen both in use and I much prefer "Terran". Of course, this is only really important in settings that have multiple disparate human factions. Otherwise, plain and simple "human" works pretty well, or "hew-mon" if you're talking to a Ferengi. As for the "K" thing, admittedly it's a bit old, but it's not a huge irritant. At least, not yet.
  10. Kerbal Space Program plugins are coded in C#. If you're familiar with Java, it's syntax and structure is extremely similar to that.
  11. Kim Jong Un, is that you? Now what did we tell you about trying to get information for your ballistic missile program from the Kerbal Space Program forums? That's right, it's a bad idea. Now if you want to make long range ballistic missiles you'll just have to do it yourself.
  12. Well, you can hardly argue with this "logic". If it's not flying anymore, it must have been a huge failure. Makes sense to me. Take Apollo for example. It flew a total of 11 manned flights before it was retired. Clearly it was a huge failure. Then Gemini, since you brought it up. Oh, sure, it produced some invaluable information that paved the way for the the lunar missions, but if it would have been worthwhile it would still be flying, so we can only conclude it was a failure and waste of money. On the Soviet side Vostok was an even greater "failure" than Apollo, after all, it only had 6 manned flights. What a bunch of chumps they must have felt like after they set the ~5 day record for a cosmonaut in orbit that wouldn't be broken until years later during the "failed" Gemini program. How they ever recovered from such "failure" is beyond me. Finally, we arrive at the shuttle. The massive failure that it was. Oh, sure, it successfully completed 133 missions and helped build the ISS during it's 32 year lifespan, versus the 116 of Soyuz over a longer 47 year lifespan, but the fact that it's not currently in use clearly must mean it was a failure, just like Mercury, Gemini, Apollo, and Vostok before it... Excellent logic Crazyewok. Every single spacecraft has a limited lifespan. Partly because of advances in technology and partly as a result of changing requirements. Even Soyuz is slated to be replaced by a more modern and capable craft. It likely would be already if those replacement programs weren't under funded by Russia's government. That's simply the nature of spaceflight. As your technology advances and your mission requirements change you design new spacecraft that better utilizes those advancements to make them more capable of achieving your goals. So I'm curious, when Soyuz is retired and replaced by something new, the PPTS perhaps, are you going to use this "logic" that if it's not still flying it must be a huge failure? I thought not...
  13. Is there any method available to force a redraw of the tweakables (right click) menu for a part? For context, I've got a couple of GUI event buttons that toggle their visibility back and forth using "Events["eventName"].guiActiveEditor" which generally works great, but for some reason it occasionally fails to redraw the GUI to show the newly visible button and remove the button that had it's visibility set to false. Right clicking on the part again shows the GUI how it should be. However, this isn't necessarily intuitive, so is there any method available that can force a redraw of the tweakable GUI for that part? Thanks.
  14. This looks very nice. I look forward to trying it out. I'm curious, does it handle SRB's? By that, I mean does it properly factor in their thrust? Obviously it can't, and shouldn't, alter their throttle, but it would be nice if it will factor in their thrust and adjust any liquid engines accordingly. Also, how does it handle engines with large gimbal ranges?
  15. I love the idea of this mod! Great work! Quick question, how does it handle reverted flights? Hopefully they're not counted?
  16. Riddle me this... Which one had two fatal accidents? Surprise! Trick question! They both had exactly 2 fatal accidents over their entire careers, with the shuttle actually having more total flights. Anyway, seriously, drop the blind nationalism, Chekov. It serves no one. In the end every nation is going to have to work together if we hope to make any meaningful progress in space exploration and especially colonization. Personally, I welcome that cooperation. Be they Russian, American, Chinese, or Indian, any investment into spaceflight ultimately uplifts all of humanity. So why don't you get over your "Russia first!" attitude and join the rest of the world. The cold war is over.
  17. Hey Chris. Thanks for the link. I'll have to take a look at that code, though I actually just figured it out myself. The code below is capable of creating the proper icon. It turns out that I needed to use the part.stackIcon.iconImage property to assign the icon image, then use part.stackIcon.CreateIcon() to generate it, and finally staging.SortIcons to put it in the list. Oddly enough though, using this exact process in OnStart() doesn't successfully create the icon, but that's fine since "this.part.stagingIcon" does. Not that I can explain that apparent discrepancy. [KSPEvent(guiName = "Stage Activation", guiActive = false, guiActiveEditor = true)] public void toggleStage() { if (stageStatus == "On") { stageStatus = "Off"; this.part.stackIcon.RemoveIcon(); Staging.SortIcons(); } else { stageStatus = "On"; this.part.stackIcon.iconImage = DefaultIcons.RCS_MODULE; this.part.stackIcon.CreateIcon(); Staging.SortIcons(); } }
  18. This is actually a good point and while I've toyed around with the idea of one universal part, the fact is it's simply not feasible within the current constraints of the tweakables system. It would just be too unwieldy. I'm afraid we'll all just have to deal with a multitude of smart parts until Dtobi or myself can think of something better. That said, my next objective is the overall improvement of the altimeter, primarily to fix bugs such as the -1 over water problem, but also to improve accuracy and probably add another unit scale, perhaps decameters, as someone requested. As for a request that keeps popping up in this thread, I'd actually really like to implement a system so that it triggers "at" the set altitude rather than "above" or "below" and is capable of automatically resetting. I see the use for this in, for example, having a single altimeter that can extend or retract a RemoteTech antenna at a set altitude, or control landing gear for both takeoff and landing. Both of which would be useful for either reusable landers or spaceplanes. It's sort of possible to achieve this effect with 2 altimeters, but even then they don't really reset. The first version I came up with when creating an altimeter that could handle high altitudes actually had that ability, and would deploy within a set distance of the target altitude. Overall it worked reasonably well, but it did have a problem in that at extremely high vertical velocities (~500 meters per second) it could blow past the defined target window (~3.5 meters) faster than the game could recognize it, thus missing the trigger point. I have some ideas on how to fix this, such as scaling the size of the window based on velocity and switching over to OnFixedUpdate(), but at this point it's too soon to promise that I'll be able to get that working.
  19. I don't know Chris, I think this might just be an impossible task, much like custom icons. Based on your advice I set up my module as below. Clicking the toggle button however doesn't disable the icon if it's already there, nor will it bring it back if the icon was set as disabled when you loaded into the editor. In fact, this version isn't even capable of generating a blank staging icon. It will function properly when it loads onto the pad or runway, either having a stack icon if enabled or omit it if it's disabled, since I have a check in the "OnStart" method to create the icon only if it's enabled. Unfortunately, "this.part.stagingIcon" doesn't seem to work anywhere but in the OnStart method, and I have no idea why. I might be able to reinitialize the part to force it to go through OnStart again, but that's not something I've really looked into. This "simple little tweak" has quickly gone from a minor nuisance to a serious annoyance. Oh well. Any other ideas? Either way, I appreciate your help. //Field [KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Stage Activation")] public string stageStatus = "On"; //Event [KSPEvent(guiName = "Stage Activation", guiActive = false, guiActiveEditor = true)] public void toggleStage() { if (stageStatus == "On") { stageStatus = "Off"; this.part.stagingIcon = string.Empty; Staging.SortIcons(); } else { stageStatus = "On"; this.part.stagingIcon = "RCS_MODULE"; Staging.SortIcons(); } } //OnStart public override void OnStart(StartState state) { if (stageStatus == "On") { this.part.stagingIcon = "RCS_MODULE"; } }
  20. Rhidian, I'll give that a shot. Thanks. Also, Chris. Thanks for the advice. It's appreciated. However, I was originally trying to alter the part.stackIcon property, as is visible in my original post, but I met with extremely limited success. It did technically allow me to add or remove an icon but, much like the staging class method in my later post, recreating the icon always resulted in a blank box in the staging list, rather than the proper RCS icon. As to your example, unfortunately stackIcon doesn't accept a string as an assignment value. It's looking for a VStackIcon. I assume you actually meant part.stackIcon.iconImage? If so, it still doesn't accept strings. Instead I have to use one of the default icons from the DefaultIcons enum. Which sadly doesn't allow a null value, or in your example, the empty string. However, that said, it's entirely possible that I simply misunderstood you. Also, one final question for you, how do you know that the Staging class is deprecated? It seems like the documentation on the Kerbal API is a bit... spotty. Just curious if I've missed some documentation out there somewhere. Thanks again to both of you. edit - Also, part.stackIcon.iconImage appears to do nothing. Much like the rest of the functions related to stage icons... *sigh* This really isn't turning out to be as easy as I thought it would be when I decided it would be a "good idea" to add support for tweakable staging.
  21. Okay, I tested it and it does work reasonably well. Unfortunately, it's still incapable of drawing the right icon if you disable staging and then reenable it, at least until you change scenes, at which point it properly creates the icon. It seems that, for whatever reason, "this.part.stagingIcon" only has any impact during initial scene load. Any other ideas? Latest version //Field [KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Stage Activation")] public string stageStatus = "On"; //Event [KSPEvent(guiName = "Stage Activation", guiActive = false, guiActiveEditor = true)] public void toggleStage() { if (stageStatus == "On") { stageStatus = "Off"; Staging.RemoveIcon(Staging.FindIcon(this.part)); Staging.SortIcons(); } else { stageStatus = "On"; Staging.CreateIcon(this.part); this.part.stagingIcon = "RCS_MODULE"; Staging.SortIcons(); } } //OnStart public override void OnStart(StartState state) { if (state == StartState.Editor) { this.part.OnEditorAttach += OnEditorAttach; this.part.OnEditorDetach += OnEditorDetach; this.part.OnEditorDestroy += OnEditorDestroy; OnEditorAttach(); } if (stageStatus == "On") { this.part.stagingIcon = "RCS_MODULE"; } part.ActivatesEvenIfDisconnected = true; }
  22. Interesting idea! Thanks. I'll give this a shot and report back.
  23. If I understand his experiment correctly, blowing a fan against a wall generated a force that pushed against him in the opposite direction? Impressive. Most impressive.
  24. I'm trying to set up a part that can be removed from the staging list via a toggle that's only visible in the VAB or SPH. However, while I can get it to work properly in the editor whenever it loads into a new scene, during launch for example, the icon shows up in the staging list again. I have code in "OnStart" that should remove that icon, but it doesn't appear to work. You can see the code I'm using below. I've had some luck in using an if statement that checks to see if "stageStatus" is on before setting the StagingIcon in "OnStart", but the problem there is that I can't create that icon until I load into a new scene if I go back to the editor while the stage display is off. For example, if I set it to off and go to the launchpad, the icon won't show up. Unfortunately, if I then revert to the VAB and click on the Stage Activation toggle to show it again it will show a blank icon until I go back to the launchpad. Am I just on the wrong track here? How can I ensure that the icon won't show up when switching scenes if it's toggled off? // Field [KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Stage Activation")] public string stageStatus = "On"; //Event [KSPEvent(guiName = "Stage Activation", guiActive = false, guiActiveEditor = true)] public void toggleStage() { if (stageStatus == "On") { stageStatus = "Off"; this.part.stackIcon.RemoveIcon(); Staging.SortIcons(); } else { stageStatus = "On"; this.part.stackIcon.CreateIcon(); Staging.SortIcons(); } } //OnStart public override void OnStart(StartState state) { this.part.stagingIcon = "RCS_MODULE"; if (stageStatus == "Off") { this.part.stackIcon.RemoveIcon(); Staging.SortIcons(); } }
  25. rbray, perhaps I misunderstand, but it seems like your first quote here indicates that, "modfoldername/.*" won't work and should instead be modfoldername/subfolder.*, but then you immediately follow up by indicating that for the warp plugin you use that exact format. I'm probably misunderstanding, but can you please clarify that?
×
×
  • Create New...