Bartybum
-
Posts
278 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Bartybum
-
-
On 7/19/2019 at 1:45 PM, Azimech said:
You know this game has a very steep learning curve. So what is wrong with some extra complexity ... because we're talking about the DLC here. The DLC added stuff most users have never used before and maybe never will. Infernal Robotics paved the way. So aside surface features, the DLC is aimed at exactly that userbase wanting to do more. Do complex stuff. And I'm glad Squad recognizes a lot of people actually consider KSP a powerful design tool, much more than a game. Because in ways, the editor is the biggest selling point. Not career or science mode. The gameplay is flawed and I haven't had the interest to complete the tech tree since 2014.
[snip]
Personally I'm not against the idea of it, as long as it's optional. From what I've gathered you're open to this, so we can move on.
My issue is that I don't think it's the time to start tackling it yet - not when after more than six years there's still serious polishing (more complete part sets, weather/clouds) and features (life support, more planets, more systems/FTL) that have been missing from the game - features that are vastly more integral to the mechanics/logistics of spaceflight, and the game's story/identity. Features whose absence leave me feeling like I'm playing an incomplete game.
Once that's all done, by all means please, bring it on.
-
Just now, LekkoBot said:
I agreed with you up to here
Well you'll need more than that for a discussion lol. I'm talking nothing more complicated than one or two resources, ala the Snacks! mod. It's really nothing complicated.
-
9 hours ago, Azimech said:
Squad, please add realism. Heat production, mixture control, flameouts, compressor stall, progressive damage, proper starting sequence for turboshafts. And sound for all turboshaft/motors/props/rotors.
I understand that some players will relish in the opportunities that more realism offers, but KSP is a game at heart - I can guarantee that 90% of the community isn't gonna care for compressor stall, mixture control, proper starting sequences etc. They just wanna fly in space and visit planets.
I'd MUCH rather the devs focus their efforts on content that majority of the playerbase will want to utilise - more/better parts (we REALLY need more adapters, long/short landing wheel varieties, more 0.625m fuel tanks, etc.), basic life support, more planets, clouds, art improvements, etc.
-
1 hour ago, XLjedi said:
Well it applies to me, I shoulda known better... and since the vast VAST majority of aircraft, particularly single engine props, have rotors that actually turn CCW when looked at from the front, it is a bit curious (particularly with those inverse values) that CW is the default for a rotor and engine! If anything we should be scolding @SQUAD for a default that doesn't mesh up with reality. They claim they've modelled P-factor and folks are looking for a roll to the left and countering with right rudder, and we get the opposite by default. Although... I have to say, that does seem to be a pretty kerbal-ish design issue!
I will just ALWAYS be changing my motor and prop rotation to CCW as a default for all of my single engine craft. Good thing to get that sorted now before I build a bunch of stuffs.
I mean, it's not really fair to blame them, because it's in the name - COUNTER-clockwise, "counter" meaning "opposite to the default", the default being clockwise.
I don't really think one should be worried about default settings not lining up with arbitrary standard practices, especially since Kerbals are their own nationality. To me, the issues relating to physics are much more important than those relating to national convention.
-
I wonder if having tweakable prop discs as a single part would’ve been a better idea. That way you could use smaller fudge factors.
-
9 hours ago, XLjedi said:
I shouldn't speak for @Bartybum but I sorta took his original comments as the +/- values for the authority limters seemed to have values opposite to his expectation. Good news is, we are free to install them at whatever rotation we like. ...and I do like and prefer aligning them with leading edge facing directly into the motor rotation direction. Exactly as he suggests.
Yeah no you’re right, that’s pretty much what my argument stems from. It’s more about the principle of it, and teaching KSP players the right thing. Because at the moment what it teaches imo makes it more difficult than it should be.
Regarding the European CW/CCW stuff, that doesn’t really apply to me because I already knew that the direction was defined being viewed from the front. But yeah, changing your engine to CCW fixes the invert issue.
-
36 minutes ago, XLjedi said:
It's kind of a lengthy discussion but sure... I will post another video related to some of the things I've discovered while converting a jet to a multi-engine prop. First understand that if you have the engine and blades setup with counter rotation, the values for authority are inverted. So the positive and negative behave more the way you might like to see it if your engine and blades are rotating CCW.
Secondly, if you mount the blades facing forward... and you change the orientation of the engine/blades from CW to CCW, the blades are still facing forward. If you have the blades facing the "correct way" (as you have noted) when you change from CW to CCW you would also have to rotate the blades 180° so they face in the correct direction. When you are trying to setup multi-engine layouts with counter-rotating props, it's this last step where you'd have to rotate the blades that the editor can get wonky (due to mirror symmetry conflicting with radial symmetry) if you're not careful.
Now, for me... I think in the future I'll be mounting the blades exactly as you have stated regardless of multi-engine design or not. I know how to work around the issues in the editor and I'll show folks how to do that in a video so they can mount their props with zero pointing either CW or CCW, and still allow for radial symmetry to apply to the blades (so you don't have to place them one-by-one) and more importantly, be able to assign a single blade authority in your hotkey assignment and have it apply to the whole grouping of blades on a single motor grouping.
I still intend to remap the range of motion for the feathering of the props in my designs, but I also want to maintain the ability to have them feather for reverse thrust with the leading edge facing in the proper direction. So I prefer your blade orientation, and it's consistent with how I mount rotors, so I like that consistency also!
But I don't think @SQUAD needs to change anything. The only minor gripe I'm hearing is the values aren't positive for a CW rotation. If they inverted it, you'd still see the negative values appear for forward thrust on a CCW motor setup.
Sorry, I should probably elaborate that when I say that the devs got it wrong, I mean that the blade variants should have been mirrors of each other around a plane 90 degrees to the current mirror plane. The inverted deployment stuff would be solved by changing that. Under my method it'd be like this:
Clockwise:
Counter-clockwise:
-
5 hours ago, XLjedi said:
It may have been accidental, but I've seen advantages at design time to the way they've done it. Particularly related to design-time creation of multi-engine layouts with counter-rotating prop designs. ...and mounting the blades with leading edge pointing directly forward.
Can you elaborate what you mean by design-time creation of multi-engine layouts?
-
Relax, he's not being snarky.
Single prop aircraft have to deal with the unbalanced torque too. In KSP people just counter the torque with reaction wheels.
-
6 hours ago, Starwaster said:
No I'm sure that they do not intend for you to do reverse thrust by driving the airfoil backwards. A little more research went into propellers than that.
I mean, that's quite literally what their method does, if you look at it in game. If you apply negative pitch to the blades, the blade airfoil starts moving backwards through the airflow - just take a look below:
(This is a clockwise running motor by the way)
If you're wondering what about when the aircraft is flying forwards, I can tell you that the deployment required to produce negative thrust becomes more positive the faster you go. It's why if you reduce deployment your aircraft is forced to slow down.
Look, I'm sure they put research into variable pitch propellers, but to me it's obvious they missed this. The whole reason I orient my blades the way I do is that by doing so I always driving the airfoil forwards through the flow, because that's how an airfoil is designed to run, with the curved end at the front, and the pointy end at the back.
-
9 hours ago, XLjedi said:
No. As they are now, I would just completely ignore the roll/pitch/yaw and focus purely on cyclic pitch control (deployed like flaps and managed via authority value).
You mean collective, not cyclic. Cyclic controls each blade independently, whereas collective controls all at once
-
On 6/5/2019 at 12:49 PM, Angel-125 said:
Ok, I have created a similar vessel to yours and observe that at 10,000x time warp:
delta time is 200
input efficiency is 19.8 (specialty base is 0.05, efficiency bonus is 0.1, crew rank is 5, recycler supports 4, 1 snack per meal, 3 snacks per day)
Base EC input is 3
Base EC input * input efficiency * delta time = 3 * 19.8 * 200 = 11880
Based on these numbers, you don't have enough Electric Charge aboard to handle the 10,000x time warp.
This is a bit late, but from my understanding, would it be correct to say this isn't a problem with snack use rising non-linearly with time-warp, but with the EC calculations being tied to delta-time?
-
10 minutes ago, XLjedi said:
@Bartybum To your point yesterday regarding swashplates... (I think that was you anyway?)
I was noodling on that today and it seems it would require the blend of two inputs. It seems you'd need to be able to adjust or blend together the control inputs for both the deployed and undeployed rotor blades. I have not quite grasped yet how they intended us to control both the roll/pitch/yaw of the undeployed vs. the authority limiter of deployed that is used for lift? To me it seems we'd need away to control both of these inputs at the same time.
Not sure there's a mode for doing something like that with the rotor/prop blades?
I've been thinking about it too, and I think at the very least you'd require some sort of way to detect the angle the rotor hub is at in order to be able to do that, as well as lump various inputs to a single action.
To be honest I'd really like to see a primitive scripting system ala WireMod from Garry's Mod, that lets you take output values of a part such as thrust, fuel consumption, mass, capacity, status, etc., and then use those as a list of inputs for another object.
-
19 minutes ago, XLjedi said:
I see... you're installing them a bit different than I did. I thought the range of motion was a bit wide on the props, so I just left mine pointing forward, but I like your positioning better I think. I may have to tinker with that, I was trying to go for easiest possible installation to get people to a workable fixed blade prop. But the way you point the leading edge is probably more correct, and it's consistent with how I mount the rotor blades. ...and your forward/reverse thrust has the correct leading edge. So agreed. But why do you think that works in reverse?
Well I mean, it works in reverse because under my system, pitching the blades backwards induces a negative angle of attack between the flow and the blade, generating negative lift.
Just now, XLjedi said:I wouldn't worry too much about it, just invert your values when you assign the pitch to your preferred hotkey.
Don't worry, I saw the edited post
I'm all too guilty of doing that myself. But yeah, I'm happy to cop the few extra seconds adjusting stuff, and sit back with the knowledge that what I'm doing is technically the correct way 
Another thing that I've noticed is that the helicopter blades are set up under my system by default, but the turboprop blades aren't. Quite interesting
-
17 minutes ago, XLjedi said:
I see... you're installing them wrong. For these kerbalized versions of propellers. You should install them so the leading edge faces directly forward. If you watch my video, you'll see how the full range of motion works. I'm not an aerospace engineer, but I've done my share of studying as well and held a pilots license for nearly 30 years.
Well then, I'm confident in saying the devs got it wrong. Under their system, reverse thrust is done by driving an airfoil backwards into the flow (see below), which is absolutely not how reverse thrust works in real life. Real reverse thrust is done by driving the airfoil forwards but at a negative angle of attack to the flow.
Thoughts, devs?
-
1 hour ago, XLjedi said:
I really don't see any problems or a need for any workarounds...
Edit: additionally, the deployment of blades is not reversed. (possible your understanding of lift vectors is though) ...and there are two variants for each blade, one for CW engines and one for CCW, make sure you're using the right ones for the direction your engines are turning. Why do you think you need a hologram to determine the facing of a blade? Watch my video.
I understand how lift vectors work - I study aerospace engineering
I position mine such that 0 deployment corresponds to 0 pitch:
And then forward and reverse pitch, respectively:
Dunno what to tell you, but that's how I do it. I base it off this:
I have no idea what other way people would position the blades.
-
8 hours ago, Shadowmage said:
Honestly, its NOT accurate to real life (at least RC modeling). On my aircraft, I slap on a prop, hit the throttle stick, and watch it leap into the air. None of this dickering with deployments, inversions, etc.
Even the collective pitch RC propellers aren't that much of a PITA to work with. One extra axis to map to a servo, and one additional servo to configure, and the rest is exactly the same (mount propeller on motor, profit!). Even full cyclic-collective propellers (yes, they are a thing...when you want extreme thrust-vectoring on an airplane) are only slightly more complicated to setup, requiring only adding additional servos for two more axes'.
After playing around with the propellers and helicopter blades, I will certainly agree that these have been made far-too-needlessly-complicated for a stock KSP mechanic. And I love complexity and configuration, so for me to say something is 'too complex', generally means something is wrong with it at the basic design level. (essentially, there needs to be configuration, but things should 'just work as expected' when used in their simplest configuration; these do not work as expected, in any configuration) (I'm not saying that don't work... because they do in very specific configurations... but the configuration needed to make them work is has zero logic in it).
I can agree with your first point, but only to the point that the devs should've added fixed pitch blades too, for those who aren't interested in variable pitch. Saying that variable pitch blades aren't accurate to real life because they're not fixed blades is not a valid argument, because they're not trying to be fixed blades. Other than that, variable pitch is awesome, and (save for the few problems outlined below) I don't see how else it could be set up. To me it's no more complicated than configuring flaps with an incremental authority limiter.
Cyclic-collective pitch propellers are notoriously difficult to build efficiently and stably out of props, and (as far as I'm aware) aren't possible with just the blade and rotor pieces, so I'm not sure what point you're trying to make there.
So far I've encountered three main issues:
1. I don't think the symmetry and inversion issues are the fault of the blades, but the way KSP handles multiple symmetry groups for the same part. I've found that if hubs are part of the same symmetry group, then you can't attach X blades to one, and X blades to the other, because the editor will automatically set symmetry to mirror instead of radial, and add a single blade to each hub. As a result you can't have both rotor hubs be part of the same symmetry group, and consequently the hub "invert direction" tweakable becomes redundant when using blades.
2. However (and I WILL fault the blades for this), the deployment of blades is reversed (for me anyway), meaning that positive pitch requires a negative input, which logically doesn't make sense. When you choose the counterclockwise blade variant, the required deployment direction suddenly reverses. This is strongly tied to the fact that different variants are symmetrical around the wrong plane (the opposite blade variant is 180deg backwards, rather than just counterclockwise but still facing forward), so you have to also rotate the blade.
3. There's no hologram indicator to say which orientation is forward facing.
These problems are purely editor based, and I'd imagine 2 & 3 are simple fixes (number 1 will be a bit harder). However, once you acknowledge these problems they're super easy to work around.
-
-
Stock (except for Mechjeb autopilot) King Air bootleg, dubbed Aeris Regent. Max cruise speed at these RPM and blade pitch settings. Weirdly enough, increasing RPM any further reduces acceleration.
Uses E-props powered by fuel cells. After flying for an hour at this speed, it's used only 1/6th of its fuel, so this thing could maybe circumnavigate Kerbin, even more so if I added another set of solar panels
-
@Dragon01 I’ve just thought about another thing - what orientation are the props supposed to be installed at? Because up until now I’ve had them installed them such that 0 deployment corresponds to the props facing into the freestream (full pitch), and 150 deployment corresponds to no pitch (props facing in-plane to the prop disc).
I feel like I’ve been doing it wrong, because intuitively, zero deployment should correspond to no pitch and full deployment should correspond to full pitch. I’m gonna go experiment a bit more now.
I wish there was some sort of marker you could enable for the prop to help identify whether you’re facing the correct way.
EDIT: I can report that I have found a marker! At the edge of the blade (for blade type B anyway) there's a light grey triangle - mount the blades such that when not deployed, the arrow points sideways. That way when you deploy them, the arrow turns forward or backward depending on which way you want to go. This isn't super obvious though, and it took me a bit of time to notice it. I've also found that when cruising, it may be in your interest to reduce your RPM and increase the pitch on your blades. Somehow this resulted in roughly a +25m/s speed boost... this seems fishy
-
6 hours ago, Dragon01 said:
For instance, prop pitch (as controlled by authority limiter) should go from about -20% to 100%. Right now, if set up to respond to throttle, it goes from -150% to 150%, which results in only a quarter of throttle axis range being usable. Beyond 100% authority, they seem to lose thrust, and you only need a little negative range for thrust reversal. A way to clamp it would be supremely useful.
I agree, there should be a double sided limiting slider like for actuators, hinges and servos - binding blade pitch authority to throttle should traverse along that limited region. That being said, I wouldn’t bind pitch to the throttle, but translation F/B, and let the throttle control the RPM.
In addition, pitch beyond 100 isn’t useless at all. I’ve found that blade type B is most effective for takeoff when deployed at 115, then you reduce the deployment (i.e. increase blade pitch) as you roll down the runway to pick up more speed. Blade pitch is pretty much an air-based gearbox.
-
This update is so great. Really enjoying trying to learn about variable pitch and constant speed propellers by messing around.
A small thing I'd like to see though - regarding action grouping, it'd be really nice to be able to reverse the deployment direction for blades and control surfaces via action group, as this would allow quick reverse thrust on landing. It can already be done by incrementally limiting authority, but a quicker method would nonetheless be nice.
Another thing would be to have a 0.625m equivalent air breathing turboshaft for smaller aircraft, or at least more 0.625m LOX tank options to use with electric rotors and fuel cells.
-
13 hours ago, Angel-125 said:
Your PC may slow down when you open the Snacks window as it needs to do some calculations for the display.
The slowness isn't temporary though like you'd expect from a few calculations, it keeps persisting for as long as the game runs. In task manager, CPU usage jumps from ~25% to 95%, and stays there until i reboot the game. Are there any mods Snacks is incompatible with, say Restock or Stockalike Station Parts, etc.? Those are the only two that I can think of that integrate Snacks into their parts.
-
On 7/2/2019 at 12:12 PM, Angel-125 said:
Right now that's a known issue of background processing, possibly the SnacksProcessor running in the foreground too.
Is this what's causing excessive stress on my computer? When I'm playing KSP, everything runs smoothly until I click on the Snacks! icon while piloting a ship, upon which the entire game starts lagging out/stuttering like crazy.
I'm all too guilty of doing that myself. But yeah, I'm happy to cop the few extra seconds adjusting stuff, and sit back with the knowledge that what I'm doing is technically the correct way 
Finish the storyline in next DLC?
in KSP1 Suggestions & Development Discussion
Posted · Edited by Bartybum
Regarding a storyline, I'm not sure I'd want KSP to actually have one that plays out via plot.
I'd much prefer we get given small snippets of lore over time that tease information about ancient Kerbals (it's obvious at this point that they had interplanetary ancestors) - stuff like the face and SSTV signal on Duna, the Kraken, the ruins on Val, the pyramids near the Dessert launch site. Small bits and bobs that are added from time to time. Stuff that when discovered, incentivizes you with science via contracts to set up a base, collect samples, data, reputation, etc. Nothing necessary, but stuff that'll reward you for your curiosity with snippets about ancient Kerbals.
I see this as the perfect non-invasive way of including a story.