Jump to content

Detecting Stacked Elements - Discussion Thread


NQ-Deckard

Recommended Posts

While your in there coding this feature please provide better hitbox collision and feedback for objects while placing for both objects on the construct and the item being placed! Far too often there is some invisible area where it just will not place. The feedback could be on where the collision is taking place and a highlight part on the construct that is causing the collision. 

Link to comment
Share on other sites

How is it going to mark the individual  elements that are stacked? For example if a red triangle is on 65 adjusters will it highlight ones with stacking problems?   As with other games with building, your detection of overlap has not been perfect.  If a single player places one element, say a container, then places other elements next to it, there is always a chance that if you put the original element in edit and move it and move it back, it will 'think it can't be placed'.   This should never happen.

 

Link to comment
Share on other sites

It certainly would be best to test it well.  However, keep in mind it is NQ responsibility to be more careful about accuracy in checking overlap while building and slightly more forgiving for using a construct if it can't be absolutely perfect.   This is a valuable tip if you want the game to thrive and be popular.   You don't have to use the exact same code for checking overlaps for both usage and building - code for usage of the construct will potentially cause more lag than code while building it.   I know how to make code efficient and reliable.  Make the players happy instead of having them leave in disgust.   This overlap checking for usage instead of getting it right for building only is a bad idea and could end up as a nightmare.   Please reconsider.

Link to comment
Share on other sites

Fixing stacked elements is a great change and I like that there's a way to detect overlapping elements now.  But in the screenshot you included all the player knows is that at least one of the 118 retro rocket brakes (for example) is disabled.  They don't know where that element is and finding it might be tedious.  Will the stacked elements glow red like obscured ones to to make it easier?

It would be really great if LUA could do this.  Perhaps a core.getStackedElementIdList() function to return a list of disabled elements on the core.  Then this could be incorporated into existing LUA scripts (damage control perhaps?) to put arrows up pointing to the broken elements, highlight overlapping ones on an element map of the construct, etc.

Link to comment
Share on other sites

English (deepl used)

I find the rule that element collisions are only relevant for PvP acceptable.

But to generally punish all collisions of this kind is a bit crass in my opinion.

The promise that blueprints can also be used after the RELEASE has already been broken several times and with this regulation it is finally off the table.

The most annoying thing is that the industry elements have nothing to do with PvP and secondly they are mostly mistakes in the designs (NQ side).

Many of my designs are still from PRE-ALPHA. I would have to make hundreds of changes to comply with this new rule.

The question for me is whether I can do anything meaningful in the game before RELEASE without throwing it away again and again. 

With LUA programmes it was already foreseeable (absolutely 80s styles).

In the meantime I'm afraid my backer contribution was wrong, especially as JC is probably not paying attention any more.

Translated with www.DeepL.com/Translator (free version)

 

German (original)

Quote

 

Die Regelung, dass Elementkollisionen nur für das PvP relevant sind, finde ich akzeptabel.

Aber generell alle Kollisionen dieser Art zu bestrafen halte ich für etwas krass.

Das Versprechen, das Blueprints auch nach der RELEASE benutzbar sind, ist nun schon mehrfach gebrochen worden und mit dieser Regelung endgültig vom Tisch.

Am ärgerlichsten ist, die Industrieelemente habe ersten nichts mit PvP zu tun und zweiten sind es meist Fehler der Entwürfe (NQ seitig).

Viele meiner Entwürfe sind noch aus der PRE-ALPHA. Ich müsste hunderte von Änderungen durchführen um mit dieser neuen Regel konform zu gehen.

Die Frage für mich ist, ob ich noch vor der RELEASE irgendetwas sinnvolles im Spiel machen kann ohne es immer wieder weg zu schmeißen. 

Bei LUA-Programmen war es ja schon im Ansatz abzusehen (absolut 80er Stile).

Mittlerweile fürchte ich mein Backerbeitrag wahr falsch, zumal JC wohl auch nicht mehr aufpasst.

 

 

Die Waldfee
 

Link to comment
Share on other sites

3 hours ago, kulkija said:

Is this stacked or legal?

indy.JPG

Industry elements are on the list, so that is probably illegal.

Mullakin on pieni mutta tehokas tehas. niin tiä että noita romuja on välillä vaikee saada tungettua mihinkää :P
Sorry about Finnish Part.

