Jump to content

Changes to Lua screen units


Recommended Posts

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.

Link to post
Share on other sites

We need more info on what the new system is really like. The small video and code snippets don't really tell enough to judge how it is.

 

What worries me is that if the script file size limit isn't increased, the Saga HUD will have serious issues. Even if it would be possible to recreate the UI elements with the new system, it will require new code to do, and we don't have the space for new code...

Link to post
Share on other sites

I completely empathize with Nekranox on this and agree that the playerbase has far too large of an investment of time and creativity into existing HTML/CSS/SVG content to simply throw out support for it entirely.  With that said, I do love the new capabilities featured in the video.  Seems to me the obvious direction would be to leave HTML/CSS/SVG support for good instead of just for a transition period.  That combined with the fact Devs said they would be adding a player option to disable HTML content should meet everyone's needs, even if it means disabling HTML by default.  

Link to post
Share on other sites

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.

Link to post
Share on other sites

NQ was very clear that they're doing this because of performance -- they didn't think about how the initial implementation would scale at all...it's like they didn't even bother running performance tests in an MMO defined by creative possibilities. 

 

Now that they realize it isn't as performant as it needs to be, they are changing everything and trying to pitch it like its some benefit when really it was their mistake. 

 

Like many issues with DU, this was caused by poor planning and technical competence -- if you're building an MMO, you need to test for scale. 

Link to post
Share on other sites

I recommend to wait for the PTS openning to test it and judge.

It seems to bring more power and better display rate.
It's not because it change or break things  done before that's absolutly bad 😅

I have so much project which will be broken with it, and ? And wait to test and judge ;) 

Link to post
Share on other sites
19 minutes ago, Mayumi said:

We need more info on what the new system is really like. The small video and code snippets don't really tell enough to judge how it is.

 

What worries me is that if the script file size limit isn't increased, the Saga HUD will have serious issues. Even if it would be possible to recreate the UI elements with the new system, it will require new code to do, and we don't have the space for new code...

The script size limit is not a real limit. You can simply store code or UIs so, in databanks and extend so your limit.
I do it all times to load, unload libs and heavy UIs.

Link to post
Share on other sites

 

I really wonder how HTML/CSS is such a drain on bandwidth and performance and also wonder how this new method will change that. Data still needs to be sent to the clients and there it still needs to be executed. This sounds more like a very broad stoke "solution" to get rid of people using Massive image and CSS to create animations or base64 in HTML to display image.

 

So many creative solutions in game that now become obsolete, as OP states, so many wasted hours on fun projects.

 

And there is so much information missing from this announcement like what will happen to the image library NQ introduced, will that now be obsolete and will we now pretty much see the removal of our ability to simply show images on a screen in return for a requirement to use/learn Lua to use screen for anything but simple text?

 

What code is used in the video? where can we find this? what is next? Will NQ move to locking down the screens entirely. It looks like they have now reduced the functionality of screens to less than what  Space Engineers offers.

 

And yes, I expect this will break all the innovative script like HUS that use HTML as well

 

Link to post
Share on other sites

  

1 minute ago, blazemonger said:

 

I really wonder how HTML/CSS is such a drain on bandwidth and performance and also wonder how this new method will change that. Data still needs to be sent to the clients and there it still needs to be executed. This sounds more like a very broad stoke "solution" to get rid of people using Massive image and CSS to create animations or base64 in HTML to display image.

 

So many creative solutions in game that now become obsolete, as OP states, so many wasted hours on fun projects.

 

And there is so much information missing from this announcement like what will happen to the image library NQ introduced, will that now be obsolete and will we now pretty much see the removal of our ability to simply show images on a screen in return for a requirement to use/learn Lua to use screen for anything but simple text?

 

What code is used in the video? where can we find this? what is next? Will NQ move to locking down the screens entirely. It looks like they have now reduced the functionality of screens to less than what  Space Engineers offers.

 

Nothing say it's limiting possibilites, wait and test.

But I agree on the fact it's missing informations

Link to post
Share on other sites
1 minute ago, blazemonger said:

 

How is removing HTML/CSS not limiting possibilities?

Most HUD scripts will now become obsolete.

