Gaalidas

That explains it. SharpDevelop, last I checked, didn't handle the C# 6 stuff at all. I did really like some of the C# 6 stuff I saw back a while ago, such as running "using" directives as static and whatnot. I just really dislike Visual Studio for its massive loading time compared to other software. For instance... in most IDEs will show the XML comments when hovering over a method that has them. With SharpDevelop those are loaded up right off the bat with little to no delay even in large projects. in Visual Studio I have waited over 5 minutes and still received "still loading" messages instead. Very irritating. Other than the "nameof" stuff, it's all pretty easy to understand. Well, code-wide that is. The math is gibberish for the most part... but I'm used to that. Some of the formatting isn't really my style but, as it's your code, I won't complain too loudly. It would be great of the water spray could, especially under slow speeds, keep some of the original water's color. I also fear that the camera sampler is going to clip through the water and pick up the under-water shader effects or the ground under the water instead of what we're wanting it to grab. We'd also need to adjust things differently for under-water. For wheels, I would stay stick with the ground texture when hitting the ground under-water but, for repulsors especially, I would move the origin of the effect to just below the repulsion plate (or the back of the wheel if the user has them on the craft and still spinning) and make it a very subtle ripple of some sort if it were possible. On the note of wheels in water... I originally wanted to make them work like the hypnodrive in that they would produce a small amount of thrust when in the water depending on a setting in the module for the wheel that would define it's tread depth for this purpose specifically. If totally submerged, however, spinning the wheel would cancel out any thrust produced by said wheel unless it's configured like the hypnodrive. My humorous side was going to make a special Boolean field named "screwed" so that the hypnodrive could override the under-water-nullification of the thrust. (So it would read "screwed = true" and complete the really bad joke. Sick eh?) Anyway... in the end this would allow a user to, potentially, make a large paddle-boat using an insanely deep-treaded wheel positioned with its center just above the water line for maximum thrust. This all looks great on paper... so to speak... but making it actually happen is another thing entirely. My brain is full of ideas but I have a lot less drive, so to speak, to make it happen. I'm just glad this thing isn't my responsibility. It was cool being the lead programmer on a mod, but another thing entirely to actually put in the work for it. Especially when I was just getting a bit burned out on KSP. I'm trying to find the time to get back into it but I can't ever go back to pure vanilla parts. The modding is going to take some time to get fully fleshed out before my first KSP post-U5 launch is possible.

So... I did a bit of poking around at the code and I found something that I can't make sense of. It's the "nameof" method. It doesn't register as a valid method on my end. Where's that coming from? The rest of the code is beautifully done. I'm saddened by the demise of the in-flight (so to speak) GUI I worked on, but I hear that whole system changed with the engine upgrade so it was probably unusable. I was pleasantly surprised that the dust color camera was still being used. I'm thinking about trying to get the DustFX portion of the mod also available to stock colliders/wheels somehow. The original mod that module was based on (CollisionFX) ran on complete stock colliders, so it shouldn't be too bad trying to get it functional with that again. I'd just have to strip out everything that related directly to the KFWheel modules. I need to go dust off the old code from my repo. One thing in particular I wanted to address back in the day was the over-water repulsion effect in relation to the DustFX module. As it is, using the camera, you'd get colored spray that looks like whatever the water looks like. In reality you'd get more of a white-ish spray effect. Then school got in my way and... well, you know the rest of the story.

Nice to see this taking off again. I'm very curious as to how you got KF into the difficulty settings and such, and also curious as to how you got it all working again. I'd love to dig into the code and see if you managed to fix other issues we were having before the KSP engine upgrade. I only found out about this when BillyWinnJr (YouTube) mentioned the mod in his latest aircraft build. I've downloaded the source and will be looking at it quite extensively in the future. I would love to try re-implementing some of my various features from the old mod that I was working on before I had to throw in the towel.

Sounds like things are looking up for a change. Just in time too... I was just on a Twitch stream last week telling a guy about my experiences in modding KSP. There's still a lot of interest in a wheel overhaul for KSP. I'd welcome the chance to reinvent the dust plumes too. Unfortunately my schooling got a monkey wrench thrown into it and I was totally turned off on doing anything in C# for several months as a result. It'd be nice to get back into the game, so to speak, again.