Highlighting is surely most important part of the detection system.

 

Note: I'm very badly color blinded and I can't see broken elements in repair mode for in example, even those are highlighted. So is there ETA for the color blind mode?
ColorBlind.png.5b104d258102b22c4c3b801834cbd6de.png
I can help with that mode too if needed, since my color blindness is not limited to just 2 colors or 3.

-Rav

Link to comment
Share on other sites

  • NQ-Deckard unpinned this topic
  • 2 months later...
On 10/18/2021 at 9:11 AM, NQ-Deckard said:

Hello everyone,

 

We would love to hear your feedback about the new ability to detect if your construct has stacked elements!

 

NQ-Deckard

I'm confused with this whole topic, if I mount a large atmospheric brake and mount another one on top of it is that being labeled an exploit? if so how? who is the victim here? After looking at my ship I can arrange the breaks so that they are not on top of each other but what does that fix it's all very confusing to me. Is the goal to make brakes less effective? If so why? what is the shady benefit of this because I missing the part where this is an exploit. If you don't want people putting a brake on top of a brake then make it turn red so you can't this is not the violation of trust that you are making it out to be in my opinion. The reason people are putting 20 engines and brakes on ships is because the elements are really weak and it takes that many elements to get the ship to spec so you are able to leave the atmosphere which is 2g or more of thrust same can be said about the brakes our ships are littered with brakes because the brakes are really weak in my experience you need about 10 times the braking thrust and your engine thrust in order to stop in a orderly fashion. If you dont want players putting to many elements on a ship then the elements need a huge buff across the board from basic up to the highest tier engines and brakes, wings, air foil, adjustors all need buffed the less we need on our ship the better. I don't think players want to do this, I think it's a means to an end is all this is. Weak elements = many elements. You seem to throw that word exploit around a little to lightly for my comfort. According to you having a landing pad on every planet is an exploit and again I don't get that. 

Link to comment
Share on other sites

To clarify, this is in relation to elements that are jammed inside each other. Who's collision boxes are overlapping.
Several terms used by the community for this are: Element Stacking, Jankomancy, and Overlapping.

Ultimately, it should not be possible to still do. And old designs will cease to function correctly if they do.

For example, placing 20 engines inside each other is not the intended design and is prohibited by standard element placement. Circumventing that restriction by abusing a bug, is indeed an exploit. :) However, unless if involved in any form of PVP we won't act upon it, and the elements in question will cease to function properly following the Panacea update.

Link to comment
Share on other sites

I'll repost my suggestion for how to handle intersecting elements (the term stacking only leads to confusion) .

 

One way to prevent gains from element intersection and not break old designs and some of the unintended partial intersects that sometimes happens while building without active exploits, would be to use % element intersection as a limit on elements effectiveness. Much the same as with obstruction. So if for example you have two engine elements intersecting you subtract the second elements intersection from the first, so that the combined output becomes the same a single normal element.

 

This would allow old designs to continue working without exploit gains, and act as a 'catch all' for fringe cases that might happen while building normally.

 

Link to comment
Share on other sites

3 hours ago, NQ-Deckard said:

To clarify, this is in relation to elements that are jammed inside each other. Who's collision boxes are overlapping.
Several terms used by the community for this are: Element Stacking, Jankomancy, and Overlapping.

Ultimately, it should not be possible to still do. And old designs will cease to function correctly if they do.

For example, placing 20 engines inside each other is not the intended design and is prohibited by standard element placement. Circumventing that restriction by abusing a bug, is indeed an exploit. :) However, unless if involved in any form of PVP we won't act upon it, and the elements in question will cease to function properly following the Panacea update.


This is a great thing. 

I would suggest to make a cache of the obstruction computation server or client side. A construct that have not been modified should not have a new computation.
Currently I have to go in build mode for many of my construct and wait 10 seconds to reset the obstruction calculation. And when I can I use the ECU to keep my construct loaded so the obstruction is not computed again. This is painful. 

In build mod we should have the hit box of element displayed when we try to move/place an element. Every element that collide with the new element should have his hit box highlighted.
In addition, we should be able to select an engine (like the U option) and see which element/voxel obstruct his power.

