Jump to content

AccidentalDisassembly

Members
  • Posts

    1,220
  • Joined

  • Last visited

Everything posted by AccidentalDisassembly

  1. Also found that (clean install) it's impossible to load with all of the options installed (recommended ones + extras) - perhaps slightly lower res textures for the clouds & auroras & stuff are in order... I'd love the Jool clouds and all the extras, but I'd also love to be able to get the game to load - I want it all! =) Perhaps -force-opengl is the way to go, probably should have thought of that before posting.
  2. I'll attempt to answer that, though I'm obviously not the person who really knows: I don't think you can do a MODULE within MODULE thing like that and get the results you want. You want a TWEAKSCALEEXPONENTS {} thingamajig within a SCALETYPE {}. In TWEAKSCALEEXPONENTS, you define the exponent (or the specific values for given scales) that will apply to a particular variable. This one will make the thrust scale in proportion to the size within ModuleEngines modules, so the maxThrust value will be 2x the original when the part is 2x the size. This one will make the maxThrust of whatever part that gets scaletype "whatever" have those values rather than those exponents - but if you do it this way, you cannot have more than 5 scaleFactors without modifying the scaletype (but maybe that's what you want; you can have much more control over the numbers like that) - in the example, apparently everything scales linearly until you hit 5.0x scale, at which point the thrust goes crazy. I would recommend NOT defining a TWEAKSCALEEXPONENTS{} outside of a particular scaletype for the sake of being able to tweak things on a per-part basis (different scaletypes for different kinds of parts, maybe). I guess you could even define customized, individual sets of ways to scale variables for particular parts by putting the TWEAKSCALEEXPONENTS{} inside one particular tweakscale MODULE{} for one particular part, if the parts responded to the variables used so differently. As far as I understand it, you can apply either exponents (for modularity, applies to any scaleFactors anyone else thinks are useful and add) or specific values to any variable in the code of the wheels - so long as you use the name used in the code of the DLL, I think. So if one of the variables that lo-fi uses is called "MyWheelsAreAwesomeAndHeresTheirTorqueValue", you'd do: Sorry if I am telling you stuff you already know, I may not have understood the question you're asking. The example above would apply those particular MyWheelsAreAwesomeAndHeresTheirTorqueValue values to those particular scales for every part with a TweakScale module of the type "awesomeWheelScale". TL;DR: you can do what you're asking like so.
  3. Something re: the autocollecting science containers - Was driving around KSC, and autocollecting the science from various experiments seemed to generate two reports rather than one (5 experiments - autocollect - 10 available to review when you hit "review stored data")
  4. Any chance for a relatively easy fix to the borking of the altimeter? I love the mod, but when accelerating stuff in-atmosphere, other mods (like pilot assistant) die when the altimeter dies. =(
  5. I suppose it's sort of a bug, or rather an additional feature that would be good - it *appears*, anyway, that certain contracts (like aerial surveys from FinePrint) aren't affected by the modifier, and adding FinePrint contracts to the scope of your mod would be cool. =) You're right, a non-sharp cutoff would be better!
  6. If you're open to suggestions, one thing that I do think would be useful would be to allow a "maxScience" value to be defined in the cfg too, where any contract that gives more than X science is reduced to X science - so you can end up with something like this: 1) All contracts give 5% science, so a 200 science contract (normally) now gives 10. 2) maxScience is set to 5, though, so any contract that gives over 5 is reduced to 5: science from that contract is now 5. 3) But a contract normally giving 80 science still gives 4, 50 science still gives 2.5, etc. The whole point of that would just be to address there being some MASSIVE science contracts that, even if reduced 95% like they are with default settings, still give you 24 science for pretty easy stuff like testing a landing gear while landed (for example). Or, if it's not totally outside the scope, maybe science could be turned way down for part tests, but could remain relatively higher for other contract types... dunno if that's a realistic thought. EDIT: Actually, come to think of it, maybe what's going on is that certain contracts aren't being affected by your mod, from FinePrint for example. Is that even possible?
  7. It's fixed...? Where did you get a new version from? Or did you have to put one together from the TS GitHub thing?
  8. Sorry if this has already been addressed - but a useful feature for the converter would be to define a maximum size a texture can end up as, kind of like ATM does. What I'd like to be able to do is this: 1) Define which textures get resized - only things 512x512 and above (current version does this well). 2) But then define that ALL textures above that size shouldn't just be reduced to 1/2 or 1/4 size: instead, all textures above that size should be reduced by 1/2 OR 1/4 if that's what it takes to make them equal to or smaller than a given size. So if you defined a maximum of 256x256, both 512x512 and 2048x2048 textures would all become 256x256 rather than 256x256 and 1024x1024 respectively. That's probably a convoluted explanation, hopfeully just "define maximum result size" is vaguely intelligible. Would be really handy!
  9. I'm also having the issue of sparks etc. on wheels, taxiing before takeoff, and at very low speeds. Secondly I noticed - and the effect is very cool, but maybe not intended - that I get the same yellow glow that the sparks give off when I fire up certain rocket engines (as on the launch pad). The engines seem to emit a yellow glow onto surfaces around them. Looks pretty cool, but wonder if it's supposed to happen... EDIT: Also, with certain wheels (a rescaled smaller version of the stock small landing gear, for ex) the yellow glow is basically on all the time, and the wheel always sparks.
  10. I'm not sure if I figured out what was happening or not, but I did get the assistant to work correctly (and it is AWESOME) with a newer craft I made. I suspect it was user error, or possibly simply that the plane design I had was bad, or something like that. I was activating altitude/heading keepers (not wing leveler or vertical speed, I think). It was a steady nose down (as in pitch over forward and just keep going until you're pointed straight down) and not vibrations, though I finally figured out how to eliminate some of the vibrations - if I had another suggestion, it would be to rename the field ("control vertical oscillation" or something) or simply to make sliders for those of us who don't know what Ki, Kd, Kp, whatever mean. What happened on the previous vessel was: 1) enable assistant functions, numbers readout (like target altitude) was based on altitude at the time I pressed it, like it should be, I think. 2) steady pitch over until nose down, 3) no apparent effort at correction. But there are many factors which I now understand may have played into this: possibly running out of battery and not being aware, possibly crappy control surfaces, possibly also a conflict between normal SAS and the assistant... so I'd treat my report with skepticism.
  11. OK, I think that must be the problem then - I had stock SAS on while trying to turn on PA stuff. For a future update, it would be handy to somehow deal with that so that you don't have to turn off SAS (possibly blowing up the plane, especially if moving very fast) before turning on the PA. Will go try that out and see what happens... EDIT: Welp, tried that. The Pilot Assist now definitely engages, and promptly nosedives me into the ground - updating/changing heading, altitude, mode, whatever still makes it point straight down =(
  12. A couple things I've noticed so far: 1) If you're using the SAS, it generally does a good job of not blowing up the plane and keeping it pointed where you say. However, 2) Physics warp = insane flailing, and 3) Let's say you have heading 0, pitch 0, roll 0 set. If you happen to deviate from that to the LEFT a little bit (now you're heading 350, say), the SAS will attempt to yaw the plane all the way around in a circle to the left in order to come back to a heading of 0. EDIT: Actually happens on the "right" side of the gauge too. If you're heading about 45 and set 358, it will yaw right... it seems. Weird stuff happens around 0, maybe. And, though I may be the only one on this, 4) The pilot assistant doesn't actually do anything - activating, deactivating, changing numbers, updating... is there some dark magic needed to make it work?
  13. Going to go find that and give it a try - EDIT: Aaaaaaaand same issue with the version updated about 30 mins ago. =(
  14. Posted this in the TS thread too, but then remembered Biotronic isn't around too much and thought it might be good to post it here too. Having some kind of issue, possibly with TweakScale & FAR interaction - I'm using TweakScale 1.44 and the newest FAR (1.44 because 1.47 is broken). This time the issue occurred, it was on reloading KSP, going to SPH, loading craft (that was already on the runway), launching. Logspam of nullreferenceexceptions related to TS and FAR + very, very slow performance. The previous time the issue occurred, I had launched the same craft, flown far from KSC, and then returned - it *seemed* to happen, maybe, when certain parts of KSC re-loaded or when some debris re-loaded near KSC or something like that, but I am not sure. Prior to that, the same thing happened after launching a craft, reverting to the SPH, and then launching again... or something along those lines. Here's a log: https://dl.dropboxusercontent.com/u/59567837/output_logFARandTS.txt EDIT: reverting to 14.3.2 seems to fix it so far...
  15. Look in the DefaultScales.cfg file - the answer is yes, just imitate how things are done in there and add more values, or write your own type.
  16. Blech.... getting infinite logspam of this: And then that's followed by lots of this: Seems to regard the SXT TinyJet engine, or at least in the Debug screen there was mention of it, but I have no idea. Log is too gigantic to post. TS version 1.44, just started happening when KSC re-loaded after I flew away from it and then returned.
  17. Just a random THANK YOU for actually giving your parts intelligible names. I write my own TweakScale configs for most stuff and yours (for FTT) took 5 minutes whereas lost of other mods expect you to psychically divine what size "bigTank01" is. So... thanks!
  18. Makes sense. If it's just to do with vessel lengths vs. wheel heights, does that mean that (in theory) if you built a perfectly proportioned vehicle with repulsors, and then scaled the whole thing up, it would work? If it's not absolute numbers that matter, but only proportions, then maybe the repulsor's range of heights could be calculated on the fly from a measurement of the vessel length...? If that's even possible
  19. The 8m limit could be worked around if tweakscaling the repulsors just made them carry more weight (and have an amount of springiness that works for really heavy things), probably. The issue I have with them currently is that I can't set the strength high enough for ludicrously large crafts (~ 35,000 to 50,000 tons), so either I put 923859835938 repulsors (even with their strength tweaked to the max) or wait for the TweakScale goodness to arrive =) My usual disclaimer: no clue how any of this works, so I'm just going to throw out some verbiage and see what happens. If the issue is the edge of the wheel colliders being more than 8 meters from the base they're attached to (presumably), could there be an invisible, collision-less base (imagine an invisible landing gear leg, or really just an invisible, non-colliding cube, or something) that gets added between the wheel and the visible repulsor when its scale is increased? As if the repulsor part itself were actually much bigger than it looks, while the wheel collider is still only 8m from the edge of the invisible bits now added to the visible part? Does any of that even make any sense? Looking forward to the next release.
  20. The bugs aside, which are separate issues from TweakScale looking very weird on certain parts: nothing FORCES you to scale anything, and if you are afraid you will be tempted, won't be able to resist, and the ugly will overwhelm you and end the world as you know it, you can delete the TweakScale module for certain parts by going into the appropriate MM config and removing the patch for those parts.
  21. Wondering that myself, and also wondering if the answer wouldn't come when the TweakScale stuff gets sorted out - would seem to be a good way to address that. Possibly.
  22. I reverted back to 1.44, but I can maybe help with this: 1. Lots of mods, unfortunately. But my immediate suspects would be MFT, or maybe TweakableEverything, GoodSpeed's autopump thing, or something like that, since I seem to remember there being a similar mass problem with MFT in the past (before 1.44, certainly). 2. Exact steps for me were simply: put tank in VAB, scale up and down. That's really it. I *remember* it applying to any and every tank, but could be wrong on that. Any thoughts on landing legs/gear? And on Infernal Robotics - aside from the crashing bug others mention (didn't happen for me in 1.47), but instead the general impossibility of simply taking an IR part and assigning any scale values to it - currently this does not work. Posted at length with logs about this in the IR thread, no response there.
  23. Since you have limited time, I understand that this is probably not a priority - but I was wondering if you would mind looking into the interaction between TweakScale and certain parts like wheels and landing legs. I get the impression (maybe others can confirm or deny) that scaled-up landing legs, for instance, basically lose all of their "give", or springiness, and end up acting more or less like solid rods. And the interaction between TS and some kinds of wheels seems to produce unusual power relative to the wheels' size (in some cases, maybe this is just lo-fi's tracks and whatnot, though). Maybe these could be fixed by SCALEEXPONENTS or something?
  24. Is there an easy way / easy guide for transforming a normal engine (like an ion engine) into an RCS engine while keeping all the relevant animations and whatnot? I looked through many of the guides out there, but they assume you are making a normal RCS thruster with some white gas being expelled from it...
×
×
  • Create New...