Cyrik

hey guys, just wanted to say that i´m still alive. i´m moving to a new city to start my first job so it has been a bit crazy the last few weeks. once i´m settled i´ll try to get back into developing new features and continueing support. for right now the version should be compatible with 0.25

Thank you for the compliments. The one about the update thingy should be directed at ksp AVC . Its a great mod that you just throw in with your own mod and it gives you the functionality you saw. It also has a standalone plugin that gives you a bit more information on all your mods. I´m hoping more people will adopt it, especially since it couldn't be easier to use as the mod author.

I´m to sure about point one yet. The representation is still up in the air but I like your idea. I´ll think about it. Point to is a definite yes, but only one the basics are implemented. I don't want to have dependency's unless they are optional. And a definite yes for snacks:) Not sure about the UI yet. The project is frozen until I see what is in the next KSP version.

update is out. it should hopefully fix orsx compatibility and the linux issue. I´ll work on new features and other fixes over the weekend Thank you to everyone for beeing this patient of the past few weeks

Hey guys. The new version should be going up some time today

PR merged, thank you! It would have taken me forever to find that bug without a debugger. How did you manage to find it?

The stuff on the horizon will come back once you scan the planet. Scansat on/off is just the integration. I should give the button a better name. If you turn it on you only get the overlay at the spots you already scanned, which is why you don't see it right now. I will try to fix that in the next version. Until then you will have to enable/disable the overlay when you are blow it, at least if that bothers you.

You are right, apparently I'm to tired to think straight:( I also added your license text as a comment to the shader file. The readme on github and the first post here already have information on the files that were not written by me. I hope the changes are fine with you. Sorry for being a bit dumb today. I uploaded a new version that has the correct license.

Ok, the links are back up and the licensing issues should be resolved, I hope. There were no changes in the new version since my laptop can't run the game and I'll have to wait till the next weekend to have access to my pc again.

I will try to get it done tomorrow. I´m stupidly busy with work right now. Might also have to change the license from MIT to CC or GPL for a version or two:(

Hey, I´m sorry I didn't get back to you earlier. I had thought I already included a license file for the class I took from you. I´m sorry I forgot about that:( I still have your license in the Window.cs class I included and I will include your License file in the next release as soon as I have a minute off work. Sorry again guys

I'll try to get around to installing linux on the weekend. The only other thing I can think of other then permissions: I didn't put a version of the config into the /PluginData folder, because I didn't want to overwrite peoples config. Did you guys switch from 0.24 to 0.25 or start at 0.25? If you started at 0.25 Linux might not want to write the file if it doesn't exist.

ah now I get what you mean by your first point and it gives me an idea: how about opening the UI on your first time in the game? That way you dont have to fiddle with the toolbar to get it open and you can immediately see all the options you have. for your second point: I'll look into it. Thank you for checking again and giving me a detailed bug report! It is a bug. I'll look into fixing that and adding a description of the options. Thanks for the feedback. It looks to me like the folder is read only, but I might be wrong. I will test it and come back to you once I have a few minutes:) Thank you for informing me.

Hey, thanks a lot for the feedback. At first glance I´m not sure how the discrepancy happens. I will have to in the Karbonite code to see how they get their values. My plugin just asks ORS for the value at the given coordinates, so I would guess that I should be more precise, but maybe a bug crept in there somewhere. I will look into it. However, I´ll be gone for 2 weeks on an internship, starting tomorrow and I'm not sure how much free time I will have, so we'll see how fast I can check it out. About the tooltip: enabled from the start was more of a new user thing for me. I thought if i had it disabled new users might not even realize that there are tooltips and you can disable it. After you disable them they should stay disabled even after a restart. Is that not the case for you?

We are transferring resources from one ship to another, so all it does is change the amounts. FSFuelSwitch ignores that new amount and overwrites it "OnStart" with this : "newResourceNode.AddValue("amount", getResource(resourceCount));" . It basically wipes away the transfer. You can see the effect for yourself by changing the Amount in the save file. I understand you have to do that in the "(calledByPlayer || brandNewPart)" part of the if, but it would be nice if you didn't wipe it in the else section, so that manipulation of amounts worked while in flight. Thank you for hearing me out:)

