TobiwanKenobi

NQ has been doing great with their recent changes to PvP and I just wanted to show @NQ-Entropyhow clean it is right now. The desync fixes made it so much better. So here's a little video of a fight I participated in last week. (Side note: have you guys ever considered an options wheel for combat actions such as engage, disengage, reload, etc? This right clicking on a marker/widget stuff is pretty awkward.)

Nice update. A lot of great changes. PvP desync seems to have been fixed. I did a brief test today with a friend and saw zero problems. Hopefully it holds up in large scale fights. If NQ has actually completely solved the problem, then PvP is going to be so much more fun for me. Thanks NQ. Build box grid hiding is the cherry on top.

The core explosion is cute and all, but I feel you guys should make the effect so large that it can be seen from far, far away - up to 2su. It would be cool if you could see someone's core explode after you kill them in pvp. As it is, no one is going to see that effect - not the aggressor, and of course not the person who got destroyed. If NQ wants to really improve the visuals of a battle, you guys need to render all weapon effects for everyone on the battlefield. It would make things so much cooler and interactive if we could see crisscrossing lasers and railguns everywhere. I'm looking forward to the SSGI/SSAO. Ship interiors have long been too dark, even with many lights placed. Hopefully it works as advertised in those infographics. It didn't seem to do much on the PTS.

Thanks for the exhaustive reply Entropy. To weigh in, I think the major changes implemented in Athena are so extensive that it's too early to start making claims about the new balance and meta. We should probably let the dust settle before advocating for any further rebalancing. That said, considering shields were so heavily nerfed, it might turn out that heavier, more expensive voxels could use a buff. If someone is willing to spend more quanta and sacrifice max speed and acceleration to achieve a very tanky ship, I would hope that it would be a viable option. At the same time I hope voxel buffs wouldn't increase effective hp/time-to-kill of armored ships to such an extent that it becomes an issue of "did I bring enough ammo/do I have enough time to actually kill this guy?" Because that's a pretty boring meta. Rather than directly buff the hp values and resistances of voxel armor, I think it would be more fun to add a different mechanic that brings value to armor. For example to add a deflection chance based on angle-of-impact to voxel slopes. In this way, armored ships could build with the design philosophy of modern tanks, which rely on both thickness and angle-of-impact to deflect the energy of shots rather than absorbing all of the force directly. A successful deflection could reduce the damage from a hit by half or something. The game could even take into account the damage type of the attack, with different voxel types being more likely to deflect different damage types. This system could lend more complexity to armored ship design, while at the same time requiring skill from pvp pilots to use their armor effectively by presenting the best face of their ship to an attacking enemy. Victory through design, knowledge, and skill rather than just having more stats than the enemy. It would even be helpful in discouraging the ugly shoe-box ship designs that we're used to seeing. It would also leave room to outplay your enemy with a smaller ship by outmaneuvering them to achieve a better attack angle. But I have no idea if such a complicated system could be implemented without causing server issues.

I've long wanted something like this, but also a step further - a docking element that snaps a construct to another construct in a specific position. Like a magnetic docking clamp. Using this, you could more easily dock to specific spots on stations, carriers, etc., without having to use the awkward maneuver tool. Or you could use it to pick up/detach cargo pods without even getting out of your pilot seat.

With Athena, NQ attempted to rebalance the engine types. There was a lot of flip-flopping of stat values between the different PTS patches. And what we arrived at is, in my opinion, still not where it should be. Partly because the changes still don't give balanced value to each engine type, but also because the current stats don't assign a unique identity to some of the types. I hope NQ will give these suggestions some consideration soon, because I feel DU launch is the last chance to make big changes to engine balance without angering a lot of players. --- I THINK THE ENGINE BONUSES SHOULD BE: (values are multipliers, applied at every tier step, stacking multiplicatively) Military - same values as current. Trade fuel efficiency for power. Thrust 1.2 Mass 1 Fuel/hour 1.44 Warmup 1 Resistances Excellent --- Maneuver - they currently lack identity. Instead of freights getting reduced mass, give that to maneuvers. Give them comparable thrust:mass as military engines. No fuel or thrust bonuses. They would have better acceleration than military engines for short burns, but military engines would win out for long-duration burns. This would make maneuver valuable for close range fights and races, but not as good as military engines for long accelerations. Maneuver loses the advantage as soon as the military engine warms up. The mass reduction would also allow slightly higher max speeds, which would be good for space racing. Thrust 1 Mass 0.85 Fuel/hour 1 Warmup 0.5 Resistances Poor --- Freight - really drive in the 'for haulers' message. Give them thrust bonuses AND great fuel efficiency. This makes them a highly desirable engine. But give them penalties which discourage their use in pvp. Keep the very high warmup penalties, but also give them a significant mass penalty. Haulers don't care much about the extra mass and warmup. But pvpers will be very limited by it. Thrust 1.15 Mass 1.15 Fuel/hour 0.75 Warmup 1.75 Resistances Average --- Safe - the long-standing worst engine in DU! I have an idea to give it value and identity(not steal maneuver's identity like it currently has). Instead of a bonuses and penalties approach, just give it all bonuses, but small ones. A jack-of-all-trades choice; the safe choice. Thrust 1.05 Mass 0.95 Fuel/hour 0.9 Warmup 0.9 Resistances Good

