Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Update 01.129 - Server Side Character Control & Client Side Prediction

Discussion in 'Change Log' started by Drui, Apr 7, 2016.

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

    Messages:
    1,649
    CTG does not exist anymore. From various posts, CTG was known to be a real thing up until late 2014. From 2015 onwards, there was some kind of change and people stopped admitting to being members, mods stopped confirming its existence, etc. This also coincided with the (not yet public, but retroactively revealed) start of planets experiments and de-obfuscating the source code for wide access. I guess the CTG strategy was not working for them with the new objectives and strategies.

    Funny artifact from research:
    http://forum.keenswh.com/threads/whats-in-the-closed-testing-group-and-how-can-i-enter.6854283/
    Ironically we now have jump drives, planets, and oxygen-pressure interiors, despite those being outside of consideration at the time of that post (April 2014, two years ago).
     
    • Like Like x 1
  2. Korfio Trainee Engineer

    Messages:
    34
    Very interesting. This got my dev juices flowing. This should be a dev hiring interview problem. Or a graph theory exam question.

    Assuming you have a lookup table of pairs of block references and a bunch of paths with weights of some sort (maybe a graph section) attached to each one, this is fast on lookup. However, your search space grows very quickly and is thus slow to generate routes. So...

    Fun things to try:
    * create multiple separate lookup tables per type of pull/push item (e.g. one for ore, one for uranium, one for small components, one for large components, etc). This can be threaded nicely and you could prioritize their creation. Uses more memory though. But you could reuse paths that are identical?
    * obviously conveyor blocks connected on 2 sides should be treated as tubes and those on less than 2 sides should be completely ignored.
    * definitely add a delay before recalculation when player places conveyors. The light indicator on them already indicates if it's active or not. Keep them all off until the grid is recalculated.
    * if you have a graph of the whole conveyor network layout, calculate centrality and split the graph on high centrality nodes. As a first test you could try splitting at single-connection-point nodes (2 connections only). Then work on those two networks separately and copy paths from the directly adjacent blocks to the connection-point between graphs. Again, nicely threaded procedure. Can be done before calculating routes.
    * when creating your layout graph, work your way back from dead-ends totally disabling calculations for conveyor blocks/intersections that do not connect to any pullers/pushers. Then tell the player by turning their lights to 'flashing' or 'red', indicating they're not being used, so they remove them (yay!).
    * Don't wait till the whole cache is generated (don't block), once you find the first route for a pull request, even if it's long, use it while the threads calculate more routes.
    * when calculating a route going down a graph, decide using game theory based on metrics such as distance "travelled" over graph average distance (or simply centrality). For example, move towards central nodes first. Players tend to centralize.
    * change the pulling system so that the closest pusher is used first, then the further ones, and so on. This will empty blocks in a radius around pullers first. Or do the reverse. Empty further nodes to reduce route search space (sneaky :p). Just don't try to pull from every pusher evenly. It forces inventory updates all over the place.
    * if two routes of the same length are discovered between two points, choose randomly between them when creating the cache (redundancy should be implemented)
    * cache pruning: once the whole cache is generated, find parts of routes that are re-used and create additional 'phantom nodes' for them, only in your cache. Then delete them from your cache routes (e.g. if storing paths as arrays of node ids, it basically works like huffman compression).
    * when player adds blocks, don't recalculate unless something is actually connected. E.g. adding a line of 200 tubes, recalculates nothing. Adding 50 tubes in a line, then 100 conveyor blocks only connected to themselves and no pullers/pushers does nothing. Practically this means, only recalculate cache is a) a conveyor block is deleted that has at least one path to any puller/pusher, b) a puller/pusher is placed onto the network, c) a puller/pusher block is removed from the network.

    You're probably doing most of these but wth, thought I'd contribute something.

    On the simspeed issue,I propose you find what causes sudden drops in simspeed on the server and slow down that operation. The aim is as someone mentioned to keep SS stable or decreasing/increasing slowly. You need an SS scheduler that prioritizes keeping SS between +/-0.1 of current SS at a set interval - real-time.
    * if placing a large ship, don't place it. Calculate everything for it first based on the scheduler. Until the calculations are complete, nobody will see that ship. Then plug the ship in with its conveyor networks and oxygen/turret/etc values ready to go.
    * if a battleship turret battle begins to overtax the system, break the physics: calculate aim every 10 frames and do 10x the damage. Adjust frame averaging interval depending on +/- of SS caused, capped at a maximum of frames (eg. 100 frames).
    * if placing a planet, make the player placing it wait if the server SS is low. Disallow creating one if average SS for the last minute is <0.3 or something.

    Damn. Wall of text. Sorry.
     
    • Like Like x 1
    • Informative Informative x 1
    • Friendly Friendly x 1
  3. nateman2000 Trainee Engineer

    Messages:
    36
    Yeah it's just these are critical bugs that completely break the gameplay. I could do without rockets reloading in favor of getting sim speeds back to stable and where they should be (at least where they were at 126). I mean we can hardly even gather accurate information about other bugs because half of them are probably related to the root cause of rapidly fluctuating sim speeds both server and client. I wouldn't even chance combat right now. I've never actually encountered the gyro bug that's been a focus for the last couple weeks but I use modded gyros anyways. I'd have to place more than 1000 some odd vanilla gyros to equal what the U.S.S Defiant's maneuverability should be.

    That is my largest ship so far. I wanted to make a 1:1 scale Battlestar Galactica but it's just not plausible right now with the way everything is working. When I undock the Defiant from my station (change from a static grid to a dynamic one by unlocking the landing gears) It drops my average server sim speed all the way down to 0.50. It's a far cry from the average 0.83-1.00 I would get before in patch 126.

    I've made some videos to show these issues:


    First I start with best case scenario with the biggest grids landed to make them static. I go around the outside of my base giving a small tour showing that even with very good Server Sim Speeds, the jitter and rubber banding is noticeable. I also show that the station is merged with the asteroid and static.

    I then proceed to release the Raptor's landing gears and dock it. It has a very small inventory so the hit is minor but still noticeable if you're watching for the average sim speeds.

    I then proceed to unlock my larger ship, the Defiant. You'll notice the sim speed get cut in half...way below the 0.85-1.00 server sim speed it would have pre-127.

    I then have a little trouble docking it because the camera is causing huge down spikes in client sim speed (which I show more in another video.) But then I connect the conveyors and pull out of the cockpit to show that even while the large ship is locked gears and static it keeps spiking down to 0.5-0.3 every couple seconds.


    This video demonstrates how ship movement effects are much smoother than the character movement with server sim speed fluctuations. You'll notice the fluctuations do affect thrust and its noticeable on the thruster visuals.


    This video demonstrates the fluctuating client sim speed drops when you enter any control panel or inventory...any grid or even character personal inventory. The whole control panel interface.


    This video shows a custom station turret that works just fine with character cockpit camera zoomed out. When I go into the camera view...the client sim speed plummets and makes it practically useless. It's also noticeable when I try to dock my large ship with a camera in the first video.
     
    • Informative Informative x 2
    • Agree Agree x 1
  4. KitsuneSamurai Trainee Engineer

    Messages:
    20
    I wonder if creating a roadmap/progress report/patchnote collection on Trello might be a good idea to aid in the reassuring of players that things are actually getting done, and possibly help organize things that have the highest priority.

    I've seen two other game developers use Trello, and it seems like a tremendously valuable tool for increasing development transparency and organization.

    One of the silent complaints I've had for a while is woefully inadequate patch notes. Even if most players don't care or wouldn't understand, it would be nice to see all of the changes that get made every week, no matter how small. It would certainly alleviate the concern I've had for the last couple months.

    I'll admit I'm getting very nervous about the future of this game at this point, and just having something showing like this would go a long way to alleviating the fear that this game is going to die before it's born. I just wish we could see X, Y and Z were being worked on three days ago, Z got finished a few hours ago and will be ready for the next patch, Y's model is done but it still needs a texture, and X still needs a lot of work and might take a few weeks.

    I know that I was basically saying the same thing in three out of four paragraphs, but it's because I really mean it. Tell us what's going on. The good and the bad.
     
    • Agree Agree x 5
    • Friendly Friendly x 1
  5. P. Kerman Apprentice Engineer

    Messages:
    168
    Good Idea! Perhaps most importantly would be a bug tracker to avoid bugs going unnoticed in the forum. This way you can easily check for all known bugs and keep track of them. A searchable database would be best as this allows us to give all bugs standardized tags which should help immensely with avoiding duplicated reporting and spreading information over several threads.
     
    • Agree Agree x 2
  6. Riph Trainee Engineer

    Messages:
    40
    I recently threw some money at the Subnautica team and have been super impressed with a) their transparency (Trello!) b) the ease with which I can select stable/experimental builds and c) that I can press f8 and a bug report box pops up.

    If I were to give Keen some advice right now, it would be to go visit Unknown Worlds with a notepad and pencil, and copy everything.
     
    • Like Like x 1
  7. Sjonnieloper Trainee Engineer

    Messages:
    14
    Funny,

    I opend my DS savegame in a single player, invited my friends over, and amazingly everything seems to be stable, i see the guys walking instead of moonwalking, ships fly stable on earth, hmm.. at least we are playing aggain..

    Thought i'd share this with you guys..
     
    • Funny Funny x 1
  8. Nikolai Ludovik Trainee Engineer

    Messages:
    7
    Yes, on a "coop" game, it works fine, but on the normal open servers for multiplayer, everything went from bad to worse with this update.
     
    • Informative Informative x 1
  9. Commander Rotal Master Engineer

    Messages:
    4,979
    Guys i've been spamming Good Guy @Deepflame a bit with some crashlogs and he said turning off the Reactors might help. Totally does. Seems to be connected to Reactors (...no pun intended) pulling in Uranium. If you got the chance and have SimSpeed issues on a DS... try to turn off power on everything (including Batteries and Solar Panels; it looks to me like this isn't actually the Reactors being naughty but the Conveyors as long as they are powered).

    [​IMG]

    THAT is something i can play around and test with.

    [​IMG]

    Edit: turning off "Use Conveyor System" for Reactors fixed the SimSpeed issue entirely. It's a bandaid at best for now but it's quite alright for Creative for the moment.
     
    Last edited: Apr 9, 2016
    • Informative Informative x 3
  10. Shabazza Junior Engineer

    Messages:
    689
    Being able to fall back to older versions / not being forced to update is actually a good thing and a possible solution for the regular breaking of vital game mechanics by updates.
    In Minecraft we had sometimes the same issue.
    An update was breaking a game mechanic or vital plugins were not being updated as fast as desired. So we kept our server on the last working version and told our player community to not update their client, but keep the older version that matched the server for a little longer, until we were able to test the current update or even wait for one or two further updates until the critical bug was fixed or the vital plugins were being updated.
    With steam, this is not so easy, as it is so much centered on auto-updating all your stuff immediately.
    But it's still possible to give use some branches with "milesone" versions of the game that were considered "ok" by the players.
    Especially for MP, this would help a lot to avoid frustration.
    So I like the idea.
     
    • Agree Agree x 3
  11. Harrekin Master Engineer

    Messages:
    3,077
    Is it time to post the Early Access disclaimer...again?

    Seems to me like its nearly time...
     
    • Agree Agree x 1
    • Disagree Disagree x 1
    • Funny Funny x 1
  12. g4borg Apprentice Engineer

    Messages:
    271
    I agree, and in Minecraft it was also a big milestone that they launched the unified launcher which allowed you to micromanage minecraft versions, so you actually could stay downgraded.
    While ultimately, this was more because the MC code was a mess, and servers/mods were built from decompiled code, instead from a common codebase, which usually also resulted in slower adaption to new changes, I do not whish similar "multi versioning" in SE, but for things like XP compatible branch, etc. this sort of handling is a very good idea indeed.
     
    • Agree Agree x 2
  13. Wayne Barraclough Trainee Engineer

    Messages:
    24
    Hey guys, Dusan told you flat out, "Please have in mind that the system is new, and implementation was quite complex so some issues may occur. Please be patient." Followed by a double-double thumbs up and a little dance.
    I almost feel bad for him since he looked so happy about it.
    Don't worry Dusan (sorry if it is mispelled), I'm being patient. I have faith you guys will fix it. Go have a beer and we'll see what happens in the coming weeks.
    All the people crying about the patch have no clue how hard your jobs are. They also seem to have forgotten what they bought into at the time.
     
    • Agree Agree x 7
    • Like Like x 2
    • Disagree Disagree x 2
    • Informative Informative x 1
  14. deathcat99 Trainee Engineer

    Messages:
    14
  15. CrookedTube Trainee Engineer

    Messages:
    37
    I'm grateful for the hot fix that addressed hand tool bug, that was a big one for me as a survival player.

    On server simulation speed: I have enjoyed 100%/100% for the last week and a half since it had become a big issue. Last night I opened up my server to the public and over the course of an hour the server sim speed steadily decreased to 40-50% with five players. I checked their builds (survival) and all of them were just modifying/scrapping their atmospheric landers, nothing crazy. The fix was to make the server private again (sorry guys!) and delete the extra builds and wreckage.

    Overall, I know the Devs are making progress but MP is still a ways off.
     
  16. nateman2000 Trainee Engineer

    Messages:
    36
    I agree that programming is indeed VERY Hard. I don't think it's right to slam the developers or put them down because they're working hard under really difficult circumstances. This is an immensely complicated collection of systems and sometimes one change breaks interactions with one or multiple other systems.

    That's why I agree that there should be a Stable branch with changes merged that have already been tested by the community and developers and known to be working well on the Experimental branch. If there is a bad reaction they can just as easily revert the pull request.

    I'm sure there are many of you, myself included, that would want to build their complex persistent worlds on the stable instance...but also spend spend significant time switched over to the Experimental instance and check out new changes and features and to help do through bug testing. If there is a balance, it's still very enjoyable. :)

    I can understand people's frustrations because sometimes you just want to get on and build for fun. Some people would enjoy weeding out the bugs more. But with the current single version system...it can cause a big problem because it affects everyone all at once.
     
    • Agree Agree x 2
    • Friendly Friendly x 1
  17. lukeksyjedi Trainee Engineer

    Messages:
    13
    Its quite hard to do all of this and the weekly bases makes it even harder
    but they still do good work its not perfect for sure but it is quite good
    Thx :)
     
    • Friendly Friendly x 1
  18. SayHi2Jesus4Me Trainee Engineer

    Messages:
    24
    Agreed. A stable release system is non-negotiable if the game is ever going to come out of its "alpha" state.

    I don't want to just bash the devs for releasing patches that introduce bugs. Having everyone rag on the developers and throw fits isn't helpful to the development team, I understand that. But I think that when things get really botched as they have been for years now, it's not wrong for the players to express their frustrations.

    I also am growing very, very weary of the argument that this game is still alpha and we are all its testers. Frankly, this is something that I really dislike about the current direction of video game development. The whole "early access" and crowd-funded paradigm for funding games that players want developed unfortunately has a really cankerous underbelly. It is my opinion that when a game has been released to the public and begun accepting payment, the company has a responsibility to make sure that the product is of an acceptable quality. It's okay to have problems, it's okay to have a few months in the beginning where things are really rocky and barely playable. But when you have a game released for over 2 years; after having accepted everyone's money; then push to get the game an award like Indie Game of the Year? It's at that point that you can't hide behind the excuse of "early access" or "alpha" any longer. Do you think someone who sees that award and the length of time the game has been available, buys the game, and tries to play multiplayer in the state its in would ask for a refund immediately?

    And it's not even about the money, really. I think the vast majority of people here want to rant and express our frustration because we love this game. Or rather, we love the idea of this game. I've put hundreds of hours into the game and I know there are some who have put in thousands. It is incredibly frustrating to have so much of that time be wasted because the company has never prioritized maintaining any measure of quality. I'm hopeful that the developers are really trying to move to a better versioning/release system, but to be honest, this should have been done a long, long time ago.
     
    • Agree Agree x 3
    • Funny Funny x 1
  19. Tactic Alpha Trainee Engineer

    Messages:
    1
    There are two issues I've found that I haven't seen many other people talk about so here they are: In the toolbar in a ship or vehicle it doesn't give us a status below the icon for the button and the voxel hand settings menu (H) doesn't open anymore.
     
  20. Anubis 2 Trainee Engineer

    Messages:
    61
    that's great Sams the best even if SG-1 incessantly foils my plans to claim uncontested power
     
    • Funny Funny x 1
  21. BloodThunder Trainee Engineer

    Messages:
    28
    I just created a new DS after not playing for months. Now, the game is so unbearably unplayable with the de-sync issues that I can't even land and take a few steps without launching off into the distance and rubber banding until I die. This is the same server I ran DS on months before, with no issues. Thanks for the updates, but this new system is clearly not ready for deployment.

    After spending 2 hours, dealing with the de-sync on a new survival map, I died to rubber banding off a mountain-side before I could finish setting up my first station. Fixing this really needs to be a top priority for the next patch.
     
    • Late Late x 2
    • Funny Funny x 1
  22. Harrekin Master Engineer

    Messages:
    3,077
    I know it's been a while since you bought the game, with all your hours of play, but do you remember this from when you bought the game?

    Early Access Game
    Get instant access and start playing; get involved with this game as it develops.
    Note: This Early Access game is not complete and may or may not change further. If you are not excited to play this game in its current state, then you should wait to see if the game progresses further in development.
     
    • Disagree Disagree x 3
    • Like Like x 1
    • Agree Agree x 1
  23. Nikolai Ludovik Trainee Engineer

    Messages:
    7
    Have a "main" branch, and a "beta" branch, so you can test these very early features.
    And everyone lives happy and noone explodes because of frustration.

    EARLY ACCESS GAME
    It doesn't mean that simple stuff like this cannot be done in order to NOT hurt the community and start riots. So , the game can develop, peacefully in a friendly enviorment, where everyone, is happy.
     
    • Agree Agree x 3
  24. R-TEAM Junior Engineer

    Messages:
    549
    Sorry - but this is for all FANBOYS :

    From the STEAM Shopsite - the ONLY source of information over the state of the Game I as an customer musst know , no fanboys, no KSH forum or other sides - i have an contract with STEAM , not others ..

    Early Access:
    Get instant access and start playing; get involved with this game as it develops.
    Note: This Early Access game is not complete and may or may not change further. If you are not excited to play this game in its current state, then you should wait to see if the game progresses further in development.​

    I see nothing who say it is not playable with the futures he promise ... next paragraph :

    “Space Engineers is an Early Access game, which means that it is still under development but already in a very playable state and contains a vast amount of new features that have been added since its first release (e.g. Multiplayer, Survival mode). The game is being improved on a regular basis through updates that add and polish features and content, optimizations and bug fixes.

    We invite you to give us your feedback and suggestions to help us create the best game possible.

    Buy now, play on Steam and receive all future updates for free.

    Please be sure to read the list of current features before you buy the game. It will give you an insight on what is or isn't actually working:http://www.SpaceEngineersGame.com/features.html

    Everything in the game is subject to change”
    Tell me an "more playable state" then the promised "very playable" .........................................
    The Game change - Yes .. no problem .... see the change from DX9/XP support to DX11/Win64 only ... the content change .. o.k. ..
    But the promise was CLEAR -> Multiplayer and very playable ...
    Would the game relased as singleplayer game, no one would complain .. but i doubt, even 10% of the sells would happen...

    Regards
     
    • Agree Agree x 2
    • Disagree Disagree x 2
    • Funny Funny x 1
  25. Commander Rotal Master Engineer

    Messages:
    4,979
    I feel left out.

    [​IMG]
     
    • Agree Agree x 1
  26. R-TEAM Junior Engineer

    Messages:
    549
    O.k. - i musst correct - complain is ATM in single player too (IMHO the conveyors system) but 99% of the problems Multiplayer alone ...

    Regards
     
  27. wd56 Apprentice Engineer

    Messages:
    147
    Hey Keen, have you guys considered moving the update release days to Tuesday instead of Thursday? This way when you destroy playability, you can actually work on it during the week (and hopefully fix it before the weekend)

    I dont know about most people, but I have a job and the only time I can really play this game is on the weekend. So when you release playability destroying updates on Thursday, it means I have to wait to the following weekend i.e. 8 days from the update, to be able to play. Assuming the next update doesnt destroy playability further

    By changing it to during the week, with ample enough time to fix things before the weekend, you give people a chance to actually play the game during their free time.
     
    • Agree Agree x 5
    • Funny Funny x 1
  28. SayHi2Jesus4Me Trainee Engineer

    Messages:
    24
    The game is less playable now than when I bought it. I don't see a clause concerning that, so I'm entitled to my frustration.
     
    • Funny Funny x 1
  29. Harrekin Master Engineer

    Messages:
    3,077
    Things will break, it's alpha, they break and then...they break again.

    The disclaimer clearly and unequivocally states the game is a game currently in development, correct?

    Did you fail to actually research what this means?

    If this game was Minecraft, it'd still be in the "free demo version" stage.

    You should think of Early Access as pre-buying a game but getting the current in development version to try.
     
    • Disagree Disagree x 3
  30. Greystar Trainee Engineer

    Messages:
    18
    I can confirm now that the reactors in a conveyor network are what is causing the huge sim speed drop. I just tested it on my massive ship build (Ship is on the warehouse (Phoenix Rising Incomplete). With the Reactors set to use Conveyors it causes sim drops to as low as 0.03 with it set to not allow reactors to use conveyors i got a more or less solid 1.00 (it does occasionally go up to 1.02 for no real reason that I can tell, ship is not moving).


    NOTE: They are NOT pulling anything from anywhere as they already all have at least 1.2k uranium and there is none for them to pull from anywhere else (and it's in creative).
     
Thread Status:
This last post in this thread was made more than 31 days old.