triffid_hunter
-
Posts
103 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by triffid_hunter
-
-
Because UbioZur has kindly allowed to update his work, Girka2k and I have released the next update for this great mod.
I think you should make a new forum thread, and let this one die
-
is it just me or does the download link in top post simply redirect back to this forum thread?
tried in browser first, wget finds same conundrum:
$ wget https://nabaal.net/files/kethane/Kethane-0.8.5.zip--2014-04-03 09:28:41-- https://nabaal.net/files/kethane/Kethane-0.8.5.zip
Resolving nabaal.net... 173.193.193.212, 2607:f0d0:3002:54::10
Connecting to nabaal.net|173.193.193.212|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://forum.kerbalspaceprogram.com/threads/23979-Kethane-Pack [following]
-
Seems like DS mod's "engine" feature is breaking MechJeb's delta-v calculation - it shows nothing in VAB. Is it safe to just remove that "engine" from cfg file or it's needed for resupply or different stuff?
From what I've seen, providing/filling fuel is implemented as an engine that consumes a negative quantity of fuel. I would expect you to no longer be able to receive fuel if you remove the engine module.
-
Small possible bug: Mechjeb's auto pilot fails and wobbles in circles on ships I launched from the orbital launchpad unless I enable stock sas.
This is a bug with latest mechjeb release, seems to be fixed in mechjeb dev. If you go into attitude control you'll notice that many of the fields go to infinity when this happens. I can generally trigger it by decoupling a ship without a SAS wheel from a larger ship that does have a SAS wheel somewhere.
-
This mod is very understated, I'm surprised it's not more popular
any chance we could optionally add RocketParts to the list of supplied resources?
-
Thanks for the heads up. I'm seeing a handled divide by zero error in windows under the same circumstances - I should have some time this weekend to track it down and hopefully fix it.
excellent, glad to know it's not just me
just a heads up, I did manage to trigger this in the VAB today, same sequence- holding a part for radial attach, then shift+c to go no_snap -> 90
-
Bug report!
Problem: hard crash (Floating Point Exception)
1) go to SPH (doesn't seem to happen in VAB)
2) place command pod
3) select a radially mountable part
4) hover over command pod for radial placement
5) press shift+C a few times
6) at the transition from 'no snap' to '90°', KSP bombs, printing "Floating Point Exception" to terminal
using linux 64 bit binary
This behaviour isn't new in 0.23, but 0.23's massively faster load time has allowed me the patience to find a way to reliably reproduce it
Other than this, works perfect in 0.23. may want to update thread title
-
-
-
As I understand it, it is possible to get SMARTASS to track the surface-relative prograde/retrograde in the advanced mode, but I've never played around with that.
I have, you want SURFACE_VELOCITY, BACK.
would really love a couple of buttons for easy access to surface pro/retrograde
While I'm at it, any chance of moving the aerobrake prediction out of landing autopilot? I think it makes sense to separate those and make aerobrake prediction available maybe one tier earlier in the tech tree
-
Im able to manage a com-sat system which covers the whole orbital area around kerbin - but only with change a .cfg to set the length from 5.00 Mm to 7.5 Mm. Kind of cheating. But without that I cannot make it up to a synched orbit.
Keosync is at 2868km, a bit beyond the range of the starter omni antenna. Instead, put 6+ sats in a ring at at half-sync (1585km) so there's always one or two within range of KSC, and they're also within range of each other so signals can pass around the whole ring. Then you get no more blackouts in space near Kerbin.
Then you can put something with an omni and a dish or two up at keosync (2868.7km). the omni will hit your half-sync ring, and the dish can point at Mun or Minmus
maybe put a matching pair opposite KSC to keep Mun/Minmus online 24/7 (or is it 6/7 since Kerbin's day is 6 hours?)
highly elliptical polar orbits become pretty useful around this point
see my half-sync ring + two keosync sats - I set the pictured craft in an orbit with apo at 1585km and orbital period of 7/8 * 3h (2:37:30, peri about 1219km), then dropped off a sat every time I got to apo, then circularised the sat targeting an orbital period of exactly 3h (can see reading of 2:59:60.0 pictured)
Yes, I placed every last one manually using only the orbital period readout from KER. MJ was used just for orientation and ascent autopilot, but not injection orbits or circularising since it's frankly not accurate enough.
With a range of 2.5Mm you need >5.5 sats at half-sync for an unbroken, zero blackout ring. I went with 8 for redundancy and because I didn't know how accurately I could position them.
-
Bug report:
If I radially attach things, then I can only attach the welded part to my rocket by the nodes that appear at the radial attachment points.
Example (5x X200-16 tanks arranged in a 4-pointed star using I-beams):
PART
{
name = Station-Core-4
module = Part
author = UbioZurWeldingLtd
rescaleFactor = 1
PhysicsSignificance = -1
node_stack_top4294427884 = 2.086163E-07,0.4687508,2.086163E-07,0,1,0,2
node_stack_bottom4294427884 = 2.086163E-07,-0.4687492,2.086163E-07,0,1,0,2
node_stack_top4294426714 = -3.13744,-8.813257E-07,-3.137441,0.7071068,4.768372E-07,0.7071069,0
node_stack_bottom4294426714 = -0.8771394,6.429071E-07,-0.8771399,-0.7071068,-4.768372E-07,-0.7071069,0
node_stack_top4294423812 = -3.987281,0.4687499,-3.987282,-7.787723E-08,1,3.225779E-08,2
node_stack_bottom4294423812 = -3.987281,-0.4687501,-3.987282,-7.787723E-08,1,3.225779E-08,2
node_stack_top4294426620 = -3.137441,-5.002676E-07,3.13744,0.7071068,2.384186E-07,-0.7071067,0
node_stack_bottom4294426620 = -0.8771402,2.618489E-07,0.8771398,-0.7071068,-2.384186E-07,0.7071067,0
node_stack_top4294423614 = -3.987282,0.4687499,3.987281,-5.034347E-08,1,-4.366267E-08,2
node_stack_bottom4294423614 = -3.987282,-0.4687501,3.987281,-5.034347E-08,1,-4.366267E-08,2
node_stack_top4294426596 = 3.137441,-8.813257E-07,3.137441,-0.7071069,4.768372E-07,-0.7071069,0
node_stack_bottom4294426596 = 0.87714,6.429071E-07,0.8771403,0.7071069,-4.768372E-07,0.7071069,0
node_stack_top4294423582 = 3.987281,0.4687499,3.987282,-5.506751E-08,1,-2.280971E-08,2
node_stack_bottom4294423582 = 3.987281,-0.4687501,3.987282,-5.506751E-08,1,-2.280971E-08,2
node_stack_top4294426572 = 3.137441,-5.002676E-07,-3.13744,-0.7071068,2.384186E-07,0.7071067,0
node_stack_bottom4294426572 = 0.8771402,2.618489E-07,-0.8771396,0.7071068,-2.384186E-07,-0.7071067,0
node_stack_top4294423550 = 3.987282,0.4687499,-3.98728,5.506752E-08,1,-2.280971E-08,2
node_stack_bottom4294423550 = 3.987282,-0.4687501,-3.98728,5.506752E-08,1,-2.280971E-08,2
node_attach = 1.25,0,0,1,0,0,1
cost = 4900
category = Structural
subcategory = 0
title = Station Core:4way
manufacturer = UbioZur Welding Ltd
description = Warranty void during re-entry.
attachRules = 1,1,1,1,0,0,0
mass = 4
dragModelType = default
maximum_drag = 1.8
minimum_drag = 2.3
angularDrag = 14
crashTolerance = 6
breakingForce = 200
breakingTorque = 200
maxTemp = 2900
fuelCrossFeed = True
MODEL
{
model = Squad/Parts/FuelTank/fuelTank4-2/model
position = 2.086163E-07,8.34465E-07,2.086163E-07
scale = 1,1,1
rotation = 0,0,0
}
MODEL
{
model = Squad/Parts/Structural/structuralIBeam2/model
position = -2.00729,-1.192093E-07,-2.007291
scale = 1,1,1
rotation = 90,225,0
}
MODEL
{
model = Squad/Parts/FuelTank/fuelTank4-2/model
position = -3.987281,-1.192093E-07,-3.987282
scale = 1,1,1
rotation = 4.462037E-06,315,1.848235E-06
}
MODEL
{
model = Squad/Parts/Structural/structuralIBeam2/model
position = -2.007291,-1.192093E-07,2.00729
scale = 1,1,1
rotation = 90,315,0
}
MODEL
{
model = Squad/Parts/FuelTank/fuelTank4-2/model
position = -3.987282,-1.192093E-07,3.987281
scale = 1,1,1
rotation = 360,44.99999,2.706683E-07
}
MODEL
{
model = Squad/Parts/Structural/structuralIBeam2/model
position = 2.007291,-1.192093E-07,2.007291
scale = 1,1,1
rotation = 90,45,0
}
MODEL
{
model = Squad/Parts/FuelTank/fuelTank4-2/model
position = 3.987281,-1.192093E-07,3.987282
scale = 1,1,1
rotation = 360,135,-3.155136E-06
}
MODEL
{
model = Squad/Parts/Structural/structuralIBeam2/model
position = 2.007291,-1.192093E-07,-2.00729
scale = 1,1,1
rotation = 90,135,0
}
MODEL
{
model = Squad/Parts/FuelTank/fuelTank4-2/model
position = 3.987282,-1.192093E-07,-3.98728
scale = 1,1,1
rotation = 360,225,3.155136E-06
}
RESOURCE
{
name = LiquidFuel
amount = 1800
maxAmount = 1800
}
RESOURCE
{
name = Oxidizer
amount = 2200
maxAmount = 2200
}
}I'm not familiar enough with KSP's part system to derive what's wrong with this, but it simply refuses to attach as a vertical stack.. it'll snap to a node, but when I click the part remains semi-transparent and red-tinged meaning it's placed but not attached... I can successfully radially attach it though.
Also, if I summon one as the root (first) part, I can successfully attach other parts to it.
-
I want to invent the aerosol spray can before the wheel!
+1 for Douglas Adams reference
I like the rest of your idea too, ie a highly expanded tech tree with some random variations thrown in, like a 1 in 1e7 chance of discovering quantum physics shortly after the telescope, balanced to roughly follow our historical pace of development
-
I can't for the life of me remember where I saw this idea and so can't credit its original author, but it's the most sensible one I've seen yet:
(not quoted verbatim, just my own wording of the idea itself)
Each player can warp to their heart's content and their game keeps track of time since joining the server.If two (or more) players wish to interact, they must first synchronise their times. This involves the player who's behind catching up, probably using a 'sync with this player' button which will apply an appropriate amount of warp.
This solves the issue of players warping hard on interplanetary missions, and also solves time stopping while mucking around in the VAB. It also solves the issue of having all the planets and moons in the right place while doing transfers.
You might also like to consider forcing Stations to stay on rails, so players can dock with them. You would of course need to synchronise times to see other players' ships at the station, and batten down the hatches for total CPU meltdown if they've docked a behemoth
Map icons would be managed ala KSP live I suppose, I haven't used it myself but presume they have something relatively sensible?
-
Just curious, can anything be done about the initial (and often very violent) 'flop-over' when MJ starts the gravity turn?
sure, start at 1km, end at 45km, turn shape 100%
-
MJ will not toggle intakes that are copied with Alt-click...
Problem isn't that it won't toggle them, problem is it toggles them ALL to 'closed' :/
-
I built a thing with about a hundred intakes.
Problem is that manager doesnt seem to manage them all. As at launch I dont get enough air to the engines. Is it either that its limited to max intake air it can manage, max intakes that it can manage or some intakes arent working right?
Every single time I've tried MechJeb's "manage air intakes", it closes ALL of them causing instant flameout
-
Any chance someone could explain why I can't get MechJeb 2.0.9 working on KSP 0.21.1.276? I put the MechJeb2 folder (with parts and plugin subfolders) into my GameData folder but the mod doesn't load up when I start the game.
works great for me.
Does your directory structure look like KSP\GameData\MechJeb\Plugins\MechJeb2.dll ?
Is your KSP folder under Desktop or Program Files (windows) ? because windows restricts write access to those trees, which screws up some mods. Instead, try C:\Games\KSP....
-
They relesesd the 310.X Drivers in Nov 2012.
The 304.X drivers your using are from June 2012.
Unfortunately, the 304.x driver is the most recent one that supports the graphics chip in my laptop
-
Started this thread about a bug I found, thrashed my game to hunt down the root cause but I found it. Here's a link to a symmetry bug Mechjeb causes in the VAB, quite repeatable.
For those who haven't checked out that thread, he today found that MechJeb does not cause this bug- it happens in stock KSP however MJ and friends may exacerbate it (like kethane with the ScaledSpace bug)
Kudos for some good science there Jean
-
Will it use less RCS fuel? I've got to the point that I have to turn on unlimited RCS every time I use autodocking and I hate doing that.
I've given up on MechJeb's rendezvous and docking autopilots, they're completely hopeless in terms of fuel usage and time. These two procedures I do manually these days- specifically I'll use Smart A.S.S. and occasionally the maneuver planner rather than the autopilots.
The docking pilot has the right idea, but it needs to combine 'holding still in Z and moving towards docking axis' and 'moving in to dock' into a single mode, and that mode needs to have a narrowing tolerance window so that if you start it 200m out it allows itself to be really coarse with the adjustments as long as they're approximately ok (and thereby save a TON of mono), and become finer as it gets closer. Ideally it should have the two ports aligned and the relative motion vector parallel to the docking axis by about 10m out.
For visualisation purposes, envisage a curved horn or funnel coming to a ~1cm point 10m out from the target port. The docking pilot should use the minimum amount of RCS fuel to maintain appropriate forwards velocity while remaining within this shape.
A while ago I made a quicksave then let MechJeb's docking autopilot do the procedure. Came back in 15 minutes (yeah it takes aaages), and disgusted at it using 300 units of monoprop I did it myself. With 7 units of monoprop and about 5 minutes.
If I'm feeling lazy, I'll engage the docking autopilot then make judicious use of timewarp to prevent it constantly spamming RCS and shredding the monoprop.
The rendezvous autopilot should avoid the phasing orbit completely if a single burn could get an adequately close intercept. I've had numerous situations where I did one burn of ~30m/s to get my intercept within 2km then a tiny adjustment burn of maybe 4m/s to get it within 200m, where the rendezvous autopilot used a couple hundred m/s creating a phasing orbit then plotting an intercept from there.
-
I didn't see this suggested anywhere, but if it has, maybe point me to a discussion. I'm wondering if a feature could be added where a launch could be timed to the position of another vehicle already in orbit, either by a direct time measurement or by the moment the (selected) orbiting vehicle passes a reference coordinate on the surface.
What I'm trying to do is set up a comm relay network where the relay sats are equally spaced in their orbit. I think I know the basics of doing it (manually), but it's difficult to "push the go button" at the precise moment, since I can only watch one spacecraft at a time. The time it takes to switch views from the orbiting sat back to the ground, engage the ascent computer, then make it go, moves the orbiting sat farther ahead than what I want.
MechJeb can already do this. Target the craft you want to rendezvous with, then at the bottom of the ascent autopilot there's "launch to rendezvous with target".
This relies on the LPA being correct- the easiest way to get it right is to do a launch with the autopilot, then revert after the circularisation burn is complete and the autopilot deactivates itself.
LPA stands for "launch phase angle", and is simply the angle between KSC and your craft when the circularisation burn is complete. This tells MechJeb how far in front of your target to launch.
If you want to place a craft at a particular angle vs another craft, simply add that angle to the LPA before hitting launch to rendezvous!
If the orbital periods aren't exactly the same, they'll slowly drift. One of the instrumentation dialogs shows you your orbital period.
The one aspect I've had to take over from Mechjeb on more times than I'd like to count recently is docking. It just can't do it right. Either it swings about wildly, never correcting until it has swung almost 90 degrees off course, or lining up perfectly but never using the translation controls.I don't even use the docking autopilot these days. Instead, I set Smart A.S.S. to PAR- then use engine burns or translation to make the target prograde marker push the pink target sigil towards the center of the navball. This is waay faster and massively more efficient on RCS than MJ's docking autopilot.
I thought I read somewhere that MechJeb had recently added the ability to align docking ports when docking, but if it's an option I can't find it. Is that something planned, or did I remember wrong?EDIT: by 'align', I mean rotationally.
If rotational alignment is important to you, use four regular ports on a quad adapter like this. Make sure to roll into proper alignment prior to docking though
-
I posted about this earlier. MechJeb allows you to blacklist modules on a per-part basis, so there's no reason you couldn't create a logical progression of parts/features that would unlock at certain points in the tree.
I think if it's done this way then we'd end up with a whole page of various MechJeb parts with different capabilities, unless the tech tree provides a way to obsolete older parts. Then we have the issue of old ships can't plot the new maneuvers despite the fact that we all know how easy firmware upgrades are with basically everything, and it still doesn't follow the player's piloting ability, it simply follows their ability to gain science
I'd much prefer MechJeb's abilities to follow the player's ability to pilot rather than a simple stack of parts with varying utility in the tech tree
-
I know this departs at at least 80 degrees from the current concept of R&D, but I still have thoughts leaking all over the floor.
My vision of R&D is an evolution of parts based on player feedback. It relies heavily on being able to produce parts semi-procedurally with fine grain adjustments of attributes. At simplest example take three standard "seed" parts, engine, fuel tank, parachute. The player elects to direct the R&D department to develop new parts of these categories with directed changes. R&D "dice rolls" some new parts with more desirable stats in the preferred area with possibly some degradations in others. Given a handful of possibilities (1-10) the player accepts or rejects these potential parts into the stable of usable parts. "We need an engine with more thrust" or "this parachute needs to open higher but with less drag" or "this fuel tank needs to be shorter and stronger at the cost of capacity." Thus the player directs their own part development qualitatively and ends up with a selection of parts uniquely their own.
Gameplay restrictions could include R&D cost per role, cost to support a larger stable of actively available parts or hard limits on number.
A tech tree and R&D evolution would synergize well. One might give up an old model honed to perfection in favor of a new technology that's still raw. New techs could open up new attributes to adjust or extensions on the values allowable such that existing models could be brought up to contemporary tech.
THIS!
Sometimes I'd be quite happy to sacrifice some thrust for a bit extra ISP, or the other way.. or perhaps I want a fuel tank with a size that's right in between two stock tanks.
Procedural wings and fairings seem to be quite popular at the moment, making _everything_ procedural as part of the tech tree implementation would make me a very happy clam
What will you do with plugins in career mode? Using MechJeb in career mode is definitely cheating.I disagree most emphatically. Current day space missions are flown with VASTLY more instrumentation and automation than stock KSP currently provides, I'm sure they have something a fair bit more advanced than MechJeb tucked away in mission control and duplicated on the craft
I'd love to see MechJeb integrated into the tech tree in a sensible fashion.. perhaps at the start you only get the instrumentation (delta-V in the VAB, vessel, orbit and surface info during flight) and as you fly more and more missions you slowly open up the various autopilots- Smart A.S.S. first of course, then perhaps maneuver planner, ascent, rendezvous/docking, landing.
For best results, I'd love to see these opened up by player demonstrating ability to perform these maneuvers manually- perhaps something like
* "12 successful launches, ascent autopilot level 1 unlocked!"
* "40 staging events on successfully returned craft, auto-stage unlocked!"
* "20 degree plane change completed after gaining electronics level 4, Smart A.S.S. level 3 (normal/antinormal) unlocked!"
Alternatively, the text could read "MechJeb has learnt ..." (ala Black & White) instead of "... unlocked"
Hopefully the devs will create an API which allows MechJeb's author to implement exactly this!
How do we rate the science value of your missions? What even defines a mission in the first place? These things are actually pretty hazy in terms of how the game deals with them, so coming up with a nice, solid way of doing science is a deceptively tough task.I do believe I've worked out a good solution now:
The game won't award you any science automatically. That would be artificial and generally meaningless, but worse still, it would require us to make arbitrary decisions about the science value of this or that action. That's a bad road to go down. Instead, we can let you 'do science' as part of your missions, and get your science points for yourself. Here's how:
We already have a few science sensor parts, which apart from a context menu readout, are largely decorative. We can put those to some use now, along with a couple other scientific parts we're going to add.
The idea is that science parts work as one-shot experiments. That is, they're activated by action group or as part of the staging sequence, and once deployed, they to their thing. This is essentially deploying the experiment to gather data. This data isn't science yet though, because you need to get it to your resident experts over at R&D to crunch the numbers and make some sense out of it.
I like where you're taking this
I think a strong driving force during early career should be commissions; ie "take sensor X to position Y, return within 7 days and gain a 350% bonus in 'science'."
As career progresses, I think these commissions should become less important, allowing the player to perform their own science. I'd love to be able to find anomalies in space, eg take a gravity sensor to L3/L4/L5 for an unannounced bonus, or drop Magic Goo on the moon arch- essentially silent commissions.
Later in one's career I'd love to see some really massive commissions like a Moons of Jool grand tour- "land Billionaire Richie Kerman on 2 of Jool's moons and complete a full orbit of at least one other then land him back at KSC within 5 years to receive 60 million Kubles and 5000 science points."
Lastly, I'd be interested what the devs think of an exchange rate between science points and funds which varies based on events such as disasters (slightly poorer rate), deaths (vastly poorer rate) and surprise commissions (rate increase).
Getting there from here: tips for the ignorant on how to navigate between planets.
in KSP1 Tutorials
Posted
Actually there is - Maneuver nodes!
First get into LKO, then set up a maneuver node that barely escapes Kerbin's SOI in the direction of kerbin's travel (for outer planets) or in reverse direction (for inner planets).
Then create a second node in Kerbol's SOI to intercept the target's orbit, and drag it around to find your intercept.
DO NOT EXECUTE THESE NODES - instead, wait until *kerbin itself* is at the position of the second node, then delete both nodes and construct a new one to burn straight from LKO.
I made a video about it: