TouhouTorpedo

So before I go too far with this idea to hear it may not be feasible, heres a snapshot of what I'm doing. No exterior walls yet but I know what I want to do for those. The interior was the real hard bit, so I got that out the way first.

Hmm, the interior is pretty critical to my idea but its real basic though. Pretty much just uses your built in textures throughout so far (though I'll add at least one of my own maps to it) I figured if we were gonna be able to spawn in some vehicles, might as well have something fun to drive around that fits the theme. I'll grab a screenie in a second.

Got photoshop reinstalled finally, took mashing up the registry and finding every little adobe reference (even flash player) to finally get it going but it is. So I'm in a position to get going again finally. I've changed focus, I was going to have a big main building, but I think a multistory car park has my biggest interest, so I'm gonna do that first. My HQ building I wanted to do I think I will simplify as it was going to be horrendous to finish and a bit over detailed. EDIT : Quick question Nothke, how confident are you with open buildings that can be entered and making that work in Unity?

Interesting. Are you into AOCS systems tchezick? Wasn't expecting to see such a complete reply. An interesting side note is that these Gravity Gradient torques are predictable and always approach to a stable point. (Aligning the highest Second Moment Inertia axis toward the planet) So they can themselves actually be a useful stabilising force, although alone aren't much good as they can't dampen, which magnetic torque rods are useful for doing. I was developing a satellite AOCS system for an earth observation satellite some time ago, If I remember right the final solution was that for the whole of the eclipse side of the orbit the spacecraft held a 45 degree roll, bleeding off the excess momentum. Although its a very small torque it adds up over a longer period of time. Apparently the ISS does the same thing as well!

Its fairly abandoned now. With the newer version of KSP I can't see the save being compatible, but then if I wanted I still have the older version with this on there I think. Or maybe I'll reboot it and start again? Not sure at the moment.

Plugins run in either Legacy or Gamedata. Theres only a few excepts to this for all mods, one of them being kOS. Even Multiwheels 0.6 plugin should run in either directory, but you need to remember to put the plugindata folder that was included there with it.

Very cool. I was thinking something like this would be good but I wouldn't have made an implementation that neat. I've not got the time to check your code unfortunately at the moment but I hope you get it sorted. This really expands the potential in challenges, since you can verify claims properly.

Multiwheels 0.4 and 0.5 have had the downloads closed. Only causes confusion so 0.6 is the only open download now. I could upload them elsewhere if needed but they won't be on Spaceport.

I'm a bit worried you could be falling into the same trap B9 did here. The rendering textures and dials all look lovely, but I can't see this being a useful IVA view with the eye level of the kerbals being below the bottom of the window rim. Personally, I don't see double clicking windows to get a better view as acceptable since you lose the benefit of the instruments. But otherwise you end up with the instruments and no view. So this could be an absolute nightmare to try and land. Its one of the reasons I don't use B9 anymore, I just couldn't stand the IVA's being so disapointing to fly with.

I think this fellow below is right: After some thought I beleive the issue is that "Vessel.Load" when set, even when set from a "vessel", sets the value for all objects of the "Vessel" type. Probably due to the value being a static, though I'm not entirely up on that part of programming. So change one, change them all. The only exception being that distancePackThreshold IS variable on a vessel to vessel basis. The best fix I can think of, is set Vessel.Load to the upper value (300km) in the OnStart variable, and distancePackThreshold be set on the specfic vessels constantly as is currently done. I'll give this a try sometime later, maybe tomorrow and see how it works out. Could be a thing for version 2. The maximum distance will always be whatever the module with the lowest defined Vessel.Load is. This seems to be why all of the units have to be ON when you do a flight - a nearby landed vessel with the module off can cause unloading. So in simple terms I have some ideas. Its still all a bit hacky but may do the trick on solving current issues. I love this idea. Not planning to record, but I think I definitely would like to give this a go now you mention it.

Neat. Never thought I'd see those wheels doing this kind of job. They've turned out really versatile them dual wheel pods.

I'm glad someone does, that's exactly what I put them there for!

Just noticed I hadn't put the link here. Link added.

My god. I hadn't realised this. Someone with Kethane get this, and edit the CFG to a rediculous range (1500km should do it for a 150km orbit), new save, enable on all vessels, sweep the planet. Edit : oh, so a nearby inactive vessel won't? well, worth a go anyway. Normally other non player vessels are too close to make a difference. You can now be pretty far from another.

So I've been playing with kOS and wondered, just how far could I take this if the vessels didn't unload? Then I figured it can't be that hard to stop unloading. And so here we are - TT NeverUnload. Allowing you with suitable mods to fly two vessels at massive distances appart! contrary to its name it doesn't NEVER unload, but it is definable in the CFG what distance unload will occur, and the default is massive (300km). Its fairly unlikely you'll need more but you can get more with a simple tweak if you ever need it. To use, just place it on whatever you don't want to disappear and right click in flight, then press Enable. on vessels with multiple neverunload modules, activate BOTH before seperation, else parts may unload anyway. You want pictures? Here have some of the included vessel (with kOS code, but obviously not kOS itself, included!) Detaching at 15km, the payload continues ascent alone. Giving you just enough fuel to reach the pad for spaceX manpatrick landing. EDIT: forgot I should probably make this clear: The payload DOES continue on and not unload of course! (if you followed the start procedure right that is) so heres looking back down on the KSC at the launch rocket. The payload flies almost all the way up by itself but the kOS computer does for some reason fail when coasting to apoapsis, perhaps a range issue for them. There is plenty of time to switch to and circularize however after landing. This is a first release of a game stretching mod, so it is pretty buggy but usable. For now don't use it on your main save, but its good fun. Download here! http://kerbalspaceprogram.com/tt-neverunload/ License for the mod is available in the readme.txt file included in the download.

Hey there, if you've not got that thrust vectoring on that lower ring down yet, I can drop my thoughts in on how I'd do it. Have the ring as a seperate object in the model, set up each arm to the ring as two objects in the model (piston, cylinder) the piston and cylinder models must have their longitudinal axis about the Z axis, pointing toward one another. and their origins at the attach points (a pain to set up from where you are, maybe easier to remake those actuator bits) When in Unity set up a ThrustTransform containing the ring model. Now place the pistons in place in the ring's heirarchy, and the cylinders under the main engine models heirarchy. Use LookAtFX from the wheel cfg's to force the rods to always look at each other by refering to the names of each object. If all goes well, the ring should be vectoring and the pistons and cylinders following it.

Quick bug report by the way, you need values in the running code to have some kind of catch for possible NaN values, such as MAXTHRUST. Although 0.00 comes out on print, it is running code with NaN values. This is what causes the weird glitches on the graphics if you do this, as KSP tends to go a bit mad when NaN happens.

So has anyone figured out the syntax for using things like vessel status or body yet? I keep running into the same wall here. I want to know if my vessel is landed, or more specifically, for my code to know. But I've tried everything I can think of and I can't access status. I've tried if status = landed if status == landed if status = "landed" if status:landed if landed I've got no ideas from here.

You'd do better I'd say to write a controller to get the set value spot on. I've done the same thing but I'm not even using TWR on the first version, just PID values that I've tuned by trail and error. while we're on the subject, whats the syntax for testing a string? I'm trying if BODY = "Kerbin" {set g to 9.81.}. if BODY == "Kerbin" {set g to 9.81.}. if BODY = Kerbin {set g to 9.81.}. no luck on any of those variants, they all throw expression error. edit again : do we have any mathematics code? like sine, cosine, that kind of thing? we've only got direction output available at the moment but I really need vector output for a target thing I'm doing. Also, translation control would be pretty awesome.

Just started fiddling with this. I'd say a wonderful addition would be copying the previous line typed by pressing "up". Pretty much every other console interface can do this, its frustrating when you have to retype after forgetting a full stop on the end. So files can be copied out of the Archive but can they be copied to it? Yes the can, I finally got it to work. Keep forgetting full stops all the time. (extra reason why lack of copy previous lines is frustrating!)

Certainly not impossible, but out of scope I'd say for me. That'd have to be a pretty massive update with KAS like or KAS augmenting features. Its not something I really want to be spending what precious modding time I have next week on

Yeah I won't blame you for replacing ModuleRCS. I've considered it before. Some very simple changes on their end to make it behave like engines on the resource usage would be brilliant, but unlikely to happen in the near future. Rather than going as far as a dummy transform I'd just rotating the Transform "Wheel" by the ammount you think is missing on the axis. Pull appart multiwheels source if you like for a look at that, but I'd say that's a much better solution less likely to break things. The bouncyness I believe is down to the ModuleLandingGear's graphical behavior being driven off of a physics raycast, rather than the WheelHit location. I can tell why they'd do it - physics raycast is accurate inside the same frame. WheelHit is a frame slow on position output (but just add on your vessel velocity * dtime and its fine) The problem is that physics raycast seems to hit a collider on some layer that vessels can't when going down the runway (but the physics raycast will hit them). Its probably something to do with how the runway clear check works. So basically, if you want to solve the bouncy graphics on the runway problem, don't use ModuleLandingGear. You're welcome to base your gear off my Modules if you like instead, but I can understand why you'd rather not since you're trying to stick to augmenting stock games here. You could use Stock Wheel Module with an animation module on top. Again check my source code if you like for doing your own animation module for the gear, if you want to do it that way.

MK3 Expansion everything has a different texture map, so no space saving there is possible. Sure Multiwheels could texture share, but I don't plan to do any update until either I've got any actual content to add (would like to do a recode of its basics to relate action to the control transform rather than the vessel). If you're desperate though, its not hard to adjust the CFG yourself to the new system.

Just seen your bug report on wheels rotating at the wrong rate ZRM. That's pretty much why I made my own plugin outright for wheels in the end rather than augumenting the ModuleLandingGear, aside from the weird bouncing issues it has a few meters down the runway. If you're making giant non-uniform textured wheels like I was, it looks really dumb. (whereas the fairly uniform stock gear wheels its pretty hard to notice)

I've heard that seats are actually being reworked for a future version of KSP now, so either starting this development in the first place (or moaning about them often enough) has had the desired effect. I don't know if they'll be in 0.22, but I beleive we're going to get the command seats we've wished for soon!