zekew11

Indeed it is! (I play with both on my own save )

This is what I've suspected from a skim of the changelog; regardless; I'd like to get some play time in with solar in high orbits before I make a decision about discontinuing that patch (regardless of the fact that continuing it would be a complete rewrite)

Well; my productivity proved lower than expected. I still haven't had time to update the mod properly (with new balancing against 1.0 era stock labs and solar panels), but the potentially unbalanced components have been, in essence, commented out. Feedback here about desires for rebalancing of these elements will directly expedite the update process.

Depending on how productive I am, we should be 1.0 ready by the end of either tomorrow (yay), or the end of a hard school week I've got coming. regardless, expect a new version soonâ„¢, though using the old one *shouldn't* (don't come crying to me) break anything.

1.2.0 Updated module manager Added explicit support for Nertea's Stockalike Station Parts Expansion Rebalanced USI labs to being in line with rebalanced stock lab (Important: the base module weight was increased to 5.5 tons) Remember; the changes are modular. Also, I made a pretty banner. Pretty things are always nice! On a serious note though, there's been a major dearth of feedback, which makes balancing things difficult. Please give input as to how the mod is working for you!

Oh dear, it seems I didn't see these posts and neglected this little mod for a while (finals. scary terrible things.). I just uploaded 1.1.0; 1.1.1 will be up within an hour with this bug fixed! Edit: Hotfix is Up! Changes today from 1.0.0 Fixed bugs with mod-added rotating habitation rings. Full support for Lack's SXT; all large habitats can run the microgravity experiment; the science senior can transmit data more efficiently. Buffed science labs to make transmission of materials type experiments viable. Corrected typos Bundled module manager

The issue is simple; as Starwaster discribed in the main thread. a hotfix will be out within an hour. I do apologize for my absence while this was a problem: playing with unfixed bugs sucks.

I'm surprised by the generally negative reception this has gotten, so allow me to post some thoughts... manned vs crewed: this one shouldn't even be a discussion. It isn't that some great and mighty good is accomplished by this change, but rather that it is so easy to make and has no detriment to anything. thus the threshold for implementation/ "that's a good idea" should be quite low. the reality that these are kerbals should be enough to have an intern to a five minute find and replace session on the game's text assets. thats literally all it is... most of the negative feedback here is basically "Manned is already neutral so I can't be assed". while many interpret manned to be neutral, a growing number don't. seeing as "crewed" is also neutral and correct, beyond not wanting to be bothered, I fail to see the relevance. If there' a risk that changing to "crewed" is a good idea: do it! Additionally, man is only neutral if it is referring to humans... so either way you look at it "manned" can safely be flagged as a bug. harmless bug, you may argue, though some may disagree, but a bug no less. pronouns and larger issues: This is a lot about who is using the game and what messages the game is sending. kerbal space program has been lauded a great deal as an education tool and something that gets kids interested in math and science. so lets talk about messages we can send to impressionable young people. I'll share a quick story. I was a boy, probably around twelve, visiting a cousin's house. At one point she began playing a game on her computer, to which i took immediate interest. it was a western game, I can't remember many details. What I distinctly remember was a female lead character and a pink ui. I also distinctly remember wanting to be interested in the game, and secretly being very interested, but feeling guilty about liking a girly game. At present, Kerbal Space Program probably does something similar to a twelve year old girl. There is in no place a female... anything... Not only does this make KSP a "boys game" but it also reinforces the idea that these great rocket scientists, astronauts, adventures, and executives--- heck, even the engineers and ground crew running around the VAB, are necessarily male. We don't even think about these kinds of things, but games like this create de facto images of what the world is. It really probably is important to envision a fantasy land where the best of kerbal kind is a mix of both genders. Then at least we're sending our kids into the world thinking that thats the way it ought to be. I would hate for a girl to put down ksp after launching an all male crew hired after setting up a strategy with one of the space program's four important males because its a boys's game, knowing that the 12 year old boy who picked it up was inspired to study aerospace engineering. If we have the opportunity to shape young people so profoundly with this game, then it seems absolutely within its scope to at least make an effort to see to it that the opportunity to be shaped exists equally for both halves of the population. That doesn't mean we have to rewrite the english language or that everyone who say's "manned" is a woman-hating monster. It just means that its probably good to be conscious, responsible citizens of our world, and role models to our youth.

Glad to have your blessing. Reviving this was already a slippery slope for me as well. It all started when I wanted that eva patch. And then I needed the transmission rate rebalances too. And I may as well rewrite them to make them work with all my modded parts. But I'm getting more science from probes: I need to balance that. Less science from materials. Now I need the lab. oooh! that hitchiker experiment is shiney! shoot, lets throw in the solar nerf too. while we're at it, lets make it modular. now lets add probe science. Now lets write compatibility patches for a bunch of stuff... And then we had this thing.

Science Revisited Revisited Science Revisited was created by CaptRobau as a rebalance of the stock science system. Science Revisited Revisited builds upon their original work. Science Revisited Revisited aims to be a lightweight and modular rebalance of the stock science system. These adjustments aim to make science gameplay more dynamic, while preserving the stock gameplay feel. The work is built entirely through Module Manager patches. The edits it makes are also completely modular in nature. This allows users to pick and choose the changes they want to apply. Download at SpaceDock Patches Included: Revised Crew Versus EVA Reports: Switches low space and flying crew reports to make them biome-dependant, while making the same EVA reports biome independant. No more hanging off the sides of cockpits to get that "flying at kerbin's mountains" data or EVAing every two minutes in low munar orbit. Somehow this makes more sense. Reduced Transmission Penalty on Data: Science that is simple data is much more effectively transmitted. Recovering the instruments is still mildly helpful. Temperature, gravity, barometer, accelerometer, and atmospheric data are currently affected Increased Transmission Penalty on Experiments: Significantly nerfs the already low transmission rates for materials studies and mystery goo. Increased Transmission Penalty on Surface Samples: Significantly nerfs the transmission value of Surface Samples. Compliments the experiment nerfs patch discussed above. Science Lab Rebalance: Increases the Science Lab's weight to a more volume appropriate 5 tons. Increases lab's data and science storage. Rebalances several mod-added labs similarly. Probe Telemetry Science: Adds a very low value experiment to all command modules. This data is representative of the telemetry data needed to pilot the vessel. Microgravity Experiment: Replaces the hitchhiker's stock crew report with a new, slightly more valuable "Micro-Gravity" Experiment. Good flavor. Also adds the experiment to a couple mod added habitats. Plays Well With Friends There is built in support for Porkjet's Habitat Pack, Lack's Stock Extension, Roverdude's USI mod constellation, Kerbal Planetary Base Systems, Dmagic Orbital Science, and Nertea's Near Future Solar & Stockalike Station Parts Expansion. In addition, most ballance patches are automatically applied to all relevant parts. (A mod doesn't have to be listed here to be compatible; this is simply a list of mods that Science Revisited is explicitly aware of.) There is one suspect incompatibility at this time: Station Science 2.0. See thread post 61 (page 3 by default) for more information and a potential fix. Please report any further incompatibilities either at a balancing or at a functional level. Full Album This work is an adaptation of the original work of CaptRobau. Adaptation by Zekew11 with support from RealGecko. Distributed per original license: Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0) Changelog: [B]1.7.0[/B] [LIST] [*]Patch Manager Support [*]Module Manager Syntax Fixes [/LIST] [B]1.6.0[/B] [LIST] [*]Housecleaning [*]Generalized Micro-Gravity Expiriment [/LIST] [B]1.5.0[/B] [LIST] [*]Reconfigured patch which nerfs the transmission rate of surface samples; Removed "EVA Manager" dependence [*]Updated Kerbal Planetary Base Systems compatibility [*]Added explicit compatibility for USI's Ranger lab [*]Removed :FINAL tags; added :FOR tags [/LIST] [B]1.4.0[/B] [LIST] [*]Added a (disabled by default; alpha) patch which nerfs the transmission rate of surface samples; Note: requires "EVA Manager" by toadicus [*]Added an alternate configuration for "numeric" experiments [*]Re-added previously missing 1.3.1 patch changes [*]Removed Module Manager Redistribution; Module Manager is still required [/LIST] [B]1.3.1[/B] [LIST] [*]Added explicit compatibility for Kerbal Planetary Base Systems [*]Updated Module Manager [/LIST] [B]1.3.0[/B] [LIST] [*]Reintroduced Lab Rebalance! [*]Updated Module Manager [/LIST] [B]1.2.2[/B] [LIST] [*]Updated DMagic Compatibility (unsure how long this has been broken) [*]Permanently depreciated Solar Patch [/LIST] [B]1.2.1[/B] [LIST] [*]Temporarily locked Solar Nerf and Lab Rebalance Patches pending playtesting of stock 1.0 era changes [*]Updated Module Manager [/LIST] [B]1.2.0[/B] [LIST] [*]Updated module manager [*]Added explicit support for Nertea's Stockalike Station Parts Expansion [*]Rebalanced USI labs to being in line with rebalanced stock lab (Important: the base module weight was increased to 5.5 tons) [/LIST] [B]1.1.1[/B] [LIST] [*]Fixed bugs with mod-added rotating habitation rings. [/LIST] [B]1.1.0[/B] [LIST] [*]Full support for Lack's SXT; all large habitats can run the microgravity experiment; the science senior can transmit data more efficiently. [*]Buffed science labs to make transmission of materials type experiments viable. [*]Corrected typos [*]Bundled module manager [/LIST] [B]1.0.0[/B] [LIST] [*]Initial release [/LIST]

