[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[Mekan1k]

Is there, at least, a version of this that works with 1.04?

[Cyrious]

Greetlings lo-fi and thanks for the awesome wheel mod.

I however am currently looking for a hitch mod that would allow the main rover to grab the one behind it and tow it without docking to it. KAS winches and plates are too weak for the rover sizes and masses I use (>30m long, upwards of 400T loaded), and if used on smaller rover chains result in alot of whiplash. KAS pipes and standard docking ports dock the vessels together and dont allow the freedom needed (pitch, yaw, and roll). Then I stumbled across your youtube vids of the WIP magnetic trailer hitch, and I gotta ask: when will it be ready?

[lo-fi]

Is there, at least, a version of this that works with 1.04?

I wasn't aware it didn't?

Greetlings lo-fi and thanks for the awesome wheel mod.

I however am currently looking for a hitch mod that would allow the main rover to grab the one behind it and tow it without docking to it. KAS winches and plates are too weak for the rover sizes and masses I use (>30m long, upwards of 400T loaded), and if used on smaller rover chains result in alot of whiplash. KAS pipes and standard docking ports dock the vessels together and dont allow the freedom needed (pitch, yaw, and roll). Then I stumbled across your youtube vids of the WIP magnetic trailer hitch, and I gotta ask: when will it be ready?

The hitch, as it is, hit a major stumbling block with persistence and time warp that I never got to the bottom of, so I've left it as a proof of concept consigned to the "nice try" bin, I'm afraid apologies for the teaser!

[Cyrious]

Any idea in particular as to what the issues were? I may not be a modder but perhaps I could assist in getting it working.

[lo-fi]

KSP treats the tractor and trailer as two separate vessels as it should. In normal physics time, this is fine be able they're joined by a physics joint; albeit one that KSP knows nothing about. In time acceleration, the flight integrator merrily does it's thing and interpolates their orbits/trajectories - which will always be different - with physics paused so the joint is ineffective, and herein lies the problem. Similarly, save / load messes up the precise relative locations, so re-hitching is hit and miss at best. It is, sadly, something KSP was not designed to handle, and I'm trying to fight something that lies at its very core. That's not to mention all the many other little niggles that need sorting to take it from POC to something releasable.

Unless you've got a fairly deep knowledge of how these things work, progress is unlikely. It may look simple; it really isn't. I've got a lot to get ready for the next release - which I'm quite aware has been a long time coming - so no time to put into it I'm afraid.

[Madrias]

Lo-Fi, regarding the hitch, perhaps instead of having one that has two individual pieces, could we get one that makes a one-piece unit that we can toggle center lock on and stick a docking port to? Perhaps a more inelegant solution, but one that would work, I think. Basically have an action group that somehow centers the ball-and-socket hitch so that someone could back up and dock to a trailer hitch point, and when used a second time would unlock the hitch lock so that it can swivel in all directions.

It'd solve the persistence and time warp issues by being essentially one part with a reasonably-large freedom of movement (kinda like the claw), while allowing someone to simply strap a docking port on it (for those of us planning on multiple trailers) or to just hard-point two vehicles together in the assembly stage (somewhat like a crew vehicle with science bay and attached trailer full of science/comms gear, along with power generation equipment. Making one vehicle with a center pivot for controlling it while either driving across hills or rough terrain without beaching the belly pan or hanging wheels way over the edges of whatever you've driven over.)

[*Aqua*]

You didn't understand. Timewarping can let the trailer and tractor drift several meters apart. The moment physics kick in again the hitch will disintegrate. Or the whole vessel.

It's exactly the same problem which sometimes rips ground bases apart. They can drift into the ground when timewarping and are violently pushed into the air when going out of timewarp again.

It's an inherent problem of how KSP tracks objects and calculates a vessel position and it's the source for a lot of Krakens.

[smjjames]

I wonder if Unity 5 will make that hitching thing easier? One can hope I guess.

[lo-fi]

You didn't understand. Timewarping can let the trailer and tractor drift several meters apart. The moment physics kick in again the hitch will disintegrate. Or the whole vessel.

It's exactly the same problem which sometimes rips ground bases apart. They can drift into the ground when timewarping and are violently pushed into the air when going out of timewarp again.

It's an inherent problem of how KSP tracks objects and calculates a vessel position and it's the source for a lot of Krakens.

Nail | head

I wonder if Unity 5 will make that hitching thing easier? One can hope I guess.

