TobiwanKenobi

Agreed. This will effectively allow dedicated miners to run more MUs than before. More ore. They can't rob players by reducing the ore per tile, so they need to reduce charge regeneration rate.

It's a huge deal. Yeah it's fine for the average player with a few ships. They might be able to move a few elements around and fix the overlaps if it's a loosely built ship. But what about ship builders? I've sold about 700 ships. All of them were built tight like a tiger, but LEGIT. Now I have to go around and redeploy hundreds of ships for buyers so that they can use the ship they bought? Not cool. Literally 75%+ of the ships in the game will be non-functional if this system goes through as-is. The glowing element wireframe needs to be a grace area. Only clear overlaps of the actual visual model should trigger it. In short, the detection zone needs to be a little inside the visual model, so that a tiny corner of a wing poking an engine doesn't make both of them not work. This will make the current problem go away, but also ruin all the blatantly stacked ships out there, with 8 engines in the same spot.

I'm excited to hear the vertex tool is coming. However I want to ask for a few essential features to it. The tool will be difficult to use without these. We need: 1. Options for edge, face, and full voxel dragging within the boundaries of a voxel's allowed area. We need to be able to manipulate more than one vertex at a time. 2. Options for vertex grid snapping at 1/8th voxel step, 1/16th, 1/32nd, and 1/86th(this is the maximum, right?). It will be difficult to position vertices without this. I expect these features are already planned and/or implemented. I just wanted to make sure they were considered. Thank you very much for giving us the tools we need to more easily make amazing creations.

Any more info about these speed changes? I hadn't heard of this

The calibration minigame could be fun. But right now it's tedious and frustrating. I want to suggest a few changes that I feel could make calibrating MUs more fun. 1. Please speed up the animations or allow us to skip them with left click. The animations are cool, but after the hundredth time seeing them we're all just clicking on the spot where we know the button will appear while we wait for them to end. By making the minigame faster paced it will be less tedious. 2. Make hotspots more rare. Instead of searching for the hotspot on the cloud map, players should be just searching for dense clouds. A hotspot should be a lucky find, not guaranteed on every calibration, and not necessary for optimal results. You should be able to achieve your full calibration potential from just a dense cloud. A hotspot should give other bonuses, such as boosting the mining rate of the unit by 20% until the 2 day grace period expires, or spawning a sizeable surface deposit to harvest. This gives a nice reward for players, something out of the ordinary to give them that dopamine hit. 3. Give us other neat things to find as we scan, such as the gems mentioned in the roadmap, Or larger surface deposits to unearth. We can have the option of expending battery to unearth them and risk failing to find a good final calibration spot. 4. I think most players would greatly appreciate a longer calibration grace period or a slower calibration decay. Right now we feel a bit pressured to go do what we consider tedious work every couple days. If calibration was only necessary once a week, we wouldn't mind it so much. I understand that this would imbalance the ore supply, since players would be able to run more miners, so of course you might have to change the calibration charge supply rate to match. 5. Make the calibration reward rocks larger - like just one big rock rather than a bunch of 100L ones. Retrieving them is boring, it would be less so if it took less time. Or better yet, just deposit them directly into the linked container. Right now, calibration feels like a job. Hopefully NQ can inject some more fun into it, and diminish the tedium.

Awesome. Y'all take your time - this is only an inconvenience. Enjoy your break. ?

I gotta 100% disagree - it will always be a limitation on creativity. Please visit my current build, a WIP but almost finished Mcore. You can find it by searching for "Tobis Mcore WIP" at a surrogate VR pod. Screenshot at bottom of post. That ship is an example of what I consider to be a necessary amount of detail to achieve a good-looking and immersive space ship. To take away those details would diminish the build a lot. Maybe some players are satisfied by simpler ships, but most want highly-detailed ships like they've seen in sci-fi, with lots of greebles and shaping. Sure, a detailed ship is somewhat more resource intensive for a player's PC to render, but not in any meaningful amount as far as I can tell. I get the same fps whether the voxels are there or if I delete them all. Rather than limiting players, I think NQ should focus on making the rendering of voxels more efficient and optimized. To place limitations on creativity in a game that is largely about creating would just be at counter-purpose to having fun. If they want to improve performance they should look into simplifying their element models and physics calculations. Those are the real performance hog.

