Search the Community
Showing results for tags 'exploit'.
Large DU groups use these three items below to help our member base understand what is or is not a exploit. While making the case by case determination is a lot more complex generally if your doing one of these things you are using a exploit and you should not. There is always interesting debate about what is a exploit or not along with how NQ should handle exploits. As a player community we tried to help NQ with this by creating some high level if you do these you most likely are using a exploit. With today's post reminding us all of this we may have to add one about missions soon. Transporting matter beyond the maximum linked container range in a near instant fashion. Moving third party constructs without the RDMS being provided to do so. Creating items/elements/parts in a way that does not consume the appropriate amount of materials.
Currently, the skill points are generated in background with the queue, which leads people to having alt accounts trained to specialize in one thing in background, which is not optimal and ends up being P2W, as this clearly gives them advantage over players with only one account, specially players starting out. The proposal here is to complement the current system with skill-specific points, which are earned by doing these activities - being active in the game. This could apply to all skills or, at least, the most basic ones, such as Mining and Piloting. Firstly, let's do some math. I'll take as reference the skill "Advanced Mining". In terms of skill points, each level costs, respectively: 2400, 12000, 60000, 300000 and 1500000 points, giving a total of 1874400 points to complete all 5 levels. With a full queue, we currently get 90 skill points per minute, which means it would take around 20827 minutes to complete the queue, which translates to 347 hours or 14.5 days. All of this is passive, so one owning multiple accounts would be able to queue many large skill trees to specialize in these same 15 days, which for a normal account could take 15, 30, 45 or even 60 days to complete. Not really fair, right? Now, with the proposal, let's say for every 25L of ore extracted, one would get 1 skill point. With a scoop size of 250L, one would get 10 skill points per scoop while actively mining. With an average time of 10 seconds to get 4 scoops (1000L, or 40 skill points), one would get an equivalent rate of 240 skill points per minute by actively mining, which would take the queue time from 14.5 days to around 5.4 days of actively mining, not considering the points still being generated in background, which would bump this to 330 points per minute and lower the queue time to just under 4 days, but the catch is: the player would need to be actively mining to achieve that. The same could be applied for Piloting skills, with some adjustments to consider whether we're flying atmo or space. Currently, the maximum speeds are around 1000km/h in atmo and 30000km/h (150su/h) in space, so let's say we want to match the same 240 points rate of mining, then one would need to fly either 16.5km in atmo or 500km (2.5su) in space, at full speed, to match these rates. Anything slower would still be accounted for, but since your speed is slower and the points are earned per distance, you would make less points flying slower, the only thing not being accounted for is warps, as that would be way too easy In the end, if this works, the passive rate could even be lowered, as anyone being actually active would still be earning their points and the passive generation would be more towards when the player is offline (like doing IRL stuff such as sleeping) instead of being a complete benefit to players with many accounts farming points in background Hope this helps somehow!
Due to numerous reports of this happening, including pictures, lets talk about end of warp obstacles and ramming in general. Here is an example of a net placed exactly in front of a warp exit. You have about 10-15 seconds to change direction right after end of warp, but most people won't pay attention and ram into whatever is in front of them. This has been a thing for a while now, but we now have some reports of ship destruction due to warp destination constructs being purposefully placed in the way. One way to get around it is of course to pay attention and maneuver the ship immediately after warp destination is reached. However, there is a lot of discussion to be had about warp obstruction and ramming in general. For example: 1) disabling collisions between cores: this has already been done with trees so I imagine it can be disabled for static / dynamic cores, probably will increase server performance too, but also an effective way of getting rid of warp traps. 2) disable damage on collision with constructs: an alternative of the above, except collision will cause velocity changes as expected between collisions. We don't have bumper car physics, could be a bit strange, but this also gets rid of warp traps. My personal favorite and very biased option: 3) reverse ramming logic (THE RIGHT LOGIC): it's really strange to consider that an L core going at 30,000km/h can be obliterated by a stationary xs core. It just doesn't make any sense from a logic perspective, although the reason for this implementation probably has roots in server performance considerations. I think collision damage should be shared between constructs and distributed according to mass and voxel logic. Added benefits are: COMPLETELY LAG FREE MARKETS... because naturally people will start ramming, hence a necessity for garages / safe parking facilities, opportunities for business, etc. I would go so far as to say that static cores should be rammable as well. This has huge ramifications for space stations... there will be a need for space mine fields or wreckage around stations to prevent people from completely destroying stations with ramming dynamic cores. Space stations will need engagement rules such as: if dynamic construct is going faster than X amount inside a certain radius around space station, fire all weapons at dynamic core. There are all sorts of interesting ramifications for this gameplay. There is something important here I think: it is not ok to simply add a rule to the EULA saying warp traps are illegal. This is a sandbox, emergent gameplay will always happen, and a bunch of players can give a hell of beans about what the rules are. It's in poor taste when a game cannot / will not implement systems to prevent certain actions from happening but simply adds a "RULE" of conduct. In some cases it is certainly appropriate (abuse, discrimination, etc) but in this case, this is emergent gameplay and adding a RULE will not solve this issue. In this situation NQ actually has an opportunity to capitalize on the situation and create game mechanics to either solve this issue or enable ramming AND add mechanics in order to counter ramming. On the other hand, warp traps such as these can be cancerous. This is a tactic used extensively in Eve, see here: Do you think warp traps are an acceptable emergent gameplay mechanic? What are your issues with it? What can be done to solve it? Again, to reiterate, simply adding a rule of conduct doesn't work here in my opinion. NQ should really capitalize on this opportunity... I think they failed in the district 15 drama, they could have done some epic stuff there... problems can be turned into opportunities, lets contribute to the discussion and find opportunities Edit: After writing this post, I have received confirmation that players are "netted" both when: 1) player finishes warp, comes to a complete stop, then accelerates/or planet gravity pulls the player, and they end up in a strategically placed net 2) player finishes warp and gets damaged in net BEFORE coming to a complete stop from the warp