Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. Hello Guest!
    Welcome to the Bug Report forum, please make sure you search for your problem before posting here. If you post a duplicate (that you post the same issue while other people have already done that before) you will be given a warning point which can eventually lead into account limitations !

    Here you can find a guide on how to post a good bug report thread.
    Space Engineers version --- Medieval Engineers version
  2. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Inexplicable sudden death syndrome since today's update!

Discussion in 'Bug Reports' started by woosher, Apr 24, 2014.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. IronWar Trainee Engineer

    Messages:
    6
    I think I had this bug proforming on command. it would happen when i would add or delete a block.
     
  2. McGillicutti Trainee Engineer

    Messages:
    18
    SaintMerc, thank you for a concise and well explaining of many aspects, reply.

    I have a military transport on one map but haven't been near it since this patch. Originally I was playing the game and had it loaded prior to patch (offline so it would play), however the big ships would spin out of control if I manned them, even the private sail at that time, as though the gyroscope had taken over controls. I tried to take a mining transport, had saved before I went out after it, so when this failed due to it being uncontrollable I exited the game and discovered the new patch. The patch fixed these ships so they can be flown, however that I discovered after what I was seeing on screen -- which is different than what your friend you called over was seeing the ship do, funny how I had the same "ship isn't moving" experience you did as the person who is acting on the ship but the so called "helpful person" is making poor audio youtube videos of the result in creative mode. This makes me wonder if the mode determines if you can see what happens when you try to do something to a docked ship or not since this patch (which would be an additional bug); I've stayed in survival and haven't tried anything in creative, as not being able to die would, for me, make it difficult to appreciate what occurs as being the same or a very related bug to what killed me in survival mode since this is an early access alpha. Every condition that can be the same but gets the repeated final result would be indicative of those incidents preceding the result as being more certainly related to that result.

    I have ground some other ships, a mining carriage I think it is, and the single (no booby-traps to disarm) solar array commercial vehicle. These are still parked so as not to waste uranium on them while I take one apart after the other and I had no incident of death occur, only with the dual-solar-array "commercial shipment" I think it is. I haven't worked on any small ships since the patch and am not sure if that's a factor in this either. If I were to go by this thread it would appear it's with the larger ships alone though I am not certain of that of course. My hope is that with enough input from many players of the most refined specifics of actions we are carrying on with our character and lead to the final identical result, that whatever is triggering this result will be absolutely discovered -- the excerpt of code that is being called when we do anything to a docked ship according to what's here right now (though I still can't explain why not depositing the drill kept me alive for multiple runs, but it can be just a lucky coincidence so I'll chalk it up to that for now) -- that this will result in a very well done and expeditious patch to resolve it.

    This very well could be a compiler bug as well since few programs, if any (including compilers), are completed due to an ever increasing number of variables and reliances based on if they are online or not, as well as the variety of features available that the program accesses which includes their variety of errors and exploits ("heartbleed bug" comes to mind, and rule-of-thumb is for every bug found, there's usually 10 others tangentially related within that program). Let us hope there is a workaround for the compiler's error and no need to wait for a patch to it if this is the case (Please note that "compiler" is being used very loosely here and includes programs that merge mixed code from different high level language bases to work together, for, in the end, it's lowest level 1's and 0's that have to be processed).

    My hope is that the developer of SpaceEngineers has their attentiveness to game bugs and issues intensified to find and address this problem with at least a hot fix if not a comprehensive patch within the next few days, or, what I am observing to be a great momentum for a fun game in a unique environment may (and I hope not) experience a stall that it doesn't need, and I, as a player and potential investor depending on the future of the company and game, do not want to see this game have nor the developer experience such unfortunate luck. It's a great learning experience, of that there is no question, however, I, and I am sure most players who enjoy SpaceEngineers, wish them the easiest time in developing this game, that this encourages them to make many others and grow their company as a successful private enterprise built by their own ingenuity and hard work (as well as useful player enthusiasm and feedback).

    It does appear the developer is making an effort to address the issue so my "job" and sole reason for joining the forum, to do all I could to have this fixed, has been accomplished. Let's hope this developer always places their quality of work first, unlike so many developers of so many games that do not listen to their player community even when something as significant as this is to their game's play is involved. Yes, you could say I am a crusader as an old coder, one who remembers when 16k of memory and swapping segments by custom code to dual 5.25 and/or 8 inch floppy drives (or loading from "audio cassettes" depending on the hardware) was a luxury to which all responded by coding tightly to avoid all that work if they could -- no "GUI" or Windows blah blah back then. Between slow 8 bit processor speeds of 1 to 3k and not having enough RAM for variable overheads with a small 256 instruction stack, tight and often assembly coding was required to achieve meaningful and effective results. It's refreshing when I see a program coded well (not "optimized" in the modern sense of the word but mentally the coder arranged the source and used every variable to tell the compiler what to do in making every effort to achieve as capable a program as they could code in as small a space as possible). 832Meg is a far cry from many programs I've seen with patches in excess of 5 gigabytes that aren't at all achieving the volumetric, nor graphic appearance capabilities, of SpaceEngineers -- these programs are inefficient, the processor, RAM, and other "latency" issues attest to this fact. To me this game, SpaceEgineers, is a brilliant programming marvel in many ways.


    Let us hope their sense of personal integrity is a part of the company's DNA throughout a long and prosperous lifespan,


    McGillicutti


    P.S. Apologies for typos & grammatical errors and hope they weren't too difficult to read through -- tired, old, and saving my hands to play versus wear them out editing heh.

    EDIT: I went into lone survivor map, in survival mode, and noticed that every time the upsidedown landing gear on the platform (with the small red cube over it) is yellow. I've changed it to locked and green at least a dozen times today. That it keeps changing back is curious.
     
  3. pfshfine Trainee Engineer

    Messages:
    37
    I've experienced the bug while the ship is free-floating in space, over a kilometer from any other artificial objects, in both survival and creative modes. I know it isn't just mining haulers, but the specific unfinished blocks on the top port side can pretty reliably produce this bug when you take a grinder to them. It seems like there's a huge burst of kinetic energy transfer between different objects, including the player's body, and the ship. This causes the player and the ship to be flung violently, as if they had collided at extreme velocities, usually resulting in the destruction of all involved.
     
  4. Artraxus Trainee Engineer

    Messages:
    26
    Great explanation pfshfine! That is what I have been observing. I am having difficulty reproducing my results from yesterday though. Have you noticed this? Or are you still bugged out?
     
  5. pfshfine Trainee Engineer

    Messages:
    37
    Just loaded up a save with a mining hauler docked. I was able to reproduce the bug repeatedly just by making bodily contact with the top of the hauler. I didn't even have to grind anything. Exited without saving, reloaded the same world in creative, and it was doing the same thing.
     
  6. ozarkamax Junior Engineer

    Messages:
    542
    i'd like to add my observations. this seem to occurs when you have locked landing feet or when a rotor bugs out and wobbles in a confined space. deleting the offending feet and rotor seems to have gone a long way in increasing light armor large ship stability so far. and i would also confirm death seems to be coming from impacts. i've noticed lightly bumping an armor framework can instant kill as well. perhaps its sharp heh.
     
  7. ozarkamax Junior Engineer

    Messages:
    542
    i have also deleted all landing legs and placed new ones. i can cause physics issues on demand by simply docking my light armor ship to an asteroid. it has to do with the landing feet and rotors i believe. possibly the interaction between the landing feet and the block it is connected to ; i'm back from testing heavy blocks, its definitely at least feet and rotors. the ship still freaks out if docked when attached to heavy or light armor blocks. doesn't matter. removing rotors and keeping feet away from docking range does the trick. and i mean all feet. even ones you use as bay door locks.
     
  8. SaintMerc Trainee Engineer

    Messages:
    51
    Greetings

    Thanks for your feedback McGillicutti

    I can't say that it is effecting all landing feet.
    The feet on the NPC ships seem to mainly be effected, But the feet on my
    Little hauler are not effected (small ship). I can do anything on that ship I built,
    even if landed and locked.
    But not on the NPC ones if the ships are landed and locked.

    I have tested with Heavy armor blocks also and the same happens.
    But I would agree it seems the landing feet are causing the current problems.
    Not tried rotors.

    Regards.
     
  9. McGillicutti Trainee Engineer

    Messages:
    18
    Well.... I figured a good one to try this on was the crashed red ship, I mean, it does fly and all, so I made a carrier out of it, or was going to, however....

    I got the ship off the crash site and so it isn't locked to anything.... I approach a nearby large asteroid. I mine away, everything is fine, but then I find this silver vein and mine right in (no vehicle using drill) and out of nowhere, for no reason "You died" and am respawned in a yellow bus (didn't have that when I started). Now, understand, the ship was the full distance of the width of a doughnut shaped asteroid away. I am starting to think the issue is, what we used to call in SecondLife, "a bounding box issue" what the ship does in animation or as an object in movement in memory and database as "virtually real" is meaningless to the situation. The trigger is everything, and as pfshfine was saying, he merely had to touch the ship and it bugs out.

    Keeping that in mind, we tend to personalize our avatar when in fact our avatar is no less code than the rest of world it is in. I am thinking something relating to the collision detection of the avatar to large ships was inadvertently affected. The deaths are instant, and though sometimes we might find ourselves virtually (visually that we can observe) shot out from the ship, the ship visually seen spinning (though I haven't experienced this), etc., and having to fly back, only to likely die when we reach the point we were thrown away from (at least that is what happens to me), both of these are likely different code routines, but each is being wrongfully called due to an error in the collision detection as it relates to the avatar's in world "boundary" or "bounding box." That's what I am thinking at this point anyway.

    It would make sense for the toon that there'd be different detection systems for the x, w, z, and theta of the avatar and objects which is activated the moment we are within a particular range of the object and avatar (two different code segments), which would "call" the physics ones when the conditions indicate to "jump" to that code. So it seems to me that when we trigger this boundary detection (collision detection) the, using old terminology, "look up table" of the code or address to go to depending on the criteria, that this table is not accurate. I am thinking there's a memory leak or, as I mentioned earlier, the compiler is bugged and maybe Keen's coder is pushing the compiler (or maybe even Directx for that matter) to its limits which is resulting in this lookup table being overwritten with another code segment, which is why the final result is the same, the triggering seems a bit difficult and random, and yet, sometimes we don't die, we get thrown and live -- basically this explains why there's a variety of outcomes, usually that we die but other things occur as well, because the very subroutine the code is sending us to isn't there, it's the wrong address (table overwritten) or the actual code segment is being reloaded, erased, or moved.


    Hope they get it fixed soon, I'm looking at some new games already haha


    McGillicutti
     
  10. Nezerroth Trainee Engineer

    Messages:
    2
  11. nrocpop Trainee Engineer

    Messages:
    17
    I can confirm this bug is caused by landing gears. I removed all landing gears from a large ship and the momentum problem vanished. I then landed a small ship on the large ship and it began to spin.
     
  12. woosher Trainee Engineer

    Messages:
    15
    Update 01.028 appears to have completely sorted the issue my experience of the 'Inexplicable Sudden Death Syndrom'! Wuhoo! Good work, Devs!
     
  13. Uhm Apprentice Engineer

    Messages:
    149
    pointless deaths are back
     
  14. Phand Master Engineer

    Messages:
    9,650
    Hi,

    thank you for report. Please provide world. Since this is pretty bad. :( I am trying it now.
     
Thread Status:
This last post in this thread was made more than 31 days old.