I've been noticing the 100% obstruction bug occurring a lot more often after the recent changes to obstruction in Beta 1 r0.27.11 - "• Reduced engine obstruction fluctuations." Whatever you guys changed made this particular problem worse. My issue is that after entering build mode, these obstructions clear up. Why can't they already be clear? We've always had issues with engines being 100% obstructed when you first start up a ship after logging in. The way players fix it is by entering build mode once before using the ship, which appears to force DU to recalculate obstruction. But that's suboptimal as you can often forget and not notice that a bunch of elements are 100% obstructed until you're airborne. It would be nice if the game would calculate obstruction before flight. My suggestion is that obstruction be calculated once, VERY THOROUGLY, with many rays when a player exits build mode. Then this obstruction data can be recalled every time the ship is used. This way the obstruction doesn't need to be recalculated in flight or every time you visit a construct. It's just loaded from a previous calculation. I don't see a problem people cheesing obstruction with this method since it would calculate it every time anyone exits build mode. Any changes made would be accounted for. Examples: ^These large adjustors become completely unobstructed after you enter build mode for about 10 seconds. So why are they 100% obstructed if I don't enter build mode? Moreover, why is the medium space engine there obstructed? There's nothing in the way forward. The cone is just hitting the sides of the ship. Why must the obstruction cone/cylinder be so wide? ^Notice in the second screen shot that only one of the four forward adjustors is firing when I try to yaw to the right. The other three are 100% obstructed because I didn't enter build mode before taking off. Thank you for your efforts to improve and perfect the best ship building game on the market.

I have to assume the complexity calculation is broken. Surely they didn't intend for us to not be able to do extremely simple stuff. I'll take the discussion a step further though and say, PLEASE DO NOT IMPLEMENT A VOXEL COMPLEXITY LIMITATION. Are you crazy? One of the few draws of DU is the ability for to make cool space ships and structures, with neat details that make it feel realistic despite the relative simplicity when compared with something like Star Citizen ships. You can't do this guys. The creatives will leave, myself included, if they can't build cool stuff. Then your civilization builder mmo will be populated 100% by box ships. Not very immersive...

Which is both great and sad. End of an era. I've used your tool so much. Really grateful for it. Thanks for making it. Of course who knows how long it will be until NQ puts the new tool out...

I think this is a good implementation of shields. Not too complex, but gives the players more things to manage in combat. I'm not a big fan of this core combat stress stuff, especially how it scales with diminishing returns past a certain threshold. What if I want to make a super heavily armored dreadnaught? Without having tested the mechanic I can't opine comprehensively, but I hope NQ is taking into consideration the playerbase's desire to fulfill certain sci-fi tropes. We want all kinds of ships to be effective; fighters, corvettes, lightweight frigates and destroyers, battlecruisers, battleships, dreadnaughts, carriers, etc. Please keep that in mind. A PVP meta that trends toward one single type of ship will be boring.

The purpose of a decorative element is to give players access to visual detail that the voxel system can't provide due to its limitations. But players often avoid using most decorative elements when designing a ship because they must be repaired after a crash. This is a pain in the ass. Solution: Please consider making decorative elements have no hp. They should be entirely a visual choice. They shouldn't interact with crash damage, burn damage, or pvp gunfire. Note, when I say decorative element, I mean any element that doesn't contribute to the capability of the ship; furniture, lights, pipes and cables, barriers, etc. Maybe even electronic elements(logic, switches). These elements add no forces or combat potential to a vessel, so making making them not interact with damage mechanics won't disrupt the balance of DU. An alternative solution would be to rework ship repair mechanics to be less tedious. Repairing many tiny elements shouldn't be a pain in the ass.

