Jump to content

Changes to Lua screen units


Recommended Posts

35 minutes ago, CedriVastal said:

Artwork is a visual form.  Most artists aren't programmers so sending instructions with code to create works of art is absolutely unconscionable. 

 

The problem is that the person(s) telling NQ this is a good idea are actually programmers who do not understand the reach and impact these changes will have.

 

And the person/people in NQ listening to this advice in turn als are programmers so to them it makes sense. And so this translates into the video we now see of some "animated" basic shapes and a rather vague post on the forum. It is also why you see some respond with surprise, not understanding how people are not seeing this as a good change.

 

This is a general issue with NQ, everything they do is designed and justified from a programmer's perspective and ignores the actual impact it has on the player base. And if you make that point  the answer is "well, you can always commission someone to do it for you, that is what emergent gameplay is all about".. Except it's not.. at all

Link to post
Share on other sites
2 hours ago, Atmosph3rik said:

But at the end of the day the screens are fluff.  Super awesome fluff, but they aren't needed to make the game work, as a game.

 

One man's fluff is another man's content.

 

There are some very much functional constructs which depend on their screen, such as the ship cost estimator or JayleBreak's Reactor/2D+ Voxel Planner.  If the latter were to break, and if the creator either could not make it work in the new API or did not have time to do so, it would be devastating to my main gameplay loop of voxel building.

 

I also rely heavily on creating SVGs using Inkscape (or any external editor with a pen tool) to use for sales display and events.  Often, I am making these after arriving at the event!  Having to wait on the image approval process would kill my ability to do that.

 

Could I still do these things without these tools?  Yes, but the work will be slower, more difficult and result in a lower quality.

 

If the issue is, as stated, "screen unit HTML content can be pretty big and uses a lot of bandwidth and frame time to render when updated every frame by a programming board or control unit." (emphasis mine) then this change is throwing the baby out with the bathwater.

Link to post
Share on other sites
8 minutes ago, SpaceBird said:

One man's fluff is another man's content.

 

 

Yeah, you're right.

 

I'm mainly here for the voxel building myself, and If they announced tomorrow that to improve performance they had to limit the shape of voxels to simple cubes and wedges, i would be looking for a new game to play.  

 

I guess it's easier to say "oh well" when it's not my fluff.

 

I do hope they can find an alternative solution or a compromise that still allows people to use those tools in the game.

 

 

Link to post
Share on other sites

Wow, another "fix" for the markets that is just another bandaid.  Why is it so hard to delete ships after a certain amount of time!?!?!?!?!  I just don't get it.  How about you remove the markets all together and get us our player markets and we can spread ALL that processing out across the entire game?  It would at least give ME a small reason to play again.  I could set up a nice little market center and rent out shops. I would have something useful to build again.  Heaven forbid NQ try to turn lemons into lemonade. 

 

Yep, in case you can't tell, I'm one of those artists.  I made videos for this game until they removed those.  Then they only allow 5 images which is insane, but I made do.  And now they yank HTML/CSS.   If HTML (of all things) is slowing the server down so much then there are way more significant problems that need to be fixed.  But once again, NQ is taking the easy way out and doesn't care how it affects the players. 

 

I'm losing any remaining hope that I will be able to begin playing this game again.  In the two months I've been gone the game continues to move backwards.  Sigh... what a total bummer. 

 

Link to post
Share on other sites
On 4/8/2021 at 6:47 PM, Wolfram said:

It would work similar to how web templates/frameworks work, the first function would be an HTML/SVG template in syntax similar to Twig/Handlebars where we would set the heavier part of things, while the second function would be passing the variable data to that template, which would be combined and rendered as HTML on the client.

Thing is, this is NQ in a nutshell. No sane dev would implement the current DOM in a MMO game. And we see this type of thing everywhere in the game. Like opening up the notification list anyone?

 

The functionality you mentioned here should mostly have been an automatic feature (using some variant of shadow DOM) in the setHtml() function from day one. And the type of specific function calls you mention, should only be used to even further optimize the performance beyond what shadow DOM would do.

Link to post
Share on other sites

From what I read i gathered that the HTML CSS will still be supported but can be turned off forcefully in the client to prevent lag. 
 

this secondary LUA based method might have a separate/no toggle. 

Link to post
Share on other sites

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.

Link to post
Share on other sites

Hate the proposed change, like others it completely ruins the artistic implementation and vision of my constructs. If it is implemented with no SVG support, I'm out for good.

Link to post
Share on other sites

This is why we can’t have nice things. 
 

HTML and SVG only really causes issues in fringe cases (super crowded marketplaces) and those fringes are caused by NQ’s seeming complete lack of ability to do the obvious, instead opting for Rube Goldberg style workarounds and Rick Sanchez level shenanigans. 

Link to post
Share on other sites

In the end the screens are great, and some form of display is required to support the programming, but if they are destroying the basic functionality then the reality is something needs to change. The screen data (that is publicly visible) is a difficult thing to scale - and maybe what is needed is a split between personal screens (cockpit) and public screens. Remember every public screen has to go to every client - the more players there are in the game the more public screens there will be which means it is a multiplicative factor. This is bad. You need things to linearly scale as much as possible.

 

So, maybe the way to go here is in-cockpit screens (ie only viewed by the pilot for example) can be html/svg while public screens need to dynamically generate on the client based on the rest of the data regularly sent there.

 

Just a thought.

Link to post
Share on other sites

Just to give feedback on this, I have made stuff in SVG that is impossible to recreate with the little options you have with LUA API calls only. If you do plan on replacing SVG / HTML, to help improve performance, at least give more API calls. Like lines, rectangles, beziers, cropping / boolean, circles, arcs and polygons. Filled and non Filled. That at least could give us most of what we use in SVG.

Link to post
Share on other sites

Coherent UI has databinding... But I doubt they'll go there... currently the html is redrawn every frame / tick, that is of course costly if there's a lot of it. Databinding allows the html dom to stay in memory and only redraw values that change. That's one of Coherent UI's powerful features that isn't being used. Of course you'll get bad performance redrawing the whole DOM all the time.

Link to post
Share on other sites
12 hours ago, IvanGrozniy said:

Coherent UI has databinding... But I doubt they'll go there... currently the html is redrawn every frame / tick, that is of course costly if there's a lot of it. Databinding allows the html dom to stay in memory and only redraw values that change. That's one of Coherent UI's powerful features that isn't being used. Of course you'll get bad performance redrawing the whole DOM all the time.

This game is the pioneer of bad performance. I would not be shocked if we all found out that they have been bitcoin mining this whole time.

Link to post
Share on other sites
On 4/15/2021 at 10:19 AM, IvanGrozniy said:

Coherent UI has databinding... But I doubt they'll go there... currently the html is redrawn every frame / tick, that is of course costly if there's a lot of it. Databinding allows the html dom to stay in memory and only redraw values that change. That's one of Coherent UI's powerful features that isn't being used. Of course you'll get bad performance redrawing the whole DOM all the time.

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..

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...