Jump to content

Kelevra142

Member
  • Posts

    8
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Kelevra142 reacted to loaded in 0.24 Phase One - Discussion Thread   
  2. Like
    Kelevra142 reacted to DecoyGoatBomb in 0.24 Phase One - Discussion Thread   
    I think the game looks and runs better in almost everyway. Sadly the exceptions make the game look horrific. Many metal materials have a weird glazed ceramic looking reflectivity. This has an especially bad looking result on Galvanized and Stained metals as they have a really extreme normal map that causes this glaze to look like metalkc leprosy. It seems to be most noticable during the day when the metals are reflecting the atmosphere. Is this a known issue? Is it going to be fixed? 
  3. Like
    Kelevra142 reacted to Noddles in naunet stepping down, my fairwells to a great CM   
    Well time to wait for starbase and ashes of creation. 
  4. Like
    Kelevra142 reacted to vylqun in [Announcement] Support transitions fully to ticket system.   
    "To provide better support we will now treat everyone equally and make you wait 1 months for issues that could be solved within minutes if you pm a dev in discord or ingame"
    Really? Sorry that i post here, but really? For better support? Does NQ think we are retarded? At least don't come up with such an obvious lie as excuse when you don't want to provide the manpower for real time support...
  5. Like
    Kelevra142 reacted to SirJohn85 in [Announcement] Support transitions fully to ticket system.   
    Wait, people pay money monthly for an mmorpg and get no technical support on weekends? What kind of service is that?
  6. Like
    Kelevra142 reacted to joaocordeiro in Game crashes and sometimes "bricks" my PC   
    Hum a reproducible bug like that. 
     
    My uninformed guess would be somekind of disk->ram near infinite loop. 
     
    This could be 2 processes
    1 Ram exhaustion
    DU quite often spikes in ram. Maintaining a low ram usage in average but spiking 10-20GB for a few seconds. 
    I have only seen this happen when traveling at high speed and loading terrain. 
    For ppl with 32gb or less this can be deadly. 
    Lack of ram will impact every program in your computer making it go wako, sometimes showing data transfer between programa. Graphic disruption like crazy patterns apearing on screen, blue screens, but also total unresponsive hardware needing a full power cycle. 
     
    2 CPU unavailability
    Basicaly the same problem that happens above. But with better hardware. 
    So if you have a large amount of free space you are not that likely to exaust ram. 
    But if your disk is fast like 3GB/s NVME and/or your network is gbit low latency fiber, your computer's ability to get data to process, either from DU servers and/or cache can overwhelm the CPU. 
    Completely stopping any other process from getting a hold of the Processor. 
    This is usually below 1sec. But some ppl reported more. 
    Extended CPU blockage can lead to errors in other programs, specially to hardware related calls like discord accepting packages or failed disk sync. 
     
    A GPU problem (hardware or software) was on the table at some point but i ruled it out, because GPU problems either crash the computer completely or do not affect other programs, just DU. 
     
    Im also assuming that your GPU has dedicated ram. 
     
    The main issue here is that DU appears to lack an intelligent thread controller. 
    It appears that any part of the game, no matter its importance is free to launch any number of threads, with the same priority of each other. 
    It also appears that there is little to no performance evaluation on any of those thread. 
     
    An example of this was a issue some earlier version had where closing the F1 help menu would make CPU spike for like 5 secs. 
    Programmers can be excused for a bug there, we are all humans and we all make mistakes. 
    But why is a helper UI in the position to spawns endless threads, making all my 16vcores go unresponsive? 
    It is quite obvious that closing a F1 menu is a low priority operation. Surely the game needs to stop the running browser rendering, sure it needs to free the ram used by it, but that could be done over a long period of 30 secs if needed. No reason to block the entire game for 5 secs.... 
     
    There should be a thread controller saying that operation was hard limited to 1/4 of total vcores and running with a low priority. 
     
    But this pice of technology does not appear to be there. 
    Instead of a
    core.startthread(tag, class, priority, limit)
    They have a
    core.startthread(class)
     
    If my belief is true, this is a major issue.
    Because this needs to be changed.
    Because this would require to change something that should be stable at alpha1. 
×
×
  • Create New...