SpinkAkron

Recycled Parts. I'll take a look. I won't get this one out to you early since I'll need to see what @theonegalen does with the aero stuff first. So look for it in v1.0.

The Mk1 Cockpit is for making stylish science buggies. Some weirdos think you should make "flying machines" with it. Whatever trips your trigger, I guess. I think that decoupler must be from a mod. What other mods are you using?

@Trulight, In spite of being at death's door from the dreaded man cold, I bravely stayed home from work and worked on the NovaPunch config. I did end up moving almost every single part. Through OCD and over-medication, I persevered. Want to take a looksie and let me know what you think? You'll need to install the full mod and then stick these in GameData\UnKerballedStart\Mod Support. NovaPunch.zip <--- that one

@linuxgurugamer, NP_lfe_25m_Orbitalbertha is not showing any engine stats in game.

Thanks!

@linuxgurugamer, going thru the parts to make a compatibility config for my mod, I noticed a couple small issues with bulkhead profiles. Assuming I'm understanding things correctly. These three should be bulkheadProfiles = size3,size4 - missing size4 NP_interstage_375m_5m_SAS NP_interstage_375m_5m_tank NP_interstage_5m_375m_plate NP_decoupler_stack_5m should be bulkheadProfiles = size4 - currently set as size3.

I play a heavily modded setup. I've never tried RSS/RO but I think the basics of it should work. You'd need to make changes to some of the variable values. They're set to what I found worked for Kerbin launches, for instance. You could give it a try and see what happens. My reason for releasing this is to give players a starting point to adapt for their needs.

Holy underpants, I thought KW Rocketry had a lot of parts. Luckily, I'm probably only going to need to move no more than all of them. I'll see if I can have it done for the next release.

That was quick. Thanks!

For those that may be interested, I released my script pack. Spink's Script Pack

Hi, I published my first mod a couple days ago to Spacedock and following the instructions clicked the CKAN button to get it added to CKAN. It hasn't showed up and, reading through this thread, I see there is a problem with that functionality. What do I need to provide to get my mod added to CKAN? My mod is here: UnKerballed Start Thanks for the assistance and thanks for CKAN!