Unless I'm just not seeing how to code this properly, you would be trading a relatively minor gain in memory for a relatively large increase in cpu time and program complexity. My first thought on implementing your idea would be a dictionary of cooldowns. Which would mean you have a string and a double for every active cooldown. The string+hashmap lookup is a lot slower then just a field access. And if even a few timers are active you are actually loosing memory efficiency since you are now storing a string + a double for every value. Aside from the performance concerns you do have quit a bit more code now because of all the dictionary access and checks and you lose the type safety by just throwing around strings.

Mhhh, is there any benefit to having a cooldown if you have a maximum and an increase over time instead of per "usage"?

Oh right, I didn't even think about this. Good catch, thank you! I guess I really should hold off a bit and see how the API changes.

Notice: active development on this will be starting once we know more of what will change in the Kerbal APIs in 0.25. As NathanKell mentioned, there might be significant changes incoming that I didn't think about:( Hi, so without boring you to death with reasons why I want to start this addon, here are the ideas that are swirling around in my head: What does it do: tracks stats for every Kerbal, such as Happines, Sanity, Fitness, whatever changes these stats based on situations and enviorment gives advantages and disadvantages based on those stats, ranging from flavor text popups to crew deaths Ok now that you know what the vision is, here are my ideas so far: starts out as a part-less plugin to see what is possible with just adding some programming to stock parts keep the initial stats low initially do take any dependencies other then toolbar ofc Stats: Happiness: mostly determined by excitement same orbit around the sun for the 6th time? never on eva in a 6year trip? same module of a space station for 20 years? mostly a flavor stat [*]Sanity: Influences: the big brother of happiness determined by living space loneliness entertainment on board [*]Effects: random behavior staging errors input lag turning stuff on and off undocking eventually death? [*]Fitness: Influences: training gravity sleep? [*]Effects: sluggish behavior death All these stats would change over time. So a Kerbal flying to the mun and back wouldn't go crazy because he´s alone in a tiny capsule. He will go mad doing the same thing flying in orbit for a year. The stat changes would be accomplished by checking the vessel for essentials like space and entertainment and so on. I would add modules to some of the stock parts as a start and see how far I can go with that. If it's not enough (I'd guess its not), adding new parts or integrating with other mods would come in. I would also try to keep the mod as extendable as possible so that other mods can take advantage of its functionality and hook into it. As an example MKS/OKS parts would make perfect sense or even TAC life support for food quality and consumption. For anyone that has gotten this far: I´m not a graphics guy, so if I need parts for this mod at some point they will either be ugly or provided by someone else:P Aside from that I'm a decent coder so i hope at least that part is covered. Oh and while I'm at it, I'm starting with TAC Lifesupport as a design base since i really like his mods architecture. I'm not sure how long that base will be recognizable however. Enough rambling, lets hear some input:P

Yes, that's exactly the problem lines I was talking about. We look at vessel.protoVessel.protoPartSnapshots.resources and change the amount in there if the vessel isn't loaded. My request to you would be to not just clear the part.Resources.list, but take its value into account when you rebuild the new one. Unless of course I´m doing something wrong by changing the amount in there. I´m new to KSP modding so I´m open to suggestions.

I´m sorry, I must have expressed myself badly:( Our code does look at the resource node on the part and changes that while the vessel is on rails, your code ignores the resource node and overwrites it with a value stored in its own node. That is a pretty big compatibility concern since every mod that does something with resource uses that node and would have to check for your module and change your node instead, and I don't really want to touch your node and break something. So what I was asking is not to make your mod compatible with ours but make it depend look in the standard resource node when it activates. I understand that is a bit of a hassle in the VAB, because of what the mod does, and I`d be fine if it just had normal behavior in flight.

thank you for the info:)