Jump to content

runner78

Member
  • Posts

    67
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

runner78's Achievements

  1. I quit some time ago, but I'm always open to giving it another chance later. My reasons are first and foremost: Performance: even with a mid-range gamer PC, I sometimes only have 20-30 FPS, in the long run it was stressful for the eyes. Destruction: In contrast to a certain other game, a ship can crash and break down in the safe zone at any time, that was also the point where I gave up when my ship, which I had farmed for a week, crashed after a test flight. Bringing the ship back somehow and repairing it took a lot of time, and I lost the fun of the game.
  2. Hatte ich auch mal, bei mir war es einfach nur übersehenes kleines stück Erz.
  3. Der Scanner braucht ein modus für "nur aktuellen Tile", ich glaube das wurde schon mehrfach vorgeschlagen.
  4. Somewhere additional money has to flow into the economy. In a closed system there was only limited money. with 100 players starting with 100,000, it would be 10,000,000, and would never be more, due to market charges it would even become less over time. Without additional factors, it wouldn't work at all.
  5. Ein kurzes einloggen ist ja nicht immer möglich, oder man vergisst es auch schnell. Wenn ich mich recht erinnere gibt es in anderen MMO eine fixe Zeit für den Reward der für alle gilt (z.B Mitteracht), und man auch den Reward bekommt wenn man online ist, und sich nicht erst neu einloggen muss. Und es steht dann auch timer bis zum nächsten reward.
  6. Ich hatte das manchmal, wenn am Computer nebenbei ein anderer Process lief, der ein wenig mehr resource verbrauchte. Kann gut sein, dass dann das Tool ein false-positive generiert.
  7. Less the server architecture, more the client-server communication. The server should only send the client what he really needs, no things that he might need. This puts a strain on the network, but also on server performance. And too much data can also be used for cheating, I once saw a video-talk by an MMO developer who reported how quickly players analyzed the communication even in a beta and were able to pick out enemy positions that were actually not yet visible.
  8. Ich finde das müssen sie mal überarbeiten, bei mir is es schon öfters, passiert dass ich abends einlogge und dann da auch reward bekomme, dann danach vormittag/nachmittag mehrere Stunden gespielt habe aber Abend nicht mehr online war und dann für den Tag keinen reward bekomme, auch wenn ich den Tag sogar mehr gespielt hatte wie sonst.
  9. Yes, if some network operations in the client are not frame-independent. Or too much data is sent from the server to the client and the client network thread is busy. But that is only a guess, but these are all problems that have a lot of optimization potential.
  10. In such a case the problem could be the networking, too many synch points in a frame, where the client is waiting for the answer / download of the data, or poor client code to apply the data.
  11. As far as I know, DU using a mesh server and only sent the mesh object, not the voxel data. Except that GPU instancing is not possible here, these objects do not differ from other 3D objects. And even generating the voxel to mesh of a single object only needs to be done once and can be cached, not every frame. Modern graphics cards can handle thousands of draw calls (but also depends on the engine), 100-200 unique meshes should then still be easy to manage if placeable objects are batched and frustum and occlusion culling works properly. The terrain seems to work at least reasonably well as I have 30-40 FPS in my territory (but could be better). The terrain should also have a smaller voxel resolution (I estimate 1 meter)
  12. The player should only know the players in the immediate vicinity, and every character looks the same here. Other MMOs have no problem displaying 100 players in one place with personalized characters. The client does not care whether there are players 5km away, the server does not send any information to the client and does not exist for him. I can't quite understand where the bad performance of the markets comes from. Due to the frustum culling, only objects that are visible from the camera should be rendered and with occlusion culling objects that are obscured by others should also be ignored. But with DU the presence of other ships alone affects the performance, without them at all in the field of vision the camera are. And with GPU instancing you can reduce massive drow calls when displaying the same objects (engines, wings, windows, etc.) One reason could be a netcode that is not suitable for MMOs. e.g. to sync every frame/tick of every player and ship with the server and also to wait until the server has sent everything. With a large number of players / ships, this would always lead to bad frame rates. I also hope that DU don't use rollback or other netcode techniques that have no place in MMOs.
  13. This should only apply to the server, not the client. Pure gameworld: KSP is much larger, without loading times. Eeloo, the outermost planet, has an apoapsis of 567,748 SU Voxel planets: Space engineers and similar games also have voxel planets, although they are smaller, but they are multiplayer and can be mined down to the core (Space engineers). And also runs on older hardware. I was still playing space engiers with my old AMD Phenom II and a Readon HD 7850.
  14. Geozentrisches Sternensystem, die Planeten alle fix, die Sonne bewegt sich um die Planeten
  15. Oder Ram voll und keine Auslagerungsdatei/volle Festplatte, bei 32GB aber eher unwahrscheinlich. Ich habe 4x8 und hatte noch nie einen Ram Absturz. DU ist bei mir auch nur ein einziges mal abgestürzt.
×
×
  • Create New...