Good Enough Rocket Science kOS Script Pack Thanks to Kevin and all the others I learned from! First of all, I'd like to thank Kevin Gisi for his great YouTube series on using kOS. I learned a lot from him and used his code as the starting point for mine. Go watch his videos. I've also picked up snippets from the kOS threads on this forum and reddit. I never planned to release this so unfortunately I didn't make the effort to keep track of what bits I got from where. So, here's a big thank you to all the folks sharing their code and expertise on the various forums. What it is This is a library of scripts I've been working on for a couple years of playing unmanned careers. I thought making it available might help players who'd like to try kOS but don't know where to start. I tried to keep the code simple and easy to follow. It is composed of a boot script, a library of functions, and a mission folder. The library functions are the building blocks used to build the missions. They cover launches, changing orbits, intercepts, docking, landers, and science gathering. I'm sure there are better, more exact and efficient ways to do it, but I went with a "good enough" mindset. If it got the job done reasonably well most of the time, it was good enough for me. By releasing them I'll have the opportunity to take advantage of user's experiences and suggestions to improve them. NOTE: there are bound to be some bugs, inconsistent performance, etc. I can't guarantee they'll work for all situations and mods configs, but it should give people an idea of one way of approaching kOS and a place to start. You may need to tweak things to fit your situation. If you provide feedback and bug reports, I can fix and improve it both for my use and the community. What it's not For those unfamiliar with kOS, it's not MechJeb. It's not plug and play. It's more of a tool kit. Unlike a regular mod, you're expected and encouraged to dig in and change things. I've learned more from trying to figure out why something isn't working as expected than when it does. It's very rewarding when you see a mission you've designed actually work like you intended. File Structure There are three main folders within the script folder itself. The boot folder contains the boot script (boot.ks). The library folder contains the functions that are used by missions. The mission folder contains sub-folders with the name of the mission. The mission folder is named for craft that will execute the mission. So spacecraft "Mun Probe I" will execute the script in folder "scripts\missions\Mun Probe I". I find it makes it easier to keep track of things. Within the mission folder is a script file names "mission.ks". This is the file that the boot script will look for first and attempt to execute. It will also look for a file named update.ks whenever it reboots. This is how you can make changes during a mission. Any library scripts needed by the mission are loaded via the require("name") function. It works pretty nifty I think. Program Flow Processing is structured around two primary concepts - Phase and Run Mode. Examples of phases are launch , orbiting, landing, etc. The mission script work with phases. Here's an example of a CommSat launch. The main loop is a series "if phase =' statements that control the program flow. When one phase is complete, we setphase(x) to move to a different phase. Setphase also saves the phase variable to a file so that in the event of a power failure or reboot you can continue in the same phase. That's the intent anyway. I'm not sure how well it works in practice. @lazyglobal off. if true and require("ascent.ks") and require("systems.ks") and require("changeorbit.ks") and require("control.ks") and true { main(). } else{ notify("REBOOTING"). wait 10. reboot. } function main { local iHdg is 90. local iOrbit is 1067600. local iPitch is 90. local fOrbit is 1067600. when ship:altitude > 60000 then { deployFairings(). } when ship:altitude > 70000 then { deployPanels(). deployAntenna(). } if phase = 0 { setPhase(1). } until phase = 0 { if phase = 1 { ascent(iHdg,iOrbit,iPitch). wait 5. setPhase(2). } if phase = 2 { changeorbit(fOrbit,true). setPhase(3). } if phase = 3 { adjustPeriod(7200). if approx(apoapsis,1067.7,2) { setphase(0). } else { setPhase(2). } } } setPhase(9). notify("Orders complete"). } The functions being performed within the phases are the library functions. They are uploaded to the craft by the requires() function at the beginning of the script. In the same manner the mission script is controlled by Phase, library functions are controlled by Runmode. in the scripts, runmode is shortened to 'rm' . Memory space in kOS is determined by character count, so I tried to keep that low without adversely impacting readability. Even so, advanced missions requires files to be deleted and new ones uploaded as there isn't space to load the full set at once. Look in the missions/archives folder for examples of missions I've put together. I move mission folders in and out of the archive folder as I need them. This keeps the mission folder from getting cluttered while still keeping them handy. There are displays in the console showing the phase and runmode and whatever other info I thought I needed to see at the time. Here's the ascent script. It's not mechjeb but it works well enough most of the time. //ascent.ks @lazyglobal off. require("control.ks"). function ascent{ parameter tHeading. parameter tApo is 100000. parameter iPitch is 80. parameter ApoETA is 60. parameter sBurn is 5. local rm is 1. local mPitch is 0. local mPitchAlt is 60000. local pidAlt is 60000. local kP1 is 0.05. // 0.05 local kI1 is 0.6. // 0.5 local kD1 is 0.001. // 0.01 local aPID is pidloop(kP1,kI1,kD1,0,1). set aPID:setpoint to 200. local tPitch is 0. local tLaunch is 0. local tPrd is getPeriod(tApo). local fIg is true. local tWork is 0. local hWork is ship:facing. set tLock to tWork. set hLock to hWork. lock throttle to tLock. lock steering to hLock. rcs off. sas off. clearscreen. local tCD is 10. eTime().eTime(). if rm = 0{ set rm to 1. } until rm = 0{ if rm > 1 and verticalspeed < -50 and ship:altitude < 65000 and ship:periapsis < 0{ set rm to 0. } else if rm = 1{ if tCD > 0{ notify("COUNTDOWN INITIATED: T - " + round(tCD)). if fIg and tCD < 1{ local lEng is list(). list engines in lEng. for eng in lEng{ if eng:stage = (stage:number - 1) and eng:allowshutdown{ eng:activate(). set tWork to 1. notify("IGNITION"). } } set fIg to false. } set tCD to tCD - tElapsed. } else{ stage. set hWork to ship:facing. set tWork to aPID:update(time:seconds,verticalspeed). set stageMax to ship:maxthrust. set rm to 2. notify("LAUNCH"). } } else if rm = 2{ if ship:altitude > 8000{ set kP1 to 0.156. set kI1 to 0.101. set kD1 to 0.060. set aPID to pidloop(kP1,kI1,kD1,0,1). set aPID:setpoint to ApoETA. set rm to 3. } else if verticalspeed > 50{ set tPitch to min(iPitch,max(mPitch,90*(1 - alt:radar/mPitchAlt))). set hWork to heading(tHeading,tPitch). } else if verticalspeed > 20{ set hWork to heading(tHeading,90). } set tWork to aPID:update(time:seconds,verticalspeed). if twork < .1{ set tWork to .1. } } else if rm = 3{ set tPitch to min(iPitch,max(mPitch,90 * (1 - alt:radar/mPitchAlt))). set hWork to heading(tHeading,tPitch). if eta:periapsis < eta:apoapsis{ set tWork to 1. } else if ship:altitude < pidAlt{ set tWork to aPID:update(time:seconds,eta:apoapsis). if twork < .1{ set tWork to .1. } } else{ set tWork to setThrottle(ship:apoapsis,tApo,0.1). } if (ship:apoapsis > tApo){ set tWork to 0. set hWork to ship:prograde. notify("COAST TO APOAPSIS"). setAlarm(time:seconds + eta:apoapsis - 90). set rm to 4. } } else if rm = 4{ set tWork to 0. set hWork to ship:prograde. if eta:apoapsis < sBurn + 10{ rcs on. } if eta:apoapsis < sBurn{ notify("CIRCULARIZE"). rcs off. set rm to 5. } else if eta:periapsis < eta:apoapsis{ notify("CIRCULARIZE"). rcs off. set rm to 5. } } else if rm = 5{ if ship:periapsis > 70000 and ship:orbit:period > tPrd{ notify("ORBIT ESTABLISHED"). set tWork to 0. set rm to 0. } set hWork to ship:prograde. set tWork to setThrottle(ship:orbit:period,tPrd,0.1). } checkStage(). set tLock to tWork. set hLock to hWork. eTime(). telemetry(rm). print "Ascent " at (1,1). print "Pitch : " + round(tPitch) + " " at (1,7). } lock throttle to 0. lock steering to ship:prograde. clearscreen. } I think that's a big enough wall of text. I guess I'll just throw this out there and answer questions as they come up. Feedback, suggestions, bug reports are always welcome. REQUIRES: kOS DOWNLOAD from SPACEDOCK Copy the Script folder in the download to your Kerbal Space Program\Ships folder. DO NOT put in the GameData folder. Included in the download is my KerboScript definition file for Notepad++. Changelog 1.0.2 Name changed to Good Enough Rocket Science kOS Script Pack boot.ks - changed to generic connection check adjustInc.ks - added navigation.ks requirement adjustOff.ks - added navigation.ks requirement adjustPrd.ks - changes for align function ascent.ks - general improvements changeOrbit.ks - changes for align function control.ks - removed RCS from align function. Added functions idle, setThrottleTWR, useRCS. Moved lng2deg to navigation.ks. Added connection info to telemetry function. Added lng2deg moved from control.ks. Added lib_circle_nav.ks requirement recovery.ks - reworked. science.ks - changed to generic connection check. systems.ks - changed deployChutes to use activateModule. 1.0.1 boot.ks - added connection check to boot(), moded lng2deg to control.ks ascent.ks - made mPitchAlt a parameter, added default to tHeading, added rcs/sas control.ks - added lng2deg moved from boot.ks insertion.ks - fixed syntax error on iOrbit MunDescent.ks - added > 5000 check to rm 6 navigation.ks - added require of control.ks for lng2deg recovery.ks - added rcs on to rm2, rcs off to rm5 science.ks - added inoperable check to getSample() Mission Folder - several mission scripts fixed/updated 1.0.0 initial release This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

