nekranox

I'm going to keep this short, since I haven't played in 3 months:
 
Removing HTML is overkill. The UI rendering solution you use in game already supports dynamically updating HTML without having to rewrite the entire content. See data binding in: https://coherent-labs.com/Documentation/cpp-gt/df/dfb/_h_t_m_l_data_binding.html
 
If you're worried about performance, this will be more efficient than your new Lua solution. You should make use of the technology you have already licensed and use instead of reinventing the wheel. More advanced UIs could be generated with the use of JS on top of this.

In the end, I get there may be a need for changes and I also get that this will mostly always impact someone somewhere.
 
What I do not get is that NQ  still is unable to provide information in a way that prevents confusion and chaos. What was released is pretty much telling us nothing substantial and raises a ton more questions than needed due to lack lustre communication.
 
Combined with the fact we heard al these words before, several times in fact, and then say absolutely no change s of improvements performance wise after the changes came into play, I'd say NQ should really know better by now. The proof is in the pudding here and so far they have neglected to serve it.

As someone who played a lot with screens (even made a UI library around that), I understand the issues with updating them all the time, but I also feel the new tech is not the way to go and is definitely a step backwards instead.
 
What I honestly think could be done is understand WHY people keep spamming the setHTML method instead:
Currently, whenever we need to update any information on the screen, the only option we have is to update the entire thing, which indeed, costs lots of bandwidth and overhead, specially since sometimes all we need is to update one or other information. Some ideas that could improve on the way things work today:
 
Use templates to decouple the screen's SVG/HTML from data:
Introduces two new functions: screen.setTemplateCode(template_code) and screen.setTemplateData(variable, value)
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.

So, for example, let's say we have this template code: 
<p>Hello, {{name}}!</p>
We would only call the setTemplateCode function once with this content and then call setTemplateData('name', 'Wolfram') to set the variable values, which in that case would be rendered on the client as:
<p>Hello, Wolfram!</p>
With that we wouldn't need to keep sending over the HTML all the time, since we could only update a single value instead, this would be extremely helpful with larger HTML or SVG pieces.
 
Note that the setTemplateCode function should have some sort of limit, maybe running once every 15s, so that people look for smarter ways of updating stuff, by using the setTemplateData function instead.

This seems like a bummer.
 
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.
 
The question is will this be enough of a performance boost to justify hacking off such an awesome feature.
 
I do wish they had considered this five years ago, but hindsight is 20/20.  Nothing to do about that now.
 
 
 
 

Yes, and for a potentially massive impact this may have to the game, why is NQ extremely vague about this
If NQ kills HTML/CSS they pretty much kill the entire core of their "customizable UI" pitch for the game which I'd say they should be open about.
 
Also, I ask again, how does transmitting and running Lua code different from transmitting and executing HTML/CSS?
This change will make most, if not all construct bases screens no longer work it seems, I'd say that calls for a bit more detail that the meaningless video they posted and a bit  of text saying pretty much nothing.
 
It just seems that regardless of recent events not much is learned yet.
 
Like what? The point is not that there is change, the point is not that things need to be done different going forward. The point is that NQ creates chaos and insecurity for a lot of people by half baked announcements that really tell us nothing
 
I am realistic, that means I voice optimism when there is reason to and will voice critique when I feel that is warranted. Being critical and questioning choices made does not mean you are not optimistic.

When creating artwork, you use familiar tools like Adobe Illustrator. That's how I created the Bacterium pets and then I used CSS to animate them and make them breathe. If I can't import vectors to display them on screen then I cannot work with my existing tools. You'll find that many other creators will share my feelings on this.

Maybe...we'll see soon, but let's be clear: NQ didn't do this because it's a "better system". 
 
They made it very clear in their post that they're doing this because of performance, then tried to spin it like it's "better" while admitting that it won't be as flexible. 
 
They're doing this because they didn't really test how certain aspects of LUA scale in an MMO environment and now the performance cost is too expensive. 

For those that havent read:
https://board.dualthegame.com/index.php?/topic/22565-changes-to-lua-screen-units/
 
