Jump to content

Renegrade

Members
  • Posts

    2,419
  • Joined

  • Last visited

Posts posted by Renegrade

  1. Woot!  I'm trending!  :wink:   The truth is out there...

    In a more serious vein though, I'd love to see Dres revamped in some way to make it NOT an angry useless space potato.  The Drestroids were a nice start, but not enough in my opinion (they're NEAR Dres, they AREN'T Dres though).  Muns, atmospheres, more interesting terrain.   Anything!  Give it a huge mun and make it volcanically active... Rings.  Just.. not something that's basically Ike wearing a fake mustache.

    smzEPC5.jpg

    "I'm totally Dres and not Ike in a shoddy disguise at all.  Not even a little bit!"

  2. 2 hours ago, Majorjim said:

    Nope, not the case at all, DL my test craft in the bug report, it is a single part with legs attached it vibrates across the ground. It is almost certainly connected the suspension model.

    Even a two part ship has flex.  Parts are never perfectly rigidly attached. Also, the test craft 2 does not jitter in my test sandbox save on either the runway or launchpad unless I force physwarp.  The un-numbered one does explode and sometimes takes the launchpad with it.  My own tests show the more flexible a part is, the more the bounce happens.  Making long support shafts for wheels (or landing struts or landing gear) definitely makes it worse.

    One other thing I've noticed though is that sometimes the wheels seem to be reacting immensely to what should be a tiny force, and there might be a fp underflow type issue going on.

    NB: At no point am I denying that the problem exists.  Nor am I saying that the current code is acceptable. A positive feedback loop between a craft's suspension and flex shouldn't exist like that in the absence of any significant outside force.

  3. 2 hours ago, GoSlash27 said:

    Can we please move beyond yelling at Squad for all the bugs in 1.1? Yeah, we're peeved. Yeah, they are aware of it. None of this complaining is helping to fix the bugs.

    If we want to fix the problems and get back to blowing things up, we need to roll up our sleeves and get to work.

    Bug reports need to go in the bug report thread here: http://forum.kerbalspaceprogram.com/index.php?/forum/69-technical-support-unmodded-installs/

    Uh, most of the bugs have already been reported in the pre-release.  At least, any that I complain about.

    1 hour ago, sal_vager said:

     

    It also doesn't help to have duplicate reports, please look to see if your issue has already been reported, it may already have a workaround.

    Question: if it's already reported in the 1.1 Pre-Release section, does it have to be re-reported in the main section?   My ladder bug and symmetry bugs are still outstanding, but in the 1.1PR section.

  4. The "jitter" issue seems to relate to the flexibility of the craft.  If I make a sturdy craft, with gears/struts/wheels attached on non-wobbly parts, the issue doesn't crop up.  If the gear is installed on more flexible locations (like on a row of poorly supported modular girder segments for example), it hops and jitters around like mad.  Various wheel right-click settings do not help.  Strutting can make it better (or at least delay the onset and severity of the jitter)... I'd almost guess that the actual wheel physics are happening in the wrong order with craft physics, which could very well create a feedback loop..

    I'm also rather alarmed by the sinking-into-the-ground issue as I'm afraid that when it's finally fixed, bases and landed craft will launch themselves into the air once loaded for the first time.

     

  5. 9 hours ago, Alshain said:

    I blame Microsoft.  Nearly every PC built this century has a 64 bit CPU, they haven't produced 32-bit CPU's since then.  Yet, Microsoft still offers Windows in 32 and 64 bit.  If they would just stop offering 32-bit, everyone would be the same by now.  Should have happened way back on Windows 7.

    Atom processors were released fairly recently and only a limited selection models have 64-bit support.  So there'd be entire generations of netbooks and compact-form PCs restricted to Windows XP or Vista following that plan.  So they pretty much have to have a 32-bit branch.

    (NB: Atoms are part of the x86 family, rather than an ARM chip or something.  They pretend to be ARM though, low power, even lower performance...)

    Also re: Steam, it probably defaults to 32-bit as that's guaranteed to work on any system.  It's the "safe mode" option.  32-bit will work on a 64-bit system (works extremely well in fact).  64-bit will not work on any 32-bit system. 

    9 hours ago, Alshain said:

    Does Apple offer 32-bit anymore?  I know technically Linux can be compiled in 32-bit but I doubt many home users capable of compiling Linux actually do that.

    64-bit incurs heavy penalties both in code size, page tables and kernel constructs, so any machine with 4 gigs of RAM or less should really be running a 32-bit kernel, unless you really need to hit that swap hard with a broad address range for some masochistic reason (strongly UN-advised, active swap is a good way of killing any type of fixed storage, and also killing any sort of performance).

    This goes double for servers, as an older Core 2-era CPU makes for a very powerful server (web/samba/mumble/etc), and THOSE chips actually run 32-bit code much faster than 64-bit code (the additional hardware required to decode 64-bit instructions is reconfigured for additional 32-bit decoding/branch prediction or somesuch), and are often hard-limited by chipsets to a max of 8 gigabytes anyways, and are usually equipped with 4 or less.  I'm actually very sad that I don't have any working Core 2 machines now, which means I have to run my own main server off of a power-hungry i7-920.  That's going to really add to my fun when the temperatures warm up next month and that damn potato-cooker is making it 32C in here (AC is central to the whole building complex and doesn't come on until LATE May, and even then, the potato-cooker will be fighting the AC tooth and nail).

    So no, it's not "technically" - there are MANY 32-bit Linux installations, partly because it's much less bloated than win-suck.  Heck, my remote server was rocking a whole gig of memory on a P4 chip for the longest time, and would still be doing so if the hard drive hadn't been flagged with a SMART warning and there hadn't been a limited-time sale on 8-gig Lynnfield units.  I'd love to see a bloated 64-bit OS try to stuff it's fat ass onto that P4 machine.

    64-bit is actually kinda niche in it's usage, most things can be done fine in a 32-bit environment.  There's only a handful of things that bloat out so wildly as to need that - stuff like games (well, some games.  There's seven entire generations of 32-bit and 16-bit console games, and most of the 32-bit ones would run on a 29-bit CPU if such a thing existed~), video/photo editing, big data stuff, some types of scientific research, etc.  The vast majority of everyday things can happen in 32-bit just fine - spreadsheets, text/word processing, casual surfing (FF official windohs build was 32-bit ONLY until VERY recently), little gizmos (calculators/post-it thingies/calendars/email programs/chat programs etc), terminals, Steam, etcetc.

    I always get a good laugh when I see "notepad.exe" in taskmanager with no 32-bit tag on it.  Like as if that can handle a 60 meg file, let alone a >4 gig one.

  6. Does Godwin's law need to be rephrased for our new forum software?

    "As an online discussion grows longer, the probability of a comparison involving Bad People or Adolf Kerman approaches 1"?   Not sure what the forum would mangle A.H. into (if at all), as there's no longer a preview button.

    28 minutes ago, mcirish3 said:

    The irony in this of course is that the younger generations won't understand just how bad they were and may end up repeating it.

    The only thing we learn from history is that we learn NOTHING from history.  :P

     

  7. On 2016-04-22 at 7:33 PM, DrMarlboro said:

    fNz5nPn.png

    That doesn't work so well with the LY-01s as forward gear, I've found.  I notice you have the LY-10s up there.  I built a similar plane earlier (on the T2 runway though), entirely by coincidence (it was very front-loaded, so the wings were too far ahead for a tricycle arrangement), it worked very well. 

    However, I tried to build a test plane for the T1 runway in a testing save, and it was able to take off and land just fine from the dirt-mountain-ridge which pretends to be a runway with tricycle gear, but with the LY-01s up front, it would start to yaw left or right after reaching about 20m/s.  A longer, heavier version (3.6t/8.1m -> 4.2t/8.9m) was capable of taking off, but it too would spin out upon landing, losing about half of it's parts.  With tricycle gear, the longer version handled even better. 

    Anyhow, the whole point is not that it's completely unusable, it's that the runway is inferior to both it's own grassy shoulder AND the terrain around it.  Also, consider comparing it to the T1 launchpad, which is every bit as usable (within it's mass/size limits) as the T3 variant.  Can you say that about the T1 runway?

    (I'd say it's almost unusable, both the taildragger and tricycle gear designs easily wrecked gear if the ground speed was anything over 35)

    BTW, have you tried landing that thing with the reaction wheels in the cockpit disabled?  I have a feeling it would fall over without #lolreactionwheels on any sort of rough terrain.  The main gear are rather close together.

  8. 4 hours ago, monstah said:

    edit 2 - Oh, no! It's not as usual, you now double click. My mouse is just dying of old age, and clicks register as double sometimes :rolleyes:

    Ah, that explains it.  I noticed that it seemed "glitchy" before, but that's why - it was only responding when I was fast enough to simulate a double click heh.

  9. On 2016-04-07 at 0:13 PM, Foxster said:

    Is there one mod that if it wasn't updated to work with KSP1.1 would mean you would just quit playing? 

    No.  None.

    KAC is my most important mod, but I can and did play without it (or ANY mod whatsoever, save for my custom flag) throughout the entire 1.1PR and was pleased enough.  That's not to say that my enjoyment is vastly enhanced by things like KAC/Alternate Resource Panel/KAS/KIS/VOID etc, but I can make do without.

    It's like a steak.  I can grill up a steak with literally nothing else and enjoy it for dinner. The mods are like.. sides and sauces and drinks that greatly enhance the experience, but they're not strictly required.

  10. 8 minutes ago, Jarin said:

    Part of the problem is how smooth the ground is in the rest of the world. Terrain-scatter debris or soft dirt that can catch a wheel and flip an aircraft should be much more common.

    Well, that still wouldn't justify why the runway is basically a little tiny mountain range.  They really do need to smooth it out.   It doesn't have to be perfectly smooth, just.. not quite so violently bumpy.  Also, they should get rid of the broad green shoulders it has; they're almost as wide as the dirt part and perfectly smooth (may not be possible from a technical point of view, although I'd like a detailed explanation of WHY~).

    Also they need to have moar tiers of all the buildings with smoother progression, but that's a rant for a different thread.

  11. Just now, MK3424 said:

    I pretty much saw that function before 1.1... but when... i can't remember...

    Maybe through some mod, but not in stock.  (there's a mod for everything)

    My 1.0.5 pure stock save doesn't have any buttons like that for engines nor RCS (there is something like that for aero control surfaces though).

  12. 2 hours ago, EliasDanger said:

    Ill stop hating on Dres when its spokesman stops way overposting in the forum games section.

    I'll stop hating on Dres when it's no longer an angry space potato.  @Alshain is totally correct: it's a Mun for people who want to spend more fuel and time (and hassle) to get there.

    I've landed there at least once unmanned and once manned, and I really do think it doesn't have anything to offer.  It's roughly the same gravity and radius as Ike (slightly smaller than the Mun), pretty much looks like the Mun or Ike and has no atmosphere or anything.

    The other planets all have stuff that makes them more interesting:

    • Jool has it's own sub-system of muns and is the only gas giant.
    • Eeloo is far away, icy, and has that interesting criss-cross of canyons.
    • Duna has an atmosphere and is significantly larger than Ike/Dres/Mun.  Also it has Ike.  And also a canyon system.
    • Eve is.. scary gravity planet with scary thick atmosphere and has... some sort of fluid on the surface, and Gilly.
    • Moho is deep in the gravity well, and is Duna-sized (Duna Jr) but without an atmosphere.

    Also if Dres is supposed to represent Ceres, it's way too big.  Ceres in KSP terms would be somewhat smaller than Minmus (although not as small as Gilly).  If KSP ever got double-planet capability, making two Ceres-ish style things in orbit of each other to replace Dres would be pretty cool.  Alternatively, making it Ceres-ish and then giving it some ultra-light muns (Gillys) to fling the Drestroids about would be interesting too.  Or give it some sort of atmosphere.  Anything!

  13. 35 minutes ago, MK3424 said:

    This function was added in 0.24 to enable the use of multiple engines to roll the craft.

    The core code was, but the UI panel to control whether or not an engine is tied to it didn't appear until 1.1.  Prior to recently, there was no (stock; I'm sure there was a mod, cuz there's always a mod) way of disabling the roll binding for an engine without disabling the entire gimbal system for it.  Now we can just tick off 'roll' if we have too much roll authority, and leave the other bits enabled (or disabled) as we see fit.  Personally I'd have preferred sliders (0-100%) but this is still way better than in prior versions.

    Also in prior verisons of KSP, locking the gimbal in flight could result in the engine being stuck off-axis if it happened to be off-axis at the time of locking.  Now it seems to revert to proper orientation when gimbal lock is applied.  Another nice new featurette.

  14. 7 hours ago, suicidejunkie said:

    Switch view modes to ANYTHING other than auto.  The last thing you need when flying EVA is for your camera to spin around wildly because you just technically went suborbital!

    ^ exactly this.  AUTO uses orbital vs. sub-orbital craft status to determine which mode to use (I believe it's switching from 'orbital' cam view to 'free' cam view for orbital and sub-orbital respectively.  I strongly recommend that @jpinard pay attention to that advice there. And any other inexperienced EVAers.

    EVA shouldn't be a thing of fear, it's a thing of joy in KSP.

     

  15. 18 hours ago, Broco said:

    Another thing to add: a GC is not a bad thing. It's needed to make sure unneeded data gets unloaded from your memory. A GC normally runs in the background and "parallel" to the software, which means it doesnt hold your regular program. In KSP however it seams that the GC pauses the game, collects the garbage and then resumes the game. This is no good behaviour, and I would really like to know what causes this since I didnt have the problem in 1.05 but others had. I didn't change my hardware in between btw.

    Garbage collection actually cannot ever be totally parallel to execution.  Even the most sophisticated systems (read: complicated and bug-prone), sooner or later, are going to have to have to throw on a bunch of mutex locks or enter a critical section to alter the allocation tables/trees/whatever.   Also, these more sophisticated systems that try to reduce stalls are not efficient: they have much higher overhead overall than stall-oriented algorithms, so while they might reduce the hiccups somewhat, they'll reduce the overall performance/framerate too.

    Squad can't directly impact any of this anyways, they're using C#/mono, which runs on the CLR or Mono's version of the CLR, and that handles the garbage collection.  To significantly change it, they'd have to move away from the CLR entirely, which ALSO means a new language (the CLR VM supports many languages, but C# only supports the CLR), which would be even more work than porting away from Unity.  The only thing they COULD do is try to reduce the number of allocations/deallocations (well, implicit deallocations) they do.  So, fewer objects, buffers, etc, and/or pack them together in some way (if that's even possible with "modern" languages?).  NB: There are some tweaks that can be used for GC configuration, but they'd be largely platform specific (MS-CLR vs Mono-CLR), and only have a handful of options with limited capabilities, and tend to default to "as parallel as possible" anyhow (nobody likes those pauses in any sort of environment).

    GC isn't magic. It's also over twenty years old (Java dates back that far and has had GC since day one), and still causing problems.  Sure it's nice not having to manage heap manually, but you pay for that convenience in performance and smoothness.  Trade-off will always be trade-off.  Also remember how GC was supposed to get rid of memory leaks?  *snerk*

    #programmingdirectlyinANSI-CandOpenGLmasterrace~

  16. On 2016-04-21 at 7:07 PM, AdmiralTigerclaw said:

    However, I feel there is a weakness in the current save-game structure, namely, everything about a game instance is saved to one large file.  Not only does this result in sometimes extended load times (as the game searches through the ENTIRE file), it leaves the file easy to corrupt, and save-games easily lost.  Even a minor syntax error compromising the file because the game itself encounters an error during loading/saving can result in a complete loss of the file.  A writing pass on a save game may result in an incomplete file because of an error, again, total game loss.

    KSP loads the entire save into memory anyhow (with no searching at all), splitting into multiple files would actually slow things down with more unnecessary file I/O.  (Unity used to, and may very well still have, a hideous bug where any file open operation checks network connections as well as local files for some idiotic reason that could cause massive slowdown on any file open if the system had certain types of network interfaces, which would make this a thousand times worse if it's still a thing).  NB: the actual LOADING of a save takes about a second.  Most of the delay at start is loading assets.

    The current system actually ALREADY backs up your save to a directory within the save folder called "Backup" (ex, KSP_install_dir/saves/MySaveName/Backup), so you should be less boned when and if the file corrupts (I've never had an actual save file corruption, except one time when I was testing and editing orbits and made a data entry mistake).   Also, quicksaves are just regular saves with a different name, so you can restore a main save from a quicksave by copying the quicksave.sfs over persistent.sfs.  NB: the hard modes allow quicksave, but not quickload, so "F5 for safety" (as Das says) is always a good idea, even in hard modes.  That being said, I wouldn't mind better control over that backup dir (more files, more frequently, etc).

    One thing that DOES need to be addressed is that the thumbnails aren't stored with a save, but instead clumped together in a folder that ALL saves use, so just copying an entire save folder to a new machine/install doesn't copy the little ship icons.   it's in the base KSP dir, under "thumbs" (KSP_install_dir/thumbs as per my previous example).  It should really be "thumbs" under the SAVE directory.  I'd like to know why it ISN'T...

    TL;DR: I say NO to idea, it would be slower.  Splitting files is no replacement for backing up.

    On 2016-04-22 at 3:17 AM, mattinoz said:

    I wonder if such a move would make multi-player easier. Maybe go further and break master flight file into SOI files. Active physics then only needs deal with writing one the SOI file and the craft files in physics range. Different processes or machines could be handling different SOI co-ordination without dealing with two processes trying to write to the same file.

    Craft aren't actually SOI specific, but you could write a quick perl script or similar to actually break the craft in a file down by SOI (it's the ref number in the ORBIT block).  Also you could parse out all ships individually into subdirectories via SOI similarly too.

  17. After playing a pure-stock 1.1-pre-release campaign for testing purposes, I'd have to say that the existing stock controls are rather inadequate (particularly when it comes to interplanetary, but even around Kerbin's muns it's kinda lacking)  and I'd definitely support this concept.

    (Usually I have PreciseNode installed so I don't have to worry, but the stock stuff is misery as it stands now)

  18. I concur.

    Duna could use more biomes, and better ones.   (and Mun and Minmus, fewer biomes)

    Duna is an interesting place to land - the thin atmosphere makes for interesting challenges and also interesting opportunities (I tend to favor a parachute-assisted landing, but there's also high speed plane-type affairs or pure engine landers etc), and naming some of it's distinctive features as separate biomes would add incentive to do more of those interesting biomes..instead of doing like 397 billion Mun landings and 285 million Minmus landings...

  19. Old posts are old.  A lot as changed since 2014; there are contracts (as mentioned above), plus there's no reason to send a kerbal along to do an ISRU scan, that's best done with a probe.  Also, probe-core-enhanced ships don't require a pilot-class kerbal for SAS (unless the core is the stayputnik), and can be operated entirely unmanned if needed.  Lander ran out of fuel in a stable orbit but can't get back to the station?  Maneuver the station out to the lander instead!

    One thing that hasn't changed though: If you're new to the game, probes are a great way to try various things out.  They're lighter than manned vessels (and thus less expensive OR have more delta-v, or a mix of the two), and if you crash it.. Eh.  No biggie, nobody died.  When I first started out, I tried out things like landings with probe cores first to avoid killing kerbals.

  20. 15 minutes ago, Norpo said:

    Assuming that the XL chute is being used for the 3-man 2.5m command pod, that's still a safe landing speed, the pod has a high impact tolerance. The 7.3 m/s figure for the 1-man pod is also safe as well, but just a bit more sketchy. The 1-man pod has an impact tolerance of 14 m/s and the 3-man one of 45 m/s. Still safe, just a little bit faster.

    Exactly.  45m/s (or 162km/h!) can be easily attained with just three of the radial drogue chutes...no main chute required (although that results in a 39m/s touchdown which probably WILL wreck everything else on the craft).

    So I wouldn't worry if it's in the 8-10 range unless hitchhikers or science labs are coming with it (boom).

  21. 23 hours ago, regex said:

    I think the reason was more to avoid reinforcing the image of KSP as a disaster simulator (anecdotally from an interview with/post by @HarvesteR saying much the same thing) but IMO that reason has long been subverted by Squad's own advertising and the fact that they made the buildings explodable.

    Well, Harv also said that adding monoprop to Kerbals in the place of EVA propellant would make 'em too heavy to walk.  *cough*

    Anyhow, I definitely support being able to launch directly to the EAS chair.  Would help testing rovers and ultralight craft (air or space) immensely.   I happen to like building craft like that proposed Apollo emergency lunar launch vehicle..

×
×
  • Create New...