How about you do what makes the most sense since you know more about how this works than me. I won't make any more changes til your stuff is ready. The end result will be v1.0

That is needed when restricted to small parts. The part count just becomes to big barrier to progress. I playtest on straight hard mode which reduces funding to 60% and doubles the upgrade costs. Grinding out 450k while restricted to 30 parts, while it might be technically possible, just ain't any fun. I'll make it optional so the player can choose what they prefer. I really dislike the VAB upgrades mechanism. Both the part count and the action group limits are artificial constraints. I was hoping I could move the height/length restrictions from the launchpad to the VAB, but it doesn't work like that. I think it should work if I remove the AFTER[zzz] from the main config and change each mod config to be AFTER[mod_name] so the mods can't override me. That sound right? Thanks!

Oh sorry, I wasn't aware that would cause you problems. There was some mod that was overriding mine. I don't recall the details. I'll be happy to change it to whatever you think would work best.

The rescale variable doesn't exist in the stock engine config. I had to add it in my config rather than changing it with the '@' prefix. The physical rescale works fine. The rescale of the thrust feels right. The flame effects are a little off but it looks like I can adjust that the same way as the nodes.

I have a script library I've been working on for a couple of years while playing unmanned careers. They are my building blocks for creating missions for commSats, science gathering, docking, landers, etc. They're not proper rocket science, just good enough for what I was doing. My focus was on simplicity and clarity as I was learning. I thought I might clean them up and release them like a mod, giving players new to kOS somewhere to start. Is there any interest in seeing something like that released?