Hey y'all... me again... Hold the applause... I am surely not worthy anymore. Looks like progress is being made. I was reminded of this mod a few days ago and started to miss the old days when things worked in the expected way and our biggest problem was what to create next. So sad. I'm still wanting to revisit my dust effects modules someday in the future once the dust is settled (woah... what just happened there?). Better just strip all that out for the time being and get this mod working in the most basic form first. KSP 1.2 looks like it could be a major stepping stone to getting these things functional again. At the very least the videos of the wheels in action under 1.2 are looking a lot more stable. Good luck y'all. Yer gonna need it.

Hey y'all. Just popping in to say I have not, as has been passed around in the alley ways, died and rotted. Well... I haven't died anyway. Life is, after all, a slow rotting of our bodies until we stop functioning... so to speak... Okay, that's disgusting to think about... moving on. I was looking at a stream of Planet Nomads which, according to those streamers, is built on Unity and, from what I've witnessed, has some pretty interesting wheel physics going on. Derpy as heck, but functional including suspension systems and whatnot. This certainly means it's possible to get this stuff to work to some degree as far as the engine is concerned. It is, at the very least, able to provide some hope for better wheel physics in KSP eventually.

Honestly, that sounds like just about every fast rover I ever made in KSP... except swap out miles for meters, and hours for seconds, but otherwise... yup, hit a certain speed and suddenly the entire thing goes WHACKO! I have a feeling it's not for the same reasons though...

Ah... good to know. I was only speaking from my experience. The expertise simply doesn't exist in my brain. They sure look less detailed though, which really stinks.

Yeah... sorry about that. Seems I overestimated what I could handle with school and real-life stuff going absolutely nuts on me. I appreciate you wanting to move away from this stuff lo-fi, but we need someone to take command who can handle at least some of the pressure. I'm still lurking around, but I fully support the closing of my thread and the re-opening of this one. My thread was going nowhere quickly. Edit: As for the project linked above... I had an initial look at the code and I must say I'm impressed so far. Actually, I only looked at a single file... BUT (You gotta shout those awkward words out with emphasis to get the attention of the sleepy forum lurkers) I like where you're heading with defining objects for the various wheel-related modules instead of sticking everything into the module class. This should end up with much cleaner code overall. This is something mod authors for KSP could really use more of. I used to download sources for just about everything I downloaded to use in KSP to take a look at the magic behind the DLL. I can't even express the messy and down-right ugly code I would find in those projects. If you manage to revolutionize the world with your product, but the sources are ugly as -insert expletive here- then you've done a disservice to the world in the long run.

I never thought the original post would be resumed again... considering it is a pretty hefty topic as it was when we closed it. Anyway... despite my plans and ideas and whatnot, it is obvious i don't have the time to actively work on this and likely won't in the near future. Don't forget about me, though, when assigning any permissions and whatnot. Summer comes relatively soon and i may yet have some time to look into this mod again. One thing I have been doing is a bit of research considering how the wheels are implemented in this and other Unity-based games. For instance: I have been watching a LOT (I mean a -insert expletive here- load) of Space Engineers content on YouTube lately and they are plagued by the barely-manageable wheel physics that we are now dealing with here such as the extreme slipping and sliding (drifting anyone?) but they also have a lot of adjustable settings on the fly without having to reinitialize things and whatnot. I don't know if that's as much of a problem in the new engine, but I remember a while back we had to give up changing certain values when the flight scene was loaded due to limitations in the engine... unless that was squad-side in which case I am totally wrong... and it wouldn't be the first time either. Nothing has really come out of this research other than the fact that is sucks for everyone, cross-game-platform even. On the up side, for the SE players anyway, a lot of the innovations in KSP vehicles are starting to filter into SE builds as more KSP players are picking up the other title as well. I'm still waiting for someone to make an SE version of that crazy Kethane rig lo-fi showed off in the early days of KF. Anyway... looking forward to see if you guys can make it work. I'd be interested to know if anyone has actually managed to make any of the modules load up in the game and if any of the features at all are still functioning. The only thing I can think of that could still work okay would be the basic rendering of the GUI menu since they left a lot of the old GUI API still accessible, but I doubt the activation icon still functions properly. I really like the idea of auto-adjustments by the way... That was one of my long term goals when I set up the GUI to be able to handle adjustment sliders and whatnot. I wanted those to, in the end, become more of a debug option and have the wheels actually grab their settings from a craft-based module (vessel modules I think they were called) which would determine if the craft is even in need of such a module (if not it would kill itself... suicidal modules? Depression in module AI when its purpose is determined to be null? I know the feeling...) and, if so, would then calculate all the necessary variables and make them available to each wheel to then include in its individual computations based on its position on the craft and how much of a load it is being asked to carry. I also wanted to find some way to have the wheels be able to adjust their suspension to keep the craft either as level with the ground as possible or as level with with upright vector as possible (and also apply this to legs) and, possibly, provide IR-style bookmark points for suspension height and such to help with fixed-height ramps for back or side-loading cargo bays (or drop-down bays even). It's a long list of improvements to the craft control scheme that would all rely on some way of auto-adjusting dynamic variables while in the flight scene without re initializing anything. Other than that, i wanted to make KF into an extendable project which I am learning more and more about in school right now. (Technically "right now" is a loose term since the current topics are all on Unit Testing which I am beginning to really hate with a passion. That and doing web-development with Linux which is completely new to me despite my geeky upbringing.) Anyway... I hope this project sees the light of day before the next big release of some unknown title from an unknown developer blows the world away and sucks us all into it. I'll be sure to keep an eye on it and pipe up if I see anything useful.

