Jump to content

SGCam

Alpha Tester
  • Content Count

    57
  • Joined

  • Last visited

About SGCam

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location:
    Ohio, USA
  • backer_title
    Gold Founder
  • Alpha
    Yes

Recent Profile Visitors

691 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. That's exactly what a bot would say... ?
  7. A solution that would both solve this problem and be infinitely versatile: Players can create what is essentially a piece of paper The paper is given a name when it is created and also shows who created it and when The paper is basically free to make and takes up a minimal inventory volume This allows an org to entrust creation of their notes to a specific person, and basically treat those notes as org currency. If you are worried about that person scamming you at a later date, only accept notes created before a certain date. Overall, this idea solves the desires of people for things like bank notes and stocks and org currency, all in one single and simple custom item. It shouldn't be too rough from a computational perspective, as the item only has 3 variable fields - name, creator, and creation date
  8. @BiGEdge I'm not sure where you think you heard that, but having an EVE-style skill tree has been part of the plan since forever.
  9. Dual Universe can not run on 32 bit Windows (for many technical reasons).
  10. Technically, you aren't allowed to discuss NDA topics outside of the forum or the official discord NDA channels. In practice, that hasn't stopped a lot of people, but they are taking a risk that the things they say and post are not released to non-alpha players. There is no official approval/verification process, though the now-official discord was using direct messaging to forum accounts to determine their NDA status before it was official.
  11. NQ said there will be the ASA "Arkship Safe Area" and also several MSA "Moon Safe Area" aka Sanctuary Moons. Both will be PvE only areas. IMO, automated defensive turrets for static constructs are only necessary if timer-based shields are uber expensive (which tbh they probably will be). Regardless, balancing automated weapons will be a challenge, particularly to avoid spamming by large orgs.
  12. SGCam

    Cameras and Video

    Please use search function - there is some good recent discussion on this exact topic.
  13. This is a planned feature, and I think it is a great idea to prevent offline pvp. @OldingDaGrund I personally like the idea of shields, providing they consume large amounts of energy. However, the problem is that they can remove a lot of the risks of combat (ie, the winning side emerges with NO damage) and also a lot of the nuances of 'subsystem' targeting (which NQ has mentioned will probably be a thing) by giving the construct a unified health pool. I think that if hp-based shields are a thing, that they should be limited to static constructs and should not work in conjunction with any other kind of shield, including territory shields. That way, they fill a role of protecting smaller outposts from minor hit and run attacks.
  14. I think this is a great idea, but there are some serious technical hurdles to consider: If the camera being viewed is near the player, then their GPU load will be (roughly) doubled since the scene needs to be rendered from a second perspective. If the camera being viewed is NOT near the player, then their CPU and GPU load (as well as their network utilization) will all be (roughly) doubled due to the camera having to compute the scene (voxels, elements, players, etc) and render from that perspective. In some games, this isn't a big deal because you can just offload it to another thread since you are not using much of the CPU or GPU. However in more complex games where you are already using a substantial portion of the client's resources, you can't due that and it causes everything for the player to slow down. Some examples: In the FPS "Insurgency: Sandstorm" when using a scope with zoom, the game renders the scene twice- once for the scope at its specific zoom level, and once for everything outside the scope with no zoom. This isn't a big deal because the scenes aren't very complex, and it can be turned on/off with the graphics settings. Not having this feature doesn't put anyone at a disadvantage. In Space Engineers, there is a source mod that allows exactly what is proposed in this thread- viewing cameras on a screen. Having more than a couple of cameras can bring a client's PC to its knees due to the complexity of the scenes in the game, and can even grind servers to a halt. Unfortunately in games like SE and DU, not being able to see the screens due to having a weaker computer could be a significant disadvantage, so having it as a setting isn't fair. I suppose you could offload this extra rendering to the server, but then you need to stream the camera's view to everyone that can see it's screen, thus consuming tons of bandwidth on top of the extra server resources. Basically, I love the idea, but I'm not sure how technically feasible it is considering the extreme complexity of scenes in Dual Universe.
  15. Everyone will be in the same "shard/server". Literally every single player. And that's why not having NPCs works - because there should be plenty of players to make it feel lively.
×
×
  • Create New...