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

[Tiron]

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.

[Rockhem]

The Deva don 't want to hunt down a bug for days just to find out that it was caused by a mod.

[Tiron]

The Deva don 't want to hunt down a bug for days just to find out that it was caused by a mod.

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?

[Brenok]

Maybe try using Alt-F12 to bring the cheats and use "hack gravity" and "infinite fuel"? Then you could attach some small rockets and fly quickly.

What kind of bug are you experiencing that could only be tested on a mountain?

[Captain Sierra]

Here is what you do. Build the rover with stock parts. launch. Install hyperedit, hyperedit rover NEAR not AT desired location. Uninstall hyperedit. Drive rover the last little bit of the way, experience bug. Report. At the time the bug occurred, you were running KSP stock, therefore mods are not causing the issue and the devs have to listen.

[Captain Sierra]

Maybe try using Alt-F12 to bring the cheats and use "hack gravity" and "infinite fuel"? Then you could attach some small rockets and fly quickly.

What kind of bug are you experiencing that could only be tested on a mountain?

I think the bug in question is regarding the new terrain model of the mountains and that is why he must go there,

[Tiron]

Maybe try using Alt-F12 to bring the cheats and use "hack gravity" and "infinite fuel"? Then you could attach some small rockets and fly quickly.

What kind of bug are you experiencing that could only be tested on a mountain?

Let's see...the rover goes faster up steep hillsides than it can on a flat, a LOT faster (Like easily overtopping 30 m/s when it normally tops out at about 23 m/s, and even then generally only with a slight downslope), and accelerates much harder too.

And the old suspension instability problem is even worse, with entire terrain 'facets' that trigger it...and when you're on one it basically kills thrust from wheels, which knocks the speed down from ~20 m/s to about 1.25 m/s until you get onto a new 'facet'. It wasn't so bad on the flat, but up in the mountains...there's huge facets that do that and you end up crawling to get off them.

Edit:

Basically, my problem is not editing it to go stock, I could do that easily, because both the carrier aircraft and the rover only have a few mod parts, all of which are easily removed. The problem is that it's using most of them to attach the rover to the carrier aircraft in a way that allows it to get off the ground and doesn't screw up center of drag.

In order to attach it to a carrier without the mods, I'd either have to build a plane onto the rover piece by piece, build the rover onto a plane piece by piece, use subassembly loader(which I don't have) to do the same thing only all at once, or hack the craft file to get it into the VAB so I can attach it to a rocket.

