CptLoRes

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?

Exactly. Incremental HTML DOM updates is one of the fundamental techniques that makes modern interactive web pages possible with reasonable resource drain on smartphones etc. So the current LUA Screen implementation is fundamentally flawed. And now NQ is blaming the technology (that works great for billions of users btw.), instead of their own bad implementation that probably was some early "just make it work as quickly as possible so we have something to show, and then we fix it later" deal that ended up being the 'final' version. And now they want to throw out the baby with the bathwater, and start over using classic "Not Invented Here" reasoning to try and fix already solved problems. This makes my blood boil, since this type of reasoning and reinvention for the sake on reinventing, is exactly why this game is where it is today..

The announcement is pretty much just a summary of all the things we have been saying and asking for the last couple of years. Here is to hoping, this time it's for real.

And in that time frame NMS added more new features and playability then NQ has ever done since the start of the game in late 2016 (plus what I would guess is 1-2 years of private dev time before the kickstarter). That from my perspective says everything.

A long, long time ago in pre-alpha, players had 9999 of everything. And it was the most fun I ever had in this game, since experimentation and building wasn't hidden behind a wall of grind.

Sure, whatever I guess at this point. But they are still essentially reinventing the wheel (into a subpar version at best), because they could not be bothered figuring out how to properly fasten the nutbolts. A shadow DOM on the client side would have solved 99% of the problem. And if that wasn't enough they could have just rate limited DOM operations to avoid excessive usage.

Regardless of color scheme, using a serif font for the relatively small text sizes in a forum is a big nono. But we are back to sans serif now, so I can live with this.