Okay, guess I *won't* be reporting this bug after all...

[Sean Mirrsen]

I don't use "no mods at all", but I fly stock. Getting easier every version, with KSPX slowly merging in. As such, removing mods to make a perfectly stock install is no hassle. All I use is the Subassembly Loader, and am considering re-getting the Kerbal Engineer. I mostly do it so I can share whatever I make with anyone, but coincidentally it also makes reporting bugs much easier.

Also, reporting a bug like this, especially a location-specific bug that can be on a distant planet, can further expedite the bug's confirmation. Because, for instance, a whole lot of people may have a rover on the way to Eeloo, or already on Eeloo, and you asking to check if the bug still works in a completely stock install won't be near as much of an inconvenience for them as it is for you.

[Commander Zoom]

Looks to me that you're trying to make some kind of stand on principle and/or the letter of the rules, and everyone else figures you're being silly, lazy, or a troll.

I don't think you can win this one. My advice, honestly, is:

(a) As others have suggested, find some means (ANY means) of getting the craft to the location in question, test the bug, and report it; or

( Walk away.

No other course of action will have a positive outcome, IMO. In particular, I greatly doubt you're going to get SQUAD to change either their posted rules or their testing methodology. If that is your hope, give it up now.

Edited July 29, 2013 by Commander Zoom

[Sof]

Well, that's most of my point: They really ought to make an exception for hyperedit, or build similar functionality in, to go with this policy, so that it isn't quite so hard to test something that has to be done in a particular spot.

I've never been to Eeloo myself, it's just kinda the 'worst possible case' where having to redo something stock can be just devastating.

TBF, hyperedit just edits the config.

If you note down the location of your mod rover when you get a glitch you think may be stock, you can just give a stock rover the same parameters by manually editing the file.

[Tiron]

Looks to me that you're trying to make some kind of stand on principle and/or the letter of the rules, and everyone else figures you're being silly, lazy, or a troll.

I don't think you can win this one. My advice, honestly, is:

(a) As others have suggested, find some means (ANY means) of getting the craft to the location in question, test the bug, and report it; or

( Walk away.

No other course of action will have a positive outcome, IMO. In particular, I greatly doubt you're going to get SQUAD to change either their posted rules or their testing methodology. If that is your hope, give it up now.

Actually, I did. I cheated the gravity off (and infinite fuel), used a couple of little radial engines to fly it over to about where I'd been landing at, then flipped gravity on and infinite fuel back off and used the parachute it already had for emergency airdrops to land it.

Proceeded to verify the issues still happened and posted it in the bug report forum.

If it wasn't such a short distance, it wouldn't've worked, though.

TBF, hyperedit just edits the config.

If you note down the location of your mod rover when you get a glitch you think may be stock, you can just give a stock rover the same parameters by manually editing the file.

Well it'd work, but I'm not sure I'd suggest that for most users. Persistence editing is a fiddly and fickle beastie, and the game doesn't handle errors in doing so particularly well. I don't know about the persistent.sfs file, but in .craft files it actually stores all the location info for each part independently. I haven't done much in there vessel wise except to occasionally delete things, so I can't say offhand if it does that in the save file as well, but since the structure for a vessel appears at a glance to be basically identical to a craft file, I'm guessing it probably does. Which just makes it that much harder.

It'd be easier to just delete the mod parts off the craft, assuming none of them are structurally significant (Like with my rover, where it's just a few scattered surface mounts), and load the existing save file on a stock install. Trick there is you have to get every reference to the deleted part, which is usually just on the part it was attached to. If it has any 'child' parts, you have to delete those too, and all THEIR references (Struts and fuel lines would be the big culprits here).

[Sof]

It'd be easier to just delete the mod parts off the craft, assuming none of them are structurally significant (Like with my rover, where it's just a few scattered surface mounts), and load the existing save file on a stock install. Trick there is you have to get every reference to the deleted part, which is usually just on the part it was attached to. If it has any 'child' parts, you have to delete those too, and all THEIR references (Struts and fuel lines would be the big culprits here).

the persistent.sfs file is rather noob friendly in some ways. Not too difficult to figure out. (easier than a stock mission to eeloo)

[Tiron]