If I may make a suggestion: Currently mods that add parts to build specific craft are a minority. To most players the parts aren't worth their weight in RAM without being able to be applied to a variety of applications. Additionally they feel out of place in a game about designing your own solutions. The first problem is slowly being eased: by popular demand tools to reduce ram usage are getting better and better, from forceopengl to ATM to the optimization allowed by tweakscale, firespitter tank switcher, and even the hope that one day 64 bit windows will be stable, players' game data directories are slowly getting bigger. :all applaud: The second problem can be carefully addressed by this tech tree. Essentially what I'm proposing is a short series of mid to upper tech nodes under the premise of a "skunkworks". These nodes could contain parts included in build-a-craft type mods. The balance would come where the player, in unlocking a skunkworks node rather than another node, trades versatility in parts for mission optimization provided by the modders. The best example of a mod that would benefit from this integration is the KSO mod by helldiver, which I think is absolutely stunning and deserves more attention than it gets, yet simultaneously exclude from my career mode because of its awkwardness with respect to the part-pack sqo. I also am biased in that I am currently working on an Endurance for KSP mod that, without some high tier skunk-works nodes, I'd be almost at a loss for tech tree placement. If these types of mods are to have an equal opportunity in the community, they need a more logical tech tree solution than is currently available. Thanks for the consideration!

