codepoet

KSP has a class AssetBase that provides a public method GetPrefab(). I assume I can use this to access prefabs for gameobjects priovided by the game, such as attachment node icons, CoM Markers, Models of the VAB. The problem is not knowing what the prefabs are called. Does anyone have experience of doing this, or can offer solutions?

I saw a thread asking for suggestions on sanity a while back, perhaps it was you. Anyway, I have been thinking of how it might work ever since. My thoughts were that sanity not be a resource that depletes, but a value for each kernel that varies up or down based on their environment. Obviously living space has an impact, as does distance / communication lag from home. I also though it would be good if the sanity of each kerbal was affected by their own attributes and those of the other kernels they are living with. So: 1) stupid kernel loose sanity faster, 2) courageous kernels have a positive effect on other kernels. 3) lack of sanity has a negative influence on the sanity of others. The idea is to make sanity less of a problem that you solve by sending out a new part (ie send a container of fun with the cargo run to the colony), but instead it is more about the mix of crew attributes. It also has the fun of one kerbel loosing it and driving his crew mates mad, or alternatively, topping himself and so removing the negative influance on the group. You could also sepetate certain crew members for the benfirt of others, or intruduce a very courageous kernel to restore everyone else's sanity. Anyway, just my ideas. If you need any support or encouragement with the coding, feel free to ask me in a PM.

It would not replace Procedural Fairings which are essential for housing payloads. Also I am not sure that I will be looking to provide the funky use of the aerotail that mobius does to taper out towards the engine when it is wider than the tank. I think the thing it wopuld be most useful for is mounting things on top of boosters. We will see - it is early days and i have little time to spend on coding!

I have decided to do away with this part and start again. I am no good at modelling so I figure that my best bet is to procedurally generate the fairing each time rather than trying to model it. That way I can also have the option of no fairing, and then you have got the "floatnode" that have also been using. I have started a new development thread for this work, and would welcome comments, ideas, feedback and people willing to play around with the part wile I work on it. I will not be updating the part that this thread refers to any further.

Current Download You can download something to play with here. It is offered in the spirit of seeking feedback and bug reports. I am grateful to those who take the time to experiment and test my work. Please do not use it for anything important - no compatability with any previous or future releases is guarenteed. Source code is available here. Even better than posting a bug is to post a fix for it Get in touch with me if you are planning to create a pull request. Introduction: I have started work on something that has been spinning around in my head for a while now - a solution to several problems: 1) stack mounting an upper stage with more than one engine above a booster 2) Fairings for engine compartments 3) Mountings for engine clusters. Of these problems 1) can be solved using the PWB Engine fairing for clustered engines. 2) Can be addressed using Procedural Fairings and 3) by mobius works. However I wanted to sort of bring them all together, along with another part I created for my own use that I call the "FloatNode". The idea is to have a single part mounting plate, on which patterns of attachment nodes can procedurally be created (typically to hold engines). A bottom stack node is then procedurally relocated up or down depending on the size of what is connected to the plate, and when something (typically the previous stage) is connected to it a fairing is procedurally created to enclose everything that is attached to the plate. I have started work, and so far have a part that is the plate, on which you can arrange patterns of nodes, and also relocate the "floating" node based on what you attach to it. The next thing I need to start thinking about is the fairing (I am sure procedural fairings will provide some inspiration), but wanted to get a dev thread running on this as I would welcome ideas and inspiration as to which direction to take this in. Instructions: 1) Create the part and add it to the bottom on your stack 2) mouse over the part and press 't' to change the size of the top edge of the engine mounting plate 3) mouse over the part and press 'p' to change the patter of attachment nodes on the bottom of the mounting plate. 4) add engines 5) mouse over the part and press 'f' to relocated the "floating" bottom attachment node 6) add a lower stage Eye Candy The plate. Note that it starts with the floatnode above the plate. This is because I could not figureout which way was up in blender (yes I am that bad at this stuff!) Turn it around and pop it on the bottom of a tank. Mousing over the plate, and pressing 'p' changes the pattern of attachment nodes on the plate. You can have lots Or none, and use octostructs to attach stuff instead Here I have attached a wacky selection of engines Note that the floating node is now too high Mousing over the plate and pressing 'f' relocates the floating node based on the size of the engines. Here the lower stage has been attached. If the engines are wider than the tank they are placed under, the engine mounting plate will adapt its shape to take account for this. Since prerelease 0.4 the mounting plate can become quite curvey Planning I wanted to build a list of features and things that I hope to do with this, or have been selected. Of the two lists, the "vision" are all the things that it would be nice to achieve, or would be really cool. The "scope" is what I am going to realistically aim for, for a first release. Vision Add procedural attachment nodes to any part Add procedural attachment node from a list of predefined patterns Add procedural attachment nodes in any pattern (ie x rings, y nodes in a ring of radius z etc etc) Generate a mesh for the attachment plate Generate a mesh for the attachment plate that blends the cross section from the bottom from the part above to the pattern of nodes below Generate procedural fairings to enclose the stuff attached to the procedural nodes (optional) Get the fairings to blend from the part above to the part below. Get the part to also act as a decoupler? Create a GUI to set all the complicate options if all the above gets implimented Use Blizzy toolbar Scope (Done) Add procedural attachment node from a list of predefined patterns (Done, but needs to be textured nicely) Generate a mesh for the attachment plate that blends the cross section from the bottom from the part above to the pattern of nodes below Generate procedural fairings to enclose the stuff attached to the procedural nodes (optional)