I need .625m booster engines for my mod and I figured the easiest way to go about it is to re-scale the stock engines. I worked out what I needed to do to make them good enough for testing. I am unsure if there's anything else that's needed to call them 'done'. I would greatly appreciate having it looked over by knowledgeable folks. This is my re-scale of the LV-T30. Is there anything else I should change? // Rescale LV-T30 to .625m +PART[liquidEngine] { @name = UKSliquidEngineLVT05 @TechRequired = start @node_stack_top = 0.0, 7, 0.0, 0.0, 1.0, 0.0, 0 @node_stack_bottom = 0.0, -7, 0.0, 0.0, -1.0, 0.0, 0 @fx_exhaustFlame_blue_small = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, running @fx_exhaustLight_blue = 0.0, -10.3, 0.0, 0.0, 0.0, 1.0, running @fx_smokeTrail_light = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, running @fx_exhaustSparks_flameout = 0.0, -10.3, 0.0, 0.0, 1.0, 0.0, flameout @entryCost *= .5 @cost *= .5 @mass *= .125 @title = #LOC_UKS_liquidEngineLVT05_title @description = #LOC_UKS_liquidEngineLVT05_description @bulkheadProfiles = size0 rescaleFactor = 0.5 @MODULE[ModuleEngines] { @maxThrust *= .1 } } @PART[UKSliquidEngineLVT05]:NEEDS[MissingHistory]:AFTER[zzzUnKerballedStart] { @node_stack_top = 0.0, 0.45, 0.0, 0.0, 1.0, 0.0, 0 @node_stack_bottom = 0.0, -.42, 0.0, 0.0, -1.0, 0.0, 0 } Thanks for looking!

So I finally get this up on SpaceDock where people can see it only to find that a problem has crept in. The new re-scaled engines are no longer getting their thrust re-scaled. I'm trying to figure out what changed and fix it. Sorry for the inconvenience. I'll have a 0.9.1 version up as soon as I can. FIXED. 0.9.1 uploaded. Those responsible have been sacked.

I've uploaded version 0.9.0 to Spacedock/CKAN. Did some balancing work and added the new Custom Barn Kit requirement. Swapping the VAB/Launchpad costs is a big help. @theonegalen , let me know when year aero stuff is ready and I'll integrate it and bump up to 1.0

This makes all the time I spend watching my landers rolling down hills (again) much more entertaining. Thanks!

A great help for the eternal "now which mod is this from?" question. I wish I'd had this for the the last several weeks. Thanks!

In USMat.cfg ,it is defined as TechRequired = Unresearcheable so it doesn't show up by default The only references I can find to it being placed is DMagicCommunityTechTree.cfg @PART[dmUSMat]:NEEDS[CommunityTechTree,UniversalStorage,!RP-0,!SETI]:AFTER[DMagic] { @TechRequired = miniaturization @entryCost = 15000 @cost = 9000 } That means it requires Community Tech Tree. Do you have that installed? *Edit* It also requires Universal Storage - NOT Universal Storage 2.

The mod fits so perfectly, I sometimes forget the parts aren't stock. Excellent work!

Being restricted to small parts, the part count limit becomes a problem sooner than stock. I'd like to remove the part count mechanism and replace it with a craft size restriction, but that does not appear to be possible. To balance the need to use more parts per rocket, I'm testing a Custom Barn Kit config swapping the upgrade costs for VAB and Launchpad. On hard mode, the costs are 450,000 and 150,000. The mass limit isn't a problem til much later than stock, when the player has more money to spend on upgrades.