foma87

Because it would make so much more sense to implement these features by starting from zero and developing them from ground up? Why would it be a problem to buy out the mods, if the features they provide coincide with Squads ideas of what the aerodynamics should look like? And the sound of this post comes off like Squad were busy counting money and not working at all. Because apparently only modders work hard. Great assumption! I bought this game a year ago and was regularily lurking these forums since then. The criticism back then was much more creative and productive. The amount of whining because feature XY has not been implemented, and unbased bashing of the developers (because they're obviously lazy, right?) in the last few weeks has gone completely overboard. As for the features I'd like to see: Anything that can make good use of the FinePrint mod which will be implemented is a welcome addition. (e.g.: Base building on planets, more rover parts, better use for satellites etc.)

For anyone too lazy to tweak the numbers themselves, I made a config with science from funds and rep from funds nerfed by a facotor of 10 as suggested. Back up your old strategies.cfg file which is located in gamedata/squad/strategies and copy this file into that folder afterwards. https://www.dropbox.com/s/xyvusp073omc8ue/Strategies.cfg?dl=0 Have fun!

I agree with all of your suggestions. I just don't think these things really have to be in the next update. As for regex' list: The main reason cinematics are even made is not primarily to please the crowd who already own KSP with some eyecandy. They're there to spark interest in potential new players by showing some funny clips. After all, Squad wants to sell the game. You won't convince anyone to buy the game by telling him that there's this space agency game, which got updated now with realistic aerodynamics. As for KSP being educational or not. As far as physics go, I'd say it's decent. I was writing scripts via the KOS mod and was surprised how well the calculated results to different experiments (such as suicideburns or hoverscripts) matched up with the observed results. I think they got newtonian physics pretty spot on. The aerodynamics are a different game though, I'd agree on that. He's talking about the resource feature and about how many people wanted it, yet for some reason he thinks that multiplayer, which is also popular I'd imagine, should be delayed and released as a DLC. Same could be said about the resources honestly. All in all, he just wants this game to be polished, balanced and released (a thing we all want), at least that's what I can deduce from his suggestions. Personally, I would like to see more smaller parts. Buying the RLA mod for example. And maybe take an idea or to out of the FinePrint mod playbook.

YES, I got it! It actually worked with the timestamp in an <until>-body!!! So now I got an orbiting script which is almost completely failsafe (when using rockets that is.). The only rule it has is no solid fuel boosters past the 1st stage. When using only liquidengines it will run at fuel efficient throttle given the current height. When using a combination of solid and fuel engines, it will lock the throttle to lift the weight of the rocket without the solid boosters until those are empty. After that it switches to to fuel efficient throttle again. It will start a gravity turn at 10k meters and end it at an angle of 45° at 32k meters. And here comes the part with th ISP calculation: The node for circularization is calculating the exact time the engines have to fire up in order to run through the node in the most efficient manner (half the burntime before the node, and half after). In order to do that, it needs to know the combined ISP of the currently ignited engines. If the burntime of the node is greater than the leftover burntime of the current stage, it will jettison it, fire up the next stage, AND recalculate the combined ISP of the NOW currently ignited engines. Thank you guys so much for your help!!! And if anyone is interested (script is a whopping 3195 characters): //lists set hAsc to list(). set hAsc:add to 1000. set hAsc:add to 10000. set hAsc:add to 20000. set hAsc:add to 32000. set acUp to list(). set acUp:add to 6.05. set acUp:add to 3.32. set acUp:add to 22.04. set acUp:add to 205.23. //vAsc 110, 268, 716, 2332 //hAsc 1000, 10000, 20000, 32000 //aAsc 6.05, 3.32, 22.04, 205.23) //script //standard variables set aAsca to 0. lock v to verticalspeed. lock h to altitude. lock hApo to alt:apoapsis. lock etaApo to eta:apoapsis. set isp to 0. set g0 to 9.81. set aUp to 0. lock thrMax to maxthrust. lock mTot to ship:mass. lock solFor to g0*(mTot-(stage:solidfuel*7.5)). lock solAcc to solFor/thrMax. lock liqFor to (g0+aAsca)*mTot. lock liqUp to liqFor/thrMax. set pitch to 0. set dvNode to 0. set t to 0. set thrIsp to 0.001. set thrTot to 0.001. //staging, actiongroups, utilities, isp calculator when stage:liquidfuel<0.001 and stage:solidfuel<0.001 then { unlock t. clearscreen. stage. print "Staged!". set t to time:seconds. wait 0.001. preserve. }. when stage:solidfuel<0.001 then { clearscreen. stage. print "Staged!". }. when h>70000 then { ag1 on. panels on. }. //ascension lock steering to up + R(0,0,180). until hApo>125000 { if stage:solidfuel>1 { lock throttle to solacc. }. else { lock throttle to liqUp. if h<hAsc[0] { set aAsca to acUp[0]. }. if h<hAsc[1] and h>hAsc[0] { set aAsca to acUp[1]. }. if h<hAsc[2] and h>hAsc[1] { set aAsca to acUp[2]. }. if h<hAsc[3] and h>hAsc[2] { set aAsca to acUp[3]. }. }. if h>hAsc[1] and pitch>-45 { set pitch to -((h-hAsc[1])/488.88). lock steering to UP + R(0,0,180) + R(0,pitch,0). }. }. lock throttle to 0. //node variables and ispcalculator list engines in e. for eng in e { if eng:ignition="True" { set thrtot to thrtot + eng:maxthrust. set thrisp to thrisp+(eng:maxthrust/eng:isp). }. }. lock isp to thrtot/thrisp. lock mDry to (mTot/(constant():e^(dvNode/(isp*g0)))). lock fuelNeed to mTot-mDry. lock fuelFlow to (thrMax/(isp*g0)). set burnTime to (fuelNeed/fuelFlow). //apoapsis node set apoNode to node(time:seconds+etaApo, 0, 0, dvNode). add apoNode. until apoNode:orbit:periapsis>124000 { set dvNode to dvNode+5. remove apoNode. set apoNode to node(time:seconds+eta:apoapsis, 0, 0, dvNode). add apoNode. wait 0.001. }. lock steering to apoNode. wait 5. if (stage:liquidfuel*5+stage:oxidizer*5)/1000<fuelNeed { unlock t. stage. set t to time:seconds. }. until apoNode:eta<((burntime/2)+60) { set warp to 3. }. set warp to 0. wait 0.001. until periapsis>120000 { if t<time:seconds-1 { set thrtot to 0.001. set thrisp to 0.001. list engines in e. for eng in e { if eng:ignition="True" { set thrtot to thrtot + eng:maxthrust. set thrisp to thrisp+(eng:maxthrust/eng:isp). }. }. lock t to time:seconds. set burnTime to (fuelNeed/fuelFlow). }. if apoNode:eta<(burntime/2) and dvNode>50 { lock throttle to 1. }. if apoNode:eta<(burntime/2) and dvNode<50 { lock throttle to 0.1. } }. print "Done!". edit: a little bug caused an error after staging a solidfuel booster. fixed hopefully. edit: it seems like the max numer of engines you should use is 10.

According to Steven, <wait> commands in triggerbodies have no effect, whom I like to thank for his insight on the <when>-mechanics. I feel stupid now. This should actually give me the same results with less code. Nice find! I´ve tried this exact idea yesterday, the error message persists however. As you explained, you`re right that the problem is running a loop in a <when>-body. As for your suggestion with the timestamp and in the <until>-body, I think this might just do the trick! I`ll try it out and report back. Much obliged.

This part of the script is actually designed as a staging condition. The engines are indeed flamed out when the trigger is activated. The reason for this, is that when the <when>-body is triggered, there is virtually no fuel left. I`ll show you what I think why I get these error messages. As for the boolean to string comparison: I tried running the listscript without it being embedded in a <when>-body with activated engines. It returns the correct amount of isp. So I would think that this shouldn`t pose a problem. I´ll check again though. I´ve tried relisting the engines in two different ways. In this example I tried relisting the engine in the whenblock: when stage:liquidfuel<0.001 then { clearscreen. stage. print "Staged!". set x to 0. set y to 0. set isplist to list(). //list of engine isps set thrlist to list(). //list of engine maxthrusts. set thrtot to 0. set thrisp to 0. list engines in e. for eng in e { if eng:ignition="true" { set isplist:add to eng:isp. set thrlist:add to eng:maxthrust. }. }. until thrlist:length=x { set thrtot to thrtot+thrlist[x]. set thrisp to thrisp+(thrlist[x]/isplist[x]). set x to x+1. }. set isp to thrtot/thrisp. print "Cummulative ISP: "+isp+" sec". set t to 0. wait 0.001. preserve. }. With this configuration, I get an IPU error. Since I wanted to use this <when>-trigger for staging, I also tried manually staging the rocket with a throttle of 1 and then running the script. As soon as the <when>-body triggered I get an IPU error again. So I cranked up the config:IPU in order to test what would happen if there is enough IPU to go through the body. I got the errormessage described in my previous post. The problem with this method, from what I can explain, is that when the <when>-body triggers, it creates a list based on the state of the ship at that exact moment (before staging). This means that the list will contain engines which are staged away a moment later. The second problem is that the engines at that point in time are flamed out due to lack of fuel, which results in the isp of each engine being 0. I can see that this could cause the infinity in stack error message. In the second configuration, I set up 2 <when>-triggers: The first <when> stages the rocket and sets a variable t to 1: when stage:liquidfuel<0.001 then { clearscreen. stage. print "Staged!". set t to 1. wait 0.001. preserve. }. That change to t triggers the other <when>-body with the list script: when t=1 then { set x to 0. set isplist to list(). set thrlist to list(). set thrtot to 0. set thrisp to 0. list engines in e. for eng in e { if eng:ignition="true" { set isplist:add to eng:isp. set thrlist:add to eng:maxthrust. }. }. until thrlist:length=x { set thrtot to thrtot+thrlist[x]. set thrisp to thrisp+(thrlist[x]/isplist[x]). set x to x+1. }. set isp to thrtot/thrisp. print "Cummulative ISP: "+isp+" sec". set t to 0. wait 0.001. preserve. }. I get the same error messages as above. Either too little IPUs or trying to push infinity into stack. After looking over the second method, I realized that it does not help to trigger a <when> within a <when>-body. the timeframe in which both <when>-bodies are going through is the exact point in time before staging. So what it boils down to is this: I need a trigger which activates after a staging-event. This trigger may not be connected to the event itself. Does that make sense? It sure doesn´t to me . I hope I could convey my problem without causing too much confusion. My brain hurts. PS: Thank you for the tip with the boolean value. These are things I couldn´t find in the doc.

I have come across another problem. Is there a way to create a list within a conditional statement like <when>? I would like the script to recalculate the total isp of multiple engines which get active immediately after a staging event. Right now, the script looks like this: What this script is first to add up all the values from thrlist and then to divide the value in thrlist[0] by the value in isplist[0]. Then the value in thrlist[1] by the value in isplist[1]....etc. At the end, <thrtot> gets divided by <thrisp> to get the isp. However, when my condition is met I get this error message: Note that the script works when I´m not using a conditional statement and have ignited engines.

Yes, that would come in really handy. I wanted to have two lists: One with altitude-benchmarks and one with velocity-benchmarks in order to calculate the optimal acceleration for a given altitudeframe. Example: I resorted to adding the benchmarks manually to the lists. Although that did mean I had to cut the benchmarks from 14 to 4 for each list, since I`m too lazy and it visibly overloads the script. Thank you for your answer nonetheless!

Hi there, I´m trying to define a variable x with multiple values. Example: x1 = 23 x2 = 372 x3 = 5 x4 = 17 ...etc. I know I can create a list like this: In this case, I could get the value of x2 like so: My question now is, is it possible to create a list with values without using that much code. I could see the script getting huge if I try to make a list with lots of values. Something that could look like this maybe? Any help is appreciated.

Hi there. This is my first post. I´ve been a long time stalker on these forums and basically just registered because of KOS. I´d like to say that this is an incredible mod. Thanks for all the work! Now I´m not sure if this is the right thread for it, since I don`t know if the problem I encounter with my script is a mathematical one or a bug in the mod. Anyway, since I´ve already started, I might as well just state my problem: What I am trying to achieve is have a readout of the angle between 2 bodies orbiting the same body. I took Kerbin, a satellite in Kerbin orbit and the Mun as an example. This is basically what it looks like (excuse my paint): The angle needed is γ. Now in order to get γ basic triangulation is used in the form of this formula, since the length of the sides of the triangle are known: This is what it looks like when scripted: Note: Explanations were added in this script. Additionally the original script loops this procedure. The problem is, the "phi"-readouts are often NaN° (I´d be very thankful if anyone could explain this expression to me). Sometimes I get correct angle readouts (compared with VOIDmod current phase angles), and sometimes I get NaN°. Specifically when γ gets wide (from my impression I´d say when γ>120°). I say impression, because I haven`t found it to be always at the same degree. I would like to ask if anyone else has tried using this method to calculate angles or knows any other method for getting precise angles, or if I completely messed up the approach to this problem. The angle would be used to compare the optimal ejection angle with the current phase angle, in order to script the transfer burn at exactly the right place. Would be much appreciated.