Just to say I am very interested in this (I just spent half an hour looking for this thread). To offer my 2cents worth - I would be interested in being able to add subassemblies to the construction queue - so I could have several of my standard small medium and heavy boosters on order, but the actual spacecraft or payload would constructed and then bolted ontop seperately. I am looking forward to a formal release

No offence was intented. I was not laughing, but genuinely offering encouragment to anyone that is struggling with EVA.

Does anyone have any experience of calling AddAttachNode? I want to be able to dynamically create attachment nodes on a part, but I am unsure what the config that is passed into this method needs to be. I gegt the feeling it needs to contain the name of a transform - but where does such a transform come from? How can it be created? Any help would be apprechiated.

So clearly not something that everyone wants!! I know what you mean about sucking at EVA, I could not work it out at all for months, and lost countless kerbals who are still orbiting the sun to this day! But then one day - it just clicked. Do persevere, it is possible. Anyhow the feature I mentioned is all the same something that I would like for my own gameplay. I am strapped for time at the moment, but if I get a chance I may fork the code and impliment it myself, for my own use. If I get it done and it is any good then I may offer it to other OCD players.

Does this mod take into account the structure of the craft when transfering crew and only allow you to move crew between adjacent parts, or does it allow you to move crew betwen any parts in the same vessel. I would be particularly interested if it was able to know if there was abig fuel tank in the way or a girder or similar, so that in designing your craft you needed to be realistic about placing docking ports directly on to pods - presumably certain other parts could be marked as able to allow kerbals to pass along them, such as structural adapters or 6-way connectors.

Does that mode have significantly differently scaled bodies or bodies with unusual atmosphere characteristics? It might well be that the procedure MJ follows does not work for bodies with particular characteristics that do not exist in the stock game. Does anyone have experience of landing on bodies that are scaled to "real" size - is that the RSS mod or somethign similarly named? I have not really looked at those sorts of mods myself.

OK, well if you would like to offer up a paricular scenario that someone interested working on the code will be able to reproduce and maybe improve then please do so - it would be useful to have a save file, or craft file with full instructions and a landing location on a particular body, from a particular starting orbit. Unfortunately saying "it does not work in a variety of scenarios" is not going to give anyone much to work with and is unlikely to motivate anyone to want to do any dev work on that area. I can offer some advice though related to the code I have worked on (ie parachutes): 1) You will probably get better results if you have more than one parachute on your craft (particularly a drogue and a non-drouge) and use tweakables to set the full deploy height for each one be different so then each open at different times. That way the auto pilot will have more oppertunites to correct for errors by changing when it plans to open the parachutes. 2) You will get the best results with the parachutes depending on the pitch angle of the velocity vector at the time that the parachute(s) are deployed. That might take a little thinking to work our that that means - basically how much you are going down against how much you are going sideways. If you are going straight down before the parachutes open (low altitude eve) then it does not matter much when they open you will always land in the same place. However if you are going almost horizontal when you deploy the parachutes (ie high altitude Duna) a small change in the ground height can make a big difference to when the parachutes are fully deployed and hence the landing location. Somewhere in between these two extremes is a peak of optimum accurarcy. (ie Kerbin). I hope this is helpful or at least interesting. Sorry that I am not offering to make it work better, but it works fine for my own gameplay, and that is what motivates me. However if you can provide a detailed scenario where it is failing I will gladly take a look.

