westamastaflash

What would go in the Rails warp toggle? Hyper-warp and Slowmo could use the settings that are set in the other panels, but I'm not sure what would go in rails toggle - current altitude max warp allowed maybe?

I'll take a look. Sorry I haven't had much time to work on this recently.

Maybe... I'm not sure to be honest. I'll try to release something soon and just note in BIG RED LETTERS that hyper warp can cause trouble in low orbits.

There was a thread about this here: For some reason things are a lot *worse* when I change the Unity TimeScale. Maybe something changed in unity in this release... I am considering some options like 'correcting' the vessel's orbit as if it were on rails if and only if there are no forces acting on the vessel... I still have to think about this.

I noticed this as well, and it really does feel *worse*. This problem makes Hyper-Warping with my mod Time Control a big problem in low orbit, since with sped-up time you can see the changes to the semi-major axis happening much more quickly (even with zero reduction to the physics engine fixed delta time step). *sometimes* the changes stop completely for maybe a complete orbit or two, but then restart again. Here's an example - I tracked the vessel's 'orbitalenergy' parameter over time, and it is decreasing. I think you can derive semi-major axis from this value. At 22:40:57, orbitalenergy was -2528029.48805985 At 22:50:32, orbitalenergy was -2528030.95893785 I think KSP is calculating specific orbital energy using the standard equation as -μ / 2a (where a is the SMA), because my SMA was around 698488.7 m at the start and 698488.3 m at the end. I'm not sure if μ includes your vessel's mass or not. I'm guessing not since the G of the planet is so big it would hardly make any difference. When I use very high time scales (50x) to speed up time, the vessel's SMA (and orbital energy) loses many meters over the course of a single low orbit. It has to be something screwy with how KSP is calculating the orbital parameters with respect to the planet over time. I might have to introduce something in my mod where the orbital parameters are captured upon entering hyper warp and 'adjusted' if there are no forces currently acting on the center of mass of the vessel. This can be difficult though given that if I make an adjustment, how do I know the vessel is going to be moved to the 'correct' place... I really don't want to try to figure out how the coordinate system in KSP works so I can basically rewrite the logic that makes a vessel orbit a planet... I guess I could simply ignore the coordinate stuff altogether and use the previous orbital parameters and basic 2-body calcs (which i guess is what on-rails does too). One thing is for sure, it definitely gets much worse when I use the hyper warp functions of my mod, which mess with Unity Time.timeScale and Time.fixedDeltaTime. I wonder if there's something screwy between the on-rails planets and the vessels happening when I speed time up.

No new release for 1.7.X yet. I am getting some strange behavior with Hyper-Warp where the the Semi-Major axis of a vessel is slightly changing while in hyper-warp. I'm going to have to research. This seems to be happening even when On-Rails warp runs without time control installed. But since Hyper-Warp is done in 'real-time' the effect is much more severe.

Recompiled and released for KSP 1.6.1. No new code changes.

I thought I had inclued an option to disable the screen messages in the time control options panel (part of the main options)? "Show Slow-Motion Onscreen Messages" "Show Hyper-Warp Onscreen Messages" Are these not working to turn off the message display?

Sorry I'm still catching up on stuff in RL. I will see if I can work on a recompile in the next few weeks.

Sorry folks. RL is killing me. I reached out to both @severedsolo and @linuxgurugamer but haven't heard back yet on yay or nay for taking it on. I meant to do more, but you know how things get.

Ahh KSP is now 1.6? I will try to find some time this weekend to work on this. It's been touch and go with a ton of crap at work right now...

It's from Nov - YYYYMMDD is the naming convention since it sorts correctly on computers.

Yep. I know about this and am working on a fix but it will be until after the holiday season.

Given the holiday season here in the states and my current load @ work I cannot promise a stable release for awhile yet. I've been working on it when I get the time, sorry! You can try the experimental version on the build server posted further up, it was compiled against 1.5.1. There is still a problem with launch sites that I haven't got sorted. I need to figure out how KSP does their new launch sites and put it all together.

Nothing has changed with the scrapyard integration, and nothing probably will for awhile.

I would love that as a feature as well. As for the launch issue, it might have to do with a brand new save having trouble identifying the KSC launch pad. I am still in the process of debugging. I can only work on this some evenings and weekends since I work FT and have a 3 year old, but I'm making slow progress.

Yeah it's not completely clear. You need to click into the latest build (Manual Build 20181103.6), select the "summary" tab, and there is a zip file under 'build artifacts published'.

Yeah this is the biggest problem that I am working on solving. The VAB / launch pad levels are completely screwed up. Also, the inability to launch from Dessert or Woomerang. Plus KSCSwitcher / KerbinSide support is also broken.

