Greys

As mentioned in the main Virgin Kalactic thread, I am releasing this project under MIT as of now, and will no longer be developing it myself. Repository is in the first post, if anybody cares, have at it.

I am officially backing out of modding KSP, HexCans has changed from CC-By-SA to MIT license. To the few people who actually enjoyed my parts I thank you, and if the interest exists, you're all free to continue it.

It's been a long time coming but I'm making it official now. I have no intentions of putting any further time into KSP, or KSP modding. I'm not leaving the community but I've run out of give-a-damn, interest, and time I feel like spending on it. To whosoever cares for the things I've made, or may find it in the future I have altered all of the license files for my projects, it is all MIT now. This is the first time I've logged onto the forums in weeks, and I've barely been posting for the better part of a year, so you won't see me around likely, but I'll be in the IRC, the modders one, for as long as I care to stay. There have been some commits pushed to the repository since the last update, new mostly incomplete features, I don't have it in me to finish them or integrate what exists but they are there for whoever cares.

A single mesh collider object can have 255 (or maybe 256) faces, but you can have multiple mesh colliders (and multiple primitive colliders). All colliders must be convex, so your system as depicted must be a minimum of 3 mesh collider objects or it will be automagically simplified into a convex hull that I think will resemble a dried cat turd. I don't expect that number of faces will pose a significant issue for anyone except the most abusive players, if you can make any of that out of primitives instead of mesh that'll help, but you'd need to sacrifice accuracy by quite a bit. With how large that capsule is I'd say the accuracy is worth the performance hit.

I believe one part is allowed to have multiple solar panel modules, as long as you give each of them uniquely named transforms and suncatchers; but you can only have one animation play at any time with stock modules. As such you could have an indefinite number of static solar panels, but you can only have one deployable solar panel; should be fine to have both though, any number of statics and one deployable. If someone has made a replacement solar panel module that allows for multiple deployables I am unaware of it, but solving that issue is literally a few letters change in code.

rescaleFactor impacts only the MODEL node, coordinal fields in PART (such as node_), and transforms used by PartModules. It does not impact NODE nodes. This is problematic because MODEL.scale does not impact anything which does not use a transform such as node_ definitions and old style FX definitions, creating a dynamic where if you use MODEL you need to be very careful with rescaleFactor, and if you use NODE, rescaleFactor Must be 1. Additionally, as of 0.25, NODE definitions Could Not define a part's SrfAttach node, suffice to say that the stock game was simply negligent in this regard. I've not inspected the more recent releases but I see no reason to believe this has been fixed. I have previously made a plugin which corrects this situation, you can find it on KerbalStuff as SrFix, but I am not currently in a situation to update it. I do find it doubtful that it needs to be fixed, a recompile is likely all that is required at worst, and it has a very open license.

So I wrote an edit for my above post, and then went to work without applying it... sooo it's live now, basically I was wrong about keels, FAR makes wings act like they're underwater when they're underwater, so keels, rudders, probably hydrofoils, all that should work correctly as long as you have FAR, and BB may enhance this further. Customized parts may be necessary to have appropriate behaviors and more importantly mass.

There are and have been various mods that add stuff for operating on the ocean, but at this point the most important one is Better Bouyancy by Ferram of Aerospace http://forum.kerbalspaceprogram.com/threads/105094-0-90-Better-Buoyancy-v1-0-Simple-Water-Fixes-12-27-14 What this does is change how bouyancy is calculated, but also make the ocean surface significantly less lethal, which permits your boats to travel at higher speed with less risk. I also recommend for any vehicle that is in contact with a service you get a mod that either changes the stock UI, or offers an additional UI, which will dislay your speed in more common terms, specifically Kilometers per Hour or Miles per Hour, it's just very easy to not have a good grasp of how fast you're going when looking at meters per second, for example 60mph, highway speed in much of the USA, is 26.~m/s, it's pretty easy to make a rover that goes 20, with mods I've made rovers that do 90m/s, throw a rocket on and you can make a rover do 300m/s, that's almost 700mph, more than ten times highway speed. I'm told FAR has this option built in, there's also Speed Unit Changer, but it's somewhat out of date. With these two things you don't really need anything else, you can made jetboats out of stock parts, but I would also recommend some mod to launch in the water; you can do this with Firespitter, though I've never gotten the feature to work, and you should be able to use ExtraPlanetary Launchpads to build a little dock. or even just a place closer to the beach. Bonus points for launching your boats via airship. The only thing that I am not aware of to complete the paradigm is a mod which adds appropriate boat based propulsion, that is to say, propellers. For the most part your boats will need to be driven by jets, maybe aircraft propellers from the handful of mods that offer them. The great thing about these is that water in KSP isn't actually water, it has this weird attribute of being full of air; jets, and air intakes, work just fine underwater. Because reasons. Finally, I'm not entirely sure, but my understanding of the stock behavior and mods in play says that your boat will have no real inclination to go.... forward. Boats don't normally go fast enough for normal aerodynamics effects to be powerful, and I'm not aware of anything that would make hydrodynamic effects.... exist. Boats will be kinda like pucks skimming over the water, they'll just as readily go sideways as any other direction, and turning will be dangerous at any significant speed. turn slowly, and slow down when you want to turn. Probably a good idea to use MechJeb's Smart SAS to keep the ship pointing in the right direction for long trips as well. edit: I have discussed it with Ferram and keels should work just fine in water, they should behave not as if they're travelling through air, which would make them underpowered and useless; but as if they're travelling through a dense water like fluid; thusly they will have sufficient force available at boatly speeds to be useful. Because this is true, rudders will also work for steering, and hypothetically hydrofoils should work fine. You will require FAR for this though. With only Better Bouyancy you won't get the whole water experience