Groundless hope and boundless optimism will get you a long way in life... but not with KSP's flight integrator

Other types of parts may be far more feasible, Madrias. You want to make something like the Bofors BV206 or articulated dump truck, don't you.

[Cyrious]

Well, could a flexible but lockable ball joint part similar to a Claw that could be used in the VAB or SPH to link 2 segments together as one vessel work? It would be considered one vessel (one center of mass, one active control part), but allow the 2 segments that the part is holding together 3 axis freedom of movement. Going into timewarp or saving automatically locks the joint, which then unlocks after returning to the vessel or coming out of warp.

The problem I see stemming with the initial mag-hitch is the fact KSP has weird code when it comes to rover and base persistence and physics. Anything made of more than one vessel that isnt in orbit acts wonky as hell when physics turns back on. The idea of the joint part is to make a single vessel from the start.

Other types of parts may be far more feasible, Madrias. You want to make something like the Bofors BV206 or articulated dump truck, don't you.

Something like that essentially. The ability to link rovers together isnt quite as important (to me at least) as the ability to let rover chunks move freely.

[lo-fi]

I'm afraid that just isn't how it works. You'll notice in the videos, vehicles were hitched in flight. If they're one vessel when launched, you get solid joints. End of story. You're describing IR with the joint spring set low. So I guess, happy days with a config bash!

[Cyrious]

Damn, it was worth a try.

Another question I have though: Would it be possible to give the repulsors "side drag" as a tweakable?

Heres what I mean by it. Repulsors as they function now are omni-directional. No matter what direction or orientation they're sent in, they will continue on until drag or something else changes it. What I propose is that when the side drag is turned on, when the vehicle is moving forwards or backwards along the long axis, there's no drag as usual. But when the vehicle changes orientation, the repulsors instead change the vehicle's direction. So if I turn 20 degrees to the right and hold it, my ground track will curve to match my new direction instead of keeping going in the same direction.

The strength of this correction could be tweaked as well, from very weak (turns are very drifty) to very strong (turns are very tight).

The direction of the drag could also be a tweakable, allowing for variations in part placement and ship design.

[lo-fi]

Sounds like a job for another part really, otherwise you're doing lots of crazy things like working out which orientation/position they're in. And really, you're asking for invisible wheels with no motor and not a lot of lateral grip

[Cyrious]

T_T

But i wanna make a functional podracer damnit! Cant exactly do that with your repulsors because of how drifty they are.

And orientation of the drag zones could be as simple as making them parallel to the line drawn between the center of mass, the root part, and a cockpit/probe core.

Eh, no biggie, I'll just have to make do with what I got.

[Darren9]

^ You can let the "chunks move freely" with a KAS winch Cyrious, if you winch it in to 0.01m it has more or less the properties of the hitch but a single craft. I've been caravan racing and had real pod racers, since the aero update though they really aren't as effective as they used to be.

[Gaalidas]