Exactly. Can't warp stop on someone if you can't warp past them.

Future space magic. Also, gathering of trace particles and nano-engineering them down to their atomic constituents, then reassembling into different elements. It's a space magic thing, you wouldn't understand.

With today's Athena patch, I finally got to test a small core cannon corvette I've been working on in prep for the changes to max speed and adjustor maneuverability. It worked great! The L-core meta definitely seems to have been disrupted. But now that some people will be trying to fight at very close ranges, it's vital that positional desync be addressed. When your target is teleporting around, it's impossible to try to stay in close ranges. If this constant desync isn't improved before launch, I fear many new players will see the jankiness of pvp and just leave the game. Here's an example video of how difficult it can be to fight at ranges of about 50km. NQ, I hope you can find a solution. You're on to something with the new pvp balance. It feels fun. This fight was conducted on April 26 at 22:13 to 22:27 UTC, at the edge of the safe zone in the vicinity of coords ::pos{0,0,-2614807.8509,610839.4670,-2685631.4847} if NQ wants to check server logs or whatever you might need to identify issues.

Ok, Aegis is cool. The first space market. I love it. But what if there was a XL market 'ship' (it would of course have to be a space core made to look like a ship) that 'warped' to a different and random planet once a week during maintenance? Players could bring their ore and elements up to this market and list them for sale. Eventually, once a month or so, the ship returns to Aegis for a week and players are afforded the opportunity to buy outer planet ore without having to travel for it. Vice versa, as the ship travels from Aegis to outer planets, players operating on those outer planets have a chance to buy goods without having to transport them from the safe zone. This provides a low-risk but very slow and delayed way of transporting resources around the system. With the randomness of the ship market's destinations, players wouldn't be able to easily exploit it to avoid transporting goods entirely. Moreover, goods stored and listed on this market could be taxed, once per week, so that players can't just use it as a permanent mobile storage of material. Just a random idea I had. There may be more problems with it, but I thought it could be a fun thing to have in DU.

Love it. We've needed this for so long. This is going to make space travel much more enjoyable. One map feature that I want is to be able to see the positions of ships that you have have a transponder match with. This would help a lot with pvp fleet organization - the ability to visualize the disposition of your allies. Positions for contacts that are online would also be nice.

I'll keep my opinions about a wipe brief: I don't like the idea of a full wipe. I've put thousands of hours into building my ship-selling operation. But I understand how a wipe could help. I'm resigned to the inevitability of it. I can deal with losing my money and my ship factory. HOWEVER, don't take our talent points! We paid for those. They aren't resources. Taking them is basically deleting our character/account. Whatever advantage they provide, we're owed it. If talent points go, I'll go. And I think removing schematics would be a bad idea. Every player could manufacture everything they need again, and the market would be pointless.

Good info, thanks for the devblog. But how exactly do the stasis weapons work? Do they decrease the max speed of the target by a flat amount? Or do they reduce engine/retro/adjustor thrust? Or do they increase the the effective mass of the ship, sort of like ships currently behave when approaching max speed? Does this affect the target's adjustor maneuverability? EDIT: Also, could you give us the formula for the ship speed changes, so we can get some expectations of how fast ships might be?

@NQ-Deckard I have one more suggestion for the vertex editor. It's a difficult one but would be very helpful: I would like the ability to move multiple vertices at once, all linked. To be able to shift-select multiple vertices and move them in sync. I understand this would present problems with the displayed coordinates of the vertex and cursor - you can't display coords for multiple vertices of course.

Oh wow. I never would have known. That should do nicely. Thanks very much for your responses to those four issues.

But it's not practical at all when you're trying to modify a voxel normally, which is the typical situation. Copy paste is what we use when we want to modify a bunch of voxels in succession. Imagine if every time you tried to copy a voxel, it instead copied the previous voxel that you pasted unless you specifically told it not to. That would be awkward. I clicked on the vertex to edit that vertex, not to edit the last vertex I edited.