the persistent.sfs file is rather noob friendly in some ways. Not too difficult to figure out. (easier than a stock mission to eeloo)

I've fiddled with it before, just not much with individual vessels. Mostly I just resurrected Jeb... There's a reason there's so many conditionals in there.

Craft editing I've done some pretty significant stuff, though.

[Mr. Scruffy]

Having some very interesting problems with a rover, most of which are extensions on problems I'd seen in prior versions, only now greatly worsened. Except I go looking for the bug report forum (which has moved), and I find this in a sticky:

...If you are experiencing problems we will be expecting you to attempt to recreate these problems on unmodded installations first or you won't qualify for support and your thread will be closed.

Off the top of my head, I can't really think of a way to get a 2-ton rover from the SPH into the mountains 70 km from KSP on a stock installation without spending probably close to an hour either redesigning and testing a carrier aircraft (which was hard enough to do for the much smaller and lighter DEMV mk 5), or 1-2 hours driving cross country, by hand. The one halfway reasonable idea I do have would rather ironically require downloading and installing a mod I don't have prior to going stock in order to pull it off in any kind of reasonable timespan.

Given that I'm not being paid for my time, it's simply too much time and effort to go to just to report a problem, even if it is a fairly serious one.

Especially since I am about 95% certain that none of the mods I'm using affect the rover wheel system.

I understand that you're not in the business of providing support for mods, but at the same time making it harder for people to report an issue is NOT a good idea, unless you like people grumbling about unresolved issues that never got reported.

Yeah, maybe they should not simply close such ´mod-tainted´ bug-report-threads but rather leave them open for user-discussion and maybe there will be someone out there wanting to try it vanilla-style, thusly ´purifying´ the report. Maybe there should be an extra-subforum within the bug-report section? I mean, why suppress info, if it can be useful, after all - doesnt mean the devs have to look at it, until it´s been verified in vanilla.

[sal_vager]

Not sure if this helps but the wheels have a lot more torque at low speeds, so they accelerate a lot faster, could this impact your testing of this issue at all?

[Tiron]

Not sure if this helps but the wheels have a lot more torque at low speeds, so they accelerate a lot faster, could this impact your testing of this issue at all?

Oh I know that, and I'm certain it's not related for a simple reason: I've actually hit higher speeds going up steep slopes than I can on a flat. I mean, on a flat it tops out generally at 22-odd M/S, maybe 23 with a slight downslope. It's easily overtopping 30 m/s going up steep slopes, and showing signs that it'd go even higher if allowed. It's basically acting like it's going downhill when it's going uphill... And it seems to handle absurdly steep slopes too. It's like an uber-Mako!

[Sean Mirrsen]

If it's SAS-equipped, this may be something like the infiniglide bug. Rover wheels exert force on the vehicle proportional to what they exert on the ground - i.e. due to gravity. This is why rovers are so sluggish on the Mun. When you're driving up a slope, the terrain pushes up at the wheel as the rover accelerates, the more the steeper the slope and the higher the speed, so you get a constant increase in effective power. SAS adds to this, exerting force to try and keep the rover horizontal, and pushing down even more on the wheels that go up the slope. Something like that could be the cause.

[Tiron]

If it's SAS-equipped, this may be something like the infiniglide bug. Rover wheels exert force on the vehicle proportional to what they exert on the ground - i.e. due to gravity. This is why rovers are so sluggish on the Mun. When you're driving up a slope, the terrain pushes up at the wheel as the rover accelerates, the more the steeper the slope and the higher the speed, so you get a constant increase in effective power. SAS adds to this, exerting force to try and keep the rover horizontal, and pushing down even more on the wheels that go up the slope. Something like that could be the cause.

It's SAS equipped but the SAS isn't on, because I rebound the rover controls to IJKL, which is how I discovered that the Rover Controls don't override the SAS attitude lock setting. If you've rebound them, the SAS will fight every course change you make, so it's off, and its torque on a separate set of keys, so I'm pretty much completely sure it's not that.

[Sof]

are you able to provide a video of the problem? I've yet to experience anything like this and am curious.

[Spartwo]

I already reported this

http://www.youtube.com/watch?v=jlEcf3ImqVk

