Jump to content

SGCamera_Beta

Member
  • Posts

    78
  • Joined

  • Last visited

Everything posted by SGCamera_Beta

  1. This is a planned feature via buying DAC as an ingame item. It is planned to work almost identically to Eve's PLEX system. Its just not in the game yet. More its a game for people without kids. You can still work a full-time job and hit a 6 hr/day average if you play the game as your primary hobby.
  2. The voxel meta is driven by the fact that every voxel type has the same HP per kg of material, which makes the densest materials with the most resists the best for armor. Which is garbage because the value of a lot of materials is that they are stronger for less mass (ie titanium).
  3. This is the number one issue actually. In general I agree that there needs to be ways to create more detail (texture painter when?), but large amounts of elements have serious performance issues. Even non-functional elements (ie, decorations) produce CPU load just by existing; so if you encourage people to use sub-voxel sized elements to decorate, they WILL end up with a 10 billion rivet warship, and they WILL complain about having terrible performance. Also, having to repair a whole bunch of miniature elements when you crash would be awful.
  4. If it was implemented as an element, then you could just turn the element off when you don't want it to operate. I had this idea because of that specific gameplay. The number one problem is that there is no way to detect if someone is logged off on your construct, and even if you did know they were there you have no way to remove them. My suggestion is the simplest implementation to solve both of those problems, however I do agree it potentially detracts from emergent gameplay. If another solution resolved both problems such that as the construct owner if I could spend some time working to find and remove players from my construct, then I would be all for it. Personally the most annoying thing is that characters totally disappearing from the world is very unrealistic, and the fact that people can use it to their advantage and there is no counter-play makes for a frustrating game mechanic.
  5. The XL and expanded XL containers are not efficient from a volume, mass, or cost standpoint. Where they are useful however is that due to the linking limitations, they produce the largest volume 10-stack of containers possible. Basically, they are only useful for simplifying warehouses.
  6. I guess its not popular with NQ since they deleted the upvote suggestion. ¯\_(ツ)_/¯
  7. The simple answer to the problem is that its a game and the scaling is different from real life. Therefore people's expectations are too high. The better answer is that we don't have large enough wing elements in order to support heavy-lift aircraft. We really need Large and XL wing elements. Thrust doesn't define the carry capacity of an aircraft, lift from it's airfoils does. Yes, you do need thrust to move forward and counteract the drag from the airfoils, but thrust does not directly cause lift.
  8. I added this to the Upvote site, but I will also post it here for discussion: Players logging off on other people's constructs is a problem, for numerous reasons. Players that log off on someone else's construct should be "kicked off" the construct. When a character logs out of the game on a construct that they do not have permissions for (defined either by a construct-wide RDMS right similar to Board Construct, or by applying Use rights on a "Security System" element), their character should be moved outside the build area of the construct and their physics should be de-parented. There should be a way for the player to know their right status on a construct before logging off to avoid confusion. When not in the safe zone, the security system could become lethal instead.
  9. With the talent refund and the bonus 1 million points, there are a lot of people sitting on large amounts of talent points. I think if it was the only way to access schematics, those people would spend those points to get access immediately. Overall though, the idea of using talent points to buy schematics is really just a roundabout way of locking every recipe behind a skill. I don't think its a terrible solution, as it would encourage specialization even more, but I can understand why a lot of people wouldn't like it.
  10. DAC prices will be determined based on how much quanta people are willing to spend to buy one, and how little people are willing to get for their money when selling one. NQ shouldn't have anything to do with DAC prices. Also, the Kickstarter/Supporter packs have so many DAC's in them, that I expect the in-game DAC market to be garbage for the first 6 months to a year after release.
  11. I am 100% in favor of letting scripting do nice things, whether its hard to write or not. I was simply pointing out that letting scripts access things that would allow PvP autopilots is a bad idea. There is a reason NASA uses MechJeb - in a full 6 DoF environment, computers are better than humans. They can take all the variables and compute an optimal course and orientation to maximize weapon time on target, minimize enemy hit chance, or even just have a perfect intercept. That may be realistic, but it doesn't make for a fun game. The issue isn't that PvP mechanics are too simple, its that Newtonian Physics is a solved problem. You would be surprised at how much you can do in 1000 lines of Lua script. I agree that the outcome of the engagement should typically be decided ahead of time - logistics, how much gun your side brought, how good your ships are, etc. But in an otherwise equal 1v1 engagement, the ship with the PvP autopilot will win 9 times out of 10. And since the script would increase the combat effectiveness of the ship so much, allowing them basically makes them mandatory.
  12. Oh...right. I was all excited about the talent reset but had forgotten how terrible buying them back is...
  13. While I agree that it seems like the ideal meta and its not the optimal solution, I think it is better than what we had, as there are some drawbacks to it. Large Cores (the element) are very big and very heavy, which will reduce the usable volume and the mass budget of a "small L ship". Also, they are VERY expensive now, and if it gets destroyed you have to entirely replace it.
  14. I'd expect something along the lines of "If you haven't been online in 60 days, everything you own gets compacted into your inventory and you lose all your territory units. Organizations with no members online in 60 days will have everything compacted into the super-legate's inventory. Anything in a PvP area will not be compacted, and will be left for other players to find." Personally, I would prefer to see everything become abandoned and salvageable instead of compacted, but I think compacting things in safe zones is a reasonable compromise.
  15. I think having a "global market" would detract from player choice. If there is only one market, then trading becomes a much less interesting thing. Not to mention that hauling would cease to be a job. There is also the side effect of it being easier to manipulate for large groups, and the general increase in prices from being able to monopolize all points of sale. The lag of markets mostly is due to the number of constructs there... many of which are containers, junk/abandoned, damaged and smoking (bonus lag), or all of the above. I think having player run markets would actually FIX some of the performance issues. It will be a service the market host would provide: creating a low-lag environment by towing constructs - something that NQ generally has refused to do, thus the current market lag situation. Global markets would drive DU towards being a theme-park MMO, and that's not the direction the game should go.
  16. As of right now, you can't - you have to pickup your TU and then have a legate of your org place a new TU. It is planned to allow the trading of territories, it just isn't implemented yet.
  17. Or even a spawn delay on a per-player basis for respawning on res nodes that are on ships that are in PvP. So when you die, you get a message: "Your current res node is under attack. Would you like to wait XXX seconds or would you like to spawn at your next immediately available node?"
  18. One of their interviews indicated that they are only "approving" things on the site that they would consider doing. Afaik, third person perspective was already ruled out years ago.
  19. Straw man aside, there is a huge difference between building ships and writing programs. Pretty much anyone can build a decent ship if they work at it, and learning how is a core part of the game's learning curve. People expect building things to be part of a sandbox game, and in general people find that building things they can see and use and show off is fun. Knowing how to program is a much rarer skill and frankly isn't fun to most people; NQ has said that they do NOT want to make programming a mandatory thing, since it reduces the interested players for an already niche game.
  20. I don't see them changing that decision, because being able to get the position of enemy ships would allow you to write combat autopilots that would be vastly superior to player pilots. NQ is trying very hard to make the game not be dependent on lua, so I doubt they will add a feature that makes it mandatory in order to be competitive.
  21. I could live with good looking borg cubes. But that's not where the meta is at, unfortunately. That is definitely a good strategy for closing the gap in some situations. Personally I think its a little backwards that large ships need close the gap to smaller ships. Though to discuss that: once you have determined that you can't escape an aggressor who has a range advantage over you, you should accelerate towards them to minimize their range advantage. It also helps, because to then stay in range of you they need to turn to use their engines, thus making it so they can't fire railguns at you. Its most effective when using retros (space brakes), but unfortunately that only works if your pursuer is directly behind you and on the same vector. Overall, if they have both a range and acceleration advantage over you, you are screwed. The question is only how screwed. Realistically the answer is "very", but you should still get at least some chance to fight back. @Myrias I am a big fan of Children of a Dead Earth - such an amazing true-physics space combat game. I think lot of the stuff you mentioned would be great for a simulator, but doesn't make a lot of sense for an online multiplayer game due to complexity and computational loading.
  22. That would be the ideal situation, but I was trying to keep them from having to recalculate things on the fly. Particularly since people have scripts that can toggle thrust pretty rapidly. A vector change would be an acceleration, which should be the primary cause of accuracy reduction. Still, someone with a high transversal velocity relative to you would force your turrets to rotate to hit them, and there is a limit to how fast a turret can do that. If they are flying directly towards or away from you, hitting them should be relatively easy.
  23. We can debate all day about if pirates flying XS cube ships with L Railguns have any class or not (spoiler: they don't, cubes are lame), but I think we can all agree that the current iteration of PvP has plenty of problems. Current Problems: Lock-on range is only determined by core size Some weapons have ranges that are greater than the minimum Lock-on range Weapons have no/minimal accuracy falloff with increasing range Weapons have no/minimal accuracy loss for high transversal velocities and accelerations My Proposed Solutions: 1: Lock on range needs to be based on different parameters. The current meta of L guns on XS ships is problematic, since S and M ships (even if they also have L guns) are outranged and don't even get an opportunity to fight back. I propose splitting lock-on into 4 separate "Radar" units: Radar - lock-on range based on sum of ship's 3 cross-sections (already calculated, and doing it as a sum encourages non-cube ships) Gravimetric - lock-on range based on ship's mass (already calculated, makes heavy ships easier to detect whether its cargo or armor) Thermal - lock-on range based on magnitude of the ship's maximum thrust in newtons (already calculated, makes ships with lots of engines easier to detect) Electromagnetic - lock-on range based on power capacity and shields (obviously only useful when/if those systems are added) Balancing the ranges from the 4 methods will take some trial and error, but overall it would make detection more "fair" by adding more control handles for NQ to balance. 2+3: Weapons being able to shoot far is very reasonable, and is really a necessity for the BVR combat caused by the velocities of ships in space. With the lock-on changes above, #2 becomes less of a problem. However, just because your weapon CAN reach that far, doesn't mean it should have great accuracy at doing so. Weapons should be able to fire when they are locked on, regardless of range (maybe missiles would be an exception to this), but should have accuracy falloff due to that range. Additionally, lasers should have damage falloff with range. I'd like to see the weapons rebalanced accordingly: Railguns - high accuracy, low rof, moderate damage Cannons - moderate accuracy, moderate rof, moderate damage Lasers - high accuracy, high rof, damage falloff at range (low damage at long range, moderate damage at short range) Missiles - moderate accuracy, low rof, hard cap range limited (high damage at short range) 4: Unless you are exactly in the target's flight path, you shouldn't be able to hit someone blazing past at 30k kph, aka "0.99c". Accounting for transversal velocity forces pursuers to match velocities in order to have high hit chances, not just reduce the distance. This means that weapons need a "tracking speed" property, so that some are better than others. While tracking speed should vary by weapon type, it should primarily vary by weapon size so that Large weapons have low accuracy at high transversal velocities. This solves the "the ultimate ship is the biggest ship covered in the most armor and cannons" problem, by making it hard for large weapons to target faster moving ships. While that can be overcome by adding a ton of engines to make "the ultimate ship" accelerate like a fighter, it will also drastically increase their Thermal signature thus allowing smaller ships to plink them to death from out of range. Additionally, if transversal acceleration and facing cross section were taken into account, small and quick ships like fighters would be harder to hit. Now some of you are going to say "but SGCam, that sounds a lot like the combat mechanics in EVE." And you are right, it does. But as with many things in DU that take inspiration from EVE, Lock+Fire combat is one of them. That system overall works pretty well for EVE, and the more granular and customizable nature of DU means that it can be even more effective here. I'm also looking forward to warp interdiction and tackling, but that would be a whole other post. Overall, the more complex the mechanics, the less all-around advantage "meta" builds have. They may be powerful in certain situations, and that's ok - as long as they are weaker elsewhere due to their optimization. Adding tradeoffs opens up the design space for more varied and interesting PvP, and will hopefully prevent us from playing "Cube Gank Squad 2020" going forward.
  24. Eve always erred on the side of too many faucets, and that problem got notably worse with the move to F2P. Turns out that bots don't really use sinks.
  25. If the camera view replaces your regular view, sure. If it is being shown in addition to your regular view, then it causes all sorts of technical problems. https://board.dualthegame.com/index.php?/topic/15034-camera-elements-that-can-link-to-screens/&do=findComment&comment=106749 Also searching is your friend.
×
×
  • Create New...