Update: Some progress has been made on the code front. I've got a build server going here: https://dev.azure.com/KSPModsWMF/KerbalConstructionTime/_build?definitionId=9 Builds are compiled against the latest version of my code after I check in changes. This is untested, unsupported, and *not a release*. I'm still working on getting the launch pads to work correctly after the changes that were made with launch sites. But if you want to try it out in 1.5.1, the latest build will at least run. There may be exceptions or errors. One other thing I am planning on doing is leveraging a pre-built expression parser for the formulas, so they will follow order of operations, and provide additional functions. I have added the code for the MIT-licensed Expressive but not yet tied it into the formulas.

KSP 1.5.1 update released. Includes a fix to an exception that sometimes threw on a scene change, and allows one to go straight from a PAUSED state into a warp or slow-motion state.

It definitely appears to be somewhat hacky. I need to review this code. I might be able to leverage some of the ideas that the Hangar mod uses. The difficult part is resetting single-use parts and such.

One of the reasons is that the code, as it stands, is nigh-impossible to maintain without accidentally breaking things. Half Nearly All of the internal logic of the mod is embedded directly in the user interface, while other, just as important parts, are in static classes that maintain state and operate as 'global function containers'. Also, every scene change, the entire mod reloads itself. There are a bunch of calls that assume things are ready, but when they're not, throw NullReferenceExceptions instead of strong errors. There's a little bit of instrumentation to track where things went wrong, but not enough. Incremental improvement will definitely happen, no code is being thrown out completely unless necessary. But 250-line functions are simply not debuggable in a meaningful way when submitted as part of bug reports. As far as modularization, I'll back track a little bit on that. I don't think that means "5 mods". It means "one mod but with very clear boundaries between various things both *in the code* and *in the GUI*. As you said there's a lot of flexibility with the formulas, and I don't want to take *any* of that away. From a pure UI/UX perspective, I don't expect much of anything to change initially. I'm currently just trying to get it to build and work consistently with 1.4.5. The new 'launch sites' that KSP added seems to have borked a lot of the launch pad specific code.

Ah, that makes sense. I wasn't sure what you meant. I was not planning on changing anything drastic - the build points per unlocked tech would stay, probably as a core option that is turned on by default. I may even add another option to grant a build point per X launches , or per X tonnage launched, or some such thing. To represent your space program's ability to learn from what you've done before.

Not sure what you mean... In career mode, you can buy build points with science and funds already using the "Upgrades" button from the space center KCT screen? The default science formula is min(2^([N]+2) * 1.0, 512), where N is the number of upgrades previously purchased, so you max out at 512 science per build point. The funds formula is min(2^([N]+4) * 1000, 1024000), where N is the number of upgrades previously purchased, so you max out at 1024000 funds per build point. Total Build Points available comes from multiple things: Starting Upgrade Points + Total Techs Researched (When using tech unlock times) + Total Techs "In Progress" (When using tech unlock times) + Upgrades Purchased with Funds + Upgrades Purchased with Science + "Inventory Sale Upgrades" - Does not appear to be used in the code + Total Techs Researched (When not using tech unlock times) + "API" build points - Does not appear to be used int he code

I've been looking into the code in detail over the past few days, doing some instrumentation on it, identifying places that can be improved to help track down bugs. One of the things I want to do is work to modularize each of the main KCT features, so that each feature can operate independently, but also as a cohesive unit As part of this as well, per one of @magico13's ideas, I am looking into breaking this up into a few more manageable components: Kerbal Construction Time - Core Mod. Will provide the necessary shared functionality for each sub-component. Purchase Build Points with Funds and Science. - Some Assembly Required - Rocket Assembly Facilities. Each rocket requires a 'factory' to build all the components. Build Points allow for faster and/or parallel rocket construction. Allows immediate launch on build if Launching is Complex is not activated. - Launching is Complex - Add Rollout / Rollback of rockets to launch pads, Reconditioning of Launch Pads. Build Points to allow for faster rollout/rollback and pad reconditioning. Individualized to each launch pad if Kosmodrome Konstruction is activated. Optional future feature to require pads have cyrogenic fuel storage facilities that can hold the requisite amount of fuel the rocket needs before it can launch, to go along with more 'weight limits' for each rocket pad. - Kosmodrome Konstruction - Takes over all aspects of KSC construction, upgrades, and launch pads. Build multiple launch pads. Integrate with KSCSwitcher, RSS, and stock launch sites. Option to start with just the KSC and "open new launch sites" and upgrade those individually. Build Points can be used to purchase new launch pads or open new Kosmodromes. - Not-So-Mad Science - After starting to research a technology node or part, it takes time to complete the research of that node or part. Build Points can be used to speed up this process.