Gaalidas

Alright, so I decided to give this a try. I am so new to blender that I could probably accidentally blow up the planet before I actually created anything with this thing. That being said, I followed the instructions and was greeted with (upon the first "run script" stage) an error that the script had failed. It says to look at the console for more information, but I can see no console anywhere. Fail?

The only thing I see out of place is that "intakesize" should be (notice the case) "intakeSize" if these sorts of thing are case sensitive, which I like to think they are. At least, in the code I know they are unless the redundant definitions have been... uhh... defined. I'm also not sure if that module adds anything that you could actually notice to the part, but I've never tried using them before. Beyond that, nothing seems out of place. UPDATE: So, I did some code diving and discovered a few other things about that module. It might be having trouble if a transform named "intake_transform" is present, or another transform defined using the parameter "intakeMeshName = your_transform_name" where the transform name is the one used for that part's intake, if it has one. I won't begin to understand why that's needed, but it is defined in the module code so it must be important.

That was EPIC. wow... - - - Updated - - - No... don't go there.... ugh! - - - Updated - - - The values I entered were limited purely based on what was considered "usable" when taking into consideration the originally intended use for the part. For instance, you could scale the mole tracks and make them usable as a snowmobile, but that would start to border the ridiculous considering what they were made for. Still, no one will fault you for tweaking your local copy for the results you want. Just don't go making too many changes to the default. I intend to update my TweakScale implementation in the near future to implement things such as scale-based RPM limits and such. I'm still testing... with some hilariously over/under powered results. My goal is to reduce those moments where you scale down a wheel a ton and find out the wheel is still powerful enough to flip your rover when you try to move. I'm messing around with the torque curves and a tweakscale exponent for the RPM limiter to get the right feel. For the hypnodrive (screw drive) what we really need is not the standard omnidirectional scale factor, but rather a way to procedurally change its shape so that we can stretch it lengthwise, thus providing a longer stable surface for the craft to rest on. This is something for the far future, however, along with the near impossibility of procedurally generated tracks. However, I doubt that differently-shaped and sized screws as additional parts would be too difficult. I'm not a modeler, so I have no clue what goes into that.

Every once in a while something like this pops up that many of us didn't even know we needed. And now... we need it.

In the past we've all come to this point and then, suddenly, he comes back with news that is less than promising, but any news is good still. However, it does look like we'll never be seeing this stuff. I really wish he'd put up a download for what he's got and let the community try and polish it further. Some people just hold on to their projects a little more than others and only release when it's perfect. I sorta wish he'd kept quiet about it so I didn't have to wait for it. Not knowing it exists would be better than having images and video of what looks like a complete part and not having anything to play with.

I'm afraid that, unless we experience a grand new miracle, this mod won't be seeing an update. I continue to look over the code from time to time, as I learn more and more about C# and its inner workings, but this is not just a problem with a KSP mod. This one makes use of some funky DirectX stuff that complicates things further. in the end, you'll just have to take a hard look at the parts in your "mooooorr mods" and make some hard decisions. I've had to cull my B9 parts down to the ones I use the most and remove the ones that aren't used by me or any downloaded craft files (at least, the ones I decided to keep). I also had to take another look at any stock textures (squad folder) that had not been resized yet and do some quality-reduction passes. You don't need a huge texture, no matter how detailed, for a part that, for the majority of the time, is packed away into a 3x3 pixel screen-space. Until we get a stable KSP experience with full use of the maximum ram available on the host system, we will have to continue making these decisions. Even with DXT and LOD there are memory limits.

Also note that procedural parts has been the cause of many incompatibility problems in countless other mods. It may not be something fixable on this end. Just something to keep in mind. Like an argument, incompatibility is a two-way problem.

Y'know, this "hanging" business reminds me of an odd behavior I've discovered when my computer has been running a long time without a reboot. KSP will load, but each and every file will take 10x the time to load. I haven't read all the discussion, but at the top of this page, in a quote, I read something that sounded like this. Make sure your problem isn't due to a computer that isn't getting its beauty rest.

Definitely not the intended use of those wings. How's the ride?

In the case of the laden swallow that met an untimely end there... is it really dead, or is it only pining?

I have absolutely no clue what you are referring to there, but sure I'll go with that.

No worries. We ignore the original warp drive for perfectly valid reasons that we spend minutes preaching to ourselves in the mirror every morning. Some of those reasons might even stand up to the scrutiny of others. Rest assured, however, that our acts of ignoring are for all the right reasons. The dancing midget told me to say this. Always do what the dancing midget tells you to do... ho knows how to disturb you... always watching... always listening.... always dancing.... What was I talking about again? Huh, oh well. Probably not very important anyway.

