XLjedi

I tinker with Mission Builder from time-to-time... Maybe best to post a question or two in the Mission Builder forum. Although, I acknowledge not many seem to follow or post in that forum on a regular basis. If I could just figure out some way to have a catch-all node fire, complete it's little string, then return to the main storyline thread, I think I'd be pretty happy with Mission Builder.

I may give this a try...

At some point during the beginning of this video, I say that I will attempt to keep it within the 30 minute mission parameter and not turn it into another hour-long dissertation on helicopter design. I then proceed to do another hour-long dissertation on the various design elements of this new rescue helo. My apologies for the length... They say the first step toward recovery is admitting you have a problem. Hello I'm XLjedi, I talk a lot in my videos. ...or at least I talk a lot since I figured out how the mic works.

yes, it's a PDF doc... but if anyone would like to translate it to another language feel free to reach out. I can provide an editable format for translation.

honored to be included, thank you!

oh thank you! my PC died and havent been able to check in daily... so just now seeing this, thanks so much! I hope folks find the guide useful.

How to add my own mods to the game... I know what I want to add, I've just been so lazy about tinkering with Unity. I blame the new parts that have me sidetracked once again on storybook missions.

@Bartybum I would love to be able to describe my own mission parameters. On a relatively simple check-the-box scale... something like just set the base you want to goto with whatever rocket/cargo. Once you demonstrate that a mission can be done, the result can then be automated to just rerun the same mission cost/benefit when a valid launch window is available. Maybe a dropdown list of your own resupply missions with red/green indicators. ...and I'd be fine with allowing those to just be auto-completed with a % complete bar to properly account for the time it would take to complete the mission given the current window. On the one hand, I don't want resupply to be tedious at all... but on the other, I really want to be able to demonstrate that at my current tech-level I could successfully run the mission to provide whatever supplies are needed. I'd like to setup orbital refueling stations with a system like this. Then as my tech improves maybe I can redo the supply mission to improve on the cost-per-ton of delivery and delete the older less efficient missions. I'd like to be able to manage my own system of supply-line missions at the strategic level, but establish each mission as viable at the tactical level. I acknowledge that I do kinda group together life support supply requirements with all types of supplies in general... and see the overall logistical challenge as less of an individual ship thing, and more of a proximity to a supplied base thing.

I have a few... some are complete train sets too. ...and a dragon, there's big green dragon.

Yeah... I think I possibly have every single SW Lego set that was released in 1999. ...along with the instructions and box. The 7140 X-Wing (the first SW set that they ever released) and a few others are completely unopened. So I guess those are all officially antiques now. Didn't seem like it was all that long ago.

Excellent... noted. I think we can safely move on now to what features folks might like to see in an implementation of a supply-line or LS system.

OK, so... provided it's not "too ambitious given the time and budget" then you're OK with LS being implemented?

OK then, to further clarify... I'm perfectly OK assuming the opposite of your quoted statement. Particularly as it relates to semi-hypothetical wishlist discussions.

@Brikoleur LOL, OK... I don't presuppose what may or may not be too difficult for developers to implement. They seem to be pretty sharp folks! For the sake of "wishlist-type" discussions, I'm pretty OK assuming they're clever enough to tackle the challenge. ...then they can tell us later that they saw people wanted it, but it was just too hard or time constrained, or whatever and they just didn't have the time to implement it. I think they could implement supply-lines and piggy-back off the comnet structure.

M'kay... same level of challenge/complexity could be implemented to work with connected supply lines. Worse that could happen is kerbals get put in hibernation pods until supply lines restored.

Based on that logic, one might suggest they shouldn't bother to reimplement the comnet system then?

@Brikoleur What are your thoughts on a relatively simplistic "supply line" type radius implementation? I would like to see something where a base-to-base supply line network might need to be established and yet not have to deal with repetitive resupply missions. I'm guessing the coding would be very similar in many respects to how the current comnet works? Maybe a refinery on one planet or moon can simply be connected to another planet or moon base with drone resupply ship connector. When the orbits are within acceptable windows, supply levels are tested and resupply drones are launched if needed. I don't think we really need to literally model the drone launching in much detail. Maybe only an active supply line on the big map, and that's it?

I doubt I'll really be playing it too far beyond sandbox at launch... Of course, I'll start a career just to see what it's like, but I'm more interested in seeing the craft file format and structure and to begin tinkering with whatever mod/dev tools are available. Probably have to spend the first month or two rebuilding all my craft if no craft file port feature is offered. Which would not surprise me at all. There are not too many games that I would buy at launch nowadays. Don't know if I could actually name a single one in the last decade... But for KSP, I've gotten enough hours of playtime out of it that I will step out of character and support it from day one.

@sturmhauke@Snark Very interesting discussion and insights...

