Agathorn
Members-
Posts
1,139 -
Joined
-
Last visited
Everything posted by Agathorn
-
v0.2.1 experimental 2 https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.2.1e2 This is an EXPERIMENTAL release. Experimental releases are very much "development snapshots" and are released for the express purpose of getting user feedback or testing on a very specific bug or feature that is being worked on. If testing an experimental release, please limit feedback to the scope of that release. This is an alpha release and thus should be assumed to be buggy, and capable of breaking your game and game saves. Experimental release of the new reworked GUI. This is still very much a WIP. This release implements the new TestFlight GUI skin, addresses issues in Experimental 1, and adds a new compact Flight HUD. New TestFlight GUI Theme designed for clarity Settings pane is now split into multiple "sections", each of which can be selected from the drop down list at the top of the settings pane. The Master Status Display now has a maximum height for display of the part status. If too many parts need to be displayed, the GUI will start to scroll instead. Added scroll view for Part Display Added filter to show only failed parts in Master Status Display Added setting to set size of scroll view in one of three increments, Small, Normal, or Large Added setting to hide/show flight data on part Added setting to hide/show resting reliability on part Added setting to hide/show momentary reliability on part Added setting to hide/show part status text Added setting to truncate/shorten display names for parts Added setting to lock/unlock the Master Status Display window Added setting to enable/disable the compact Flight HUD Added new compact Flight HUD which displays *only* the parts that have failed, and a repair button. Part names are colored for quick identification of the severity of the failure. Green = Minor, Yellow = Normal, Red = Critical Moving the Master Status Display (after unlocking it) now saves the window's position Moving the Flight HUD save's the windows position - - - Updated - - - Proposal For Reliability and Failure System Redesign https://github.com/jwvanderbeck/TestFlight/wiki/Proposal-For-Reliability-and-Failure-System-Redesign
-
Looking very nice, and I agree I love that thin part for legs! Ingenious.
-
Trust me I have no problems with this. It really is the whole point, and as long as the code is working properly (IE there isn't a math or logic error) then all is good. It is the desired end result anyway! Wow thanks for that. I was doing a lot of reading over the last bit since your first post, and I see now that I was getting close but this really, really helps cement things for me. I don't think that will be necessary though I appreciate the offer. While I want to make the system as good as I can, I don't necessarily want to 100% accurately model reality. I think what we have here will be good enough. Also bear in mind that we will be cheating a bit, as we are in essence front-loading the determination of a failure rate. In other words in the real world parts are tested and from those tests a failure rate is determined. But for our cases, we are generating a failure rate right from the start, before any parts are used (though this will start from a base configured number that feels right), but further more we are making them more reliable over time based on the amount of flight data accumulated from test flights. So we are fudging the other end of the system, and then using all the fun math above to help determine based on the derived numbers, whether a failure has occurred or not. Don't worry about second failures. We will assume that once a part is repaired, if it is, that it is as good as when it was launched. You've been so very helpful and I appreciate it, but I have to ask for one more thing which seems like it should be obvious, but as I said i'm just not a maths guy, and certainly not a statistics guy. How would I be using Bayes' Theorem in this? Are we talking something like P(t)=P(dt)*P(t)/P(dt) ?
-
Using NASA Mission Control Software with KSP
Agathorn replied to Rich's topic in KSP1 Mod Development
Ok said the hell with the released binaries, and just downloaded the source and built that. Got the base OpenMCT up and running now, but having issues with the extra plugins that we would obviously want like Earthview and Satellite Tracker. I can compile Earthview just fine, but the plugin doesn't seem to be available inside MCT. And Satellite Tracker doesn't even seem to have a build environment set up, so I need to dig farther into that. Some of the plugins do seem to work though so I am not sure what I am doing wrong. @Rich if you happen to pop in here, if you could share anything you learned about compiling and using the extra plugins that would be great. Honestly I wouldn't hold your breath. To the best of my knowledge no one is actively working on this. I am messing around a bit in my spare time for the fun of it, just to see what I can get working. -
Using NASA Mission Control Software with KSP
Agathorn replied to Rich's topic in KSP1 Mod Development
Getting OpenMCT up and running is a real pain. The latest downloads all seem to give me corrupt files. I can get one of the earlier releases to run, but adding any of the views just throws exceptions and fails out. Think i'll mess around with this a bit in spare time though as it could be fun. -
Very cool and I am glad you found it easy to do. That was certainly my goal! Right now things are definitely a bit rocky, and there will be some major changes to the API coming when I overhaul things for the Push vs Pull setup and the new Reliability and Failure systems (which I plan to type up a proposal for soon). After those changes though if you would like to help on some documentation that would be exceptional!
-
WIP - Environmental Visual Enhancements Development
Agathorn replied to rbray89's topic in KSP1 Mod Development
Is there any way to get CityLights to display the detail texture only at certain altitudes? I want to have more detailed lights at low altitudes, and another at higher altitudes/orbit level. EDIT: Ug I just realized my city lights overall city lights isn't orientated correctly anyway and there seems to be no way to adjust it. I really liked the old system. Is it possible the old EVE still works? -
Yes this bothered the *hell* out of me as well. The sort of issue here is that as NathanKell is very much a 100% real guy, his design for sounding rockets doesn't involve using pSRB at all, but a pTank with inline seps at the bottom, so doing this you can get the sizes to match. Unfortunately a 0.3m booster is much more powerful than a 0.2m booster though, so upping it that .1m might be bad for gameplay. - - - Updated - - - NathanKell my guess on this would be because there is no actual link to the Releases page on GitHub, so people not clued in don't realize. Or thats my guess. I think simply adding an entry to the OP for Manual Install and adding a link to the Releases page on GitHub would probably cut that down a lot. Oh and getting links to the other mods! (*runs*)
-
WIP - Environmental Visual Enhancements Development
Agathorn replied to rbray89's topic in KSP1 Mod Development
What about at the same altitude though? My problem is the old system I could take two image, and adjust the X,Y offset to make them line up. This new system has an offset given in 3 values that I don't seem to understand because change any of those 3 values doesn't offset the image any. This is making it so that I can't get two images at the same altitude to line up the way I want. -
WIP - Environmental Visual Enhancements Development
Agathorn replied to rbray89's topic in KSP1 Mod Development
Still wondering on this if anyone can please help. I want to be able to take a series of 5 or 6 overall images on layers and line them up together to form one continuous texture over the planet. -
This is actually what I am leaning towards. Thanks! Thanks for the links, I appreciate the reading. Isn't that just very unrealistic though? My main problem with a MTBF system is that the mean time would have to be stupidly low for gameplay reasons and it would just plain feel silly to me. 12 seconds MTBF on a rocket sounds silly. Or is it just me? This is similar to my thinking. For game play reasons the player really has to have *some* indication of the overall reliability of a part, even if it can fluctuate. One thing I am toying with now, and have in my GUI mockups, is a "Resting Reliability" and a "Momentary Reliability". True, I could do something like that, but doesn't that seem like it could be pretty harsh? Seems unfair to hit you with a failure that you couldn't do anything about, or even know about.
-
WIP - Environmental Visual Enhancements Development
Agathorn replied to rbray89's topic in KSP1 Mod Development
Hi, In the really older versions of this mod I had made some config files, that unfortunately do not work anymore. I was trying to re-create them but the controls are very different. You used to be able to give it one large image that it would wrap around the whole planet, and you could set the radius of the sphere it was wrapped to, as well as an X/Y offset to align things. I can't seem to figure out how to do that anymore. Is this no longer possible? -
Just wondering how things are coming along on these. I absolutely love using these textures - they're pretty much the only ones I use now - and would absolutely love to see more from you in this design. Also are you still working on the Gamma Upper Stage texture? It seems a little odd where it has like a semi-transparent edge to it.
-
Yeah the problem is right now it doesn't work that way Currently the system is essentially a "pull" model rather than a "push". Everything is controlled by the Scenario which polls all the parts and asks for an update. I did it that way planning to eventually support TestFlight on ALL craft not just the active vessel. Unfortunately after some research it turns out that really isn't doable. So TestFlight will have to be restricted to the active vessel, and thus I Can rework the system to a "Push" model instead, which will allow things to work like we are talking about, and more. So once I am finished with the GUI rewrite, i'm going to get everything merged back in, stabilized a bit, then break off into another dev branch to rework the system to a push based system.
-
[1.0.2] B9 Aerospace | Procedural Parts 0.40 | Updated 09.06.15
Agathorn replied to bac9's topic in KSP1 Mod Development
Yay on all-moving control surface! As for "fixing" the memory leak, one thing we were talking about in #RO would be no longer using those tweakable menus and making your own UI instead. I'm actually in favor of that approach since I think the tweakables menus are a bad interface anyway, but that's just me. -
So what you are saying is that in the VAB it is too far to the right? I will look into that (in addition to letting the window be moved properly) Is it indeed supposed to be a straight +/- modifier. At -25% your reliability should be 75% on a 100% reliable part. So what you are seeing is definitely a bug. Doh that isn't good. I will make it so that the window has a maximum height and scrolls if it needs more space. The idea was that reliability modules would take care of this by increasing or decreasing the aggregate reliability under certain conditions. So for example if an engine is throttled higher or is under higher heat loads, a reliability module might penalize the overall reliability. It could also do the same thing for initial ignition.. sort of. Since parts are only polled every so often, that wouldn't work quite as expected. I like your ideas on a MTBF system except I fear it makes things over complicated, and it is also hard to fit into the game play, because your calculated UT offset might occur when the part isn't even on an active vessel. All these ideas are good, but would require some major refactoring of the system. Now i'm not against doing that, and I am not going to dismiss good ideas just because they mean more work, or major changes to my "vision" so let me spend some time mulling over things, and see how it works out. I know for one thing I don't currently like how failures tend to happen in batches, so i'd like to introduce some variability in that anyhow. On the flip side I will point out how failures were extremely common especially in the early days of unmanned rocketry. Look at RTV-G-4 Bumper with 3 successful flights out of 8, or Vanguard, 3 successes out of 11 launches. I look at something like this page (http://www.windows2universe.org/space_missions/unmanned_table.html) and I think it captures exactly what I am trying to provide. At the top of the list, the early launches, you have lots of failed missions and as you get farther down the list, more and more missions start succeeding. But even then there are the occasional failures, and even to this day they still happen every now and then. I think those early days of your space program should be will sprinkled with problems such as stages not igniting, or thrust being lower than expected, antennas not deploying, and yes big explosions every now and then That is what I am striving to provide and with everyone's great ideas I think we will get there Let me spend some time thinking on ways of reworking the system to be a bit more fun and dynamic.
-
This is something that is really hard to say. I know what you mean and I haven't figured out how to approach it yet. The way it works right now is every X period of time, it polls all the parts for a potential failure based on reliability and if they fail that check, then they get a random failure. Problem is if you are checking for a failure say every 30 seconds, then even something with say 80% reliability has a lot of chances to potentially fails. In the new UI you will see that you can change the time between failure checks, and one way to "make it easier" is to simply make it check less often. I'm not sure if that is the solution or not though. On the other hand, I could do something like it has to fail 2 checks before it fails, or something like that but then you start stepping on the whole reliability system. tl;dr I don't have a solid answer for you but i'd love input and thoughts on the matter. No it being on the capsule was actually a mistake and fixed in 0.2.1 This is actually the intention behind the upcoming Flight HUD which you mention below. The in flight HUD will be a very condensed view only showing failures. I hadn't thought about, and in fact TestFlight was conceived of long before contracts were added, that but its a neat idea. At the moment I know nothing about how contracts work in the API, but I will look into it. Can I possibly get you to submit that as a feature request on GitHub so I don't forget? That could get OP pretty quickly I think, but let me do some thinking on the matter. Guess I forgot to save the window position See above for the info on the HUD. Thanks for your detailed feedback. Very much appreciated!
-
v0.2.1 experimental 1 https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.2.1e1 This is an EXPERIMENTAL release. Experimental releases are very much "development snapshots" and are released for the express purpose of getting user feedback or testing on a very specific bug or feature that is being worked on. If testing an experimental release, please limit feedback to the scope of that release. This is an alpha release and thus should be assumed to be buggy, and capable of breaking your game and game saves. Experimental release of the new reworked GUI. This is still very much a WIP. This release adds a settings GUI and enables the user to modify TestFlight settings directly in the UI. Settings are saved as you update them. Added new GUI system courtesy of **TriggerAu** Added new Settings dropdown to the TestFlight Window. This panel will allow you to modify all global TestFlight settings.
-
Some mods are compiled against 4.0 but they often cause issues and incompatibilities. I think Unity's version of Mono is still predominantly .NET 3.5 even though it has some of the pieces of 4.0
-
I'm having a SIMILAR but not exactly the same issue. Though not with all parts. I have two stock radial chutes and a structural I-Beam on my sounding rocket. All three parts are TweakScaled down in size to make them fit. The I-Beam works fine, but the Parachutes reset their WEIGHT when I move from VAB to Launchpad. The size remains correct but they gain 20kg of weight which makes my entire real scale rocket go to crap Like I said though the I-Beam remains correct.