Peppe
-
Posts
141 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Peppe
-
-
Direct3d is under the umbrella that is DirectX. DirectX has a whole bunch of non graphic API as well to support 2d/sounds/input/etc.
Everything under directX is a microsoft product so designed and built only for windows.
Wine tries to map directX graphic api calls to opengl.
The Unity engine the game runs in has support to run openGl directly, so I would not bother with Wine.
If your graphics drivers are up to date the main bottle neck in the game is CPU. What are you running?
-
Congrats on the release.
Look forward to the new innovations and your support through all these versions is admirable.
-
Haven't had a chance to play 1.0/1.0.2 yet, but noticed this thread and the payload challenge thread and wonder one thing...
How come there is doom and gloom on the SSTO/Spaceplane front while rapiers and jet engines are punching in close to or above a 50% payload fraction in the challenge thread.
I know the speeds and top altitudes have changed, but surely there is room to take the lessons learned in that thread and make a 30-40% payload space-plane.
Payload challenge thread:
http://forum.kerbalspaceprogram.com/threads/116729-Stock-Payload-Fraction-Challenge-1-0-2-Edition
-
No problem. There are some liquid fuel only tanks for jet engines and the nuclear engine. They don't require oxidizer.
-
I mostly haven't played since the 0.24 days, so perhaps this is a recent thing or something new.
My ship is pretty basic:
http://i.imgur.com/qZKNt07.png
My SRB and main stage engine work fine. But when I separate them, I have no electric charge going to my second engine. The parts are stacked as so:
chute -> command pod -> heat shield -> stack decoupler -> stabilizer -> rcs tank -> liquid fuel tank (with RCS thrusters on the side) -> LV-T30 "Reliant" engine
My SAS and RCS work, so I assume it's not heat shield related. And there is plenty of electric charge in the command pod. But there's 0 getting to that second stage engine. Any ideas?
- - - Updated - - -
Just noticed, the engineer's report says as much. It is also saying that it isn't receiving oxidizer. I still don't really get what the problem is though...
That tank in the later stage looks like the liquid fuel only. You want a tank with oxidizer as well.
-
I found this mod from the combo package in the MKS/OKS thread.
Was not 100% sure from the config file, but it looks like 10MW karbonite generator converts to 25 electric charge second? Tested in game and that seems right using consumers I know use 15 Energy a second.
The mini drill seems to be consuming the wrong amount. Says it will use .25 MW and consumes .25 electric charge, shouldn't it use .625 electric charge a second?
Assume it is in a different unit than electric charge for a reason maybe I am missing a mod that helps track consumers + producers spread across a ship. Reading up on the units more seems like it is common in KSPI reactors.
-
Congratulations on the full/public release!
The pre-releases were all working well for me, so i'm sure the full release will be fine for most users.
-
Wanted to say this mod manager is pretty amazing. I have been using it since the .24 release and it has made it easy to stay on the current/latest version. It all works smoothly with some minor issues usually on the mod hosting side, but overall the tool is simple and easy to use.
The planned features look great as well.
Would it be possible to have an option on github sources to download pre-releases? Example:
scansat project: https://github.com/S-C-A-N/SCANsat/releases
remote tech: https://github.com/RemoteTechnologiesGroup/RemoteTech/releases
Obviously need to be an informed user to use a pre-release, but if you want to test/use the bleeding edge it would be nice to have that option.
You have a great first release!
-
...
Life Support
- Add life support systems only if they are going to effect gameplay in interesting ways. Perhaps instead of just dying when starved, kerbals just go insane and act erratically until they get fed. You could have insanity chance based on bravery stat.
- Add random events and interesting ways for players to deal with them. Lets be honest, the main reason everyone loves the idea of life support mods are because of Apollo 13. If there isn't a way to do "failure is not an option" and mcguiver your way out of something, then it just isn't nearly as interesting. Perhaps add ways to scrap\dismantle certain systems to get others working? Maybe the success chance is dependent on the stupidity stat.
This sounds more like the part failure mod, http://forum.kerbalspaceprogram.com/threads/85798-0-24-1-Kerbal-Mechanics-Part-Failures-and-Repairs-v0-4-Help-Me-Balance! . I have not tried it yet, but would interesting if it's 'rocket parts' used for repair could use RoverDudes's repair/maintenance system.
To balance resource systems you would probably need to make the fuel cost on kerbin super high and not have any of the resource available on kerbin. Then the player's incentive to seek out and produce their own fuel is to reduce their mission cost.
- Add life support systems only if they are going to effect gameplay in interesting ways. Perhaps instead of just dying when starved, kerbals just go insane and act erratically until they get fed. You could have insanity chance based on bravery stat.
-
Thank you! Really really helpful!
One question: What is the "Gravity Parameter" and where would I find it in the map view?
I'm trying to use this together with Real Solar System so the numbers don't match.
The numbers for the kerbin universe are on each wiki page for the planet/moon:
http://wiki.kerbalspaceprogram.com/wiki/Kerbin
How accurate is the real solar system mod? Not sure if you could use real world numbers or if they would have some of these numbers calculated already and posted somewhere on another wiki.
You might try these numbers, but again the real solar system mod may be scaled in someway to work in the KSP engine:
http://en.wikipedia.org/wiki/Standard_gravitational_parameter
-
Just started using this for .24 and it is excellent. Easy to use and just works.
Thank you Llorx and all your contributors.
One question, some mods say to delete their previous folder before installing. Does this mod delete the folder as part of it's extraction or should I have been manually removing the folders when the readme indicated it?
I'm guessing it does not delete, so is there any easy way for me to do a re-download all?
-
This is a great tool; I'd been doing a lot of these calculations on paper. I had been doing some of the minimum & maximum orbit calculations on paper, hadn't gotten around to spreadsheeting it yet... and coincidentally was looking for how to calculate darkness time for satellite batteries.
But could you please explain what you're showing with "Optimal Field Of View" on the Satellite Relay tab?
That is for Remote Tech mod. If you don't use the mod don't worry about it.
My calculation for it is +-3 degrees from the minimum safe separation between a set of satellites.
Not sure it is truly optimal, but more a rule of thumb i tried to make for myself. I know i did not want the lowest orbit (drift -> failure risk) nor the max orbit (too much fuel cost), so how to find something in-between?
My thought was, take 3 satellites equidistant to each-other -- with perfect orbits you could have orbits as low as the radius of the planet. For kerbin that is 600km. My orbits aren't perfect, so lets add some flex to the numbers. If we allow for +-3 degrees of drift on each satellite we could setup safe orbits ~720km that survive drift. The extra orbit height means the planet blocks less of our line of site to the other orbiting satellites increasing our time to failure.
-
Okay, here's the idea for dish targeting:
Mode 1: Target planets. Has the cone of vision (dish parameter), anything in the cone connects as if the dish were an omni.
Mode 2: Target satellites. Currently it's very static and does not use the cone of vision in any way. I intend on changing this to function like above. This way it won't matter what you point at, behaviour is identical.
Mode 3: Groups. You can subscribe a number of satellites to a group, such as "LKO Sats", and you will be able to target everything in that group at once. For performance reasons, this would NOT have a cone of vision.
OPINIONS?
EDIT: Memos of a rambling fool:
- Revise targeting;
- Exception-robustness;
- Debug menu / configuration menu / satellite fixer
- Refactoring
- Eggs
- Crisps
- Find some sort of agile board to track my current issues
- Delete half the issues on GitHub.
Mode 1 and 2 being similar is a good idea. I think it will encourage using dishes with the right cone size for the job.
Mode 3 sounds cool, but complicated and might make signaling too easy. Without a cone to worry about you could use dishes to relay a signal in much more flexible arrangements. Seems to negate the above, where now you don't have to worry about picking the right dish for the job. Sizing the dish and cone angle I think makes for an interesting game-play element.
My mode 3 would look at a cone mode to fixed points around the body. Like poles and each horizon, so you can target the planet center (current mode) or the sides.
targets (x) around body (o):
-x-
xox
-x-
Maybe enable the multidish range bonus by default. So if you need a cone angle of 25 degrees, but out 200Mm, you can do it with 2-3 dishes depending on how you scale the multidish bonus.
Someone many pages back also thought being able to target the zenith from the surface in cone mode would be good. Not sure if the cone rotating on a surface might not update if the ship is inactive.
If the mode 1 changes don't filter by the target, so truly anything in the cone will connect I think that will give us a way to relay through moons. If the moon can also talk to the ship and the planet, when it crosses the signal path it will not require a re-target to maintain the signal -- assume the ship's cone can see a relay sat around the moon?
Assuming you have relays on all planets and moons, then moons will not block the signal.
Only scenario that leaves to lose signal is something large like the sun/jool, where you might not be far enough away for your cone to hit a relay (planet or sat) without targeting away from kerbin. A dynamic way for the sat in this situation when kerbin goes behind the sun/jool to try to relay to a backup planet or list of backups -- until kerbin is available again might be good. Struggle to find a solution that does not make it too easy.
If that sounds too easy maybe you just make the player bring a backup dish and they have to manually point to alternate relay path around the sun before they lose signal if they are worried about signal loss through the direct path.
- Revise targeting;
-
Nice page.
Write something about each antenna part; what it's most common use?
For example:
Communotron 88-88
This dish is most commonly used for interplanetary communications in the inner kerbol system. It has enough range to keep Moho, Eve, Kerbin and Duna in range.
Dres is also a possibility, then communications can be become interrupted as Dres is sometimes just beyond the range of this antenna. As this dish is light-weight
and retractable it's a great dish to include multiple of on your interplanetary communications satellites. Just remember that's it not the best dish for keeping
contact with probes that are entering an atmosphere.
Or maybe describe a possible career mode satellite network buildup?
Not sure how the KSP wiki is, but since this is a mod should most of the information be collected on remotetech's wiki rather than KSP's?
https://github.com/Cilph/RemoteTech2/wiki/List-of-available-parts
-
So I was overlooking that. I was looking for a button on the flight computer's interface to send other commands, I didn't realize that once you set the delay it applied to action groups and other commands. That means you have to setup action groups to activate or toggle the dish/antenna. I've been setting up one just to activate the omni antenna because it's sometimes hard to find and deploy manually with the mouse and I don't want to forget to do it before getting too far away from the KSC. I've been setting it to only activate so I don't accidentally press it again and turn off the antenna losing control of the craft. I just tried to do it without action groups and don't think it can be done. In order to queue up an activate, the antenna or dish has to be deactivated first, because when you right click on it, the only option is deactivate.
This brings me back to my other feature request, to be able to set up the command queue before sending it. The way it works now, when I send a command, it goes into the queue immediately and begins counting down the delay set. If I need to set multiple commands to go off in a specific order at specific times, I'd like to set all of that up with the timings, be able to double check it, then transmit the command queue to the craft. It can be done now, but once the first command is set, you're racing the clock to get the rest of them plugged in, and constantly having to adjust the delay time to account for the time already counted down. If you make a mistake, you have to cancel everything and start over.
I have not used KOS - kerbal Operating System, but i believe integration with it is the next layer planned for the flight computer. It would let you script advanced tasks to perform and KOS would perform them with local control. I believe it will work similar to what you are describing... if you play modded minecraft i imagine it would be like programming turtles in computercraft.
If you already have a command group to activate the antenna, then you just set the delay for what you want. Say 5 minutes. Then hit the action group. Then reset your delay to zero and manually deactivate the antenna with the mouse.
Probably doesn't feel logical, but if you have other actions to do during the entry and landing you can start far enough to trigger everything with one master delay. Say we setup a reentry 30 minutes out:
We set a 28 minute delay
Hit action group for parachutes.
Wait/warp x minutes
Hit action group/hotkey for landing gear
wait/warp x minutes
hit hotkey to extend antenna
reset delay and manually retract antenna.
warp to reentry
Since we scheduled things with the same delay the reentry will open our shoots, then say 2 minutes later extend our gear, and then maybe we warped 5 minutes setting this up, so the antenna will extend in another 5 minutes. Basically perform the re-entry commands in space well ahead of your arrival with a delay and then shutdown the antenna.
-
I'm new at RT, and I finally, after many failed attempts due to brain farts, I have a working relay satellite system in orbit. I'm in career mode with only the communotron 16 and the two short range dishes (50Mm and 90Mm) unlocked right now. I put three satellites in 700km orbits. They use the Stayputnik core with a communorton 16 and the 90Mm dish, plenty of battery power for night and solar panels to recharge in the day. At 700km, they are just high enough for the dishes to maintain LOS and the communotron 16's are in range of one another and at least one is in contact with the KSC. The dishes are targeted at the active vessel.
I'm also using Deadly Reentry, FAR and Procedural Fairings. Last night I tried to send an unmanned probe around the Mun, but it lost communication beyond 3km, the range of the built in probe core antenna. I had a Communotron 16 on the craft inside the fairing set to start active. It turns out the Communotron antenna was snapping off shortly after launch even though it should be shielded by the fairing. I don't know if it's a bug with RT2 or the other mods, but shouldn't the fairing be shielding the antenna? There also wasn't any indication that it broke off. The flight status (F3) showed no events. I only realized that it was breaking off when I noticed I was losing control at exactly 3km. I had to put on the short range 500km antenna on and deactivate the communotron during launch.
Now to my main problem, which I can't think of a workaround for. The probe did a slingshot around the Mun, grabbed science and came back on a free return trajectory. I had two of each science equipment on board, one to save and collect if reentry was successful and one to transmit before reentry just so the mission wouldn't be a total failure if the craft burned up during reentry. I was afraid the communotron would snap off during reentry, so I used the tweakable system so the parachutes opened at a lower altitude just in case DR killed them if they opened up in the upper atmosphere like they do by default. I staged the parachutes before reentry, but didn't lower the landing struts because with FAR I thought it might cause the craft to flip around so the heat shield was facing the wrong way or DR might cause them to burn up being deployed. I just hoped the communotron would hold up through the reentry so I could deploy the landing struts, but it didn't. The craft touched down and fell over, but luckily it didn't break up.
For probes returning to Kerbin, I can always try to reenter near the KSC so the short range 500km antenna is in range which will allow me to deploy the landing struts, but what about sending probes to land on planets with atmospheres? Since you have to retract all of the communications equipment for reentry, how to you deploy landing struts after reentry and re-deploy the antennas once it lands?
I played with the flight computer, but unless I'm overlooking it, I don't see the ability to send anything other than maneuver commands. It would be nice to be able to send other commands like retract the comm dish, wait 1m and deploy the landing gear, wait 2m activate science equipment, wait 5m and re-deploy comm dish. As it is now, I don't see any way to send a lander probe to a planet with an atmosphere without first setting up a bunch of relay satellites around the planet, and putting them low enough for the short range 500km omni antenna to connect to it since it is the only antenna capable of operating while moving through an atmosphere.
Also, regarding the flight computer, it would be nice to be able to queue up commands before transmitting them to the craft rather than sending them one at a time to be stored in the queue.
You can do what you want with the existing flight computer.
You can set a custom delay to queue an action group - expand flight computer and set delay in lower righty. Setup reentry, Delay the expand a few minutes, remove custom delay and retract anything that can break.
You can test your craft to find good delays to use or over engineer a safe lander.
-
I'm using the Alternis Kerbin plugin where Kerbin orbits Jool. I was using DTS-M1, which has a cone angle of 45 degrees. I was targeting a Kerbin from Mun and Bop (Kerbin's moon) was within the cone, but a connection only formed to satellites orbiting the Kerbin, and not Bop. I had the satelites around Kerbin and Bop pointing towards Mun, and all were within the dish's distance.
Sounds like issue 200:
https://github.com/Cilph/RemoteTech2/issues/200
Targeting a body will only talk to satellites in line of site and orbiting that body. So something can be in the cone, but if it is outside the SOI of the target body it will not be communicated with.
You might add your usage scenario to the issue and see if that might encourage a change in the code proposed by maxdreamland.
I personally think dishes should only use cone mode no matter what they target, but maybe that creates a performance issue.
-
Error in "Github / RemoteTech 2" , "Launch First Satellite" documentation?
at the bottom of the doc. It states:"The 'Comms DTS-M1' has the largest cone angle at 45°, as such, if you have three satellites, all targeting 'Kerbin', one over the Kerbin, the other two can sit on the other side of kerbin, still within the primary 'KSC geostationary' satallite's cone. These two will not talk directly to each each other, but they do not need to."
unless I'm missing something, there is NO way each satellite in (my) geostationary orbit can communicate with each other with a DTS-M1. Using 3 satellites, each with a DTS-M1 set to "Kirbin", I can see the (potential) angle of ambiguity (LOL) and they do NOT intersect with each other. They do not even come close. The only way to use this setting would be to use 4 satellites and your satellites had better be perfectly aligned with each other. 5 satellites are a better "fit". If the DTS-M1 had a 90 degree sweep, it would work with 3. Am I missing something?
also, i don't understand why it states "These two will not talk directly to each each other, but they do not need to."
and yes, I understand what a geostationary orbit is and have a true geostationary orbit
update, perhaps i do understand. The "back side" satellites do not have to be equally placed (say each satellite @ 120 degrees). That makes sense
That whole section is new. Does not come off very clear. You are correct the far side satellites would not work with an eqalateral triangle, but there should be window where they can point at kerbin and see the sat over KSC.
At any rate I would prefer lower orbits and all Omni's to cover surface to orbit comms. Dish's should point out... To moons/planets.
-
I have noticed when targeting a planet with a dish, it won't connect to a dish in range around a moon. The same is true if I target a moon, the dish won't connect to sats in range around the planet. Are there any plans to fix this, or a way to make it work?
Here is a quick example of the affect of cone angle. Comparing one sat from each tier kerbin to minmus:
Javascript is disabled. View full album
If you are not using DTS-M1 or KR-7 for your moon to planet and back link you are probably have a very tiny window where sats can be to communicate. Minmus in the above shots is only 60Km. The 88-88 can see maybe half of minmus, but if you use the 88-88 to look back to kerbin it is 10x larger planet so the same sat will see an even smaller window/field of view of kerbin.
You have to size your dishes for the job they will do.
-
Testing that hotfixed build. Please advise if it's safe to rename deployed satellite (after manned deployment craft was recovered), don't really want to risk editing my save
Bugs all had to do with ID getting unloaded or not unloading when they should renaming never did anything.
-
I have noticed when targeting a planet with a dish, it won't connect to a dish in range around a moon. The same is true if I target a moon, the dish won't connect to sats in range around the planet. Are there any plans to fix this, or a way to make it work?
What is the cone angle on the dishes you are using with planet/moon targeting?
And what is the your distance to the target?
-
I'm using the Communotron 88-88 with 40 Gm range. This one doesn't have enough field of view?
OK I see now it has barely a twentieth of a degree cone angle, I didn't realise it was so constricted. Thanks guys, my mistake.
Sounded like that type of problem.
Also the super long range dishes have a smaller cone angle than the game displays. I've put the values in their part files here:
https://github.com/Cilph/RemoteTech2/wiki/List-of-available-parts
The largest two dishes basically need to be about 10 times further out to see even half of kerbin using the cone targetting. ~10,000-20,000 Mm
-
I have a satellite in Minmus orbit with the stock round dish on it and a station in low Kerbin orbit with a dish aimed at Minmus. When I control the Minmus satellite and target Kerbin I get no connection, but if I target the station directly it works. Sup wid dat?
Just to make sure, on minmus you are using the 50Mm or 90Mm dish?
Any others will have a cone angle too small to see more than a small window of kerbin until they are 1000-2000 Mm out.
-
I'm sorry to be a bother Peppe, but does that dll also address the issue with the map vessel focus selector?
What is the issue with map vessel and focus?
If it is related to 189, yes. If not probably not.
Any way to enable crew limits and XP in sandbox?
in KSP1 Gameplay Questions and Tutorials
Posted · Edited by Snark
Link to defunct website removed by moderator
I like this mod to remove tech tree from career mode, but have the experience, contracts, money:
Tree Toppler