We don't know anything about the new system.
And yes existing systems will be broken. And ? It's not a reason to say it's shitty 😅 It will just give a new support of developpement. And more possibilities.

We even don't know what kind of limits we will have 😅 For HTML/CSS it was the characters, and it was heavily impacting performances. On FPS aspect and data transfer aspect. And it seems hugely better on that... so wait to test.

I will may be say it's a huge shit after testing it. But for the moment, I stay optimistic ;) Be optimistic sometimes ^^'

 

Link to post
Share on other sites

Starting off by saying I am glad to see they are attempting a change to lower the issues at markets. I like the new possibilities to screens as well.

I am though wondering if we can have the over all game option to by default, allow html coded screens to be on or off by default. With this grant us the option to turn on or off any screen in the game and allow the screen to be on or off based locally instead of by server. Meaning if I toggle a screen on or off, it is only effecting the screen for me, not the server. That way my game does not have to load a screen unless I chose to turn it on. But that will not change what the person next to me sees.  

Could be a fair compromise to keep html in game to avoid lua creators from having to redo entire code.  

 

Link to post
Share on other sites
4 minutes ago, Elias Villd said:

We don't know anything about the new system.
And yes existing systems will be broken. And ? It's not a reason to say it's shitty 😅 It will just give a new support of developpement. And more possibilities.


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. 

Link to post
Share on other sites
On 4/8/2021 at 5:14 PM, Elias Villd said:

We don't know anything about the new system.

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.

 

Quote

 And more possibilities.

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

 

Quote

I will may be say it's a huge shit after testing it. But for the moment, I stay optimistic ;) Be optimistic sometimes ^^'

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.

Link to post
Share on other sites

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.

 

 

 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

We'll see how it goes.  I was working on a framework that did much the same thing, tbh it's crazy that we don't have a proper object-oriented UI framework yet.  But they may let us specify "class" and "style" tags as parameters, who knows, we'll have to wait and see.  If we can get those, we can retain full functionality, though it will take some rewrites.  

 

But as a whole the new system should be much cleaner on code size too, HTML strings were un-minifiable, so things like SagaHUD should actually end up with a lot more space after the rewrite

Link to post
Share on other sites

I think NQ shouldn't completely disable HTML. It is necessary to enable the player to use the screen locally. There is no need to sync HUD with other players if they are not on the ship. NQ, please do this: if html is used, then the code is executed locally and does not sync.

Link to post
Share on other sites

This is the first change I find I need to throw my voice out there with. 

This game already has a very limited community of artists and animators.  This game's look and feel DEPENDS on those artists.  The new system will only allow for basic shapes?  Get real.  We already have a 50kb limit which is outrageous for more complex SVG, but we deal with it.  Effectively banning HTML isn't about performance.  It's about censorship. 

 

This is one excuse I can't believe based on how long lights perform.  You want to increase performance?  Fix the lights.  You want to lose your game's aesthetic and appeal to artists?  Implement this change.

Artwork is a visual form.  Most artists aren't programmers so sending instructions with code to create works of art is absolutely unconscionable.  Killing off artists isn't going to affect your bottom line, I understand that, but the removal of freedoms in expression or being limited should outrage any reasonable person.

Edited by CedriVastal
missed a conjunction
Link to post
Share on other sites
1 hour ago, Dimencia said:

We'll see how it goes.  I was working on a framework that did much the same thing, tbh it's crazy that we don't have a proper object-oriented UI framework yet.

 

Especially when the middleware they use for the UI elements can support that just fine. While I am not a total fan of Coherent, what NQ is doing with it is like buying a fully decked out toolkit and just using the screwdriver and the hammer and then try to fasten something that needs a wrench with those.. sortof .. ;)

 

This changes just feels like something NQ is doing to "fix" the performance problems at markets mostly. Instead of actually addressing the problem, they just nerf the functionality of the game for everyone anywhere.

Link to post
Share on other sites

Does this bullshit change affect the system screen too? If not I'll just stop using screens, but if so, I'm gone. I don't think the new system can draw my ship UI without needing to move a huge amount of html (i.e. one drawRect per pixel.)

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