metl

That's what I thought it was supposed to do and that is probably why it worked before and didn't now. I took that line out thinking it was redundant. So how do we reverse it to where the contract appears under the false condition?

I first thought it was an odd way to read it to, but it seems as if the expression is making sure the contract requirement of the target vessel matches the value stored in the DATA node which is the specific vessel orbiting Kerbin. It seems to not care that it is a string. Like I said, it seems to work, but does have a bug in it so I will definitely give your suggestion a try. I figure if anyone knows how it works under the hood, you would be the person to ask! thanks for pushing out the updates to docking Well, it was working (I thought. I might just not have cycled the contracts enough to get it to come up again.) It accepts my original syntax as valid, but it seems to have no effect on whether the contract appears. Using the suggestion you gave, I get an error that says the value supplied for the expression is invalid. And i didn't have any luck trying to write my own requirement. WAY above my ability! LOL!

I think i figured out using the DATA node expression to check for a ship in orbit. For the most part, it works, but after the vessel is destroyed, it takes declining the remaining related available missions a couple of times before they stop appearing. Here is how i got it working: DATA { type = Vessel requiredValue = true targetVessel = targetVessel = Vessel().LKOStation().where(v => v.IsOrbiting()).Kerbin() } } REQUIREMENT { name = vesselcheck type = Expression expression = targetVessel == true } What do you think?

I use the science funding mod so I get money for science returned. I'm not forced to do contracts that way and it greatly helps with overcoming the "grind" of contracts just to get money for upgrades. One trip to the mun can get net close to a million funds if not more depending on how much science you gather (I just do one or two biomes at a time.)

On hard difficulty, getting the funding for upgrading even just the R&D can be a very arduous task. I finally had to use custom settings so I could have the harder difficulty options without the gigantic increase in building upgrade costs. I soon discovered that the only real increase to difficulty is in fact the upgrade costs. I hope they can incorporate something a little less artificial by the time 1.0 releases.

I've looked at the wiki on how to extend requirements and create new ones, so I may play with that to create a new requirement type based on if a vessel exists.

I am trying to prevent a duplicate mission coming up if there is already a vessel in existence with the same nametag. On the reverse, I want to make a mission appear only if a certain vessel nametag exists. I'm certain an expression should be able to do this, but i just can't figure it out. My example: expression = vessel(myVessel).IsOrbiting(Kerbin).false I've tried several variations on the () and using periods, plus rearranging the statement, but nothing works. What am I missing?

I believe that should be solved with the upcoming change to the way it looks for the science module as opposed to the lab specifically. It just depends on how Station Science has the parts set up.

That did it. I can't tell you how many times I overlooked that, and kept making the same issue! I apparently forgot what I named the part! The changes have been uploaded.

This is exactly what the stock station missions needed! I cannot give enough kuddos to this! I only have one idea. Instead of looking for four docking ports, maybe someone could make a small part defined as a "station core" identifier? Maybe a specific type of antenna or light? Or even a specific docking port? Maybe copy and just retexture the stock one so it stands out from the regular but still functions as a docking port, but with a "station core" module that your mod looks for? Just an idea because I do know some people build craft in orbit using docking ports (not me, I lack that talent, LOL!) Otherwise, well done sir! So out of curiousity, I created a git fork and added a "Station Core Docking Port" and changed the Station Core cfg to look for that part. (No retexture, not sure how to do that.) I tried testing it to see if it is even a feasible idea, but I cannot get the contract to come up. Looks like I may have screwed something up somehow

I like the 10k turn. It's simple and effective, even if not efficient.

As someone who grew up wearing glasses and have to deal with glare every day, I don't miss sun flares in games. They make pretty screenshots because, well, lenses pick up sun flares but real life has no such flares.

Or you could just disable the "revert to" features when starting a new game... An Time