I don't actually have access to the new libraries yet, so I can't really comment on what needs to be changed. As for SharpDevelop stuff... the only stuff unique to that program are in the form of comment lines that SharpDevelop interprets. That shouldn't have any impact on Visual Studio or anything else. Anyway... I'm sure the GUI will need to be completely redone with a Unity 5 compatible GUI system. It's supposed to be a lot easier with the new unity tools, but I haven't had a chance to mess with that yet. I'm still a bit worried about the SpaceDock entry for KF. I don't know who the tagged author is and the link in that entry still points to the old thread. Hopefully all the differences are namespace/dll issues. They'd have had to do a ton of work if their modules were changed so dramatically as to be outputting different stuff for related modules. It's likely that anything new relating to wheels and collisions has been changed, but configured to output the same kind of data that other referencing modules would expect. This would limit the need to completely rewrite the entire game. One thing to note here is that the wheels in that image aren't actually drooping into the landscape. They're drooping into a static model of the runway. Landscape is defined as the planetary surface. Also, the droop can occur on any surface and, while the "long-roving" thing does happen, it also shows up a lot when tweaking the scale of the part. EDIT: I haven't had any trouble editing posts... so my guess is you all are doing something wrong. So... stop it. There. That's fixed now. From looking around in the post you referenced, Aqua, it looks like a lot of this will be easily fixed in a temporary form by moving around the referenced DLLs and changing some namespace stuff around. I found it a bit funny that they talked about shortcuts being eliminated in Unity 5, considering I never actually used any of those shortcuts nor even knew they existed. Oh well.

