kellpossible

Just for reference, you do realise that 60m/s is 216km/h right? Pretty bloody fast for a rover! So is 40m/s = 144km/h and 20m/s = 72km/h. Totally agree with you on some parts here though, so many glitchy sections around KSC. Also the thing about the scenery boring at low speed, agreed, even with scattering terrain doesn't help very much. Some more fractal/procedural detail might help alleviate things here I guess. A lot of these are meant to be lightweight wheels for optimal delta-v during space transport so I guess they will always be a bit fragile compared to their earthbound counterparts.

Fair enough, and brave of you to show your designs here in this thread, knowing that there would be those who would criticise them. I hope you're still okay with this thread serving a secondary purpose of receiving feedback and through this allowing yourself or others to learn more about how the physics works in the game and in real life (and thus how to design better craft), which is clearly how many of the responders here are taking it. As pointed out before, sometimes parts placed on your craft will serve only once purpose. Science modules tend to be fairly useless when they aren't gathering science, and they make the craft heavier with less delta-v... Wings are pretty useless on SSTO's once they get into space. In fact why should an ssto need wings at all? Actually I guess it might be possible to design an ssto craft without wings if you didn't want to have them, just like it's possible to design a re-entry craft without stabilizing fins, but as always in KSP, design compromises must be made. From what I can see, you personally have a strong attachment to the part recovery mechanic in the game which has carried over across versions? Perhaps more so than a lot of us here, who I'm guessing, at least early on in our KSP designing careers with FAR or the new 1.0 aero, write it off as a lost cause, after observing real life space programs, make the observation that the holy grail of re-usable spacecraft is a huge design hurdle, not to be approached lightly. I think one of the beautiful things about KSP erring on the side of realism in this case is that those who have even a simple understanding of aerodynamics, like that of experimenting with paper planes, can take their knowledge gained through that experience and apply directly to the game. And vice versa, I like to think (and perhaps this is somewhat misguided, but given I'm studying engineering, all the reading I've been doing lately on the topics inspired by KSP seems to confirm that idea.) that after playing a decent amount of KSP I should have a better chance at designing my own aircraft or rocket in real life. From my point of view, (and I'm not saying yours is "wrong" or anything), you're suggesting that it would be better for the game to allow paper planes to fly nicely backwards when thrown, when all real life experience seems to suggest otherwise, it would be equally frustrating for those who have experience with making paper planes as it would be for you if it wasn't this way. I'd also suggest that you'd be finding the process of making paper planes just as frustrating if you applied the same principals.

I've got pretty much exactly the same problem on mine using linux. Could it have something to do with the path case sensitivity? Windows doesn't have case sensitivity on the file paths, so you can get away with having a mistake in the file path. Top left is the home screen, with same problem. All the sub pages of the FLT section work, but nothing else does. Hope that helps somewhat with solving the problem?

Hey SimplySimon, I see you added my radial part, I hope it suits ok. I'm on holidays now so I'll have to finish the texture off for that I guess!

Hi there JDP, I created a patch from your github project to enable support of ProgCom CPU emulator for KSP I submitted it as an issue on github. Really love using this plugin, good work! Did notice while creating this patch that it was hard, and a little messy, some things could do with re factoring. It seems as though RemoteTech wasn't really designed from the ground up, but rather grew organically. While this did make changing things and understanding the code a little tricky, I totally respect where this has come from, and what it is! Would love to help on it at some stage

GitHub is pretty much the standard around here as far as I can tell for sharing sourcecode. (Also, we can see what people have been up to in the changelog). I would recommend creating a github repository for this project. You can then have a folder in there for community examples for us to share our code as well. Feel free to chuck my model and textures up there too, I'll finish the the texture tonight. I've also just did a patch to https://github.com/JDPKSP/RemoteTech to enable ProgCom to work in conjunction with remotetech. Probably need to submit this to the original author sometime to get it included. It's a little bit of a hack, but as far as I can tell, most of remotetech grew organically, so everything in there is a bit of hack But hey it works, and now can program probes that continue to function after losing radio contact I'd be happy to make some more models for that. Well that does sound like good news! How would other plugins do this? Would they have to reference ProgCom's dll? Or would it be purely parts/config based?

Well, one could implement memory mapped i2c or spi registers. Then each sensor device would be representing an i2c or spi device which can communicate with the cpu via one of those protocols. spi is simpler, but i2c would not need any extra registers per sensor or device. But you are right, this would definitely raise the bar for beginners. Although, one could probably implement a library on top of a lower level serial protocol to make it simple for beginners... I've spent a good chunk of today sifting through the complicated tangle of remotetech's gui code and learning about unity programming along the way, so hopefully when I've gotten this to work I could move on working exciting stuff like this 3d modelling and texturing is soooo much more relaxing than coding unfortunately. I've got the feeling you are correct about the mechjeb stuff. If we can get enough sensors and input from ksp, it should be possible to port a lot of the autopilot functionality to this ProgCom as an autopilot library or something like that.

Ok, so looks like remotetech only gives control to itself, and to mechjeb (when the probe is in range). So I'll make a few changes, and add support for ProgCom as a source of control, and perhaps provide a list or something to switch between the available control sources... I was also thinking, perhaps it might be worth making some sensor modules while I'm at it. like radar altimeter, bumper sensors, laser distance sensors, etc. Then perhaps progcom could adjust the available hardware for polling based on which hardware is part of the ship in the vab. EDIT: and what would be really cool would be support for mechjeb! if this cpu could manipulate mechjeb (if it is attached to the ship) and use that as its control system instead of its own that would be fantastic, then get all the functions for auto landing, orbit transfers, docking, the whole shebang. That's probably a bit of a dream... but hey mechjeb is open source, so it should be possible to make the changes. I'll see if I can get remotetech to work first

although, come to think of it, a cpu like this would be great on remote probes, so maybe I should make a miniature version. I haven't tried out remote tech with this mod yet because I switched to 0.20, just wondering does it work to control the ship even when the probe is out of range in remote tech? If it does I guess this would make it possible to write landing software for when the probe/lander is on missions which usually have a 10 minute communication latency with remote tech, thus making landings impossible without some form of local control like this for instance . If this requires some work on remote tech I've got the remote tech source code with me, so I could give it a crack some time.

Well it's taken me several hours, and I've still got to finish the texturing (got ambient occlusion set up as a base texture, just need to add some texture/colour and add some ProgCom text on there ) Also, I don't have unity, so at the moment the model is imported as DAE, which unfortunately I think means there is no context menu for it, and also it doesn't highlight when selected and go transperent when detached from the rest of the craft. These are bugs with KSP, I guess I need to report them at some stage if they haven't already been reported. I guess more permanent fix when the model is finished is to chuck it into unity and export it as a unity model. Here's the zip with the part file, and source files in it: IC.zip I'm releasing it with Creative Commons by-sa license So, SimplySimon, I hope you like it, let me know if you think it's ok, or if something will need to change... I made it a bigger part because: don't have to worry about it sinking into things and disapearing. and also because a cpu is a pretty powerful feature to have therefore I figure it should be a bigger part to make the user think twice before placing it on a tiny ship. (in the same spirit as other ksp parts like asas)

How about something like this for the model?