CptLoRes

That's the job of professional community managers, filter the forum posts into a manageable list and present to the devs. And then write back with comments from the devs so that there is some two-way communication, and the community feels that they are being listened to. But that never happened. Not even when this used to be a pre-alpha forum with the specific intent of providing feedback for the devs. And on top of that, one of their big selling points during the Kiskstarter was the promise of a totally transparent dev process that would engage the community along the way. And you don't have to look very far for this. There is now a pretense of engaging the community with the blog specific feedback forum threads being done lately. But it is still very much a one way street, with no real engagement from NQ.

The performance issues in DU are fundamental software problems., that no amount of client side tinkering is going to solve.

So why do they then keep doing the same type of mistakes? Learning from past mistakes and improving is a fundamental skill that any dev team should be very aware off. Here is the typical pattern on how NQ 'interacts' with the community. --- NQ: We are going to do A. Community: That will cause problems with B, and C and D, NQ: No response.. Community: Lots of speculations and frustration because there is no response. NQ: Releases original feature patch with no regard to community feedback Community: Generates lots of feedback, mostly about the predicted problems that are now turned into reality NQ: Silence... Community: Problems are now so bad that people are starting to riot. NQ: "Don't worry guys, we know there is a problem and we are looking into this." NQ: Long silence, while community continues to riot and point out ways to avoid said problems NQ: Release some quick and dirty patch that half solves the problem, and causes unplanned collateral damage Community: Continues to point out problems with patch and quick-fix, and how they could have been avoided NQ: Very long silence before announcing next feature, and everything starts over again.. --- So if people are wondering about the current state of the game and the bad mood in forums, it is because this release cycle accumulates lots of bugs and fundamental game issues over time and at the same time manages to alienate the community.

NQ has a long history of saying one thing, and doing another..

Calling the patch 0.24.2 or 0.25 is totally irrelevant. The discussion is about why NQ is taking so long. And saying it is because they waiting for other features to be complete in 0.25, is just highlighting how NQ is unable to make sensible priorities. 0.23 did A LOT of damage (again because of bad priorities), and the mission planner should have been part of that patch. Edit: Or even better they would have released the mission planner first to get feedback, to ensure they had a working alternative before destroying the industry (only about 1/3 of the entire game-loop).

Problem is they have been saying things like this, and still ending up under-delivering since the beginning (2016). So if they suddenly had loads of features ready now, it would be the first time NQ managed to pull a stunt like that, ever. Only time NQ showed real progress in a timely manner, was the do-or-die crunch they did for the 'beta' release. But then they went straight back into the same old afterwards.

Spaghetti code is great for proof-of-concept, and 'I have this crazy idea, let's see if it works" type of deals. But, there is also this tendency that if the quick and dirty test actually works and you make the mistake of showing management this, it then somehow has turned into ready for 'production' once they leave the room.

This is a first for me.. Inconsistent docking has always been a problem in this game. And the obvious solution that was suggested way back was to make docking a menu action, instead of the trial and error process of landing and using the move tool to try and get a coupling. And now they implemented it.. Like.. what? I don't know how to react to this. NQ actually did something we suggested? Cannot compute. Error! Error!

@NQ, if you are wondering why there is so much negativity in the community this is pretty much it in a nutshell. Having to watch your inability to execute even the simplest task in a meaningful way over and over again, is enough to make even the most dedicated player lose hope.

And despite all players being tall, furniture elements still looks like they where designed for giants.

For me I still remember the first time I discovered and explored one of those huge underground/water cave systems, and how it gave me a sense of wonder and excitement. But sadly as with most things in this game, it is only skin deep with no real content or advantage to be found. So the excitement wore of very quickly. Same with flying into space and the first time you approach a new planet, very exiting. But again, once you get past the new biome and different allocation of ore in the ground, it is just more of the same with magical markets that just are there with no explanation how their where built.

It is a bit of an apples to oranges to bananas comparison.. In most browser CSS/SVG transform is GPU accelerated, so that would definitively be A LOT faster. But at the same time I have a feeling that the CSS/SVG implementation in DU is not using the GPU, so then it becomes a question on how optimized the software fallback is. And of course while importing your own 3d engine is seriously cool, it also leaves less script space for other stuff. If NQ really wanted people to make cool screen projects they should add support for webassembly and webgl, instead of re-making functionality themselfs. But that is not their way.

Nice project. Reminds me of old skool demo scene stuff. But I also have to be a bit of a downer, since I have a feeling CSS 3D transformations would not only be simpler, but also much faster.

Constructs may not be larger than "Small" sized Just consistently enforcing this single rule on advertising constructs, would have made a big difference. But the only consistent thing about NQ, is their inability to be consistent at anything.

Tragically that would result in valid constructs completely obstructed by a cage disappearing, while the offending cage who are visible to players (renders) remains. But it can't be so. Not removing constructs who have been seen by players would not make ANY sense, since the act of being seen by players is a major part of the problem causing unwanted lag.

Did NQ do the cleanup? I can't really tell at D6. Maybe a bit more organized and higher quality clutter, but still.

For the first time in a month I logged in and did the ring (flying the border of the mother-ship zone) looking at constructs. And closing in on D7 I was kicked out with a server disconnect and my ship went down, hard.. So even on a decent computer (Ryzen 2700X, 32G RAM, M.2 NVMe SSD, gtx1080ti, fiber internet 250/250) the lag consequences can be real.