Seriously this community keeps finding the most astounding minutia to be unreasonably enraged by. It's almost like there's some secret gambling house that's sending in sacrificial debtors and betting on what will happen. There's so many correct or at least acceptable ways to have dealt with the situation, the best option would have been to just do it and hope it works, you'll usually be happy with the result, worst case someone will post and after making a post you can ask them over PMs to delete and repost, if you're nice and reasonable people tend to do what you want. If you're not nice or not reasonable, sarcasm is the normal result, it's just the way of the internet and you should just be prepared for that.

That's exactly what retained objects is. In scene change KSP creates a bunch of objects and then leaves them there taking up space when they're no longer needed; and because it does this every scene change, the more times you change scenes the faster you will crash. As well KSP creats a hell of a lot of objects that do get disposed of correctly during scene change, which is why memory spikes during scene change and then comes down to a bit more than it used to be, which makes it even easier for KSP to crash.

Well, there's a handful of things you'll need: Learn how to consume resources: part.RequestResource(), you can see it in use in a lot of mods, if the mod uses a custom partmodule to consume or generate fuel, this is how they do it, unless they don't because RequestResource() is really annoying. Learn how to work with transforms: as I expect you're familiar with, the thrustTransform of each engine bell is responsible for orienting the particle system and representing the thrust's position, and another transform is used for gimballing the thrust transform, you're going to need to replicate all of that. Learn how to apply a force: Best thing I can point you to for that is ModuleRCSFX https://github.com/NathanKell/ModuleRCSFX/blob/master/Source/ModuleRCSFX.cs I don't know it's code myself, but it's relatively small and simple, and it's made by some of the best modders in KSP so it should be really good. Learn how to take values from cfg files, I don't have a good example for this but it shouldn't be too hard to find And once you know all that you'll be able to replicate the old ModuleEngine, not sure how the mode thing works but others can help. If you want a faster conversation you could come to IRC://IRC.Esper.net/KSPModders and chat with a lot of knowledgable people more directly.

You are however allowed to look at other mods' code, and maybe we can help you find some apt examples. What specifically are you looking to do?

the only problem with the original proposal is that the mod would only work as intended in full career mode; even in just science mode it would be severely gimped, and in sandbox it would be entirely disabled. I don't think there's a solution to that so it may be something that just has to be put up with.

http://forum.kerbalspaceprogram.com/threads/95056-PartReplacement-Prototype-v1 https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/BetterPart/PartReplacement.cs https://github.com/Greys0/Virgin-Kalactic/blob/master/GameData/Virgin%20Kalactic/Patches.cfg https://github.com/Greys0/Virgin-Kalactic/blob/master/Source/Virgin_Kalactic/TrackResource/TrackResource.cs come to IRC://irc.esper.net/KSPModders if you need help

Memory is occupied by objects and references to objects; but predominantly objects. An object is mostly anything that gets stored, so like, variables and whatnot. In order to free up memory you must destroy objects. This means you must have a reference to an object and be permitted to cause it's destruction, but furthermore you must know that it is safe to be destroyed. While you may be able to make a mod that reaches into KSP and deals with leaked objects (objects which have completed their lifespan tasks but have not been deleted because they were forgotten), and there is currently a situation where a lot of objects are being leaked quickly so that'd be kinda nice; as far as mods are concerned the mod itself should be fixed. This is not something that can be done generically, it will need to be a custom coded solution for every leak.