Alright, I've reached the end of my sanity with this GUI stuff. I have everything configured identical to another mod that I know works without any issues, but when used in the exact same way here I am presented with null exceptions spammed to the log. There's absolutely no difference in how I'm calling anything, but the result is completely different. We're just going to have to live with no in-game configuration for the time being. Lots of mods have global toggles that are only modifiable in their configs, so it shouldn't be a real problem overall. I've simply had enough of this complete bovine excrement of a GUI system where 15 mods can define the controls, the style, and the way of activating it in completely different ways that all work perfectly fine in their mod, and have no trouble using an "OnGUI()" method to tie them all together but, when I try to use it, failure ensues. Heck, there's no error being produced from the part of the code which is supposed to even add the stupid button to the launcher, and still I get no icon in the launcher even! I've even tried copying over a complete GUI system from another mod (disabling the incompatible variables and such of course, since KF won't have them) and it still fails. I simply cannot waste my time with something that I am doomed to fail at over and over!

[lo-fi]

Are you tempted to enter Lita's challenge posted a few days back, Darren?

- - - Updated - - -

Alright, I've reached the end of my sanity with this GUI stuff. I have everything configured identical to another mod that I know works without any issues, but when used in the exact same way here I am presented with null exceptions spammed to the log. There's absolutely no difference in how I'm calling anything, but the result is completely different. We're just going to have to live with no in-game configuration for the time being. Lots of mods have global toggles that are only modifiable in their configs, so it shouldn't be a real problem overall. I've simply had enough of this complete bovine excrement of a GUI system where 15 mods can define the controls, the style, and the way of activating it in completely different ways that all work perfectly fine in their mod, and have no trouble using an "OnGUI()" method to tie them all together but, when I try to use it, failure ensues. Heck, there's no error being produced from the part of the code which is supposed to even add the stupid button to the launcher, and still I get no icon in the launcher even! I've even tried copying over a complete GUI system from another mod (disabling the incompatible variables and such of course, since KF won't have them) and it still fails. I simply cannot waste my time with something that I am doomed to fail at over and over!

Woah, sorry you're struggling! Push what you have to Git and I'll take a quick look to see if I can spot what's going wrong. I know what it's like when you're stuck staring at something that doesn't work; it's painful!

[Gaalidas]

Alright, I'll put it up. On the plus side, the config loader works even in the different way I've done it, and might be capable of saving the information back without issue if we could ever get it to toggle in-game. The GUI stuff is kinda messy right now since I've been commenting out broken stuff and adding in new stuff that I've seen working in other mods. If this doesn't pan out, then we'll have to comment out anything having to do with the GUI before moving on, since it spams NullRefs constantly right now.

To test, you'll need the two icons I made which I'm gonna put into the Assets folder in the non-source repo as well.

[Darren9]

I already collected up the mods and had the pod-racer built for it Lo-fi, then launched with it for the first time in the new aero and it all went bad They only work by enough drag at the rear to keep the ropes reasonably tight - I think it'll need about a hundred air-brakes. All this more realistic stuff, just not helpful when you're making sci-fi nonsense

[Gaalidas]

Someone needs to build a mod that will allow you to define certain marked parts to use a simpler aero calculation to allow for the creation of sci-fi nonsense while still enabling other parts and crafts to behave realistically. That could be a real pain to code.

- - - Updated - - -

Is there, at least, a version of this that works with 1.04?

It'll all work, except for the TweakScale stuff... which won't work very well until everything gets updated for this mod. Complain to the TweakScale devs for not keeping legacy support for the old scaletype configs. The new scaletype configs I made are tweaked for the new code we've been working on for the parts and simply won't work right with the old parts.

EDIT: I just looked at my last log from my last failed attempt on the GUI, and for some reason it thinks I'm trying to call a GUI element from outside of the OnGUI method, which means it's not even loading the settings from the config file now, so that's broken too now.

Edited July 12, 2015 by Gaalidas

[*Aqua*]

Afaik the GUI system runs in a different thread so you just can't simply access variables of another thread (like the main loop the MonoBehavior runs in). It can be quite a pain to pass data between threads.

One of the easiest (but not best) way to transfer data is to put them into static variables. But be really really careful with that! If two parts of a program modifies the same variable at the same time the result will be unpredictable.

In C# you usually use data binding for syncing data between GUI and database but IMO that stuff is very difficult to implement. I tried for weeks to understand that but still can't get it right.

[Gaalidas]

Well, as far as loading the settings and accessing them, I can revert my changes pretty easily and get it working. As far as modification goes, as long as we make sure that the other modules are updating their local instances of that variable from the config manager, then everything will stay in sync. The variables in the config manager were never meant to be updated from the outside modules. if we needed to update a global variable from another module, I'd likely have the config manager periodically check for changes in a separate variable in the module we needed to update from and simply set the value to be equal to that. In this way, the variables being loaded for global access are only being set from within the class that they are managed from.

However, I don't see any situations where an outside module would ever need to change the value of one of these global variables we've set up. The modules should be using local variables which are set from the global variables first. We don't need to persist data from the flight scene backwards into the editors, so it's pretty easy to keep track of what is setting what value and keep collisions from happening between saved data.

I'm starting to feel like I'm typing in circles and making little sense... but it makes sense in my head.

I do remember data binding from my ASP.NET class last quarter. It actually isn't all that complicated, but in ASP you have prefabricated methods for handling all of that, and prefabricated controls for the web-GUI which are already configured to receive the data. You also have access to the database structure from the beginning so you can predict how the code will interact with it. In KSP, we know there's a database of stuff in there somewhere, and we have methods to access it, but we really don't know exactly what it looks like or how it's structured until we start asking for information and it starts telling us to "stuff it where the sun don't shine."

Edited July 13, 2015 by Gaalidas

[lo-fi]

I already collected up the mods and had the pod-racer built for it Lo-fi, then launched with it for the first time in the new aero and it all went bad They only work by enough drag at the rear to keep the ropes reasonably tight - I think it'll need about a hundred air-brakes. All this more realistic stuff, just not helpful when you're making sci-fi nonsense

Hmm. Have a look at the custom drag cube thread, I think it was NathanKell posted. You might be able to make a winglet or something with high drag quite easily.

I'll take a peek at the gui stuff.

[Gaalidas]

Take a peek, but I wouldn't spend a lot of time trying to figure it out. We can revert a few changes back so that we can use the config loader again like before and shelf the GUI for a later release. I just wanted to see if it would be possible. The priority is getting the rest of the parts rewritten for the new module rewrites and completing the dust stuff. On that note, we need to re-add the biome color definitions for when the global variable that enables the camera sampler is turned off, which should also be automatically set to "false" internally if the dust is disabled. In fact, if the dust is turned off globally, there shouldn't be any cameras, dust definitions, or any other effects defined during flight at all ideally.

That said, I'd like to look into scrapping the MM patch to apply the module and instead simply predefine the module in the part configs that we have.

[lo-fi]

I'm always in favour of scrapping MM patches "Hey, you could write an MM patch for that!". Wait. What?? Or you could, you know, put it in the config... It is useful for stuff where there are dependebcies, options or you want to add something to all parts, but it's a widely abused tool IMO. It will no doubt still be needed to remove the collisionfx for the KF parts, though. Although I could maybe just remove that in code anyway and ditch the whole thing, which is quite appealing.

I'll run you through my diagnostic steps on the GUI stuff:

The first problem I can see is in Start()

ArgumentException: You can only call GUI functions from inside OnGUI.
  at UnityEngine.GUIUtility.CheckOnGUI () [0x00000] in <filename unknown>:0 


  at UnityEngine.GUI.get_skin () [0x00000] in <filename unknown>:0 


  at UnityEngine.GUI.Window (Int32 id, Rect clientRect, UnityEngine.WindowFunction func, System.String text) [0x00000] in <filename unknown>:0 


  at KerbalFoundries.KFConfigManager.InitGUIElements () [0x00000] in <filename unknown>:0 


  at KerbalFoundries.KFConfigManager.Start () [0x00000] in <filename unknown>:0 

And it's actually telling you that there's an issue with InitGUIElements() within Start(). So let's look there and add some debugging stuff. settingsRect = GUI.Window(GUI_ID, settingsRect, KFGUI, string.Empty); sticks out at me as having potential for causing the problem, so let's add some debugging lines:

		void InitGUIElements()
		{

			centerLabel = new GUIStyle();

			centerLabel.alignment = TextAnchor.UpperCenter;

			centerLabel.normal.textColor = Color.white;

			//leftLabel = new GUIStyle();
			//leftLabel.alignment = TextAnchor.UpperLeft;
			//leftLabel.normal.textColor = Color.white;

			appTextureGrey = GameDatabase.Instance.GetTexture(string.Format("{0}/{1}", strIconBasePath, strIconGrey), false);
            print("googleflungle");
			appTextureColor = GameDatabase.Instance.GetTexture(string.Format("{0}/{1}", strIconBasePath, strIconColor), false);
            print("kadooglafla");
			GameEvents.onGUIApplicationLauncherReady.Add(SetupAppButton);
            print("abrakadabra");
			settingsRect = GUI.Window(GUI_ID, settingsRect, KFGUI, string.Empty);
            print("nomnomklakture");
		}

In the log, we get:

PartIconFixer, PartIconFixer v1.2.0.0 starting

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


googleflungle

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


kadooglafla

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


abrakadabra

(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)


ArgumentException: You can only call GUI functions from inside OnGUI.
  at UnityEngine.GUIUtility.CheckOnGUI () [0x00000] in <filename unknown>:0 


  at UnityEngine.GUI.get_skin () [0x00000] in <filename unknown>:0 


  at UnityEngine.GUI.Window (Int32 id, Rect clientRect, UnityEngine.WindowFunction func, System.String text) [0x00000] in <filename unknown>:0 


  at KerbalFoundries.KFConfigManager.InitGUIElements () [0x00000] in <filename unknown>:0 


  at KerbalFoundries.KFConfigManager.Start () [0x00000] in <filename unknown>:0 

OK, so it is that line that's causing the problem. Googling up the argument exception, it seems pretty straightforward that you're not allowed to draw GUI elements outside of OnGUI(), so why are we trying to do that? Where did the code come from and what does the original look like?