Khitan

Hey everyone,
so the event was a few weeks ago but no one talks about what happend their.
At the moment when at every PVP Battle something wierd happens and an Member from Hyperion taken part of it, everyone says that Hyperion is using Cheats or Glitches.
Yes the two ships which takes part of this Battle uses Stacked Elements and Burried Elements, but both is allowed from NQ at the moment and thats really not the Problem.
 
After this Battle we dont know what happens, so we decided to do some research. We figured out one really big Problems that game has at the moment.
We have this Information a really long time but i dont know why my Leadership or NQ didnt put an offical Statement on the Forum or so.
 
So what we figured out:
If your ship gets enough DMG from PVP fights your PC uses much ressources.
In this Fight the most AC members shoot with Railgun which makes good Damage but the Damage per Seconds are low. Both Hyperion ships shot with laser which has after Cannons the highest DPS.
Both Ships got 4 Seats of Laser which means per Ship 24 Lasers. At the moment Hyperion engaged the Boo Ships their getting so much damage in an shot time that their PCs are "Burning".
The pc off the Pilot is the "bottleneck" in this Part, on his PC the Ship gets calculated. But the biggest Issue in PVP fights at the moment where the Damage at the Voxels, at every shot your PC Downloads the "new Voxels" of your ship. The Boo Ship got a really big Part of Gold Voxel which creates microvoxels with every shot/damage so your PC Downloads really much Voxel changes.

We tested it and the Download is the biggest Problem in the actual PVP.
My PC in the Video got:
i7-8700k(overclocked to 5.0Ghz), 32GB Ram, Readon RX 6800XT, Samsung 970Evo M2 and and 1Gbit Internet Connection.

First test
11 Gunner, 50 Missiles, 4 Railguns to a Plate of Gold Voxels
Most shots missed, network spike 40Mbit/s, lowest FPS around 20
 
Second Test:
8 Gunner, 48 Lasers to a Plate of Gold Voxels
Min of FPS: 2, Network spike to 254Mbit/s

Third Test:
8 Gunner, 48 Lasers to a Plate of Iron Voxels
Min of FPS: 5, Network spike to 159Mbit/s

Fourth Test:
Ethernet Limited to 16MBit/s 
8 Gunner, 48 Lasers to a Plate of Iron Voxels
Min of FPS: 5, it takes around 2 Minutes to load every Voxel Change.

You can watch these Results in the Video:

Hello again Noveans!
We have heard your initial feedback on the screens and we want to elaborate on some of your major concerns.
 
Will this affect both screens and content written to the players screen (HUDs)?
No, this technological change will affect only screen units at this time.

Will all player created work on screens suddenly become non-functional?
No, this technology will be available side-by-side with the current technology, both first on the PTS in a prototype state, and eventually also on the Live server.
We strongly recommend everyone does test and experiment the new tech on the PTS, as your feedback and testing will help shape this feature.

How will this make a difference on performance?
The main reason being that the current implementation does not allow for much control over the performance impact of screen renderings. Complex 3D transformations using a combination of HTML, SVG and CSS has a significant impact on render times in the client. Adding to the fact that screens are often condensed with multiples of them in close proximity to each other, there is an increasing drop in performance on the client with more screens using the current technology. The new system allows for more precise control over rendering time allowed across screens and allows us to safeguard the level of performance impact the screens have on the client.

So you will be removing HTML support entirely?
Not necessarily, the two techs will run side by side for an as of yet undefined period of time. Eventually we may introduce a phase where we make the rendering of HTML on screens an option for players along with a warning that it can significantly degrade client performance. Players with that option disabled will simply not see any HTML content and not suffer performance degradation because of it.

Why not improve the current HTML implementation instead of the new technology?
This is a complex topic, HTML/CSS/Javascript is a group that forms a UI technology. For reasons beyond the scope of this topic we do not allow the use of Javascript inside the screen units. When you remove Javascript, the group effectively becomes a not so efficient vector image drawing technology which we have very little control over in terms of rendering. We have previously implemented a lot of small limitations here and there to reduce the impact of the screens, but there are (and likely always will be) edge cases which will eventually crop up using that technology. As such, the new technology has built-in limitations on how taxing a screen unit can be, and if a screen unit goes over the limit it will simply stop drawing. This is why we ask you all to go and test this, and help us find caveats and where you run into things you can and can’t do.

What about bandwidth? Are you doing this to reduce data transfer for screens?
The current implementation does not address this, the current implementation is a way for us to collect your feedback on this concept. Eventually we may change the way data transfer for screens is handled, where we may increase the size of the defined “template” inside a screen unit itself. Followed by a lower limit on the amount of data transferred to the screen from external sources. Allowing the screen element to do the rendering and drawing work, using parameters fed to it by a control unit.
For example: You would draw the design of a fancy instrument panel using the screen element, and a programming board or control unit just sends the values for all the instruments to the screen. This is currently not in the current implementation however, but may give you a better idea of why this technology has a lot of potential for more intricate and powerful designs.

What about artists who draw using external programs and import their SVG’s into the game?
One of our hopes is to provide a good enough set of commands in the screens API so that our system can express most SVG graphics converted to these commands through for example a small conversion tool. It is unlikely that we will develop and maintain a conversion tool for this, but this is also why we want your feedback on this new API for you to let us know what commands you really want to see included to make this process easier.

We sincerely hope that this answers many of your initial questions and concerns.
I personally can’t wait to see what you will all come up with in your designs!
 

Hello Noveans!

Currently, screen unit content is an HTML page. We synchronize screen unit content between players by sending the whole HTML; however, 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. This has a significant impact on client performance for players, especially when a lot of screen units are in the same area. 
Performance improvement is of paramount importance to us and an ongoing request we get from players. Consequently, it is something we will continually work to achieve. 
 
To address this, we are bringing a possible solution to PTS so that players can try it out. This prototype involves using a new API to draw screen units with a dedicated Lua script. This will use simple drawing commands like
drawRectangle(a,b,c,d) drawText(“Hello DU”) Simple actions like setTextContent will not be affected. 

In addition to performance improvements, this new tech also allows for some unprecedented possibilities to create even better screen displays than before. Check out this video to get a taste of what it can do! 
 

We realize that this change will mean that players won’t be able to use SVGs on screens anymore, and that SVGs are easier and more flexible than uploading static images. It’s important to note that the new Lua system will still allow you to draw complex images. You don't really need any Lua knowledge, and it’s easier than the DPU system.

Additionally, we added an option to deactivate HTML screen units for players who experience the worse framerate. We expect this to bring significant performance improvements in markets and parking areas.
Once the change is fine-tuned, thanks to your feedback after trying it on the PTS, we will announce a transition period to allow players time to switch over to the new API before we disable support for HTML-based screen units. We will continue to support both techs during this transition period.

We strongly encourage everyone to check out this change when it’s available on PTS and share your constructive feedback with us on the forum. 
 

This is my opinion.

NQ wants this to be a community game. They want folks to play together and build relationships.
 
We are building relationships... in Discord. We can't build relationships ***In Game*** because the communication tools in game are awful.  This is, IMnsHO, the single biggest mistake that NQ has made, and is continuing to make.
 
If they want this to be a community building game, then they need to provide the communication tools to actually build communities. This includes mission terminals, player market terminals, etc but it also includes, threaded chat, tags, filtered customization chat tabs, in game email, ship hailing, and proximity voice. Without these, we are alone in game, and together in Discord.

I don't think it hurts anyone.  From NQ's point of view every DAC in existence has already been paid for, and it shouldn't matter who redeems it.