Jump to content

rasta013

Members
  • Posts

    664
  • Joined

  • Last visited

Posts posted by rasta013

  1. 2 hours ago, akron said:

    You can test it out when you get a chance. Files are now up on Github.

    Yup will do.  Working hard on a test for Shadowmage and KSPWheel/KF but I've already moved your new parts into my sandbox fun install to check out the changes this weekend.  Will specifically look at that fairing since I like that little part and would enjoy using it in other places more easily.

  2. 13 hours ago, CarnageINC said:

    *snip* This created an error in MechJeb that basically doubled my Delta/V of what it actually was.

    I can tell you how to recreate it. Add a probe core, tank and engine.  Then add a 2nd probe core.  Then detach the 2nd core but don't throw it away.  Then detach the fuel tank and engine and throw them away.  Now add a new fuel tank and new engine.  Then reattach the 2nd probe core that's been hanging around.  Now change the root order so that the first probe core is root again.  At this point you should have doubled dV.  It won't trigger it 100% of the time but it does about 95% of the time.  

    It's caused by a limitation of the root tool and it loses its mind and starts reporting where it's at in the staging order incorrectly to MJ.  This is my understanding of the problem anyway.  The best way to avoid it is to always throw away anything that has command capability either manned or unmanned if you remove it from a craft - engines/tanks too.  Also, if you start messing around with staging orders after loading any subassembly you're likely to face it again as well.  You can sometimes force MJ to show the proper dV by playing around with some decouplers along the stage even if you remove them afterwards.  I've been experiencing and replicating this error for a while now - definitely more than a year.

  3. 5 hours ago, eddiew said:

    Ahh, thank you. I feel like I've read somewhere that reflector telescopes can also have issues with not showing the wires that hold the smaller mirror in place too?

    You're referring to the difference between a Newtonian reflector (has no upper support structure focusing the light column onto an upper eyepiece) vs. a Richey-Chretien style telescope like the Hubble.  Just for comparison...a 20 inch Newtonian reflector is a long tube generally around 7-8' tall and a 20 inch RCT would be around 3 feet tall.  They are super lightweight and strong with amazingly short focal planes allowing super precision focus...but they suffer diffraction spikes as described by @astroheiko

    I seriously apologize for making this 3rd off post in the thread and also shall contribute my screenshot fig leaf...

    A timed re-entry of 3 ASERT/Asteroid Sample probes as they passed over the KSC on their return home from a successful mission

    21O5xNf.jpg

    My current game is getting me killed on the science front since I run a 10% science game with 90% contract science penalty making me constantly use every asset I have available to gathering higher tech.  This planet pack is absolutely stunning for this type of forced long term game play.

  4. 1 hour ago, MaverickSawyer said:

    Nah, he just needs to get clever. There are ways past the steepest part of the science curve other than simply brute force.

    I generally agree with you hence the overly restrictive science settings I play with.  Combine that with entirely eliminating the stock solar system (including the Sun) and many of the "ways past" are no longer there.:D

    EDIT:  And I also just recalled this bit...if I really wanted to defeat the science game in my restrictive setup just install MKerb... :P

     

     

  5. The EC hogginess really starts rear it's head during difficult climbs where you're pushing the motors hard.  Using both the medium and large wheels I was able to cope strictly with a pair of the big fuel cells.  I would drop in power during heavy demand periods but as long as I had intervals of relative clam cruising it would come back up again.  It's definitely not carrying a few hundred measly EC anymore though and I love it!

  6. 1 hour ago, Shadowmage said:

    *snip*  I might need a bit more information on this. *snip*

    Just as a follow up.  Using the latest dev version:

    Non-scaled version I couldn't break no matter what I did or how hard I hit the water including at Gear Ratio x:1 (max speed 43.12 m/s).

    Re-scaled was another matter.  I broke them rather easily and have other things that I'm reporting on Git.

    Also as a side note, I used to use Vessel Mover regularly and would frequently break my wheels/gear or other parts when I transferred vessels to water but just never tracked it all the way down to figure out why...(maybe frequently is overstating but was common enough) :ph34r:

    EDIT: As a side note, the new acceleration code is not allowing breakage to occur from runaway wheels like it was in the release version.  I was regularly getting air in testing sessions this morning, often significant and they wouldn't break from mid-air acceleration.

  7. Sounds like you've got a great plan for going forward tbh...

    Simplification of processes like the adaptive cap system will go a long ways towards fixing a number of the problems and getting this back to a frequently usable and less of a problem child.  The one and only thing I would change would be tracking electrical usage along with gyro decay.  Electrical usage, especially on high flying telescopes, needs to be something we have to deal with imho.  I'd be find without it though as it's really not that big of a deal...

  8. Ok - I test the same way generally as well.  No extra frills and all stock parts for testing to be able to Keep It Simple Stupid.  I'll just begin by banging the crap out of the modules and parts themselves to try and find any quirks I can track down and then will move into testing them against other mods, specifically ones that integrate into functionality that may require interfacing with rovers/wheels.  Unfortunately, I'm in the same boat as you are in re: to FAR.  I haven't used it since .90 days and even then I was only lightly using it.  Do you want issues reported here or opened on Git?

     

  9. 2 hours ago, GreyKestrel said:

    I was hoping to see additional updates on the topic of Research Bodies + GPP. :) Has anyone had any luck in the last week getting these two mods to work together? 

    Thanks!

    Paul

    Not yet but admittedly I've not tried very hard because I've got 3 testing projects for KSP on my platter right now.  I do know that @Galileo has a working version of RB included with the GPP distro and the very first time I setup GPP and went in to test, it all seemed to be working for me too.  That said, I didn't go deep at all and was using Hyperedit to cheat my way around flight times for spot checks and as mentioned above, RB and Hyperedit don't really cooperate.  It wasn't until I had my much larger install setup that I started seeing actual problems with RB and I'm about 99.999% sure that it's an offending mod, not RB...

    In summation, tl;dr or whatever...it does work with 1.2.2 and GPP but you may have other mods causing issues with it.  

    My suggestion would be to start with a completely fresh install of KSP in a new directory.  Get GPP up and running with only the required pieces for GPP and include the GPP RB install as your only additional mod.  Your mod list would ONLY have: 

    Spoiler

    Module Manager

    Kopernicus

    Modular Flight Integrator

    Community Resource Pack

    GPP

    ...and the GPP Research Bodies install included in the GPP zip file.  INSTALL RB NORMALLY FIRST THEN MERGE AND OVERWRITE WITH EVERYTHING IN THE ZIP!!!

    Once that's done, start up the game before you add anything else and see if RB is working then.  This will at least give you a clean starting point totally unadulterated from any previous attempts to get it working...

  10. I'll explain a little better since now that I read what I wrote I'm not quite sure... :confused:

    SD-18 has adapter settings for Barrel (1.875m), wide (2.5m) and slim (1.25m)

    SD-25 has adapter settings for Barrel (2.5m) and wide (3.75m)

    Specifically, what I was asking for was to have the 1.875m option on the SD-25 BUT...

    2 hours ago, Angel-125 said:

    You can flip the adapters upside down

    This will probably work for what I want using the SD-18 since I want that option to down convert from 2.5m to 1.875m specifically at the decoupler...sometimes logically thinking about stuff doesn't work out as well as I'd like since it tends to overlook the obvious creative solution... :P

    2 hours ago, Angel-125 said:

    Also, anybody want to take a crack at rebalancing MOLE's parts for USI-LS?

    I can put it on my list but I've got DEV branch testing going for BDB and KSPWheel right now.  I'm mostly done with the BDB stuff so I might be able to get a look at the balance on it in the next short period (week or so).  Since I've got the full WBT suite installed on a GPP play through I can get a good feel for the balance as it's backed by USI-LS.  I've also got a good feel for the math behind it too and have already used that spreadsheet to fix a few personal parts of my own.  If someone else gets to it before me though, more power to you....

  11. 1 hour ago, Shadowmage said:

    What would help would be someone who wouldn't mind doing regular testing of the dev branch.

    I haven't got as much time for testing as I used to but I will definitely help out where I can.  Is there any specific setup you want tested, as in stock+KSPWheel+KF only or do you want testing across the board against other mods?  Just want to know how to setup my install to test specifically what you want and to be sure to avoid anything that may be of a concern.  Just as a basic setup for testing I would usually have KER/MJ installed for diagnostic readouts and TweakScale for mods supporting it (like KF).  Other than that I'll run anything you want or remove any of those 3 if you don't want them in the way of results.

×
×
  • Create New...