erendrake

Well that is annoying If you would please do the following: 1. Open KSP 2. Run your double SSTO script 3. Once one of the scripts stops at 2.5km, exit KSP 4. Open KSP.log from the root of your game folder and copy the contents into a pastebin http://pastebin.com/ 5. share the new pastebin url in this thread.

That is very interesting, I responded that the load distance needed to be changed but if you are using never unload then maybe we have another issue. I would be interested in seeing a log from when this happened.

I had been waiting for them to have another release, now that is done i need to get back to this.

Sweet and thanks for the video! That is all about how KSP loads craft, but luckily you can change the default load distance with SET LOADDISTANCE TO <WHATEVER YOU WANT>. and your craft should stay loaded longer than they normally are.

Thats great news i know kOS scripts are action group heavy beasts so this is a pretty exciting change

I have been too dont worry, I think we will get some pretty epic videos going.

I am working on the AGX-kOS Integration and i have a few feature requests for the AGX API. 1. The ability to trigger an action group on an arbitrary loaded craft, not just the active craft. 2. The ability to get a list of parts that are linked to an action group. 1 will make kOS integration possible 2 will make it compatible with some future work that we are planning on doing with action groups and is a much lower priority for me. if you would rather have these requests on github, i would be happy to copy them over

Some basic information about specific part types (engines, docking ports, ect) are available now. (eg http://ksp-kos.github.io/KOS_DOC/structure/engine/index.html ) * AGX integration is in the works * Getting/Setting part fields and buttons and such is in the works. sorry to be vague on timing.

Sirkut has given the kOS team everything we need to give you guys way cooler integration. We on the kOS team have been distracted by something shiny and will take advantage of this soon.

I am guessing that github might have changed their paths??? or I fat fingered the paths. One is more likely, the other makes me feel better Fixed!

We discussed this in IRC a few days ago and rule 4a reared its head. http://forum.kerbalspaceprogram.com/threads/87842-Add-on-Posting-Rules-Aug-21st-2014 In this circumstance i think it is a minor breach as the user would specify the location. That being said we should ask before we break it.

I believe our recent change would let you do this. if you simply dont set the throttle in code or set it to 0. i believe it wont take control We have a pretty solid RCS control api, here are the docs. http://ksp-kos.github.io/KOS_DOC/structure/control/index.html http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

ill just leave this here.. <Erendrake> NathanKell: I keep thinking about asking for a priority in MM so you could say :AFTER[1] OR :AFTER[1000] <Erendrake> then i realized all that would do is move the goalpost and people would be in the MM thread asking "How do i get in after :FINAL[2140000000] <Taverius> i wish AFTER took logical operators <TonyTheLemur> :JUST_BEFORE_THE_APOCALYPSE <Taverius> heh <K3|Chris> it's CSS z-index all over again <K3|Chris> and !important <Erendrake> exactly <Erendrake> !!important!! <TonyTheLemur> agh i hate !important <TonyTheLemur> i confess to using it rarely, but i still hate it <TonyTheLemur> one of the github issues on a site i work on is "get rid of all !importants" <Erendrake> Im glad its there, but you hope that it is never required

You could have just talked to the mod author, Nathan said he doesnt mind moving his CFG off of final.

I believe it is discouraged. NathanKell is a bad boy https://github.com/NathanKell/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry-RealChutes.cfg

I believe final should take care of it unless there is another "final", in that case i think they execute in alphabetical order?

We have actually talked about this quite a bit and i am torn on this. Figuring out the data and including it as a constant as a little more of a real world feel to it. You being the designer derives the isp and inputs it before launch. getting the data from kOS does have the benefit of being more reusable

Unfortunate turn of phrase. I still want to do the List query syntax as well.

Genius! What if we let you query the list of parts that are in any action group, add support for AGX and call it a day!?!?!?

was this in the new release?

NEW RELEASE New Hotness * Updated fonts, Thanks @MrOnak * Now runtime errors show source location and call stack trace (Github issues #186 and #210). Example: ~~~ Tried To push Infinity into the stack. At MyProgramFile2 on Archive, line 12 PRINT var1/var2. ^ Called from MyProgramFile1 on Archive, line 213 RUN MyProgramFIle2("hello"). ^ Called from StartMission on Archive, line 2. RUN MyProgramFile1. ^ _ ~~~ * (WHEN and ON) Triggers that are taking longer than an Update is meant to take, and thus can freeze KSP are caught and reported (Github issue #104). Gives the user an explanatory message about the problem. * WARNING: Because of a change that had to be done for this, it is **_Highly_ recommended that you increase your *InstructionsPerUpdate* setting in config.xml to 150% as much** as it was before (i.e. from 100 to 150, or if it was 200, make it 300.). * Multiple Terminal Windows - possible to have one open per CPU part. (Github issue #158) Old and Busted ( now fixed ) * "rename" was deleting files instead of moving them. (Github issue #220). * Was parsing array index brakets "[..]" incorrectly when they were on the lefthand side of an assignment. (Github issue #219) * SHIP:SENSORS were reading the wrong ship's sensors sometimes in multi-ship scenarios. (GIthub issue #218 ) * Integer and Floating point numbers were not quite properly interchangable like they were meant to be. (Github issue #209)

NEW RELEASE WARNING: Because of a change that had to be done for this patch, it is Highly recommended that you increase your InstructionsPerUpdate setting in config.xml to 150% as much as it was before (i.e. from 100 to 150, or if it was 200, make it 300.). New Hotness * Updated fonts, Thanks @MrOnak * Now runtime errors show source location and call stack trace (Github issues #186 and #210). Example: ~~~ Tried To push Infinity into the stack. At MyProgramFile2 on Archive, line 12 PRINT var1/var2. ^ Called from MyProgramFile1 on Archive, line 213 RUN MyProgramFIle2("hello"). ^ Called from StartMission on Archive, line 2. RUN MyProgramFile1. ^ _ ~~~ * (WHEN and ON) Triggers that are taking longer than an Update is meant to take, and thus can freeze KSP are caught and reported (Github issue #104). Gives the user an explanatory message about the problem. * WARNING: Because of a change that had to be done for this, it is **_Highly_ recommended that you increase your *InstructionsPerUpdate* setting in config.xml to 150% as much** as it was before (i.e. from 100 to 150, or if it was 200, make it 300.). * Multiple Terminal Windows - possible to have one open per CPU part. (Github issue #158) Old and Busted ( now fixed ) * "rename" was deleting files instead of moving them. (Github issue #220). * Was parsing array index brakets "[..]" incorrectly when they were on the lefthand side of an assignment. (Github issue #219) * SHIP:SENSORS were reading the wrong ship's sensors sometimes in multi-ship scenarios. (GIthub issue #218 ) * Integer and Floating point numbers were not quite properly interchangable like they were meant to be. (Github issue #209)

I am also not excited about adding a module to every part There are also assignment issues. We could auto assign each part an incrementing integer or even a Guid but i honestly dont know much about the editor and how it deals with copying and re-snapping parts. If it behaves like I think it does we would end up with either * Parts getting the same Id * A ton of constant Id changes whenever you touch the craft I am sure that both of these would also be "monstrous". I think it would make the most sense for it to be a textbox that the scripter would control. You can type in whatever you like, it gets copied on part clone or whatever you do and you can keep it up to date and reference it in code. That would solve a lot of problems (other than the every part needs a new kOS module, which sucks). That would of course require a tweakable textbox that the stock game doesnt have . I think we can get it with the KSPAPIExtensions but i honestly havent confirmed that. It would also be pretty useless if we didnt also have more string manipulation tools in the language (starts with, contains, ends with, trim , ........) which is non-trivial. The solution that Steven and I have been tossing around for some kind of part query language is the one I like the best. It requires the most design as i dont think anyone would be happy if we are redoing the syntax every release and breaking everyone's scripts. This is a complicated problem and it will require a lot of design and thought. I thank you for your input

We are not about shaming here. Steven and I were honestly confused about what you wanted to do that you couldn't. It sounds like the real world abstracts this calculation behind a person doing the calculation rather than the flight operating system giving it to you. There is no requirement in kOS that the user iterate over the engines, you as the designer could input these variables the same way they do in the real world. That being said i do think that because the stock game provides some of these aggregate values for mass, thrust and lift it makes sense for kOS to expose them too. Ill look to see if the KSP API has public state were i can fetch these . If not it shouldn't be that hard to add. thank you for your feedback and I welcome you to send us pull requests if the mood strikes you to help out.

I would argue semantics around the word "expectation". If there is useful data about craft and parts that isnt exposed no one is more serious than Steven and I about exposing it to you guys. From skips last few posts I cannot tell what he wants let alone what data is missing for him to accomplish his goal. I am seriously asking him for more information so we can resolve his issues.