You are pretty much bang on the money with most of what you say, but there is more to it that that: After the de-orbit burn, the landing autopilot will course correct until the landing prediction is within 150m (as you observed). After this it will not course correct unless the error grows to more than 600m (almost what you observed). At this point the craft will cruise until either a deceleration burn occurs (for bodies with no atmosphere) or the parachutes are deployed (bodies with an atmosphere). The the case of a deceleration burn MJ can control the overshoot / undershoot by burning more/less than it anticipated it would have to. For parachutes it can contol the overshoot/undershoot by timing when to activate the chutes. The deceleration burn seems to be more accurate, but timing the parachutes works well on bodies with thick atmosheres in flat areas. Timing parachutes around hills is hard as the AGL triggers the full deploy. It would be interesting to know if your landings were: 1) on a body with or without an atmosphere 2) whether or not you are using parachutes 3) if you are landing on a body with a thick atmosphere (ie not Duna) 4) if you were landing in a hilly area, or a landing site near a slope, or an approach path the pases over a slope. 5) if the landing error was an overshoot/undershoot error or if you landed to the side of the target.

Well I think this is quite a good idea, and something I would probably use in my own game play. I have a few thoughts for how it could be implimented, so I plan to do this in a fork of the code. It is up to others to decide whether or not such changes are to be pulled back into the "official" dev branch though.

Oh, I see, so it is to prevent landing on top of something else. So it is basically a complaint that the landing is too accurate! I will take that as a compliment!

Could you please clarify what you mean by this. The guidence screen does already display the distance from the predicted landing site to the target landing site.

I think that this is the place to find some solutions for the problems I am experiencing. I and writing a part that I hope will have multiple surface attachment nodes. Indeed I hope it will have a variable number of these. I had planned to just make a call to AddAttachNode, but the config to pass to it is proving to be a bit tricky. In particular I get errors about the transform. Do I have to define the transform in unity, or is there a way that I can define / create it and use it on the fly to created multiple attachment nodes is various locations at runtime? Thanks in advance

My experience and thinking about this suggests that it is only the final burn that counts. I believe that it is necessary to do previous burns to raise the AP, but arrive at the PE in the place and at the time that a single burn would have occured. Then the final burn is the one that puts you interplanetary. This is why one of my wishlist manoeuvres is "raise Ap to arrive at Pe at a certain time." I am on my phone, I will write more at my pc

You have never been to Laythe - if you had you would know whether or not it had an atmosphere. Since you have never been there, I can;t see how you are the best person to come up with an interesting, fun and challenging way of landing there. However if you are looking for a considered (and play tested) laythe challenge, then there is always this.

If I were to add anything to Mechjeb it would be things like this. I have been flying with ions a lot recently, and some sort of burn automation I'd essential for a largeish ion craft. I also refuse to use nukes, so often my large intetplantary craft have a single, high ISP engine to save launch mass, so I often have TWR<0.1, which can mean splitting burns over multiple orbits. It is no big deal, especially if you start a few days before you need to be on your way. I have a series of spreadsheets for calcing things like raising AP over multiple orbits, or planning to be at the PE at a certain time by raising th AP to adjust the orbital period. That could be useful to come back to do the rest of the transfer burn at exactly the right time, or planning the time to AP to get into the correct geosync orbit. If I do start to add any such features to my fork of Mechjeb, I will consult with others and offer it to be pulled once it works.

Thanks Starwaster, that is just the sort of info we need to look into this. I will see if I can't fix it when I get a few free moments tonight (I am in GMT), unless someone else fixes it first.

