Jump to content

SciMan

Members
  • Posts

    1,131
  • Joined

  • Last visited

Posts posted by SciMan

  1. I found a little bug that tripped me up when I tried to edit the CrewCapacity of this capsule in the part.cfg

    When I edited it the first time, i found the CrewCapacity = 7 line, and changed it to 3, but when i loaded up the Dragon_Rider.craft file again in KSP, it still had 7 kerbals in it!!! That threw me for a bit of a loop, but i found the issue when I looked at the .cfg again, problem is, it calls out CrewCapacity = 7 in two different lines! (thar's yer problem!) so, i removed the first "CrewCapacity = 7" line (the one i changed the first time) and changed the second one to 3, and that fixed it.

    I'm alright with having a 3-seater Dragon Rider capsule, but a 7 seat version would be even better. Hold on, hold on, I can already hear you asking "but you just had that! Why did you change it from 7 seats to 3 if you want 7 to begin with?" and the answer is simple, really. I changed it because, quite frankly, the present state of the UI means that it looks fine when you have 3 or less kerbals in a pod, but it if you try to put in any more than that, it "works", but TBH, it looks ugly, not to mention that it covers up the Time-warp/MET timer portion of the UI (as others have said).

    I have an idea for how to fix the UI to allow more than 3 kerbals to be displayed in the lower-right corner, but it has problems.

    I know one problem with this solution, and that is I have no idea if it is even possible to move or rescale the crew portraits in 0.16 or any future version.

    I suspect that the problem is that the crew portraits locations have been hard-coded into the CommandPod PartModule, and that the positions of the portrait for crewmembers 4 and up is simply undefined, so they default to being placed at x=0, y=0 (which in this case, happens to be the upper-left corner).

    If there was a way to define the position and scale of the crew portraits in the .cfg, that would solve the issue.

    That could be handled by 2 new lines in the part.cfg, and they only need to be used if the command pod has more than 3 seats.

    The first new line would be:

    forceCustomPortraitPositions = (true/false)

    this tells the game that you want to define the crew portrait positions yourself, if its not there, or if it is set to false, the game acts the same as it does now.

    The second new line would be:

    crewPic_"name" =  v, w, x, y

    this line tells the game what order to fill the crew portraits in, how big they are, and where to put them, broken down like so:

    • v = Seat Priority, valid values are integers 1 and up. This tells the game what order to fill the images in, 1= filled first, 2= filled 2nd, etc
    • w = Image Scale, valid values are nonzero decimals from 0 to 1 inclusive. This tells the game how much to scale down the image, 1.0 = full size, 0.5= half size, etc.
    • x = Horizontal Position, y= Vertical Position, valid values are any decimal from 0 to 1 inclusive. This tells the game where to put the image in the UI, (0.0, 0.0) is the upper-left-hand corner, (0.5, 0.5) is the center of the screen, (0.0, 0.5) is the center-left, etc.

    This is not how it works currently, (to my knowledge) but I took cues from how values and flags are assigned for other variables in other partModules, and would hopefully be more "familiar" to someone already used to editing .cfg files

  2. Accelerando, that sounds a lot like it could be built like a hybrid rocket with quite the... unconventional propellant combination.

    The "fuel" might be water ice, and the "Oxidizer" would be, of course, an Amat particle beam.

    In this case, the water ice would serve two purposes; firstly, it would be the "normal" matter that the AM-particle beam annihilates. Secondly, a portion of the water ice that does not react with the beam would be vaporized into steam and then superheated by the energy created by the matter-antimatter reaction. The superheated steam would then be exhausted out of a conventional bell-shaped "De Laval" nozzle to provide thrust.

    this setup could also use regular liquid water, and most likely be more effective that way as well, but I chose to use water ice because it fits the "hybrid rocket = solid fuel and throttled liquid/gaseous oxidizer" analogy better, as well as helping to avoid the need to separate steam from liquid water.

  3. One new bug found!

    Does anyone else think that the 1m Bearcat engine mountings are made of rubber? To me, no matter what fuel tank I attach it to, it starts sliding and wobbling around its attach node, at anywhere from 75% throttle upwards!

    Luckily, I found a couple of ways to fix it.

    The first fix was simply putting struts on the engine, and that works well enough until the bug gets resolved.

    Now, seeing as no other 1m engine from this pack needs struts by default to keep it stable, I looked a little deeper into the issue. What I found was that the engine's .cfg did not have "breakingForce = xxx" or "breakingTorque = xxx" lines in it! When I added those lines in with both values set to 1000, the problem disappeared entirely, however a lower/higher value will probably work just as well. That is my second way to fix it, and the one that I humbly recommend be put into practice by Tiberion.

  4. IIRC, MechJeb's launch autopilot already has the "time launch to rendezvous" option, and that can reliably put you within 100m of your target if it is in a circular orbit of 0deg inclination, only issue is that you need a liquid fueled engine for the final stage (the one that sets the orbital Ap and circularizes the orbit) because MechJeb doesn't have the code to do the real SM3's little "spiral" it does at launch to basically waste just enough fuel so it burns out at *just* the right time to put the KE warhead on the right target

  5. Hey, Tiberion, loving the pack so far! I have been trying all the parts out to figure out the best way to use them. While doing that, I found a bug with the SPS-175 engine, it was showing fuel consumption = 8 instead of showing me Isp values. I took a look at the .cfg to see if i could fix it, and it has values for Isp and vacIsp, but its still using the old LiquidEngine module.

    Its an easy fix, just had to change one line in the .cfg, specifically:

    module = LiquidEngine 

    to

    module = LiquidFuelEngine

    and that cleared the problem right up.

    One more issue I found, but its just a part balance issue. If the long 3m tank (T3000) holds 10,000 fuel, don't you think the long 5m tank (TD5002) should hold more than 15,800 fuel? Especially so due to the fact that stacking two of the 3m tanks will get you more fuel than one of the 5m tanks, and for less weight to boot!

  6. i've had problems decoupling radial stages before as well, my personal solution is to edit the .cfg of the radial decoupler. and its hardly what one would call a "hack" type edit, there's only one line of code to change, and it actually makes it work like (i think) the dev's intended it to.

    so, the line you want to change looks like this

     
    // --- Stage Separator parameters ---

    ejectionForce = (number here)

    and for the tt-38k radial decoupler i think i used a value of about 250 for a reliable "shove" away from your rocket, you can try using a smaller or larger number (bigger number = bigger push), but try to keep it under 1000, else you might find the spent stage isn't the only thing that gets flung off your rocket!

  7. Thanks for the response, sir. If I understand you, instead of merely adding 6° to my 90° (newb mistake) I should launch at 6°? That's great!

    hold on a second there, don't forget that launching from KSC at a 90° HEADING (due east) will put you in a 0° inclination orbit, while launching at a 0° heading will put you in a 90° inclination orbit (aka polar orbit)

    This means if you are putting numbers into MechJeb's ascent autopilot to set up for a Minmus transfer orbit, you need to put in 6°, as it is asking for orbital inclination, not launch heading.

    Now, if you are launching manually (no MechJeb) you should hold the heading at 96°, which is indeed "merely adding 6° to my 90°"

  8. CosmicX1, most people call that kind of tiny srb a "retro-rocket" or a "separation assist motor", because they point "retrograde" aka backwards and they get the spent stages of a rocket out of the way.

    The KW Rocketry pack has a part that can be used as a retro-rocket, and best of all its been updated to work with 0.16! the part from it that you will probably want is called the "KW Series Sideswiper I" in KSP once you have the pack installed.

    You don't really need to install the whole mod if you don't want to, all that you need is the "kwSpinBoosterSRB" folder from it, take that and put it in your "KSP_win\parts" folder and you have the part.

    find the mod here: http://kerbalspaceprogram.com/forum/showthread.php/2448-0-16-KW-Rocketry-v0-5

    One thing you will need to do when you use them is use your part rotation options to rotate the new part so that it points where you need it to point.

    The controls for part rotation are not a well-documented feature of the game, so here they are.

    press W/S, A/D, Q/E keys to rotate the part 90 degrees per press, holding the SHIFT key when rotating a part makes it turn 5 degrees

  9. Most of the reason i got MechJeb in the first place was for its (usually) EXCELLENT ascent autopilot, and the A.S.S. autopilots. those work just like the default autopilots in Orbiter do, which is exactly what i expected.

    Now for the problem i have with MechJeb:

    I have been trying and trying to do orbital rendezvous, and somehow i keep messing up. I know the basics from previous experience with Orbiter, how to 'catch up' to the target and match orbits (even if i\'m not on the same plane) but i can\'t seem to figure out when and where to burn so that i don\'t just coast right past the target.

    I can usually end up passing by the target within 50-75km or less, but even with MechJeb\'s A.S.S. autopilots helping and the correct target selected for rendezvous AND the info displays provided by the Rendezvous Module, i either end up (still) sailing right past or start to fall behind again.

    Then i noticed that the Rendezvous Module actually has autopilots of its own, so i tried those. immediately noticed that the Rendezvous Module autopilots were trying to control the same inputs as the A.S.S. at the same time, so i turned off the A.S.S. autopilots, and let the Rendezvous Module do its thing for a while, watching my orbit in the map view to make sure i did not end up in an impossible orbit. good thing i did, too, because that\'s EXACTLY what almost ended up happening! (good thing i had enough fuel, was able to prevent an unplanned re-entry) and EVERY TIME i engage any of the Rendezvous Module autopilots that take control of the main engine\'s throttle, it seems to end up sending the periapsis of my orbit into the atmosphere, or even right under the surface of Kerbin! the specific autopilots involved are the 'auto-sync', 'home on Y+5m', and 'kill rel. vel' autopilots.

    Am I using the wrong autopilots at the wrong time, or is there actually a problem with one or more of the autopilots that i mentioned? a guide on how to use the 'auto-sync' autopilot would be the most helpful to me, as i don\'t actually know what the autopilot is trying to do to synchronize the orbits. i THINK it is trying to match the lat/long coordinates and altitude of the ship\'s Ap and Pe to the target\'s lat/long coordinates and altitude of its Ap and Pe, respectively, but i really dont know how it goes about doing that. going to run some tests with it to see if i can get it to work right.

×
×
  • Create New...