I PMed you

any news here? I'm quite looking forward to this... additionally; I'm having a problem. everything appears to be working great on the pc end; server status is green. However, on my mobile phone i can search for, find, and select the server, but pressing connect has no effect. My phone is android 4.1.2 and connected to the same wifi network as the pc. any tips?

quick question: does the current version of mks oks work with ksp .24.2? I'm waiting to update until a couple more mods become compatible and I'd like to get the resource depreciations behind me before I've developed an extensive infrastructure. edit: by that I mean does anyone happen to know; I don't expect it of anyone. edit two: well I'm embarrassed; I managed not only to come off rude, but also to post in the wrong usi thread. thanks undercoveryankee for handling my incompetence

I've created a few models for ksp previously; so I have a preliminary workflow. I was actually working towards a product similar to the current MKS (I called them land habs; the purpose being to add flexibility to the creation of low part count surface bases.), but I didn't have the coding skills or time to ever actualize a mod of that caliber. I was wondering specifically though how to set up a hanger in unity for use with the plugin; and what plugin limitations I should be keeping in mind while I develop concepts.

How would one set up unity configs for one of these? I'd like to have a swing at modeling some.

Here's how I'd lay this out: bear in mind that I'm as novice a coder as they come, but I like thinking about these things. For a lot of my inspiration (as to what the system should look like, less as to implementation), see rimworld. I'm mainly reacting to the tacit idea present in this thread that we need to be updating happiness values in real time. that just seems silly. Each value that the plugin created and tracks is on a turn system. One turn=one kerbin (6hr) day. A complete re-calculation of the value only happens once per turn, though certain actions, like transferring to a new vessel, could force a recalculation. Second, factors affecting these values break down into "conditions" and "events". As I explain I'll assume we're working in the value "happiness" The first calculation layer is "conditions". Conditions are things like "spacious environment" or "experiencing gravity". Conditions can be stored in code as two bytes: one being the effect on happiness (if your scale is -100 to positive 100 a zero value would be equivalent to -100 while 200 would represent the positive 100) and the other being the condition id (used to fetch, for example, the description string from a config file.). using a string instead of an id byte would open the system up to modding quite nicely. Conditions underpin ultimate happiness value calculated at the beginning of each turn. Essentially the calculation starts when, each turn, the program checks what conditions apply and then finds the sum of their buffs/de-buffs. the value returned will henceforth be referred to as base happiness, and should also be rounded and stored as a single byte. We're also going to duplicate this byte under the name "active_happiness". The next layer is the events system ("went on eva", "had friendly chat", "ate hearty meal", ect). This is where the mod can have the most flavor, but is also a processing and ram heavy proposition. My thinking is that while events can have influence over a kerbal's mood, you shouldn't be relying on events to keep your kerbals happy. That's what conditions are for. With this in mind, we only need to track events on loaded kerbals within a single turn. None of the events system I'm about to describe needs to be processed in time warp or for unfocused vessels Each event, upon manifestation, applies its own offset to base happiness. This allows you to dynamically alter the final happiness value in real time, without going back and re-checking for all the current conditions. base happiness is still stored, along with two bytes for each event (in the same style as a condition), and we add one more byte: active happiness. The calculations involving this data still don't occur every frame, but simply once when each event manifests. For example; you tell your chef to prepare 5 hearty meals. for 5 random kerbals aboard your vessel, "base happiness" is retrieved, an offset is added for "ate hearty meal" and "active happiness" is saved. To be clear, at the end of each turn the events list is deleted for all kerbals, and was only ever present on kerbals that you focused on and who had an event occur effecting them. The third and final layer is happiness inertia. If you take Bill out of the space station and put him in a tiny pod on a tug, he shouldn't immediately go bananas. This can be tackled very simply by taking advantage of the turn system. Previously we discussed calculating base happiness from the average of a list of conditions. Now, we simply take this value and average it against "active_happiness" from the last turn (weighted average if you so fancy: useful perhaps for something like "fitness", which should have considerably more inertia). The result is that whatever you did yesterday that made bill so happy: the computer doesn't care. Bill doesn't care. the last trace of that data was obliterated when, in the next line, we overwrote "active happiness" with the new turn's base happiness. But even though his head is touching the ceiling, he just ate spinach goo out of a tube, and he's on freaking space tug duty again... he's... smiling... To review, we have two calculations: a conditions calculation that returns byte base_happiness and occurs for every kerbal once every six hours, and an events calculation that occurs for one kerbal, only when focused and only once when an event actually occurs. Two bytes describe the current state of the kerbal: base happiness: for use in events calculations, and active happiness: the actual final value to be printed on a ui for example. up to two lists (functionally tables or arrays: looking up an offset (byte) via an id (byte or string)) are kept per kerbal; one for conditions and one for events. Polish. The events system is where this mod will derive the bulk of its flavor, but no events will occur on unfocused vessels. I would argue for a simple system that spawns 1-3 applicable events per kerbal when he is first focused on during a turn. this way an events list can have some background population with things like "had pleasant chat", "didn't like the food", "Beat Jeb in chess". these would be balanced for an even distribution of positive and negative offsets so as to not give an advantage to traveling to duna in physical time warp, and thus very deliberately avoid having a large game play effect, but the added atmosphere would be almost free computation wise and imho add greatly to the mod. Expandability. The list system allows us to keep one list of all the conditions impacting a kerbal. multiple different offsets can be defined for each of these conditions, allowing the same master list to be used in the calculation of all variables addressed by the plugin. Example ram usage for 1 of 2 crew in a hitchhiker and a 3 man pod headed for duna, using happiness, sanity, and fitness: Conditions List: (2d array) [23,90,99,100] (id 23: "vacuum packed diet", -10 happiness, -1 sanity, 0 fitness) [47,100,95,50] (id 47: "zero g", 0 happiness, -5 sanity, -50 fitness) [8,100,105,100] (id 8: "its me and a partner", 0 happiness, +5 sanity, 0 fitness) [27,110,115,120] (id 27: "ability to exercise", +10 happiness, +15 sanity, +20 fitness) [233,110,100,105] (id 233: "breathing room", +10 happiness, 0 sanity, +5 fitness) 4x5 bytes is 20 bytes. the program additionally creates 2 more bytes times 3 variables (base happiness; active happiness); so we're at 26 bytes for this guy. lets square that because other mod authors add more variables and more conditions. 676 bytes per kerbal. 200 kerbals in your save: 135200 bytes. about 135 kb. about the size of this post as a .txt file, or 1/3000th of the ram one with 4 gigs on their system might expect to be allocated to ksp. What I'm saying is that if you play with variables as bytes you have to try really hard to blow up your ram usage. what I'm unsure of: How to apply random flavor events: My thought is to attach them to conditions. for example; the condition "Large Crew" would enable the random event "Beat Jeb at Chess" to spawn. I just don't feel it's very elegant though; and would certainty complicate the conditions definitions, wherever these were stored. How best to track the conditions list: What constitutes "spacious living quarters"? do we re-check the list each turn (seemingly prohibitively expensive) or force specific types of changes to cause a recheck (seemingly very sloppy) probably some hybrid: we cant rebuild the list for 150 kerbals every 6 hours in 10,000x warp, but we also shouldn't attach code to every SOI change and write and run code that's constantly looking for perceivable gravity. How best to implement the list system: The thought crossed my mind that we're going to load the directory of possible conditions and events into ram once; why copy most of its data over into each kerbal's lists. Basically, do we use the id of a condition to reference a common database elsewhere in ram to retrieve offsets for calculations, or do we save the cpu some effort and simply copy over the couple bytes into the kerbal's data. In my example I did the latter, as it seemed simpler and still not too costly, which I figured was good given my poor understanding of transactions in ram in unity or C# Event StackingOne of the big discussions in this thread has been avoiding exploitative stacking of event buffs. The turn system makes this much easier to avoid. The options are A) once an event has occurred that turn it cant happen to that kerbal again until the events list is purged at the start of the next turn. you could conceivably do this with around three lines of code. alternately, each time you stack an action it has half the effect of last time. first eva of the day? +10 happiness. Second? +5. Third? 2 (rounding to floor bc we have only a byte). Thus, the fifth eva and onward has no effect, and the previous four contributed +18 happiness. Lastly, I'm a big fan of the adversarial system for idea development: tear this thing to pieces and I'll do my best to defend it. Do try though to offer better solutions to problems that you dislike how I solve.

