Jump to content

TobiwanKenobi

Member
  • Posts

    26
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

TobiwanKenobi's Achievements

  1. 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.
  2. 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.
  3. Any more info about these speed changes? I hadn't heard of this
  4. 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.
  5. Awesome. Y'all take your time - this is only an inconvenience. Enjoy your break. 🙂
  6. 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.
  7. 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.
  8. 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...
  9. 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...
  10. 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.
  11. 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.
  12. 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.
  13. Shouldn't be possible if they don't have docking permissions.
  14. 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.
×
×
  • Create New...