I noticed this posting just now about the max speed and EC consumption. EC consumption you should be able to figure out easily enough from the code if you've been able to look at it, and it really hasn't changed at all in any of the more recent (as in the last 6 months... I've been out of the code for a while now) changes. Max speed, however, is going to be a bit more of a bugger for you. In my testing, I've never been able to get a KF rover even close to the speeds I could with the standard wheels. However, I also couldn't get a KF rover to flip or freak out nearly as much as I could with the stock wheels... so it still pays for itself in the end. I was actually looking at AutoRove recently (and would like to take a look at the source sometime soon) and liked the idea behind it. Considering we don't change how the craft is controlled at all, you might not even really need to integrate anything unless you keep really close tabs on what each wheel is asking for in EC. Though... one thing worth mentioning is that we don't actually call it EC consumption or anything similar. I made it much more broad so that future modders could make the wheels run on different fuel types without having to change the code at all.

Honestly, I'm not the one to be talking to I'm afraid. I'm surprised this topic is still being used even. I figured the new team would start up a new topic and take it onward from there. However... I'd simply love to see some new content for this mod created even if it was in the form of a third party add-on (like how BDA has all those sub-mods being developed all over the place). Even if the team thing fell apart and I started maintaining this solo there still isn't any skill on my part whatsoever in content creation. In fact, there's barely any skill in code creation as well, at least as far as wheel functionality goes. Lo-fi did his magic on that stuff and there's no reproducing it from scratch as far as I am concerned. The best I can do is copy and paste bits and pieces and pray it compiles, al lthe while grinding my teeth in anticipation of a horrible fail.

I'd actually like to know that myself, and whether or not this person can truly claim that this mod is fully functional in 1.0.5. If so, I'm cool with it for the time being... but I'm really just a mascot right now so it would have to be taken up with the rest of the team if they're still on board. I actually noticed it wasn't any of our normal guys, or at least not the names I remember, after making my last edit here and thought to myself "who the heck is that?"

For the people with flameless poodles (there's a bad joke in there somewhere...) I can confirm that there is a case where a small engine, probably the poodle (I don't build rockets very often, so i'm pretty clueless) that has never had a proper effect attached to it. It's rather disappointing when every other engine, even non-atmospheric ones, contain proper effects and this one little engine just has what looks like the cartoon-style puffing effect... except much better quality than a cartoon variant. It's very sad.

I always loved LLL for the boxy designs... while still keeping them aesthetically pleasing for boxes... but it got really cluttered with all the parts that were simply clones of other parts, or cases where some of them had shared models and others didn't, and texture issues (resolution, detail, lined-up seams and such) and I could never really seem to make sense of it all. I like this idea of a new entry into the sci-fi box style.

So, to add to the repulsor groups thing... Yeah, that's sorts how it works. One thing I'd like to do in the future is make this a little more intuitive. Chancing values on the right-click context menu still only affects that part. Action groups, however, affect the entire set of parts with the same group number set in the context menu. This does not mean that everything will be in sync at all times though. If you set the group for a specific height (I think those action group options made it in... but cannot be customized as much as I'd like yet) then everything will sync up to that height, but if you use the bump up/down action then all that will happen is that they'll all bump up/down the same amount but still could be unbalanced until you bump everything beyond their maximums (actually, it's not possible, but eventually every part will max out and then be in sync again). I'd really love for this system to be a bit less heavy on specific action group options and, instead, offer a way to create stopping points for the suspension in much the way you can make stopping points for Infernal Robotics parts, and then offer a way to specifically call up a certain point, or cycle up/down through those points in addition to allowing for per-craft and global incremental up/down stepping like we have now (for a global option) through our GUI interface. It's all a bit clunky, but it works well if you set it up right.

Alright, so... I've been watching all the crazy stuff with KerbalStuff going down and SpaceDock taking over. I've also been slowly rebuilding my KSP mod library so I can get back into this stuff a bit here and there. This also means I've been slowly getting back into C# programming (school has be stuck in JavaScript right now... which really sucks. For instance: C# has data types. JavaScript has... Vars. What the heck is a var? A var is EVERYTHING... at the same friggin' time! So annoying.) and that means a renewed interest in KSP modding. I won't say i'm back in action or anything, but I think it's time to start poking the body... so to speak. Try not to think about that one too hard. Anyway... to answer some questions... Right now there is no official release. (EDIT: Holy Jebediah! I did not notice that there was a new release on there. Awesome! However, I am not the one to ask about this as I am only a mascot for the time being.) In fact, even when KF was in full swing, we never made it our of the alpha stages. I was going to take us into beta stage... but we all know how that worked out. I'm considering doing a temporary release sometime this month if the new administration is alright with that and if KSP 1.1 doesn't drop on us before then, but it won't be a full-features release really. Just something to get the basics up and running again with all the new 1.0.5 features and such taken into account. As for the wheel stuff... Yes, the wheels in KF work a bit differently than the stock wheel modules. They aren't a complete departure of course because they're still implemented in much the same way for the basic functionality of being round, being able to roll, and being able to support a vehicle that wants to interact with the surface of a planetary body and/or static surface (aka. bumping into it and changing momentum... aka. going up the hill instead of going through the hill... okay, I'll stop there) but that's where the similarity ends. Steering is the first thing you'll notice. It's a lot smoother and, when using... say 6x6 wheel configurations... you'll notice that not all the wheels turn the same amount. This creates a much more efficient turning system for the vehicle, as in less scraping of certain wheels and a more reliable center of the turning radius compared with wheels that all turn the same and rely on whatever wheel is grinding with the ground the hardest to determine the pivot point of the craft. Next is the suspension which is wheel-specific and travels a lot further than the stock suspensions. Also, KF suspension can be modified to raise and lower the vehicle and helps to reduce rolling of the craft in higher speed turns.. Finally we have the RPM readouts and the way it all interacts. One goal of KF was to create a smoother transition between the differing acceleration levels of the vehicle. This reduces cases of flipping due to a wheel motor going from dead stop to full power immediately, and also helps the steering and anti-roll systems. This does result in slower overall velocities, and slower acceleration overall, but it makes for a much more stable ride. All the differing data for these wheels compared with stock is quite necessary, but I would also note that it makes it a lot harder to create a new wheel and, considering I started as a simply collaborator on this mod, I lack the knowledge of how to go about doing that. As for the source code... you and me both. I'm working on getting all my old sources back on one computer so I can take stock of what I have and what is going on right now. I'm still hopeful that the new administration can come up with a stable release, especially post-1.1, but I'm working on getting back into things one step and a time. In the mean time, there is a utility you can search for called ILSpy which would let you decompile the DLL and take a look at how things are done either in C# or even VB apparently. That won't include any of my old WIP projects within the KF code that weren't ready to be compiled yet, but the functional stuff is all there. So... you guys who were going to take over this stuff from me... what's up? Any news?

Alright, sorry for the lack of commenting here. Quite busy. I'm having to learn JavaScript this quarter, and I absolutely hate it. Sure it's very similar to C# in a lot of ways, but things that take 3 days to make work in JS could be done with ASP/C# in a few hours. It's down right insane and, to make matters worse, I can't even make everything look the same on every browser that is commonly used due to different implementations on each web platform. It's driving me nuts. Good times otherwise. I have the latest stuff uploaded to one or the other repo right now. Easiest way to tell is to simply compare the latest commit data/time. I'm running completely off the older Desktop PC right now and have not even set up Github for this computer yet to check things over. My repos, I believe, should still show up under the branches derived from lo-fi's repos. There's a lot of WIP stuff in the code, but I don't believe any of that interferes with the main mod processes at all. It's possible all my WIP stuff is set to not be compiled in the project file anyway. The stock configs are so old that I don't even think they use the newest modules properly. I'm afraid we might need to chase down lo-fi to update them properly. He shouldn't need any of his old stuff installed to edit a few files with the new data required. Testing them is another matter entirely of course.

Nay, I am not maintaining it, nor am I done with it overall. There is, i hope, a new team of seasoned modders taking over the project and I have moved into the Mascot position of the team for the time being. Maintaining a mod as wild as Kerbal Foundries simply wasn't something I was up to the task of on top of being in college and lacking the world experience in wheels and such, plus lacking any clue about modelling or texturing. I'm barely up to the task of keeping up on the programming and, while I was the maintainer of the Dust Effects portion of KF, much of the work to make all of that actually work was not due to any level of expertise I had in C#. Then, with 1.0.5, there are a lot of new features of the base game that I could not make work with KF properly which was also compounded by a major hard drive failure with zero chance of recovering any data. Version 1.1 is going to break open the bag and let all the cats loose, which is also something I had more or less zero chance of being able to cope with. I have not seen any progress so far, but I do hope they continue to work on it and get a working release for version 1.1 at the very least.

That thing looks awesome. Also looks like I could break it by sneezing.. and I ain't a heavy sneezer either.

Indeed. The tracks work. Usefulness is not the goal here, just functionality. If we were worried about usefulness, we'd never have made it off the ground in the first place. More of us would still be alive too... but those are pretty pointless details for Kerbals.

A nuked save shouldn't be an issue with providing a craft. craft files are stored as separate files from the persistence file, so as long as you don't delete the entire directory for that save, you're good to go.

Question: Does it still fly like that? If so, I see no problem with the design.

So... yeah, I disappeared after my last post. My hard drive crashed... hard... as in not even enumerating files, thus no recovery of data possible. fortunately I sent some stuff to github before hand so KF is intact still. Unfortunately I sent one of the two updates to the old lo-fi repo, and the other one to my fork (I'm unsure which is which). I'll get that sorted eventually and probably focus on the old repos so it'll be relatively easy to pass this on if that's what happens. Yeah, I burnt out bad. However, I maintain interest in it and, once I recover from the hard drive failure, I'd like to get back to fiddling around with it. It's just too difficult to make it happen between school and hardware failures. I'm okay being the mascot for the most part... as it's about what I'm good for right now. I both dread and look forward to the 1.1 update, so I'll definitely be waiting until that happens to do much else. I'll work on getting the old repos updated and all my recent attempts at fixing the dust. If that doesn't do the job, then I'm going to have to pass the bug to the next qualified programmer.