I call it wobbly wheels.(haven't experienced it in .21/.1)

[Markarian421]

It might be good if there was a place we could say "hey, I think I found a bug, I'm not expecting support or anything but just thought you should know and wondered if anyone else is seeing it?" Along with version info and a list of installed mods, that last part would be very helpful for finding out if a particular mod is the source of the problem. Right now there doesn't seem to be anywhere we can do that -- I posted something like that here and a mod moved it to the support forum, and then it was on me to prove I could reproduce it stock. Which I did, but I do see what the OP is getting at -- like it or not this discourages bug reporting.

[sal_vager]

I'd like that Markarian421.

[Kosmic Debris]

And I don't want to put in hours of unpaid work just to meet their requirements, either.

Then you [fail] at being an Alpha tester and should go back to playing Angry Birds

Seriously - that's our job right now: testing software. If we have a little fun doing it then great, but there shouldn't be any confusion about what's happening here. In this case, limiting the testing scope to only their software is critical - otherwise tracking down the issue is hugely more complex. I've been there many times on the other side - perhaps you haven't, so it just looks like they're making you jump through hoops; I get that. But that's the way it is.

I'm on a number of alphas and betas, and they all have a certain level of frustration. In one game, they overhauled the currency model...and so the pile of money I was sitting on suddenly disappeared because there wasn't an easy way to do a conversion. I didn't ragequit or gripe...I just gave my feedback on the new monetary model and dove back in playtesting. It's part of the fun and frustration of shaping new software - games or otherwise.

[Moach]

You all do realize it's perfectly possible to keep two installations of KSP, right? one for modding and another for testing...

just move the addon-heavy folder out of the steamapps folder and have it download again (repair) - this is acually a good thing to do because you can also help addon devs beta test their own developments as new versions come along, they need this just as much as Squad does

there's no option on the poll for that, but well - that's what I would do

[Technical Ben]

And I don't want to put in hours of unpaid work just to meet their requirements, either.

If it were something easy, it'd be one thing, but I'm using KAS and docking struts just to get the rover there, and I only know of two ways to do it without them, neither of which I'm actually at all certain would work, and both would require substantial redesign and some testing before I could actually try it.

If I could just go there it'd be one thing, but last I checked, isn't hyperedit a mod?

There is a button to press to turn gravity etc off. Shhh... Don't tell. But it is useful for bug reporting, and can speed up the process exponentially.

Ah, ninjas beat me to it.

PS, thanks Moach for suggesting multiple installs. I currently do this with updates (full ones anyhow) as it's still Alpha so I like to test before loosing my previous install. If at all possible, an option to not load mods could help (command line?). Especially with the new mod/additions to the folder structure.

I'm all for multiple installs (I'm an old fashioned folders arrangement for PCs ) but understand both the legal department and the way some software works (Windows "user" and "app" folders... yuk!) can change that at times. Thanks!

Edited July 29, 2013 by Technical Ben

[DChurchill]

Nevermind.

[Cartz]

Wrong answer. I paid for KSP to provide capital to SQUAD during the development cycle, not jump through huge hoops reporting bugs. Sure it's an "alpha" but I'm the paying customer. I will help with testing and bugs and feedback and such, but I'm certainly not going to reinstall KSP mod free and start from scratch just to test a bug. Sorry. Not going to happen.

^^ This guy gets it...

The second we paid for this title, we freed ourselves from the chains of traditional alpha/beta development expectations. I hope you can see how paying for the KSP Alpha to fund further development work is different from being a part of a free, early access beta where devs may actually even be paying for the servers you're playing on for free.

If we, as customers, are gracious enough to provide details of a flaw in a piece of software we've paid for, and provide a list of mods that we're using and their versions to go with it, then the devs should be falling all over themselves with gratuity to us and giving their best effort to determine if the flaw is in their software, that of the mod, or the interface between the two.

All we should be expected to do is provide a .sfs file, a list of installed mods, and details of the error. The developers, whom we have paid, should handle the rest.

[sal_vager]

Cartz, you have no idea, if you look up you'll see that DChurchill changed his mind and removed his comment.

This thread has devolved into garbage, and it was such a good premise to start with too.

I'm closing this before people start throwing things.