Jump to content

artwhaley

Members
  • Posts

    639
  • Joined

  • Last visited

Posts posted by artwhaley

  1. Is there any way to get tweakscale to quit complaining twice on every load about the fact that Ckan is also apparently installed?   I read in the other thread it's supposed to be once a month but it is twice on EVERY load of the game for me without any changes being made to the install.   

    As a fellow mod maker... I certainly respect your right to list or not list your mod with Ckan...  and I understand not wanting to put in work to support whatever issue Ckan may have created for your codebase...  but please just DELIST YOUR MOD with Ckan if you don't want to deal with them, rather than annoying all the users with a tantrum twice on every load?    If the double tantrum on load isn't intended behavior, let me know what logs and details you need to troubleshoot that, I guess.   

  2. Did you have a specific use case in mind for this?   What kind of parts were you thinking about making?   Have you made parts before?   

    I don't mind helping with the plugin if you've got a cool thing planned and are doing all the partmaking stuff!   I'll have to get all set back up to do it, too, but it's not THAT bad.  lol.

  3. 4 hours ago, AtomicTech said:

    Copy that; when I asked the question I was hoping that I would get some links or something but that means that I have to go pestering LGG again.

    Thanks :)

    Is still a decent place to get started.    

    https://github.com/taraniselsu/TacExamples/blob/main/02-SimplePartModule/Source/SimplePartModule.cs  Has a really well commented example of a part module, which is what you'll want to make.    

    It's been YEARS since I've done anything in KSP plugins...  so yeah... LGG is obviously the leading expert...  But basically...  you'll create a class that extends partmodule.   You'll create KSPFields to create the places where in the part config file you set up the conversion rate and efficiency and anything else you need.   You also need an internal variable that tracks when the last update was.

    Then, in the On Fixed Update event, you subtract the part temp from the ambient temp...  if the differential is enough for your part to work, you substract the current time from the last update time...   multiply that times the conversion rate and subtract that from the part temp...  then multiply that number times the efficiency and add it to the vessel electric charge...   

    The actual programming is going to be super quick, it's going to take longer to get visual studio set up and get through your first couple of examples before you try your real project!    But it's a great thing to learn!

     

  4. I've started on a 'final' features complete update fork.   

    So far I've added support for:
    stock robotics
    rotating docking ports
      blinking lights
    stock alarm clock
    the wheel upgrades
     resource drains
    and autostruts.

    You can grab a preliminary version at https://github.com/artwhaley/krpc/releases/tag/experimental

    Unfortunately I'm building in windows and am just recompiling the DLLs, so I'm not able to rebuild the documentation and a few of the client files, but things should be named pretty self-explanatorily so it should at least all work for folks using python.   If anyone with the full build environment working wants to help out with documentation and the client libraries that require building...   I'd really appreciate it!   I'll try to eventually get around to setting up a linux laptop and making it work myself if nobody else can, but... 

    If anyone finds bugs or has questions, please let me know!   I've made pull requests to both the main repo and to Null Profile who's been doing rebuilds...   but until someone more qualified takes over, I'll do my best to get things updated and finalized!  

  5. I've started on a 'final' features complete update.   

    So far I've got support for:
    stock robotics
    rotating docking ports
      blinking lights
    stock alarm clock
    the wheel upgrades
     resource drains
    and autostruts.

    You can grab a preliminary version at https://github.com/artwhaley/krpc/releases/tag/experimental

    Unfortunately I'm building in windows and am just recompiling the DLLs, so I'm not able to rebuild the documentation and a few of the client files, but things should be named pretty self-explanatorily so it should at least all work for folks using python.   If anyone with the full build environment working wants to help out with documentation and the client libraries that require building...   I'd really appreciate it!   I'll try to eventually get around to setting up a linux laptop and making it work myself if nobody else can, but... 

    If anyone finds bugs or has questions, please let me know!   I've made pull requests to both the main repo and to Null Profile who's been doing rebuilds...   but until someone more qualified takes over, I'll do my best to get things updated and finalized!  

  6. On 8/14/2021 at 9:16 PM, wasml said:

    You've probably tried this but... "OnPreModifyServo() - Updates the values of a servo in both scenes. Is called when The PAW values are modified" and "OnModifyServo () - Updates the values of a PhysX servoJoint in Flight"

    I did try those methods and didn't get things working!

    [snip]

  7. Sorry to Necro you,  but not sorry enough not to do it.   

    Did you ever get C# control of the pistons?   I've got control of the hinges and rotational servos (but not the rotor hubs...  sigh) directly by setting targetangle values...   but setting target extension gets me nowhere!  I see the new value pop up the next time I open the PAW, but the piston ONLY moves if I drag the slider in the PAW with the mouse!

  8. On 6/28/2021 at 12:35 AM, JPLRepo said:

    There is currently no “GetAllAlarms” method - Triggers apologies - this will be fixed

    I was sort of figuring this would come in the 1.12.2 patch, but it doesn't seem to have, unless I'm missing it?  Any update on this?   Thank you!  

  9. On 7/22/2021 at 9:16 PM, Kerbart said:

    I'd like to see a final 1.12 compile, @artwhaley

    Well you're more qualified than me to do it!  :P

    I've got things moving.   Compiling against 1.12.2 was super easy, now I'm just trolling the devnotes and release notes for features that got added to the game...   so far working I've got rotating docking ports, all robotic parts except for pistons working (there seems to be a bug in KSP's piston implementation that makes it not respond to anything but the PAW, but I'm hoping someone posts a work-around), lights blinking, new wheel adaptive steering, and fuel drain parts added.

    What's left is integration with the now stock alarm clock and maneuver planners, compound part controls, autostruts, and command pods with more than one control point.   There are also a handful of issues on the issue tracker I think are worth trying to duplicate and chase down.   

    Has anyone else noticed anything broken or missing that actually affects game play?   At this point in the game / mod's life cycles I'm not concerned about emulating EVERY single button a person could ever possibly click, but want to focus on things that a person might actually want to be able to control remotely/programmatically.   

  10. Hey there, I feel like I'm either running into a KSP bug or bumping my head into something really stupid.   I'm trying to write code to control the Breaking Ground robotics parts...   and the rotation servo and hinge work fine...   but I can't get the piston to move!   I'm setting the targetExtension and seeing the new value show up in the PAW, but the piston servo doesn't do any actual movement.   if I then grab the target Extension slider in the PAW and move it, the servo goes right to work, so it's not as dumb as me only testing it on a craft without batteries or something like that.   Has anyone successfully driven the pistons?   Thanks!

  11. How many folks are using or would be using this?    The previous version still seems to work with 1.12 though I haven't thoroughly tested everything or checked to see if there are features that KRPC can't access yet?  

    I've helped a little with updating this mod for new versions in the past and wouldn't be opposed to getting it compiling against 1.12 and make a pull request...  since apparently this is going to be the final game version...  but probably won't bother if I'm the only one who writes full software suites for every rocket in python.  lol.  

     

  12. I'll also add - most of what I know about unity development...  I learned by helping to update mods when KSP versions changed.  I don't mean this in a facetious way at all - but if you're smart enough to play KSP, you're smart enough to code in C# and you might find a new hobby by getting into it!   

    Roll back your game install to 1.11.  Download the source, open it in visual studio, resolve the references (usually to the DLLs in the game directory), get it compiling (ask questions if you have trouble!)  Upgrade your game to 1.12.   Click the compile button.   You'll get a list of errors.   Start double clicking through them and play detective with the auto-complete text to figure out what's changed and fiddle with it until it stops giving that error on compile.   Move to the next one.    When all the error messages are fixed, load the game with your DLL instead of Sarbian's in the mechjeb directory.   Test all the things you think you touched.    If it all works, make a pull request.   @sarbian will then tell you all the things you screwed up.   Fix those things.   Make another pull request.    If he uses any of your fixes, celebrate.  There's nothing cooler than knowing 10 lines of Mechjeb code are your work and every body playing the game has you to thank for it.    It's even more appreciated for the less maintained mods.   I don't know if @linuxgurugamerstill maintains 4 zillion mods...  but a few years back, every update he was buried and was profuse with the thanks if you could error check a couple of little ones for him.   

    It sounds daunting but it's really not that bad.   Follow one of the 'make your first plugin' tutorials to make sure you have the build process figured out before you wade into other people's mods...   then pitch in.   It's really not any harder than orbital rendezvous and it can be a rewarding hobby all it's own.  And once you start messing with mods, you've opened up the next 1000 hours of fun you can get out of this game.  I've probably spent as much time modding as I have actually playing.  

     

  13. On 4/15/2018 at 6:15 PM, Stone Blue said:

    wot aboot @sirkut's arm tho? :P

    I'm working on some arm parts at the moment!   Sorry that Gyazo creates such low res screenshots... but it's easy and fast...

    5760ce9705b5754a95d45a9f1bd418e3.png

    I'm planning to release them for Sirkut's plugin (in fact offering to let him release them with the plugin, if he'd like.) as wholly built single part arms, but also planning to release the individual pieces as IR parts, for people who want to assemble their own arms.   There also seem to be some things that monolithic arms are better at, and some things that IR arms are better at... so there will be people that prefer one over the other.   

    That's all by way of saying, I'm a big fan of this mod and I'll make sure that there are a set of parts that are a scale that conveniently fits in the cargo bay of both the Mk3 and the medium shuttles when I have time!   I'm also paying attention to the scale of stock parts too, to try to make things that generally work well with other things!  

  14. Infernal robotics is quite easy, as far as mod making skills go.  If you find your way through all of the other steps, making a part work as an infernal robotics hinge will be simple.  A quick look at the .cfg file for the IR parts will show you that you can essentially copy the module from that file and insert the names of your two mesh pieces, as they've been labeled in blender or unity, and set the axis and call it good.   If you get everything else working and want help with that part, feel free to shout!

  15. 1 hour ago, Capt. Hunt said:

    You're confusing mass with weight.  Mass doesn't change with gravity.  A 5kg bowling ball has the same mass in LEO as it does on the Earth's surface.  What changes is the weight.

     

    Mass is a function of volume and density, weight is a function of mass and acceleration.

     

    I'm not confusing mass with anything.  I'm saying instead of tracking two numbers in software... track one, and scale it based on gravity (calculating weight in situ, effectively.)  The person above me had suggested a mass limit and a weight limit be recorded...  and I was pointing out that coding a weight limit would only make sense on one body... better to just say "You can move x amount of mass in orbit, and it scales down the greater the gravitation, since you're working against inertia AND gravity, when you're lifting weight.

    Mass is a function of the Higgs Boson, most likely, though until we understand that better it's easier for practical scientists to talk about it as it relates to inertia.   Volume is a function of atomic spacing.   Density is a derived property that relates mass to volume.   Weight I agree on, though. 

    Also, I'm smiling while being contrary and pedantic, not trying to really be a pain.  :wink:

  16. 8 hours ago, suicidejunkie said:

    Really, there should be a separate mass limit and weight limit.

    I've thought about that too.... or rather, that the mass limit should scale based on gravity, when you're landed...  Wrestling 500kg into place on the Mun is a different animal than doing the same on Kerbin... though...  I don't want to have to break out the slide rule and look up gravitational parameters when I'm packing a container and need to know what I can lift on Duna... so I think not complicating it any more than necessary is the right call.

  17. @Munar Industries  Thanks for the kind words!  Yes, you've done a FANTASTIC job of balancing the urge to be complete with the urge to keep a mod from getting bloated.   In my opinion, you've got it just right - there's not a single tank in your pack that doesn't have an obvious use case!   They look better than the stock tanks, but without changing the style so much that they don't still 'fit in.'  Really great work!  

×
×
  • Create New...