For a carrier aircraft, given the size of it, it could only be attached either on top (major center of drag issues, it might be bad enough with this thing that top carriage isn't actually possible. It barely was with the DEMV mk5 and it only weighs 1.25 tons. This is 2.19.) Rear carriage would be easier, but I'm not sure if it'd fit well enough for the plane to be able to get off the runway without dragging the sides of the wheels, which would probably wreck the plane.

If it wouldn't take so much time to get it to the mountains to test it, I wouldn't have a problem going stock to do it. I just don't want to spend an hour+ figuring out how to get there.

Edit2: I suppose I could use hyperedit (which I don't have), to move the stock rover over there, then uninstall hyperedit...that'd be slightly hilarious.

I have a sneaking suspicion this is going to make unreported bugs on Eeloo even more of a problem than it is though.

Edited July 29, 2013 by Tiron

[samstarman5]

Running mods on a game still in development is a risk you take upon yourself. If the only way to get the rover you built somewhere requires mods that anything stock can't do, I have a feeling it is a bug unlikely to be repeated by ordinary players. Therefore I wouldn't lose sleep over it and do what you can to avoid that bug yourself. Mods are the work of parties outside of Squad, and as such are completely unsupported. They might be encouraged, but it is not the responsibility of the game developers to deal with a hiccup that may very well be caused by code that they did not write. You assumed responsibility for whatever became of your gameplay by using mods, and expecting the developers to bend over backwards to something you can't be bothered to do yourself is a bit selfish.

If it is really that important to you, then you can be bothered to try to replicate the bug with just stock parts. Since you can't be bothered, then it obviously isn't that important. I have to question the validity of this thread other than it just being another griefing post.

[Tiron]

Running mods on a game still in development is a risk you take upon yourself. If the only way to get the rover you built somewhere requires mods that anything stock can't do, I have a feeling it is a bug unlikely to be repeated by ordinary players. Therefore I wouldn't lose sleep over it and do what you can to avoid that bug yourself. Mods are the work of parties outside of Squad, and as such are completely unsupported. They might be encouraged, but it is not the responsibility of the game developers to deal with a hiccup that may very well be caused by code that they did not write. You assumed responsibility for whatever became of your gameplay by using mods, and expecting the developers to bend over backwards to something you can't be bothered to do yourself is a bit selfish.

If it is really that important to you, then you can be bothered to try to replicate the bug with just stock parts. Since you can't be bothered, then it obviously isn't that important. I have to question the validity of this thread other than it just being another griefing post.

That's the thing, the problem IS with stock parts. The rover's almost all stock, as is the carrier aircraft. Stock wheels, stock structure, stock fuel tanks, stock wings, stock control surfaces... The problem is it's designed to use KAS and docking struts to attach to the rear-center of the carrier aircraft, and redesigning it to attach with stock parts would be difficult, not least because they're two seperate .craft files at the moment, but also, I'm not even sure it'd work aerodynamically or physically.

Which is only a problem because I need to get out of KSC in order to do the testing. The problem is literally only that it's too difficult and too time consuming to get the rover back to the same spot where it's experiencing the problems after going stock.

[BarryDennen12]

"And I don't want to put in hours of unpaid work"

The definition of 'work' must've changed while I was napping.

[Tiron]

"And I don't want to put in hours of unpaid work"

The definition of 'work' must've changed while I was napping.

Spending significant amounts of time redoing a system that works better than any stock method of doing the same thing just because it uses a grand total of 9 mod parts to form the connection. I could chop it down to three fairly easily. Chopping it down to none is not easy, because they're two seperate craft and...

...and what if I used docking ports...that could...almost work...errrrrr...sec.

[Superfluous J]

You've already been given a very simple solution to your problem, and a very good explanation as to why they won't look at bugs in modded versions of the game.

Just because the mod doesn't *appear* to affect what is happening does not in any way mean that it is NOT. Things have unintended consequences, otherwise there would never be bugs in software that needed reporting.

[Tiron]

You've already been given a very simple solution to your problem, and a very good explanation as to why they won't look at bugs in modded versions of the game.

Just because the mod doesn't *appear* to affect what is happening does not in any way mean that it is NOT. Things have unintended consequences, otherwise there would never be bugs in software that needed reporting.

Oh I know. But the simple fact is if the bug's specific to a particular location, expecting a user to go in and redo their entire mission all stock just to be able to report the problem is...a bit much. Imagine if the problem only happened on Eeloo? (and there are a few there, barely touched because nobody goes there.) You would have to literally spend hours reflying the mission by hand, doing calculations since you can't use protractor, etc.

If it were like my craft where it was almost all stock to start with, it'd literally be easier to hand-edit the persistence file to remove the mod parts than to redo the mission stock. And if you mess THAT up even a tiny bit...bad things will happen.

[_Aramchek_]

Oh I know. But the simple fact is if the bug's specific to a particular location, expecting a user to go in and redo their entire mission all stock just to be able to report the problem is...a bit much.

How? Why should any game dev/publisher have to fix bugs that easily could be caused by a mod?

[Tiron]

How? Why should any game dev/publisher have to fix bugs that easily could be caused by a mod?

Why should a normal user have to do tons of unpaid work to satisfy the dev's requirements?

It's not fair for the devs to have to support mods, but it's equally not fair for the users to get stuck in a situation where they have to do hours of work before they can report a bug.

Neither fact changes the other.

The simple fact is, right now:

If you simply uninstall a mod, any craft containing parts from that mod will be automatically deleted the next time you try to play, without a prompt or opportunity to try to correct the issue.

It can take literally hours or days to reach a given location in the game, and it's difficult to reach some places at all with the stock navigation UI without doing a lot of extra work to work out the angles and such.

The only method that allows you to bypass the former is, itself, a mod.

Edit:

What's needed here is pretty simple: There needs to be a way, in the game itself, to remove mod parts from an existing craft, and a debug function that allows you to easily move to a particular location. Or just make an exception to the 'stock only' rule for hyperedit, rather than building it into the game.

Edit2: Okay, the docking port is NOT working...

Edit3: Yup, docking ports do NOT work as a solution. I can't get them quite perfectly aligned and the magnet's not strong enough to pull it that tiny little bit into alignment, or so it would seem. So I'm back to square 1, where there's no reasonable way to reach the point I need to reach in order to duplicate the bug in the stock game.

Edited July 29, 2013 by Tiron

[MockKnizzle]

Someone already said this earlier: Open up the debug menu, turn on infinite fuel and hack gravity, and then just fly over there. Once you're there, disconnect your jetpack apparatus and turn off hack gravity.

[Tiron]

Someone already said this earlier: Open up the debug menu, turn on infinite fuel and hack gravity, and then just fly over there. Once you're there, disconnect your jetpack apparatus and turn off hack gravity.

I'll try to mock that up real quick, because larger docking ports isn't working...I can get the port to lock on, but it either rips it right off the rover, or in the last run, gave the plane such a strong nose-down tendency that it literally couldn't fly (I'm guessing some kind of clipping problem).

Edit: My real problem here is that wouldn't really work if the location you had to reach was on another planet. Or on the other side of Kerbin even, probably. It ONLY would work because the point I need to get to is so close.

I just don't want there to be tons of unreported bugs because going stock and then duplicating it is too hard and takes too long...which WILL happen with the current incarnation of this policy.

Edited July 29, 2013 by Tiron

[JaneKermen]

Why should a normal user have to do tons of unpaid work to satisfy the dev's requirements?

It's not fair for the devs to have to support mods, but it's equally not fair for the users to get stuck in a situation where they have to do hours of work before they can report a bug.

Seriously, are you trolling?

Because in the time it took you to do your past 4 posts you probably could have been 50% there in creating a test case for the devs.

If you don't put in the time to create a repeatable test case for an ALPHA product that you got at a reduced price in the hopes that you would send in bug reports, then why not stop whining about it?

You were given solutions as to how to do this - conversation over unless you just want to troll.

[Tiron]

Seriously, are you trolling?

Because in the time it took you to do your past 4 posts you probably could have been 50% there in creating a test case for the devs.

If you don't put in the time to create a repeatable test case for an ALPHA product that you got at a reduced price in the hopes that you would send in bug reports, then why not stop whining about it?

You were given solutions as to how to do this - conversation over unless you just want to troll.

I'm not the one coming into a thread trying to derail it with a confrontational tone.

I *am* halfway there, actually (maybe more than if this works), but that's not the point.

If you found a terrain issue on Eeloo, that seemed to be specific to Eeloo, would you reinstall the game and redo your entire mission entirely stock just so you could report it?

Maybe I should make it a poll.

Edit: Made it a poll.

Edited July 29, 2013 by Tiron

[AlternNocturn]

Then don't. If it's such a hassle leave it be and continue playing the game.

[Tiron]

Then don't. If it's such a hassle leave it be and continue playing the game.

Except that's rather bad for the game, isn't it? If people encounter bugs and then don't report them? That's kinda my point. Making it very difficult to report certain classes of bugs is a surefire way to make sure those classes don't get reported much, and I don't think any of us want that. I certainly don't.

But location specific bugs have exactly that problem with the new policy.

BTW, the hack gravity thing unsurprisingly worked, and I'm once again driving up mountain slopes at 30 m/s.

[Sean Mirrsen]

Your poll is missing the right option. If it's a bug I can recreate, and I have utmost certainty that it has nothing to do with mods, I will report it anyway, policy be damned. I'll explain the bug and the situation, and ask stock-using people to attempt a recreation, and/or attempt to recreate it in stock form myself later on.

A bug is a bug. If you don't report it, it will go unnoticed. Even if it does turn out to be mod-related, all you're doing wrong is posting it in the wrong subforum. Lesser of two evils.

[Tiron]

Your poll is missing the right option. If it's a bug I can recreate, and I have utmost certainty that it has nothing to do with mods, I will report it anyway, policy be damned. I'll explain the bug and the situation, and ask stock-using people to attempt a recreation, and/or attempt to recreate it in stock form myself later on.

A bug is a bug. If you don't report it, it will go unnoticed. Even if it does turn out to be mod-related, all you're doing wrong is posting it in the wrong subforum. Lesser of two evils.

I didn't include that since they say they'll close threads that don't follow the guidelines, so I'm presuming that if you continually ignore them you'll end up getting banned from the forums sooner or later, or something.

I DO find it hard to believe that all five of the not-me people that voted don't use any mods at all. The way the guidelines are phrased ANY mod at all counts.

[Sof]

If you find a terrain bug, chances are it isn't caused by part mods or anything.

I'd just report it anyway to let the devs know there is a possible glitch. Let them test it.

As for Eeloo glitches, just download hyperedit as your only mod, jump to Eeloo and then uninstall the mod. Your rover would still be there.

[Tiron]

If you find a terrain bug, chances are it isn't caused by part mods or anything.

I'd just report it anyway to let the devs know there is a possible glitch. Let them test it.

As for Eeloo glitches, just download hyperedit as your only mod, jump to Eeloo and then uninstall the mod. Your rover would still be there.

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.