That is awesome. Staged horizontal takeoff. That's got to be a rare occurrence. I always wondered about such a system to help oversized crafts get off the ground. Unfortunately that would only be usable once. What is really needed is a complete platform that could be brought up to speed and then eject the plane into the air, self-stopped and then return back to the beginning of the runway. Upon landing, you would have to align yourself to touch down right back on top of the vehicle which would then match your speed and latch on, then slowly bring you to a stop. We need those non-docking tie-downs for that I think, especially in-flight re-tying and ejecting. Can you imagine the outtakes for trying to create such a system, not to mention the need to re-create a flight-synchronization mod and an autonomous smart autopilot? It gives me a headache just thinking about out. Maybe it would be easier to try to implement a catapult takeoff assistance system into the stock runway. It'd bring to life a dream of launching a jumbo jet from an aircraft carrier. - - - Updated - - - Yeah, that's the same issue I was having with the hitch parts. In the editor the arrows are awesome, but outside of that they sorta loose their appeal. - - - Updated - - - It probably wouldn't be too hard to make it tweakable in the editor of course... might be worth looking at someday.

Potentially, yes. That's why this is kind of a dangerous project. If, however, small-worlds became stable enough, this could mean the beginning of being able to add large-scale asteroids (beyond Class-E) that have their own very tiny gravity fields and (like planets in this game) are not moveable by the player's crafts. It could be similar to some of the really huge asteroids in our own system's asteroid belt which are large enough to actually pull at the orbits of other smaller rocks moving past them. In the future, we might even be able to simulate a planetary formation (the impact and compress era of a planet's early stages) with a small planet being orbited by dozens of small potato-roids. Exciting stuff there. The sketches remind me of my early years watching the animated films "The Little Prince" in which the planet's inhabitant could run the entirety of his planet in less than a minute without even breaking a sweat. Of course, the illusion breaks down when you take into account that the gravity produced by that planet would have had to be so incredibly tiny that the little prince would have tripped on a rock and ended up in a stable orbit with no way of getting down, even though he'd be only 10 feet off the ground. The atmospheric range of this planet would probably have been, roughly, 10 centimeters. Unless... it was incredibly dense... yeah, that's gotta be it. the planet was so dense in the center that it produced the same odd gravitational pull that you get on Kerbin, which is way too small to produce the gravitational pull that is normally produced by planets the size and density of Earth. You totally lost me on the B612 reference though.