What have you been smoking? Squad is a marketing company and marketing 101 is "ignore everything everybody says forever until you're rich", Squad applies that teaching in everything they do. There could be no mods on Curse and Squad would still side with them; but there aren't no mods on Curse, this is a major victory for KS but the bigger question right now is "how many mods are unique to each service?" and "how many mods are on both". That's not an easy thing to determine so maybe the crowd can figure it out. Now we want to be able to say that KS has the most exclusive mods.

This is false. Anyone no matter how astoundingly without intelligence, who is capable of composing valid language, any language, which can be understood by others as was intended by the writer, is already a programmer. C# is a language, and it's very similar to english, all of the keywords are english, and mean exactly what they do in english. The syntax varies a bit but it's all pretty obvious. The only hard part about programming is knowing where the thing you need to change is, in what way it needs to be changed, and how to apply that change correctly. This is a life skill. This is not unique to programming. If you cannot do this then your life is going to be very difficult. The task you seek to complete is irrational, impossible, legally dubious, misguided, and in poor taste; but you can program, so you can try, you can find all these things to be true by your own hands, and if you have questions about how to do programming stuff we will help you with that.

I am no longer experiencing any packet loss, and the site is loading reliably; it's not quick but fast enough.

Good job not reading this thread at all, and not knowing anything about what you're talking about, we're definitely going to respect your opinion just as much as you respect us. I'm not going to begin to explain why you're wrong because it's already been done many times in this and many other threads, also you won't learn. Anyways, welcome to the community, I hope you enjoy the modders who have now blacklisted you from any and all support period.

wait, there's a bot for this? Since when!

It's not thinking that it would be easy that can be offensive, but that you're trying to look like you're suggesting something, btw suggestions don't go in this board; when really what you mean is "Someone make this for me". The general rule in communities like this is that if you want something done you're going to have to do most of the job yourself, and if you're not willing or interested in doing it, it's best you keep your ideas to yourself. Making a catchall procedural system would be as close to impossible as you need to get before abandoning ship; but it'd be relatively simple to implement a system that reveals a dust or damage mask based on conditions; that's essentially what emissive animations do. The problem is that every part that exists would need to be enhanced to contain a custom damage/dust mask, and less significantly the KSP shaders would need to be expanded to match. This is not something that a single mod could do completely on it's own, part packs like B9 and KW would need to update to support it. This runs into the issue that you need to convince artists that it's worth their time to do more work before your mod is popular yet, when there's little benefit from them doing so, and significant side effects; and conversely if the mod does take off, any mod that isn't updated suddenly doesn't fit in. This is the kind of feature that only Squad has the clout to implement because anybody else has to deal with the politics of getting the community to adopt, and Squad would undoubtedly go for the procedural system, and would do a bad job of it, permanently downgrading the visual fidelity of the game. (until somebody makes a mod to disable it)

I do plan to, but my motivations for KSP are quite low at the moment, and my life is complicated at the moment, not sure when I'll be getting back into things. I got all the licensing figured out last time, so I can say at the least that my problems will never get in the way of B9 team handling things themselves.

I fully authorize the above recompile of Virgin Generic

according to google a tankbutt is a protective covering put over the end of a capsuloid pressure vessel; that doesn't make much sense in this context. Perhaps it's related to how a lot of mod engines have base disks that appear as if the fuel tanks should extend into them; but then many mod tanks clearly show the tank inside a cylinder of sheathing (KW in particular) I've discussed before how this doesn't make sense and really the engine should contribute more fuel to the equation; but there's no easy catchall solution. Or I could be totally wrong.

It's not really fair to Kamik to just compliment whatever; while this certainly isn't the worst part I've ever seen, it has a lot of problems. First and foremost it's profile is completely unrelated to the stock parts it could go on. I assume this is because Kamik didn't have a good reference to design against. Kamik, you can use Taniwha's Import/Export plugin for Blender to access the stock model, even if you don't use Blender you can use it to extract the stock model into a format your preferred suite can handle. Second, the RCS ports appear to actually be modeled as holes in the nosecone mesh; this results in weird lighting artifacts, and the normals were not fixed after making the holes so the area around them has also gone all wibbly. These details are just so small that they should not be modeled, they should only be represented by textures; perhaps going so far as to use normals to create a lighting effect, but on suck small parts that seems unnecessary and may actually look worse at a distance; given how small they are they will usually qualify as 'at a distance'. Get rid of the holes, and draw them on the texture The color pallet of the texture is wholly too light, and the lines between tiles are a bit thin, and not dark enough. You can try to sample the original textures, you can use Zeblote's MBM->PNG converter to access the original texture and sample it's colors but you may still need to fiddle around and just test stuff until you get it right.