Read my whole post, I am aware Additionally, the note in the OP is new since I posted. no hard feelings I'm glad everyone is happy with where this is going

I do hope that someone realizes that hijacking nova's vision and taking a stab at it without his permission is at best rude and at worst illegal. The plans for these planets were and still are his intellectual property. I can't really comment on the OP's talent or execution in making planets from the couple pictures provided, but, I can testify to nova's immense talent in making planets for Kerbal Space Program, as can anyone who's been off Kerbin, or tied out his alternate universe mod. Falling short of this high mark would be failing to do a justice to the solar system that was and will always be nova's, and in so doing belittle his hard work and the value of his vision for the system. If it weren't for nova's (hesitantly?) saying to do so, I would have trouble saying that this should continue.

this looks amazing so far; keep it up!

Excellent mod; watched the dev thread for a long time and am thrilled to have the release version-love it!

in KSP, there is a certain air pressure required for semi-deployment. If a chute is semi-deployed (and therefore the air pressure requirement met), then, at a certain radar altimeter reading (500m for standard chutes, 1500 for high altitude chutes.), it will go full-deployed.

from .18.2: technically, I wasn't quite in orbit when my single launch three man duna and return mission (which was way overbuilt,~120 tons of lander fully fueled) found a ~50 ton (empty) orbital injection stage that *someone* had recently decoupled during the test mission. 120 ton duna lander (with 4 nervas): shattered to component pieces ~200 ton orbital injection stage that had been pushing the craft around 2 gs: all but a couple parts obliterated; one tank did stayed connected to its T30 and ended up interplanetary ~50 ton empty orbital injection stage that got in the way: vaporized one radial chute managed to cling to the pod through it all... the crew got to go swimming a few months earlier than anticipated.

So if I spent a few hours [read: eight] base building in v4.0 only to have the whole thing spectacularly explode on a quick load, and failed at editing the save file to resolve the issue, I should be okay to start re-building (hacks used, until I get to where I had been) in V 4.1? don't get me wrong; I adore this mod and fully understand the presence of bugs... I just would quite like to know if i'm safe to start building yet or if I need to wait for a more stable release.

download link is broken