Shad0wCatcher - thanks for the reality check, it is always good to take a break. To be honest I am about at the point now of going back to actually play the game. I am just a player, who sees working on mods as part of the game play - when NASA wanted to navigate to the moon they did not download a parts pack, they wrote a flight computer! I started working on parachutes because I wanted a solution to the Laythe Kethane rescue challenge where by I did not have to worry about driving to the target after landing, did not have to carry heavy engines and fuel to power the landing but could just fly to Laythe on ions and then appear on the surface next to the craft that needed rescuing. The solution was to land accuratly with parachutes. So I feel I have achieved what I set out to do - I will probably step back now and play the game (and live real life - I have a house to renovte, a job to work, and need to get a new job by the summer). However I have a few closing thoughts on parachutes. First is that obviously support for RealChutes is something a lot of folks would like. To get there the whole handling of the concept of parachutes needs to be abstracted out first, which may not be trivial, and then different parachute implimentations can be added. I am hesitant to start work on that at the moment as I do not use RealChutes myself. The other thought I have had about parachutes is a different solution to the problem of landing in hilly areas where the 'chute is fully deployed the AGL changes (passing over a cliff) and puts the landing off. The problem is that we can't take the terrain under the landing path into account because the terrain system is not thread-safe and the predictions need to run is a seperate thread so as not to cause a performance problem. I wondered if a fun solution would be to work with the ISA MapSat mod (if you are using it). So instead to getting terrain data from the game's own terrain system, MechJeb is able to access the terrain data that you gathered earlier by scanning the landing area. If you did not do the scan, or the data is incomplete, then your landing would be less accurate. The same principle could be used for other aspects of using AGL data in the landing system - if you have not done the scan then how can you know the height of the target location? Obviously you would impliment it so that it would only be this way for people using the MapSat mod. I would love to hear your thoughts on this idea. Anyhow I will be lurking around and if people get bugs related to the parachute targeting I will jump up to fix them, but otherwise I will be busy colonising Laythe by parachuting living modules directly into place on the surface

It will sometimes do a course correction in the atmosphere. There is nothing wrong with that - it helps it land closrer to the target. There are times when it becomes hard to control attitude (depending on the design of your craft) and as I have described above there is a point at which it will give up trying to course correct. With previous versions I have seen it get "stuck" in the course correction step, whereby it can not do the burn as it can't control attitude in the face of the drag, but is too off target to switch back to the deceleration burn step, however in the latest builds that should not happen (or at least certainly not if you have got a parachute on the craft). Sometimes burning +/-NRM is the right thing to do to correct the course - I am not sure why you are saying that is a problem. A lot has changed with the builds of the last few days. If you experience problems with those builds do please provide logs, craft files, save files, instructions for reproducing the problems etc etc. However it might be time for you to give it another go, and see if you can bring yourself to leave it turned on. I am not bothered if you use it or not, but don't go saying that it does not work if you are not even giving it a chance to do its thing.

If you can point me at the post I will take a look.

Could you explain what you mean by "unnecassery"? Are you suggesting that it would land acurately without a course correction? The way that it works in the current version is (perhaps a little simplified) as follows: 1) High deorbit burn (unless it is doing a low deorbit burn, but that is a different matter!) This involves waiting until it is a quater orbit away, and then both changing the plane (hence the quarter orbit away) and lowering the periapsis until it is 10% below sea level. 2) Then it performs a course correction which will stop once the predicted landing spot is <150m from target 3) Then it coasts towards a deceleration burn. If the predicted landing site is more than 600m from target it will got to step 2 and course correct again. 4) If there is an atmopshere, during both 2) and 3), once the atmospheric drag is >100mm/s2 the statistical analysis of the predictions starts to time the parachutes. This is significant because if the flight path does not pass over the target at this point then timing the parachutes can not move the landing spot laterally. However because it can correct for over/undershoot it is likely to bring the error down to less than 150m and therefore not course correct, and so not correct the lateral error. For this reason it might make sense to turn the autopilot off and on again before reaching step 4 (100m/s2 drag) to force a correction if the error is let's say 300m (and significantly if there is a lateral error.) 5) The parachutes will open at the time that the satisitical analysis say they should - once at least one parachute is deployed then course corrections are not allowed, as the parachute drag would prevent the craft having effective attitude control. The deceleration burn will fire if the speed exceeds the target speed defined by the breaking policy*. 6) When we reach the deceleration end altitude above the predicted landing point (where the deceleration end altitude is something to do with the distance covered to produce enough drag to cancel our current speed, or something - it is a bit complicated and I do not quite understand it, or for bodies with no atmospehere it is 500m) we then move to the final decent phase, which is esentially a free drop down to a suicide burn to hopefully touch down at your desired speed. 7) The landing legs will deploy at any stage once the AGL < 1000m That is pretty much how I understand it. So like I say I am not sure what you mean when you say a course correction is unneccasery. In the high atmosphere it is possbile and can result in a more precise landing. Once the drag gets too large then performing a course correction becomes difficult depending on the design of your craft, and once a parachute is deployed it becomes impossible.