I have two things. first, your mod is really well done, and I greatly appreciate the stop time-warp on failure feature. I want to know if there is a workaround for a failed decoupler. I started a new game and the first orbital craft I made, with the first time I was using a stack decoupler, had a failure and it would not separate, causing me to not make orbit and also causing the craft to be too heavy for the chutes, leading to a loss of poor Jeb. Since I was just starting out, I did not have the ability to EVA to try to repair. Normally I wold give this kuddos for upping the difficulty, but combined with the EVA issue, I was hoping maybe some type of workaround could be implemented. Something like if a decoupler fails, each concurrent attempt at firing it has a percentage chance of either firing properly or exploding (if it fires properly, keep on flying, if it explodes, it takes whatever is above it, but at least the lower stage is gone and won't be excessive weight.) What about something like 10% chance to detach properly, 25% chance of exploding on each re-attempt. During ascent, it would give the chance to survive, but on a return trip the odds of a success would have to be weighed with whatever you have attached to the decoupler. Take the risk of losing your heat shield because you tried your luck at forcing the return stage to decouple would be a hell of a decision to have to make. Anyway, just an idea. I'm not a dev and would have no idea if this would even be possible. Great mod anyway!

Perhaps Harv saw this cartoon when he was younger and the word just hung out in the back of his mind until they were playing around with rockets. His mind drew the connection for him and he didn't even know it... - - - Updated - - - It may have been "Turbo miles"

I'm not a big fan of FAR/NEAR. That said, I have started using NEAR recently just o get a better feel and be a little more prepared for how the new aerodynamic model with act. The more heavy loads I lift that want to cartwheel out of control make me hope they scrap the new model if that is what they have in mind. I really don't feel like I should being going vertical well into the upper atmosphere just to overcome the aerodynamics trying to do a gravity turn (and with a heavy payload, starting a turn lower, even from launch, just leads to tipping cause by the gravity pull.) Gravity turn too low= too much horizontal speed caused by weight, which leads to reverse cartwheel caused by aerodynamic drag. I'm failing to see how a "better" aerodynamics model actually improves the gameplay. But to each his own I guess.

For strength, you should probably use a something with a larger attachment node than the cubic octagonal. The part that looks like a flattened-off docking port works well (forgot the name.)

I've just now really started focusing on building a full station. I find it easiest to use a tug for each payload part that can decouple and land. My concern now though is all of the docking ports. But I guess two docking ports per section is better than 4 or more RCS blocks and other controls. Also, make sure your strut's start connection is on the tug and/or lifter and not on the payload. The end point disappears and only the start point counts as a part so you can really cut down part counts that way on the final station. (I just learned that one a few days ago.)

The actual spot you need to be in is at the lower end tip of the marker flag. It is a bit problematic right now finding exactly where to be, so I highly recommend downloading In-flight waypoints or the newer updated version called Waypoint Manager. It makes finding the right spot considerably easier.

When you look at some of the other options that were in the debug menu before and are now stock, I can't help but wonder and hope that they are making a ScanSat-type feature. Sure would be nice.

Okay, so here's a few observations and questions I have regarding all of this. First, in the current model, I would reduce my throttle for part of my ascent to conserve fuel. I worked under the assumption that since the engine became more fuel efficient as I ascended, I could reduce the throttle and get the same thrust. I generally eyeballed by ascent speed and assumed since I kept it steady, the thrust was steady. I'm guessing that was wrong and not at all what was really going on? The second thing is, how does this affect Dv calculations if the thrust does not remain constant? I guess it would be steady once in a vacuum, so I guess the answer is it wouldn't? So again, does this have any actual effect on the user's gameplay experience (beyond altering how TWR is calculated) or is this just more of an internal thing?

Can someone explain to me how this will actually affect gameplay? I'm confused on that part as twr currently increases going up in the atmosphere. So fuel efficiency will remain constant now? It didn't before? I know turbo jet engines were more fuel efficient higher up, but I never noticed a difference with rocket engines. What am I missing?

The diameter size is the least confusing as to how big or small a part is and prevents any confusion when building. They can be quite a mouthful when explaining to someone else though. "Put a size zero point six two five meter tank onto one of the zero point six two five meter to one point two five meter adapters. Make sure the zero point six two five meter end is on the top side." While clear and descriptive, is can really begin to bog down a conversation with numbers. I would like to see an actual naming convention standard used.

The second example is kinda funny but the first is quite realistic. If you remember, Apollo 11 had to almost abort because of fuel issues. They cannot account for everything.

I am thrilled to see this change. It makes damn good sense to have the engineers actually do something useful. Furthermore, calculating Dv of a moving vessel traveling through constantly a constantly changing atmosphere (or gravity source) is not only NOT basic math, it is also NOT going to be getting done by the pilot at the same time he is trying to fly the craft (but when in a safe spot, he could theoretically plot a maneuver node and figure out how long he needs to burn for.) Do you think NASA used three man capsules so they could just keep each other company? Every person in that capsule had different job assignments during flight. As far as EVA, does anyone even remember how hard it was for NASA to train the guys to do an EVA? On thier first attempt, the dude barely managed to make it back into the capsule and was entirely wore out. EVA is NOTHING like getting out of a car in a parking lot. Having to have a proper facility to train for EVA makes sense (and yes, so would requiring training, but Squad is trying to avoid artificial time sinks as much as possible. Let's not start THAT conversation.) yes, there are many things they could do differently, but the bottom line is they are purposely keeping things as simple as possible while trying to show just how involved space travel really is. The fact that they are finally including a Dv readout is freaking awesome!