For the industry, you should standardize hit box. 
The hit box of industry element should be calculated on 0.5 voxel as it's the smallest movement we can make with the tools we have. Currently sometime you can have an element that is at 0.6 voxel and the next one that is at 0.4. One of the worth element is the transfer unit, it's very hard to align them correctly.

A bit out of subject, the construct we have right should be cache client side. So when I go in high density area (like market 6), I don't have to wait that my construct i have parked 2 minutes before load.

Edited by Leniver
Link to comment
Share on other sites

Quick question (sorry if i missed it somewhere) ... how do i find out which element(s) is / are the offending items? It's all very well saying a "Container S" or a "Transfer unit" is colliding, but please help us identify them (like we can see when an active element on a dynamic construct, engine etc, is being blocked through it showing red).  I got over 1400 small containers in this Static construct .... all i did was place these side by side, or next to industry units. No exploitation here, just maximizing space.

 

1569308079_Elementscreenshot.thumb.jpg.a42676033f7e8c5393b8366ace601579.jpg

Edited by ShutWill
Link to comment
Share on other sites

@NQ-Deckard It looks like the new stacking detection system is affecting elements that were placed without using any exploits.  It would be a huge shame if all those ship designs were rendered non-functional, just to remove the remnants of an exploit that can't even be done anymore.

 

There has to be another way.  Please rethink this.

Link to comment
Share on other sites

2 hours ago, ShutWill said:

Quick question (sorry if i missed it somewhere) ... how do i find out which element(s) is / are the offending items? It's all very well saying a "Container S" or a "Transfer unit" is colliding, but please help us identify them (like we can see when an active element on a dynamic construct, engine etc, is being blocked through it showing red).  I got over 1400 small containers in this construct .... 

 

1569308079_Elementscreenshot.thumb.jpg.a42676033f7e8c5393b8366ace601579.jpg

The trick is to open this list in build mode via Tab and construct information. And then hover your mouse over the affected elements in the list and press Tab again without moving the mouse (for easier inspection you can move the list to the side of your screen). Now you can fly around in build mode and inspect all elements and find the ones that are red. When you move your element so it's not red anymore you will see in the list if that was the only one or you need to find another one.

Edited by Vargen
Link to comment
Share on other sites

1 hour ago, Atmosph3rik said:

@NQ-Deckard It looks like the new stacking detection system is affecting elements that were placed without using any exploits.  It would be a huge shame if all those ship designs were rendered non-functional, just to remove the remnants of an exploit that can't even be done anymore.

 

There has to be another way.  Please rethink this.


This, absolutely. The change is massively overshooting it's purpose and I called it carpetbombing while a surgical strike is needed. The impact of this is far to severe for what it is trying to prevent.


 

On 10/18/2021 at 3:23 PM, eviltek2099 said:

While your in there coding this feature please provide better hitbox collision and feedback for objects while placing for both objects on the construct and the item being placed! Far too often there is some invisible area where it just will not place. The feedback could be on where the collision is taking place and a highlight part on the construct that is causing the collision. 

 

This comment from three months ago is very valid and a great example of foresight which seems to have been ignored.

 

As-is, this change will possible be the most destructive for the game as a whole and will cause a massive amount of problems and as @Atmosph3rik correctly states, the ability to use stacking has already been removed, this broadstroke change to exsiting constructs where the vast majority of identified "issues" in no  way relates to the reasons for the removal of the exploit is really a bad sign of things to come.

On top of this, it is communicated in a terrible way which is already leading to many frantically trying to fix something which is not and never was an issue in this matter. And as I really do not see how NQ can push this through unles they just choose to ignore it and decide to take it as it falls, all that effort will be for nothing so NQ will need to act and act quickly
 

 

@NQ-Deckard @NQ-Sesch .. please look at this withy urgency.. I fear you are about to throw the baby out witt hte bathwater here. 

Link to comment
Share on other sites

If this goes forward,  it will require most constructs to be modified to remain functional.  With the upcoming brake changes, constructs will have to be modified  again. Please wait to implement  this collision change until the brake change is ready. 

Link to comment
Share on other sites

38 minutes ago, CptLoRes said:

If this change goes through as is, it will also set a precedent where NQ are punishing legal builders for the actions of exploiters.

It wouldn't be the first time NQ does something like this (e.g. maneuvering tool nerf). It would just be the worst case (so far).

Link to comment
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...