Quiana
-
Posts
82 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Quiana
-
-
3 hours ago, TMS said:
Years ago, Squad maintained a policy that the game would not contain Steam Achievements. The rationale behind this was some high-minded belief that KSP should aspire to more compelling gameplay challenges than mere achievements.
This never really made a great deal of sense to me, given that achievements encourage divergent player behaviour that they otherwise wouldn't do, and that such achievements are a time-tested and proven way of giving players the dopamine hit they want.
Since the impending console release success appears to have tempered the aversion to achievements that once existed, can we safely assume that Steam players will receive the same features or, indeed, that non-Steam PC users will receive the same features as part of the core game installation?
This is good, but the current reputation penalty for declining contracts will be counter-productive to your aim of giving players more control.
Is the intention to remove this?
TMS, they've already confirmed that consoles actually have a REQUIREMENT for achievements. They never wanted to put achievements in as they do also cause the exact opposite, causing a completionist to do them to get them done. The best rewards sometimes in a game like this is not the game patting you on the back, but your own sensation of joy when you complete something you've struggled at or thought 'I can do that too.' when you see someone else's work.
-
I wouldn't be too worried. All ckan does is keep track of where mods can be downloaded from and then downloads them for you. If you're suspicious, you can take a look at the metadata and see exactly where it downloads the mod from - in case of CollisionFX the download link is (https://kerbalstuff.com/mod/381/Collision%20FX/download/3.2), which is the same as clicking the download button here: https://kerbalstuff.com/mod/381/Collision%20FX
Also the CKAN database is actually built right off kerbalstuff, so, it only parses what's on that site. It won't do any other external links, either. The protection from a bad thing on there is the requirement for source code to be published and with the program, so you can do a comparison or virus scan it beforehand.
-
This demands the question of how many of us will use it with cryo engines/NFP? If not that many, unnecessary. If lots, then yeah, good ideas.
If not, then I'm sure a quick MM patch can add those swaps into the tanks, based on their dry volume and the mass of the appropriate fuels. If you need some aid, I can read up a bit and give some sample configs for the IS fuel swap module.
-
This is a hardy perennial. There is a reason why it's that way. (I forget what it is).
If I recall right, the reason it is this way is due to the wealth of information required to setup the parachutes. They are highly configurable, with good reason and need the extra space from a dedicated place to be displayed. Not only that, but you certainly do not want to accidently open all that information with a right-click on your chutes, or have to open the UI Window through each chute (though there is a symmetry toggle inside the GUI to setup symmetry partners).
-
Also you may want to actually update your MM to 2.6.5, rather than 2.6.3. It doesn't hurt to ensure it is up to date.
-
There is not enough reputation on the forum to really describe how wonderful your texturing on those models has gotten to. I remember when it first came out, they were impressive then, now they're just incredible. Looking forward to the 2.0 concepts as well, unless you're keeping those preview ideas to the development thread for the most part.
-
Quick question, call me a bit dense but if one wanted to remove the extra tag for Kerbal count in the editor but retain the mass changes in flight, what would I need to do in customizing the MM provided file for this? I like the concept of adding the weight and having to mentally adjust for it, but I also don't want to clutter up my editor windows with an additional slider as I have a fair few of those with my mod list.
-
Well my sash must be at my folks' place. I have all the badges from camps, cub scout activities and the like, including my eagle sash and dress pin (the one for lapels on suits) but not the sash itself. I'll find it eventually.
-
I noticed this from your signature. I too am an Eagle Scout. I started in Cub Scouts. I'll get a merit badge count when I get home and find my old sash, it's in storage someplace. Nice to see that we do have a few eagles on the forums.
-
Just tested the two parts, then fixed the 5 and tested again to be sure I was doing it right.
The top and bottom nodes on the 8 are backwards, just need a sign flip on the appropriate angle column in the part cfg.
The top, bottom, and "back" connector on the 5 are backwards, same fix. The "back" connector is the one that points to the back of the VAB if you pick it as the first part, it's node_stack_side0 in the part cfg.
This page has all you need to figure it out, if a mod OKs it I'll post the lines I fixed in the part configs later, I don't understand the licensing well enough to be sure it's OK.
http://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation#Node_Definitions
The license allows you to adapt and share as long as it is under the same license (IE anyone who receives is under the license, cannot use commercially, and must give credit to the original source). Did you check if they seat alright after the changes with no gaps? I know a few parts had to have minor shifts in some mods besides the +/- indicators on nodes.
-
Dev Update: Yes, even information and updates can be unpredictable! However, I've started to get back into it, slowly removing problematic numbers, still doing tons of tweaking, and hoping that things turn out. When they do turn out reliably, I will move onto the next step, which is making the temps move with the wind and then from there I'll be working on stock drag and applying that with the wind. After that, it'll be release time!
Just a side-note from looking at this again, you may want to investigate the shared module between DRE/nuFAR. I cannot recall the name of it, but there were issues with mods that adjust a certain stock module competing with each other, which prompted both mods to share-write that custom module to integrate with the flight director. You may want to look into that, seeing as this is likely going to interact with that same director. Could be a potential issue with compatibility in the future.
-
In pre-release, jet engines had velocity curves. More intakes allowed one to have more thrust at altitude without flaming out. In 1.0+, jets have both velocity and altitude curves (and the velocity curves are different than before). The RAPIER gets a 9% thrust modifier from altitude at 20km (though the velocity curve can make this number higher) and it decreases exponentially above that height (3.3% at 25km and 1.2% at 30km). Thrust also decays linearly to zero from Mach 5.5 to 6.
In pre-release, the turbojet had good thrust up to 1800m/s or so and at any altitude (provided enough intakes, and it didn't stop thrusting until 2200m/s). With the 1.0 changes, RAPIERS (the highest/fastest jets) simply provide very little thrust above 20km, and even then only up to just over Mach 5.5 (anyone know how fast that is at 20km on Kerbin?). This also means that less air is required. Engines will fall off to diminutive thrust well before flameout, usually. If you have multiple engines and they flameout together, that means that they are simply going too high/fast to thrust any longer. If they flameout asymmetrically, that can be solved with more intakes. I have never flamed out with 2 intakes per engine, and usually 1 does well enough. Intake spam is no longer necessary to extract the full performance from engines.
A little helpful support on asymmetric flameout here: http://forum.kerbalspaceprogram.com/threads/119607-Airbreather-fuel-flow-logic?p=1909169&viewfull=1#post1909169
As indicated, Intake spam certainly does not work, engines perform much in the same manner as the RL versions do (albeit significantly higher thrust values). Just check your intake placement order to ensure each engine is fed correctly and you won't have issues with flameouts in anything but a symmetrical/staged pattern. If anything, the drag from additional intakes will significantly hurt you compared to actually gunning for a little under the max height to air ratio.
-
Then why not stick with Ablator only?
I'm with Enceos on this one. The Ablator resource in stock has the same density/etc as your own AblativeShielding resource. I think the question isn't making/altering the stock resource (unless you feel the resource values need to change) but in using the existing one instead of having a separate resource tracked by just your use (or others tying into DRE) since it would be assumed most other heat shields/etc are tying into Ablator. Since the values are the same right now for both resources and I do not think the heat shield weight/cost has ever been an issue, it makes good sense to go ahead and tie into the stock one and drop the extra resource.
-
OK, Thanks to Kevin, I have a dll for windows. However, it seems there may be some issues with SDL input. This is still being investigated.
That's great to hear Taniwha. Please let us know if you need a Windows 8.1 test subject. I'm still having issues with my Saitek Cyborg X stick and need a replacement for stock joystick detection. However, the older AFBW had issues with 8.1 that were never resolved. As it is, a friend is shipping me two older Logitech sticks just in case but I'd love to be able to use my X properly for KSP.
-
Like all things SQUAD in the past when they decided to implement people's mods in KSP - the heating model they implemented is half-cooked with blood still dripping out of it. Even at 120% heating and FAR the only way to actually get in danger of running out of Ablator or destroy your craft with overheating is if you intentionally do it.
DRE, like FAR and some other mods, will always offer a much higher quality of implementation than stock. You can also paraphrase the previous statement as: "It will make the game harder than Stock", rather than "SQUAD sucks".
We could give them a little credit, as it is the heating method itself is relatively what we wanted. What they forgot to accommodate (or purposely left out) is the very reason heat-shields exist. Skin heating. Their model accurately depicts how general heating would work, distributing through the mass of the craft. It's only during the re-entry phases that this model fails to work as it applies heat until the entire mass is heated to failure, rather than what Star is working on where it will calculate the failure of the outer skin which would in turn more than often destroy the parts during reheating. This is why we still need DRE, but we can use the stock model for the most part in general heating applications. I'm sure there will be others who hook into the radiator concepts for heat management to a much better degree than Squad foresaw.
-
Set them up like this, placing in the same order:
AIR1
AIR2
ENG1
AIR3
AIR4
ENG2
If at X height each AIR produces 1 unit, and the ENG consumes 2 units, then they're evenly matched and you have no 'waste'. Beyond X height (which is now the maximum height of flight for this example setup) you'd flame out because both engines would starve within the same second and thrust would be cut evenly.
The concept scales up the same way, so if you wanted to have a four-engine you could setup this way and still have symmetric flame-out:
AIR1
ENG1
AIR2
ENG2
AIR3
ENG3
AIR4
ENG4
Now as a complex example of four engines, we have this which LOOKS like it would be okay, but doing an example shows the problem:
AIR1 - 1.5
AIR2 - 1.5
ENG1 - 2
ENG2 - 2
AIR3 - 1.5
AIR4 - 1.5
ENG3 - 2
ENG4 - 2
This would be just a bit above X height (maximum sustainable flight) for all engines. ENG2 would immediately flameout, BUT, the leftover 1 air from AIR1/2 would be passed on to AIR3/4 making a total of 4 air, which would leave ENG3/4 running. This would cause asymmetric flameout and rotation.
-
If this is correct, would that mean that you could avoid flameout by always placing all your intakes before placing any of your engines? I'm not sure if I understand what the implication here is.
Incorrect. If you did that, it would look like this:
AIR1 - 1
AIR2 - 1
AIR3 - 1
ENG1 - 2
ENG2 - 2
The air for 1-3 goes into ENG1, pushing the necessary 2 air. The leftover 1 unit of air is pushed into ENG2, which is not enough to sustain it and it flames out.
Also check my last post, I edited because the formatting threw it off. order is top down, and it wraps back up to the top at the end of the cycle.
-
I learned a most-valuable thing from a NathanKell post:
If your engines ever flameout asymmetrically, then you don't have enough air intakes. If you do have enough air intakes, your engines will flameout symmetrically when you get too high.
Unless they've changed the behavior for air intakes, this is somewhat correct. I am not sure if the old behavior is still valid, but it would be an artifact of the order of attachment for intakes to engines. The pool of intakes to engines would look like this if you attached two intakes, an engine, another intake, and an engine:
AIR1 > AIR2 > ENG1 > AIR 3 > ENG2
So in effect, air collected by 1/2 intakes is first pushed to ENG1, then past and pools leftover with AIR 3 which goes into ENG2. What would traditionally happen is that as you went higher up, ENG2 would flameout first as AIR3 would be exhausted and only the scraps of AIR1/2 get pushed into ENG two, whereas ENG1 is consuming two intakes entirely by itself. Excess air from AIR3 that ENG2 isn't using also does wrap around back to AIR1/2 pool.
A math example of this: (AIR produces, ENG consumes)
AIR1 - 5
AIR2 - 5
ENG1 - 3
AIR3 - 5
ENG2 - 3
This would result in 10 air going to ENG1 with 7 leftover air going to ENG 2 (total of 8 to ENG 2) leaving a total of 9 air in the pool.
As you went up in altitude, the intakes produce less, so the next model:
AIR1 - 1.5
AIR2 - 1.5
ENG1 - 3
AIR3 - 1.5
ENG2 - 3
Here we can see that while ENG1 still has just enough to continue to operate, ENG2 is receiving no 'spare' from AIR1/2 and thus ENG2 starves and flames out. In order to balance this, it was always a factor of putting an even number of intakes before each engine to ensure that the pool fed correctly into each engine. Please note my math examples aren't actual figures, they were made up.
The new model does help in terms of starvation, so it's rare that you will need more than one intake her jet as mentioned by Arq, but these rules still apply if you are using more than one intake. Never place your engines and intakes in symmetry mode on planes without remembering this as it can cause asymmetric flameout.
-
Updated download to optimized textures, as well as merged downloads - with installation instructions for both options. Thanks for the optimization tips InsanePlumer!
Hi Avera9eJoe, just to let you know your link is directing to the older 0.06 download, rather than your 0.07 one.
-
I should clarify- Lowering the gear reduced wave drag before I added the bulges. Once the bulges were in place lowering the gear increased the wave drag area, which is more in line with what you'd expect. I suspect that my landing gears just happened to be in the right place to reduce the wave drag when they were deployed- a fact that was no doubt partly a result of my forgetting to retract the gear while I was working on the layout.
An example of the 'happy accident' effect is perhaps illustrated by that bulge I added just below and in front of the cockpit. It's placed directly over the nose wheel because it turns out that the nose gear was in just the right place to smooth out the changes in cross section caused by the cockpit when it was extended. The bulge emulates that effect while keeping the gear retracted.
Edit: I fixed my grammar.
May be a bit late to the party, but it depends on the gear you're using. One of the landing gears has, for some reason, more drag when it is put away rather than when deployed. It's a stock bug, I believe it's mentioned more precisely in the Stock Bug Fix sticky. Take a look at that and see if it's the offending gear, it probably is not nuFAR at fault in that case.
-
Version 3.0.1 is now available. It fixes the issue with sparking wheels.
Thanks a ton Pizza, this is an excellent mod. Just a warning though, you may want to update the first post to reflect the new version (as I didn't realize you'd updated it to fix the landing gear bug).
-
I also have the same issue, as it isn't just a particular set of the Saitek family. My Cyborg-X has tendencies to lag behind and have some 'stutter' on inputs when used for KSP. Controls seem abnormally behind my input with current KSP. Unfortunately, even the AFBW was unable to assist me as it did not support the Windows 8.1 OS with all sticks and would only register a gamepad I owned.
Mind you, using the joystick in any other game has prompt response times and windows reports full use of the joystick and immediate updates when testing.
-
Can I get a copy of your fixed up source? I'm curious as to how you did it, and I would like to mess around with it (yeah, I'm easily amused).
I still don't understand all the license stuff. From my point of view, if humanity could get over this whole issue with "This is my property, and it shows just how awesome I am... now pay me for it!" mentality, we could advance as a technological species at easily triple our current rate. Just give credit where due, and release your secret so we can learn from it. It drives me nuts how everything is locked up tight under heavy regulations and high price tags. Anyway... moving on.
Good to know it's not very restrictive. I figure we could eventually integrate it when we reach the point where special effects are necessary. Right now, the only special effect stuff being modded are in clouds and exhaust trails. People have yet to jump on the bandwagon for tire tracks and dust trails, especially with the stability of higher-bit-rate processing in such turmoil.
I gotta say this though, my little mini-stroke did get me to bed at an unheard-of time (before midnight, can you believe it?) and, if you hadn't been messing with that stuff, I'd have been all refreshed to tackle that code again... if I didn't have to go to classes now. So give a cheer for mental breakdowns and miniature medical emergencies. They sure work wonders.
- - - Updated - - -
And I thought I was nuts with my wacko ideas. You have defeated me. Keep it up. I like this idea a lot, though I'm the kind of player that would cheat and disable most of that fucntionality so I don't have to worry about all that maintenance shi... err... poop. Even with that, though, I'd probably be interested in looking into something like that. You'd probably want to first look into the RPM/vesselviewer plugins (not the screen-shot grabbing one, the in-flight 2d-ship-modelling one) to see how things like this can be tracked. Then, you'd want to look at how the physical gadgets are put together for tracking information in the B9 package IVA setups. as for the actual wheel wearing out, I'd think something like the deadly-reentry plugin and it's "ablative shielding" resource would do the trick.
Would the wearing out thing be much better tracked with a mod designed for failures? A Dang-it link might be a better use than that, rather than making something like its own wear-out resource. It tracks the MTBF, so you could have it feed in 'damage' events over time from particularly rough incidents that decrease the MTBF, with maintenance increasing MTBF. A complete break would probably need a small event for replacement rather than spare-parts repairs, but it might be doable in that method with a lot less hassle than tracking your own resource in the plugin.
EDIT: Also, it would give the option to leave it non-breaking for more casual use, or have something like Dang-it to add that functionality in rather than having to handle it yourself. A few simple MM checks can make it function either way and leave it outside of your wheel/track plugin.
-
I'm having the same issue, the before-ground impact isn't working, but the time-change before deployment of chutes does work (real chutes for me).
[1.1] AFBW v1.7-beta (Joystick & controller mod)
in KSP1 Mod Releases
Posted
I figure I'll ask and see if any Win 10 folks have tried this. I know we had discussions before about issues between this application, Saitek, and Win 10. I can try it later when I get home but I've got a busy day today so I may not be able to verify if the bugs pre-1.1 are gone now.