No problem. Also, I noticed last night, when expanding my addon to add a config-level setting, that is did not actually quote my code accurately in the last post. However, I think it will be easier to let you just start typing it in and your favorite dev program should suggest the correct methods. By adding to the "if" check a check against a public bool I called "disableInEditor" (defaults to false) I managed to make it into a configuration option in the module. It's incredibly easy to add these kinds of options to modules that, when looked at in the code, are surprisingly simple considering what they do in-game. I do hope, however, that your WIP code is more up-to-date than the stuff in github. I had to do some creative things to some of the other source files to make the thing even compile. I'm not even sure what I did in a few of those cases, as I was just letting SharpDevelop do the work for me. - - - Updated - - - Input into games from a modding point of view has been a real bugger for many years now. I remember when I was too new to anything coding related to even wrap my midn around the scripting system in Morrowind, and back then we basically had to create a GUI keyboard that was very slow because of a standard "heartbeat" delay to the script execution system. what we really need is something for RPM that will temporarily lock all keyboard input (and perhaps lock your camera to the specific terminal while doing so, though I have no clue on this one) and relay it to the input in a specific terminal. I already know that locking input to the game is possible while still allowing GUI access with a mod I installed a while back (forgot its name, oops) but for relaying the keyboard input to the console afterwards... the only idea I have is somehow setting up every key on a standard keyboard as a hotkey that, when the conditions of the game-action lock and the focus on the terminal are set, output their corresponding key designation. However, one idea comes to mind which might help figure this out. We already know how to lock game-action input when a text-field in a mod's GUI is active. Perhaps we can find a way to spawn a GUI-based text-input field when a specific RPM cockpit button is pressed. It's not ideally immersive, but it might be a good stepping stone. Somehow (I'm not sure why or how) this all leads me to mention an idea I've had for some time. It's kind of like a reverse RPM monitor thing. The idea behind RPM was to put the console monitor into the cockpit, but there are times I find myself wishing I could undock the monitor from the cockpit and take it with me into other camera views. This is something I have missed since starting to run KSP after a year or so flying in the Orbiter Flight Simulator. It's the external MFD. I'm wondering how hard it would be to basically take the RPM system, with all of it's side buttons and stuff, and put it into a GUI window so that you could display a complete RPM screen separated from the physical scene. Now that I'm becoming more familiar with the RPM code, I may start looking into that myself... but I am horribly uneducated in the ways of C# and I'm really just a fiddler when it comes to KSP modding. UPDATE: I meant to mention this, but I thought that someone had already tried to make a few steps in integrating RPM with kOS. It might be Aa feature in the ALCOR pod. all I remember is a kOS folder in the RPM pages that comes with the pod, but as I am not a kOS user (yet...) I just removed it. It may just be a re-state of whatever is already in the standard input for kOS, but it would be a start.

Alright, I just did something that... quite honestly... I amaze myself with. I had one problem with the transparent pods. In the editor, everything became very unstable whenever one of those pods were active. after a few days of exploring the source, I discovered that if I added a single check to the starting function of that file (basically an "if (highlolic.issceneineditor) return;") and recompiled, I could get a transparency enabled pod opaque in the editor, but fully functional anywhere else. With a little more work, that could be made into an option someone could toggle on and off in the part configuration for that pod. Just something the current maintainer might think about implementing. From my tests, it appears to be perfectly stable.

It's been reworked several times since I first started wandering around these forums, and that was over a year ago. I didn't actually join the forums until a later date.

It's fair to say that with an extreme number of these wheels/tracks/whatever you'd get some slowdown compared to stock. There's a lot more happening with these than anyone could have expected for something as simple as a wheel. I really doubt anyone has tried to see just how many wheels it would take before KSP chocked on them. Kinda makes me want to go make something that stretches down half the runway with wheels set as thick as they go and see what happens, but with the time it takes KSP to load up that sort of test could be painful simply in time spent waiting. - - - Updated - - - Most likely there's something you're doing wrong... Oh, you meant in relation to the skids? Right... actually, I haven't even used the skids before. If this is related to suspension though, it could have something to do with a lack of a surface in which the part can relate to, thus causing it to just lock at whatever suspension level it was at when it lost contact. Similar to if you roll your rover on its back (with no chance of recovery) and had some wheels at different heights. The wheels, at this point, won't simply retract fully (thus following gravity) but will instead often just become stuck at whatever level they were at when they lost the reference point with the ground. Perhaps we need to look into a default settings for the wheels to return to if the ground/surface reference is lost.

That's some crazy stuff. I like it. I can imagine several tests of this thing causing you to nearly turn blue from holding your breath.

Than you use that custom shader loader mod to give it that warped space look and it's all good. That is, until your ship smacks into its invisible surface and goes splat.

Did you ever play the original games in that series? I remember when we had only the demo (yeah, those were the good days. We actually got demos of games, and they really worked too... sometimes) and thought we'd found a piece of heaven. I convinced the administrator of the school computer lab that Homeworld was both uplifting, team-building, and positively competitive and that we needed it on every PC in that lab (besides, we could skip math class and have epic battles, 8-sided sometimes.) I don't know what all has been changed about it, but I assume they simply did what modders have been trying to do all along and upgraded all the visuals. I do remember that if you can run it with OpenGL, many of the effects (like engine trails, which I never liked really) end up looking a TON better. It remains to be seen if that will still be the case with this version. - - - Updated - - - It never did crash the save, it was more a crash in the loading process (especially with ATM installed). - - - Updated - - - Yeah, if you read the earlier pages of this thread you'll find a bunch of people from the original group are all dev users now. I suppose we got roped in by being just annoying enough, but also entertaining enough, to wiggle into lo-fi's confidence. We don't even bother to download the releases.

I attempted to dock with a ranger today. I just resized the textures to insanely low resolution so I could load it up (that's what I get for playing KSP on a non-gaming laptop) and i gotta hand it to you guys. You made mechjeb go completely insane. I mean completely nuts! I had to crash KSP to even exit. You might think this is a complain... the exact opposite is true actually. It was quite entertaining and had me quite frantic to try and regain control. I never did, though.

It's not exactly the easiest thing to figure out. Neither of the related parts have very helpful descriptions and they show up under different editor categories it looks like. In other news, I've been working on a way to scale the maximum rpm settings with the tweakscale setting, and work continues on making the dust effects more natural looking, and I've begun attempting to re-add some of the impact sound effects for the wheels that will function correctly with the KF parts, which lack the standard wheel module that the CollisionFX was looking for. I have yet to hear any sounds, but that's really because I've got my speakers muted while I am simply looking at the debug window to make sure it doesn't freak out at me. So far so good.

Wow... this thread died down rather abruptly. I'll break the silence. I've been wanting to play with the hitch, but I'm afraid I just can't make it past the fact that the arrows stick around even after the craft is launched. It bugs me.

a toggle for a cockpit light would be awesome, as we see in several other RPM cockpits. External window lights are only really awesome when they actually light up the surfaces nearby. Hey, idea... the endurance itself could use some illumination, and I mean surface spotlights, beacons... ooohh... I gotta load up KSP now and do some experimenting! There goes my homework session. Oh well.