Maybe in outer space, but in orbit around a planet I don't think jetpack will work. I need to find some more time to mess with that.

I'll do so. Just gotta find a test buddy.

Shouldn't be possible if they don't have docking permissions.

New problems: 1. I undocked from a moving parent and ended up at zero kmh. Parent left me behind instantly. Don't know why I didn't inherit the parent's velocity. MIght be because I logged off and came back while flying? 2. After docking with a moving parent, I often teleport when exiting seat - sometimes ending up inside the parent ship, sometimes getting thrown off. 3. When trying to dock with an orbiting parent, after requesting dock, my relative velocity suddenly changes and I get pushed away from the parent. I tried to dock with an orbiting parent about ten times, each time approaching the deck at a gentle speed, only to get pushed away, and not by my vertical boosters. A nice additional feature to have would be the ability to parent children constructs while piloting an intended parent construct. Using this, we could pick up container packs or drop them.

Brief story: On the PTS, I took off in my shuttle, landed it on my Mcore, right clicked on the Mcore while still in my pilots seat, and clicked dock to construct. Great right? No silly maneuver tool involved. You get out of the seat and it's docked tight. But here's the amazing part. I left Alioth in the Mcore, shuttle docked. Out in space, I entered the pilots seat of my shuttle while the Mcore was still moving at 5000kmh. I fully expected for both ships to explode. They didn't. The shuttle was teleported just outside the Mcore's docking sphere, behind it, our speeds matched, both ships still moving. I was able to maneuver around, accelerate, brake, all in the vicinity of the Mcore, with both ships traveling at 5000kmh, just as you would expect from real life physics. There was no jitter or teleporting. So I decided to try to re-dock to the Mcore again, fully expecting explosions. As I approached the ship, the docking sphere lit up yellow, indicating that I was not parented. Right click on Mcore, click dock, now parented. I landed on the deck, got out of seat, and the shuttle was docked. All while traveling at 5000kmh. I also undocked and redocked while ORBITING ALIOTH. There was only a slight bit of jitter when I landed back on the ship. Screenshot of me flying formation with my unattended Mcore while orbiting Alioth. NQ has done it. This all works way better than I anticipated. Carriers are fully viable now. PROBLEMS: The only problem I've experienced so far is the difficulty of getting into a docked child construct. If you jump, you might fly off the ship. If you enter build mode on the child, you might teleport off the ship. Best way I've found so far is to enter build mode on the parent and fly into the child, entering the pilot's seat while in still in build mode. This needs to be easier.

So from where does this deviance originate? Was it a mistake in the creation of the original NRD voxel cube? Is it some strange bug in the game? Sorry I didn't show this very well. The second image is just a 'front' view of the bar displayed on the screen in the first image. The gray voxel there is the end of the bar. The red voxel is the end of another bar, offset in a different way so that they meet. The blue is a normal voxel. I was just visually comparing the end of the bar with the variance to another bar that had no variance so that you could better see the issue.

Hey, thanks for this wonderful tool! It has revitalized my interest in building. I'm now able to produce almost whatever I want. Such as these badass catwalks/floor grates. However, I think I've run into a couple errors in the voxel stack. While trying to produce those catwalks, I discovered that some of my vertices weren't quite in the right place. For example, when trying to make this bar of the catwalk, two of the vertices appear to be at different heights. It doesn't seem to be a visual artifact, as the difference persists when I exit build mode. I'm rather clueless about how to go about repairing these apparent errors, so I thought I would bring it to your attention. I'm not sure which voxels are non-standard. Thanks again for your amazing work. I hope you have some insight into this weirdness.

Glass voxels are listed on the Trello as a feature that should be implemented during beta. https://trello.com/c/18BRK0UK