My entire range of products in-game is based on HTML screens and CSS animations. It would not be feasible to rewrite them in any amount of time that would make it worthwhile. The new LUA based drawing features are extremely limited. For example, a large part of what makes my Bacterium product look realistic is the use of CSS animation on SVGs. Most crucially, the ability to use existing skillset (HTML/CSS) and familiar tools (SVG creation outside of the game e.g. Adobe Illustrator) are what make my products possible within the already tight limitations of DU.
 
I don't want to be dramatic, because I know its important to be constructive when giving feedback but if you remove support for HTML on screens, I'm out. Hundreds of hours of work will have been wasted and the key element that attracted me to this game will have been lost.
 
HTML/CSS is an existing technology that attracts creators becuase they can use existing skillsets. Removing it is too greater loss. If anyone else feels this way, please comment below.
 
EDIT
Can I just give an example of the sort of thing I am regularly doing on screens so you can understand how unachievable it will be using the new LUA commands:
 
My Bacterium product (https://du-creators.org/makers/NoxCorp/ship/NoxCorp Bacterium) uses animated SVGs inside <DIV> containers that are then animated to move around and transformed in 3 dimensions using CSS. This can all be achieved in around 30,000 characters of HTML/SVG markup and CSS. There are no amount of "useful drawing commands" that can offer this kind of flexibility.

For those that havent read:
https://board.dualthegame.com/index.php?/topic/22565-changes-to-lua-screen-units/
 
My entire range of products in-game is based on HTML screens and CSS animations. It would not be feasible to rewrite them in any amount of time that would make it worthwhile. The new LUA based drawing features are extremely limited. For example, a large part of what makes my Bacterium product look realistic is the use of CSS animation on SVGs. Most crucially, the ability to use existing skillset (HTML/CSS) and familiar tools (SVG creation outside of the game e.g. Adobe Illustrator) are what make my products possible within the already tight limitations of DU.
 
I don't want to be dramatic, because I know its important to be constructive when giving feedback but if you remove support for HTML on screens, I'm out. Hundreds of hours of work will have been wasted and the key element that attracted me to this game will have been lost.
 
HTML/CSS is an existing technology that attracts creators becuase they can use existing skillsets. Removing it is too greater loss. If anyone else feels this way, please comment below.
 
EDIT
Can I just give an example of the sort of thing I am regularly doing on screens so you can understand how unachievable it will be using the new LUA commands:
 
My Bacterium product (https://du-creators.org/makers/NoxCorp/ship/NoxCorp Bacterium) uses animated SVGs inside <DIV> containers that are then animated to move around and transformed in 3 dimensions using CSS. This can all be achieved in around 30,000 characters of HTML/SVG markup and CSS. There are no amount of "useful drawing commands" that can offer this kind of flexibility.

For those that havent read:
https://board.dualthegame.com/index.php?/topic/22565-changes-to-lua-screen-units/
 
My entire range of products in-game is based on HTML screens and CSS animations. It would not be feasible to rewrite them in any amount of time that would make it worthwhile. The new LUA based drawing features are extremely limited. For example, a large part of what makes my Bacterium product look realistic is the use of CSS animation on SVGs. Most crucially, the ability to use existing skillset (HTML/CSS) and familiar tools (SVG creation outside of the game e.g. Adobe Illustrator) are what make my products possible within the already tight limitations of DU.
 
I don't want to be dramatic, because I know its important to be constructive when giving feedback but if you remove support for HTML on screens, I'm out. Hundreds of hours of work will have been wasted and the key element that attracted me to this game will have been lost.
 
HTML/CSS is an existing technology that attracts creators becuase they can use existing skillsets. Removing it is too greater loss. If anyone else feels this way, please comment below.
 
EDIT
Can I just give an example of the sort of thing I am regularly doing on screens so you can understand how unachievable it will be using the new LUA commands:
 
My Bacterium product (https://du-creators.org/makers/NoxCorp/ship/NoxCorp Bacterium) uses animated SVGs inside <DIV> containers that are then animated to move around and transformed in 3 dimensions using CSS. This can all be achieved in around 30,000 characters of HTML/SVG markup and CSS. There are no amount of "useful drawing commands" that can offer this kind of flexibility.