As an experienced voxelmancer, I have problems with a few aspects of the VPT. These issues make it awkward and unintutive to use. --- ISSUE #1: Strange cursor behavior. As stated in the VPT devblog: "-[Press] The End key to send your cursor to the last confirmed coordinates. (This also happens by default when you change vertices.)" Please change this! Or at least give us an option to change the normal setting. The cursor should not default to the last confirmed coordinates, it should default to the current vertex coordinates. The use-cases for a last confirmed start position are few - players usually want to start at the current vertex coords. Having to press 'Home' every time I select a vertex is awkward. --- ISSUE #2: Difficulty in selecting vertices that are distant from their natural position(0,0,0). Situation: I have a thin voxel plate that is 1/14vx thick. (The top of voxel is squished down to 1/14vx above the bottom) I want to select one of the top vertices, but I can't. The tool only allows me to select the bottom vertex. I am forced to place another voxel above the thin plate that stretches down to meet the plate and gives me something to click on where the vertex I want to select is. Solution: Give us an alternate mode for selecting vertices that selects actual voxel vertices rather than selecting a vertex origin point. Or better yet, make this the default method. (This has always been an issue with selecting voxels with the Select Voxel Tool; one that we get around by pasting a normal voxel in the spot that we want to select, selecting the spot, then undoing. I hope we can find a solution to these problems that doesn't involve workarounds by the player.) --- ISSUE #3: Difficultly in properly viewing the vertex you're editing, especially if it's down at your feet. This one is self-explanatory. I can't really see what I'm doing when the vertex is down at my feet or otherwise far from my POV. Of course we have the vertex coordinates to give us information on the vertex, but that leaves visualzation difficult. I don't know how we could go about improving this besides allowing players to phase through voxels and elements in build mode, which I know is off-limits. Perhaps a player-view zoom feature could be helpful - usable with a hotkey? Binoculars built into your nano-suit helmet. --- ISSUE #4: My avatar arm and tool is, as always, in the way. Can my avatar be an amputee?

It appears to me that the VPT has some problems either with a bug or with UX design in general. When I click on a vertex the selected vertex position seems to default to a position far from where it was before you selected it. This forces the user to make more changes than they should have to when repositioning a vertex. When you select a vertex with the VPT, the position of the VPT tool vertex representation should be where it was before you selected it.

I think this compromise works best for everyone. Locking core counts behind a long training period will incentivize careful management of core counts while also allowing the people who truly need those core counts to attain them.

Good. I was really hoping I was misreading the post. But what does this mean? "And, in the example of these four cubes, if we were to go to a value above 84, it would result in an ill-formed shape because the blue shape would have a negative volume. This would probably create visual artifacts, and we may prevent this situation in the future." And do you have any plans to add edge, face, and full voxel moving to the VPT? It would be nice to move multiple vertices at once. Appreciate your detailed response regarding the new encoding. My 1/8th slopes were all a lie...

@NQ-Ligo Will Panacea be going to the PTS? I feel such major changes need a bit of testing first. I also hope that the team is considering adding edge, face, and full-voxel dragging to the VPT in the future. Dragging individual vertices is nice, but being able to drag multiple at the same time would really speed up some processes.

"And, in the example of these four cubes, if we were to go to a value above 84, it would result in an ill-formed shape because the blue shape would have a negative volume. This would probably create visual artifacts, and we may prevent this situation in the future." They're saying that if you go beyond one voxel away from vertex origin, it can overlap the rendered faces of the resulting voxels, leading to an ugly inside-out mess. Which is bad of course, but easily dealt with and not worth limiting our voxel positions in such a hugely destructive way.

A ship that I've built, which isn't even really pushing the limits of detail, has a few sections that are beyond 100%. https://imgur.com/a/4Klkmas I predict that it will be a significant limiting concern once we have the VPT. I definitely think I'll have problems with it. Why should we be limited in our creative projects for the sake of a few edge cases that have extreme voxel complexity? IMO they either need to raise the complexity limit or get rid of it. If NQ thinks it's absolutely necessary, I sure would like to hear the technical reasoning. This is a big deal for a detail-oriented ship builder.

Yes - it is absolutely essential that we be allowed to extended vertices 1.5 voxel away from zeroed. If they limit us to 1 voxel in the future, it will break so many amazing builds and make many feats of voxelmancy impossible. And for what? Why would we need to limit this?

I like the changes overall. I do have a question for NQ: What are your plans for space construct taxation?