Dappa
-
Posts
37 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Dappa
-
-
15 minutes ago, lajoswinkler said:
I just hope it won't be another case of "it's too hard, let's pander to the most inept of the players in order not to lose interest and forget about tilt".
I suspect we might get axial tilt! Looking at Duna(1:32 in the trailer) with a fully lit ice cap suggests it's about 90 degrees titled. Also look at the ringed planet at 1:58, the terminator doesn't cross directly over the pole but seems to be a few degrees off. Similar example at 2:13. And because rings are typically in an equatorial orbit, axial tilt is a much needed feature to light them properly and make the game look good.
-
Awesome! Will KSP 2 allow for planets with axial tilt, like Earth's 23.5°?
-
5 hours ago, TriggerAu said:
The text in the Maneuver Mode tool was set to match the existing one on the map nodes, if you'd like a change to the text a feedback would be the best way to proceed as we would change all for consistency if we did - I didnt find one for this request in a quick search.
I'd say intersect is definitely the correct term. Even the example above clearly shows that the two trajectories intersect, yet closest approach is 6025.1km, so there is no intercept! Leave it as is.
-
Although this is an old thread, let me just add my voice to this. I think it would be great to have Kerbin tilted a few degrees, with one moon on the equator and the other moon in the ecliptic plane.
-
I installed it but there's been no visible change. The distant object flares don't appear. As far as I know, I installed it correctly - I copied what was in the Gamedata folder to the Gamedata folder in the KSP directory. Pls halp
Do you have Blizzy's Toolbar installed? It's required for 1.4.0, and I assume it still is for 1.4.1 because there's no fix for this mentioned in the changelog.
-
Still requires the toolbar to change settings. I've debated adding support for the in-game app launcher thing, or allowing either to be used. That requires me to get the time to look into it.
Settings can be changed in settings.cfg. In most KSP installs prefer not to have the toolbar, because I never use it anyway.
However, since my previous post I've noticed that this mod doesn't work at all without the toolbar. No flares, no skybox dimming, no distant vessels, nothing. This was also the case in DOE 1.3 (the update that added toolbar support, or rather the requirement), which was the reason I asked in the first place.
-
Awesome, thanks for the update! Does this version still require Blizzy's Toolbar, or is its use optional?
-
I should have been clearer. Basically I'm creating a landing program, and at low speed the retrograde marker moves about alot and the ship ends up trying to chase it with comedic results. If I could get an idea of what heading the marker was in, then I could tell the steering to lock to that heading at a pitch of 85 to the horizon, so the retrograde marker slowly goes back to the top of the navball, and the ship doesn't chase the marker too much.
I hope that makes sense.
It seems you're looking for "velocity:surfaceheading". Just add 180 and you'll be going in the opposite direction.
-
Could you tell me what I'm doing wrong here? I made a short script to deorbit junk. I wrote this:
clearscreen.
print "Executing de-orbit burn.".
wait 1.
lock steering to retrograde.
wait 2.
lock throttle to 1.
Instead of locking to retrograde, the ship spins. If I type it manually it works. Also, the throttle never goes up, but also works if I type it manually. I put the waits in thinking it needed something between the commands.
Thanks.
EDIT: Also... after typing it manually, it doesn't hold after putting the throttle to 1; I have to type "lock steering to retrograde." a second time.
The problem with your script is that it just ends immediately after locking the throttle. That resets the throttle, and keeps the ship spinning if it wasn't done turning to retrograde.
To prevent your script ending too soon, try adding the following at the end:
wait until periapsis < 0.
That should keep your script running until you're de-orbited.
-
I was just thinking about modularity too, and I think Camacha has a good point. Modularity is what makes KSP so great. Having one part capable of doing everything would spoil that in my opinion, it's just too easy if you ask me. If you want to make a craft that can do everything, but it'll cost a lot of mass (and money).
In fact, I think Squad already takes this too far, by putting loads of torque on the capsules.
Well, then how much should a probe core (or crew capsule) be able to do? Real world robotic spacecraft execute a sequence of commands uploaded from the ground. They usually do very little decision-making, they don't calculate their own burns or required attitudes. The kOS computer lets us do much more than that, which brings us back to modularity.To think that a crewed capsule would NOT have the same computing resources as a probe, if not better resources, seems silly to me... Why force someone to attach a probe body on top of every crew capsule just to get access to that feature?I would agree with you on pods like the Command Pod Mk1 where they are designed to be replicas of a part that never had a serious computer (mercury capsule). Once you make it to the Mk2 Lander Can Or the Mk 1-2 Command Pod I think they clearly have some kind of computer in them so i wouldnt mind giving them a KOS module. I do think that For very primitive pods I would like to see limits such as smaller memory, read-only memory and limited available sensors added. All of that is just a wish so farJust thinking aloud here, you could go as far to make certain computer types capable of executing commands, but not able to run programs, or disable certain logic? I'm sure you'll find the right balance.
-
Version 1.3 released! See the OP for details. Should fix the vessel rendering bugs, and adds a few new features.
I don't see the planets (their flares) any longer in 1.3, while they were fine in 1.2. I also have not been able to spot any satellite flares.
-
But a bit of proper maths can make a beautiful script! So it's well worth the head-hurting.
-
I would be sad to see "Target active vessel" go away, as it's quite handy if you know what you're doing with it. Is hiding it behind an advanced mode setting instead of removing it completely an option?
I'm with you on that one, I quite like the Target Active Vessel feature, and it has never given me any trouble.
-
My idea of failsafe? Point a bigger dish at the lost craft. That should be doable with tweakables, but it would probably also require a simulation of antenna gain, instead of averaging ranges.
Just pushing a button to reconnect when you messed up, feels like cheating to me.
-
Things I'd like to have in kOS. (not in a specific order)
- Exponential falling efficiency of new antennas.
Meaning: With 5 antennas you will not have the range of 5 times one antenna but e.g. 3.05 times (factor 0.75). And while 11 Antennas give you the range of 3.83 times of one. It is impossible to reach 4. (Well with 27 you reach 3.9983 which is fairly close. And 40 brings you to 3.9999597737).
A 0.9 or a 0.99 factor might also be possible (0.99 means each new antenna is 0.1 less efficient than the one before). - Com range of the base module should be the diameter of KSC.
- Vessel to Vessel communication. Send them Values. Let them run programs. Shortly lets remote use them. Even a relay network might be possible.
So you want your data from Jool? Get some relay satellites!
I think having all those comm options would stray too far from the purpose of kOS. Such advanced communication capability would be better served by integrating kOS and RemoteTech. In fact, while the current communication system of kOS already is very simple, I think it should be simplified or omitted.
- Exponential falling efficiency of new antennas.
-
I posted the following on Github as a bug report, but it'll probably be read by some additional people here, for whom might clear up some confusion about the surface velocity vector. It seems to be flawed at the moment.
The orientation of the velocity:surface vector seems somehow fixed to the planet, and not to the local horizon. This becomes especially clear in a circular equatorial orbit, when the surface velocity vector should remain constant (in direction and magnitude). Instead, it varies wildly, depending on your longitude.
So while the length of the vector is correct, its direction isn't.
-
I just launched my first rocket with kOS, it's awesome! But I did notice something rather annoying while testing.
This was part of part of my program:
lock steering to up + R(0,-60,-180.
Notice that I forgot the ) to close the angles. I'd expect it to return a syntax error and abort the script, but it actually crashes the game!
-
That Rozer is such an ass. How can Genanand, Corald an Mallock fail that 'test' when they don't even know that there is another fuel source. For all I know they passed that test with flying colours, because they knew something had to be done when fuel was running out. Looking forward to the next chapter!
-
A quick dev update:[...]
The novel thing to this dish is the fairing that protects it during ascent. The fairing is an actual component of the dish model itself, much like the fairings found on stock engines.
I like the dish itself, but I think you should ditch the fairing, there are a number of other mods that already take care of fairings.
With this fairing built in, I see three possibilities:
1. You build a small sat with only this big dish, and it looks good.
2. You build a bigger satellite, which needs another fairing to go over this fairing. A fairing over a fairing? That's weird.
3. You launch your satellites without fairings, and this fairing looks out of place.
So in reality, the fairing only works for case #1. But this is never going top happen anyway, because any vessel with a large large dish usually has more antennas and/or dishes. That's why I think this antenna shouldn't have a built in fairing.
-
Are you saying that BERTY encountered a paradox that messed with his logical unit?
Pretty much, yeah. And you know what that means... KA-BOOM.
This story is practically writing itself.
-
An amazing read, thanks! Let's hope that BERTY's software update lets it forget about Rozer's status as commander....
Now how about leaving Rozer behind on the surface of Duna? All those in favour say 'Aye'!
-
Ummm... Here BERTY has a nice slice of cake. You like cake right... Right?
The cake is a lie.
-
Unfortunately I tried this between yesterday and today(though, with Kethane and ISA MapSat...only need one of those at a time really), and ran into the part count lag wall. Of course that's just my laptop, it starts lagging around 200parts, though this was around 145 give or take, and was really slow. Thought it was partly due to my hard drive being full, but cleared some space and have the same problem. Even removed some mods to see if that was the cause but no luck. I'll try again though once RT2 comes out, maybe I'll be able to make a smaller "probe" for my comm network than what my kethane/isa probe is.
Then do it like I do it: a small launch vehicle with the one satellite at the time.
You can even do it unmanned with a steep ascent trajectory. Just delay your gravity turn for a few km, aim you apoapsis at 100km, and start circularizing the orbit as you approach 70km altitude. You can easily do all this before you lose contact, just make sure you have enough thrust for the latter part. When you come around to KSC again, raise the apoapsis to GEO altitude, you know how to do the rest. The satellite will end up downrange of KSC, making the launch of the second satellite a little easier. It also gives coverage to place a second satellite east of the first one. Third satellite will be easy, and establishes full coverage around Kerbin.
-
Have a question for RemoteTech 2.
Was there a change that limits how many times the signal can be bounced to reach a satellite? I ask because I've been trying to set up a Com array around Kerbin and have been noticing odd things with satellites being out of contact when I think they should have signal.
Some details: I'm setting up the network at ~500km above Kerbin and have been careful to ensure that the satellites have all been dropped off with an orbital period of 1h4m15s to ensure that there is a minimum of drift. Because these are supposed to be cheap satellites for only bumping the signal around the planet before a longer range relay shoots it farther away these only carry cheap omni-directional antennas (the 5.0 Mm ones) which I determined should have more than enough range for all my kerbin orbit operations.
In spite of this satellites that are on the far side of Kerbin remain out of contact. I've looked at the signal pathways being generated and it seems like the signal no longer gets passed along after 2 bounces, even if another satellite is theoretically in range. Sometimes it will even show a link to said satellite, though instead of a thick green line it will be a narrow brown one (which I suspect simply indicates a link with no path to a Command station). Can provide images if necessary, but it feels like I'm missing something painfully obvious.
Known bug.
KSP Loading preview Rockomax Conglomerate RE-M3 "Mainsail"
in KSP1 The Daily Kerbal
Posted
You took away the interesting features from the mainsail and replaced them with.. nothing? The yellow piping and sharp angles near the top gave it some character, which is completely gone now. And while the new model does look like it's higher quality, I don't know if it's enough to make up for what was lost.
The Spark, Ant, Spider and Poodle revamps were amazing and added great quality and interesting visuals that I absolutely love to see, the Skipper was an improvement too. Take a look at those again and please rethink the Mainsail revamp.
Also, it looks like you took inspiration from a Vulcain engine, which isn't the closest to the Mainsail in function. If you want inspiration for a Mainsail, you might be better off looking at an F-1, a Merlin or maybe an RS-68.