@Snark On assumption 1, I think it's a fair assumption. ...or at least skewed more heavily to the side of less bugs, than no bugs or more bugs as a result. I would consider your "not necessarily" to be inline with this. Agreed, the probability is not 100%, but it ain't 50/50 either. QA/QC will no doubt produce fewer bugs at launch. That's a pretty fair assumption vs. nothing. ...how you go about it is a different story of course. I imagine a volunteer or very selective beta-test program would produce valuable feedback and squash a bug or two. I concede however on how much value it might add and whether or not the value of such a thing outweighs the risk. If it were me in their shoes... I have to admit that I would probably say, no thanks. We got this. Assumption 2... no, don't ascribe that one to me. However, on the topic of "treatable" or "non-treatable" bugs. I'll give a couple examples that I've come across... If you put a ladder on a platform, you should be allowed to easily exit the ladder when you reach the top of the platform. That is the kind of bug that I find to be very disappointing and it impacts my game play. I build something with the expectation that a part (like a ladder) would function as a ladder and have a way to exit/enter when you reach a platform on the top. Something happened in one of the 1.7.x updates that messed up ladders in this sense. I need to post something in bug tracker for it. An example of a harmless bug or something that is even fun to have would be part clipping having zero impact on engine thrust. This is the kind of bug that actually was pretty nice to have and allows for a bit of extra creativity. Folks even built craft designs around it... it bothered no one, did not effect game play and was easily avoided by those who preferred not to incorporate such things into their designs. Then they decide to fix it months (years?) later and it destroys or disrupts favorite craft. Not sure why we needed the Wheesly and Goliath engines fixed in this sense. Now reverse thrust on at least the Wheesly doesn't work if something is clipped to the side of the engine. They fixed what never needed to be fixed, and in the process introduced a bug that disables reverse thrust in some craft designs for no reason. Wheel interactions with the ground shouldn't cause your craft to be catapulted into a gravity-challenged low orbit, or come crashing down and causing damage to your craft... after maybe spending an hour or two of RL time traveling to some far off place. Stuff like that should be vetted and squashed before release and it may not be the tech-heads who find it. It more likely will be discovered when you get a diversity of play styles testing the engine. The bugs introduced during the transition to 1.4 (new Unity engine) were so bad that I couldn't even leave the Kerbin SOI. Craft that were docked as cargo in other craft couldn't be deployed without damaging stuff and/or blowing up. I could not play the game anymore with my fleet of craft. To risky to deploy anything without damaging it (and no way to fix it on site) so I just hung around Kerbin and only did sandbox stuff, pretty much all the way up to present... even left the game completely between December and August. Had no real reason to play anymore. 1.7.3 came out and added rotors, some robotics, and the KAL-1000 so now I'm at least playing around on Kerbin again with helicopters.

@sturmhauke As for game industry jobs... I've heard you can make literally hundreds of dollars working in the game industry! LOL I do envy the folks who can do that work and get paid a decent amount. I personally, could not afford to do that type of work. The competition is so high, and the work is... well... it's fun, right? So you have very talented folks who are willing to work for next to nothing. I've got 2 kids in college right now, with a 3rd about to start. So unless one of the publishers wants to hire me as their CFO, I don't see me being able to change jobs anytime soon. I do have on my bucket list, maybe one day when I retire, to turn my attention once again to developing applications (or more likely games) to distribute on Steam or some other forum, just for the fun of it.

@sturmhauke Seems to be a long-shot at best then... I do cringe when I see the flaming posts following any game release or update criticizing the devs for the perceived "lack of any sort of beta testing". Some things just seem so painfully obvious that I have found myself wondering, "Did you even try to play your own game?" (not pointing a finger at KSP in particular here) I do wish them well and hope for a successful (minimal bug) launch. I can also see from their POV though, that maintaining an air of secrecy and excitement may very well outweigh a bug free launch. ...and even if you do have beta testers, there will always be bugs that slip through.

If KSP2 includes colonization, I do also like the idea of some sort of implementation of LS and/or supply lines. It has to be simple enough so not to take away from the core gameplay. Perhaps something as simple as a re-supply radius on the big map? Maybe the radius could grow based on how you upgrade each base. The bases could assist one another if their supply radii overlap. I don't mind kerbals being sacrificed in catastrophic explosions... Hey, it happens! I would have a problem with them starving to death or running out of oxygen. I know it seems odd to some that one form of death is OK and another is not, but it just takes away a bit from the light-hearted gameplay for me. So a default state of hibernation would be more palatable to me personally. In which case, the kerbals are just rendered unusable until supplies are restored. It would be harder to implement, but another thing I'd like would be to have a baseline cost and/or resupply rate. So there might be some very slow baseline resupply rate for a planet base located anywhere. If you could designate that you are undertaking a "Resupply Mission" and the mission was a success. Then the cost/time/supplies of that successful mission would then be used to recalculate and therefore improve the slow default baseline resupply rate and perhaps establish the size of your resupply radius.

Ah... OK. Did they have any voluntary testers? ...or have you seen any cases like that? (aside from broad "early access" crowd funding schemes)

I wouldn't mind life support as an option... as long as it was kept somewhat kerbal-ish. Aside from instantaneous death due to catastrophic explosions, I have a somewhat difficult time putting these cute little green folk into situations where they would starve to death or run out of oxygen. I have yet to put a kerbal on the surface of Eve because I just don't have the heart to leave them there. Well... I take that back. The only exception being "Kringle Kerman"... In a storyline... Once... Not sure how he got there though. Poor Kringle is still stranded on Eve.. We have to save him! Edit: @Jimmidii Hibernation as a default state rather than death is really an excellent suggestion if LS is added to KSP2.