The market lag is just the tip of the iceberg so to speak, for a much larger problem. Market 6 and 7 are just the early warning signs for a much larger problem that will also affect player controlled based tiles and large gatherings, if and when the games gets a larger player base. Anyone who experienced 'lag city' know what I am talking about. So despite what has been said by NQ, D6&7 shows that this game will not able to handle community driven large scale cities, space stations etc. And while the long-term solution of course is to make the entire game faster and more efficient, there will also always be need for 'crowd control' functionality to manage community based long-term gatherings. So many of us fail to see why NQ has ignored this for so long, when there are simple and effective solutions that can be applied that will mostly fix the short term problem of D6&7 (while waiting for the long-term solution that may not even be possible) and also be useful long-term for player driven markets etc in the future.

If this game ever becomes popular and gains a solid player base, district 6 and worse is going to be every market in the game.

But we don't know... Since NQ treats communications with players like marketing PR, using wish-washy wording that don't actually say anything. In the entire history of this game, I cannot think of a single time where players have been involved until after the feature suddenly shows up in a blog and has already been implemented so that it will be released regardless of player feedback. And this is the complete opposite of what was promised during the Kickstarter campaign. And if it is because NQ is worried that talking about the internal dev process and limitations in features will lead to bad PR, they don't have to worry. They already have plenty of that..

Market bots are currently needed because this game is FAR from complete. Without bots the ONLY money injection into this game would be the daily 150K, and while slowly increasing day by day that money would be ALL the money in the entire game that people could use for trading.

First, we need a way to tell if someone is parked on an NQ-owned market -- that's not likely a flag that exists today> You also need a firm definition of 'parked' -- does hovering just over the market count as 'parked'? Does it have to touch the market to count, or any idle ship within a market hex is affected? The "parked" bit must be stored server-side, too. > Already mostly implemented with the docking features Then it needs a timestamp to imprint the 'parked time'. Another server-side data construct they don't have today. > Trivial to implement What if someone climbs into their construct and moves it an inch? Ideally it is smart enough to know not to reset the timestamp... > Many simple solutions. First that comes to mind is that once you have been marked as parked, you must travel a certain distance from the market/leave the market hex to reset the counter. It needs to query every construct with an elapsed time; it doesn't have to do this often, though (e.g. every 10 or so minutes); but could still be a lot of constructs at scale > No, this can be done much simpler. There are only three events in the game that would change the parked status. 1. Constructs is marked as parked, timestamped and added to a parked constructs list on the server 2. Construct leaves and is removed from the list. 3. Once a timestamp goes past the limitation in the list, do some checks and then deconstruct So all the server needs to do is save a list of parked construct ID's and timestamps. And then periodically check the timestamps against the running clock. Something that would not take any resources at all. And if the list is sorted by oldest timestamps first, it would not even have to check the entire list every time, since once you come to a valid parking timestamp in the list, you know that the rest of the list is also valid. It needs to push the "deconstructing" state to clients so that clients can render the ship disappearing and free the model from memory. Otherwise you'd be staring at a ship and it'd be gone server-side but still lingering client-side. It also will look very odd if they just vanish without some sort of animation or feedback. > Already implemented with the Alt+B compact feature. What if someone parks their ship then stays inside? Extra logic is required to eject them > This one has some merit. But I bet considering how the game is constructed, that deconstructing a ship with players inside would just leave them hanging in the air for a sec before falling to the ground. This could of course be done more elegant, but considering the rest of the game it would not be outside the norm. On a similar note, what if someone jumps into their ship right as the countdown expires? It now has to eject them and compactify the ship...even though they were about to leave? But then how is it supposed to differentiate "about to leave" players from "just sitting in their cockpit" players...? It can't. > This would be covered by the deconstruct checks. For example if there is an active pilot in the construct when the parking timer is exceeded, the deconstruction is performed after the pilot leaves the seat, or canceled if the ship leaves. Destroying stuff is a performance cost, too -- the timers must be tuned so that clients aren't having to constantly purge then reload models. Longer the timer, the more clutter but the less complexity with these edge cases. > Orders of magnitude less performance cost then having markets filled with abandoned constructs. And we are talking days for the parking limit, not hours and minutes.

Not only is it easy and fast to implement but also an effective solution. And the dev time would be an good long-term investment (for once), since if DU survives and there some day actually is a large player base. Some variant of this features is going to be REQUIRED for managing unwanted clutter and construct griefing in player owned areas. But sigh.. knowing NQ they will probably come up with some unique solution that nobody else has thought off (for a reason).

And again..... This is a problem that was pointed out years ago in the pre-alpha tests. The fact that having a consistent world in a MMO, where digging holes is the main (and arguably only) source of income does not scale well, should not be a surprise to anyone. Storing world scale geometry in a voxel DB may seem very doable at first glance, since unaltered space takes zero storage and server-client I/O. But when you then add a MMO game on top, that incentivizes all players to make world changes everywhere (digging) it is bound to collapse.

An asteroid puzzle race is just another race to the bottom for this game. It should be obvious that anything puzzle or time based will translate into gain for big org's and the 0.1% of most dedicated players, at the expense of new players and the larger average player base that don't have the time or interest to live and breath DU 24/7. Same with broadcasting asteroid locations. Org's already have the advantage in numbers increasing their chances for finding asteroids worth mining, and now they are also going to be told where to travel to kick out any smaller group of players that worked hard to find a good asteroid? Why does NQ keep making these basic fundamental mistakes over and over again?