Jump to content

Oran_Gootan

Alpha Tester
  • Posts

    36
  • Joined

  • Last visited

Profile Information

  • backer_title
    Sponsor
  • Alpha
    Yes

Recent Profile Visitors

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

Oran_Gootan's Achievements

  1. Nobody asked why you are choosing random construct abandonment, because nobody cares. The only issue is the plainly objective fact that this solution is vastly unacceptable, and you need to find another one. All the narcissistic batshit insane troll logic in the world won't make that fact go away.
  2. Have you learned nothing in the past few years?? I don't understand why this keeps happening.. Does whoever makes these decisions have some mental defect which compels them to choose the worst possible option on purpose? A short development history of the DU beta Problem: Problem: People don't have enough construct slots NQ solution: Virtually infinite construct slots Actual solution: Create a way to repackage ships and store them, removing them from the world until made active again. Remove ownership of dynamic constructs which are left unattended in unclaimed territory for too long. Problem: If we let people use lua to fire weapons, robots will take over the universe! NQ solution: An endless captcha disguised as a gunnery module. Actual solution: Restrict certain apis to user input driven events. Develop solutions to detect macro usage. Problem: Industry OP NQ solution: Break every single factory in the game, hold them for ransom until people magically come up with the money to buy schematics Actual solution: Energy system, and a much less imposing version of schematics Problem: Somehow, we can't seem to balance PVP quite right... hmmmm whats missing? NQ solution: PvP AlLoCaTiOn pOiNtZS l0l?????? Actual solution: Energy system Problem: Warp travel shouldn't be free, or nobody will travel conventionally NQ solution: Warp cells Actual solution: Tie warp to an energy system. Make designing a ship for space warp challenging. Make initiating a space warp cost energy and come with a risk. Problem: Hey this guy is initiating warp too quickly with lua! NQ solution: Remove ActivateWarp() from warp drive api Actual solution: Interdiction modules, tractor beams, warp disruptors. Increase the time it takes to initiate warp. Problem: Oh no!! Our cloud storage bill goin cuhrazy! Nq solution: DELETE MINING ON PLANETS GGRAAASGGGHHH Actual solution: Decay terrain modifications outside the build zone of a static core. Problem: We need to communicate more to find solutions that players agree with! NQ solution: Swear we are going to do our best, but instead, huff paint with homeless joe in the back of a denny's and make more asinine decisions Actual solution: Learn from your mistakes. Humble yoself. Discuss, review, and REVISE plans with community input before developing them Problem: There are too many claimed territories! NQ solution: Territory taxes Actual solution: Energy system Problem: Oh no!! We made it so that construct slots are virtually infinite! People have too many construct slots! NQ solution: Arbitrarily remove random constructs belonging to people who have too many Actual solution (still): Create a way to repackage ships and store them, removing them from the world until made active again. Remove ownership of dynamic constructs which are left unattended in unclaimed territory for too long.
  3. Would it be possible to have the API of certain elements restricted to screen click events and perhaps other user-input driven events, and not accessible from events which always fire (flush,update,etc)? It could be a good way to allow players to make custom UIs for PVP without allowing automation. Also we could bring back stuff that was removed due to automation concerns, like my activateWarp button. One of the coolest features of the game is the possibilities for customized ship UI but it is frustrating that I can't integrate certain elements due to perfectly valid concerns about automation.
  4. Is the introduction of weekly upkeep fees per tile just another iteration of kicking the energy systems can down the road?
  5. Energy systems are the only way to balance PVP. The damage output of weapons is meaningless if you can slap 50 large turrets and 25 XL engines on a block of solid gold. Energy has to be prioritized before we can even think about balance, because without it any attempt at balance can just be circumvented by adding more things to the ship. Shields would be really nice to have, something I've been anticipating for a long time, but without energy systems they're just another thing you can stack on a ship to make it even more OP.
  6. Linking of industry units and other elements on large constructs can be frustrating and quickly devolves into a gigantic all-consuming pink hairball. I played another game which had a good solution to this, which seems compatible with the current implementation of sprite ropes for links -- There's an addon called wiremod for a game called Garry's Mod which had this problem for a long time, but eventually added a way to organize and beautify links by allowing the user to place links with multiple line segments. This was accomplished by clicking your starting point and right-clicking (ctrl-clicking with DU controls) arbitrary positions which would add a segment endpoint to the wire. This allowed the user to organize even the most complicated setups like one would layout a circuit board, except in 3D. I believe this is the perfect solution to issues with link visibility.
  7. Sure, but that idea isn't grounded in any reality. That level of AI doesn't actually exist and won't for quite some time, and it's not the point -- this isn't an idea about automation or replacing the role of human players in any way whatsoever. This is about adding a necessary level of immersion to a universe which would be otherwise mostly devoid of human life- it really isn't any different than the concept of pets or creatures... If you thought NMS couldn't have been any worse of a game, imagine what it would be like if you got to the space station and there was nobody there except like 2 dudes and a corpse standing around AFK watching miami vice and one of them doesn't realize he died
  8. They wouldn't actually do anything, except their statistical presence fulfilling the requirement for operation of certain devices. These would be more decorative than anything. This wouldn't serve to detract from the involvement of real players in any way. In reality it is an unrealistic goal to fill the game with human players-- though it is a good design goal to support millions of human players there simply aren't enough people who play subscription based space computer games. An entire player built city of skyscapers with only 100 real people to live in it or a ship large enough to hold thousands of people crewed by 20 nerds would have more life if there were NPCs. This is mostly a cosmetic request, any impact on gameplay is up for debate
  9. When this game is released I would like to build and fly gigantic murder-your-face-off-deadly combat vessels into glorious battle. My concern is that when I tour the many decks of my glorious space vessel, even with a bridge crew of 15 or so human players the endless hallways and devices might seem empty and lifeless if they were not populated by a crew. I propose a noninteractive NPC crew element -- balanced around space utilization within a construct. The NPC crew could be fully clientside, noninteractive, noncombatant -- represented by a fuel-like statistic in ship operations serverside. NPCs as fuel means some devices would require attendance by an NPC to function, where the NPC fuel capacity is determined by the amount of living space on your vessel/ the number of beds, similar to basebuilding in FO4 but possibly without the whole happiness thing. Whether or not you would actually have to pay them is up for debate, but lorewise might want to consider a more optimistic personal economy where people don't need a salary to do the job. The benefit of having them clientside would be the ability to turn them off, or reduce the amount of them displayed for computers running lower performance. In terms of gameplay this would also prevent people from building ships which are just massive cubes filled with devices and a chair because you would have to build the space to support the crew to support the devices. In a possibly more detailed scenario this would require crewed devices to only exist in oxygenated environments, and ensuring your crew has a path to access them.
  10.  

    discordauth:nyKqAcfPlB0GLM91MVbmFFgvjgHSKs5Rkj6PcVS9kWc=

  11. Stargates are fine but I strongly disagree with the notion of pre-set FTL beacons. From an NPE point of view that would force players to be planet-bound unless they spend weeks sending personal probes all over the place. They would not have the opportunity to explore until they have joined an org and even then they would only be able to go where their org has been. This would make the game feel rather isolated from anyone who isn't in your org or living next to you. I think that free flight in FTL is the only real way to maintain the immersion, and if it is successful that it would be absolutely groundbreaking. Pre-determined point-to-point warp is just a regurgitation of the same interstellar travel mechanism we have seen in every space game that has ever even existed basically. Eve, X, EGS, SWG, SWTOR, all of these games have been doing this same thing for twenty years. The thing that makes DU stand out as a promising candidate for this sort of thing is the nature of the engine and the backend itself. It just takes big chunks of the galaxy and makes the computer compute those chunks, no matter where or how large the chunks are provided the chunks can be computed near-realtime. This is extremely innovative technology which should be pushed to its fullest potential. Using this tech to do the same thing any of these other games do seems like a cop-out. I think that there will never truly be a space game until it is possible to freely explore space by flying spaceships around in it at FTL speeds. DU can provide this.
  12. That seems more promising. To me, simple teleportation would not feel immersive enough. From a mechanics standpoint, teleportation gates will force the same monotonous camping gameplay you see in eve. Although I would be worried about this because the only other place I have seen this is in the STO sector map travel... I suppose it would have been better without the ridiculous clunky cartoon overlay and the overall feeling that I am a model-hacked superman (cryptic used the same engine for the space game as they did for the marvel heroes game or whatever it was) and felt too juiced up and looked bad, it didn't feel like space travel at all.. I feel very strongly that for DU to deliver w/regards to it's single-shardedness it has to include free FTL flight without any gimmicks both for the added immersion and the sheer thrill of flying and walking around on a ship at superluminal velocities. I also feel that interstellar flight should not be easy and designing ships to fly FTL should be an involved process.
  13. What you're suggesting goes beyond the bounds of cartesian space into abstract theoretical involving multidimensional spacetime. This seems to me a bit more difficult to implement and also quite a bit more monotonous, and it diverges from the incredible single shard galaxy nq has created which involves distributing computation to specific blocks of cartesian space. I'm not sure that this space can be bent without fundamentally altering the backend. Consider a superluminal pursuit in the "factor seven" plane. The superluminal performance of these vessels on this plane would be no different than the performance at any plane or at sublight. If the pursuing vessel were to jump to the factor eight plane the two ships would not even be in the same spacetime, so would not be able to interact with eachother. What I am suggesting is a simple, readily computable velocity measurement based on the performance of the vessel in question and six input signals without having to change the mathematical representation of the universe or doing an actual space-warp. The big question with implementation isn't whether we can do crazy scifi math but simply whether or not the backend can support superluminal velocity.
  14. The most commonly accepted theoretical method for FTL travel is called the Alcubierre Drive, which propose to build an engine that can warp space. This involves creating a 'warp bubble' which consists of an unexpanded region in the center, a squished region in the front and a stretched region in the rear. To simply slap on a module that make your ship go is not good enough. To make FTL ship design interesting/compelling a designer should have to calibrate the field geometry such that the ship fits in the bubble the bubble is streamlined the engine has sufficient power to maintain the bubble radius Desirable attributes of FTL drive for shipbuilders to balance: Startup time - This is the time your ship takes to initiate FTL from cold start Speed - This is the maximum velocity your ship can achieve without overloading your FTL drive Acceleration- How fast your ship can speed up and slow down.Energy usage How much energy it takes to maintain velocity. Structural integrity - The ability of your ship to accelerate in a given direction without flying apart. Power - The amount of your ship dedicated to supporting your FTL system Control systems - A well designed control system will operate your engine efficiently and safely, without exploding Interactive FTL capability will add value to ships and increase competition for engineering design and control systems. The FTL design of a vessel would have to be engineered and calibrated by a specialist, and each design would have to be unique. Equations of warp bubble can be described by the FTL drive component with simple made up math which is loosely based on current ftl research but has nothing to do with reality: The field is composed of an expansion ellipsoid and a contraction ellipsoid Velocity =Vector(D, sqrt(E*C)*FD) where D is the angle between the FTL drive and the point furthest from the warp drive on the contraction ellipsoid. where FD field divergence is the maximum distance between the two ellipsoids in meters where E energy is a constant based on the total energy supplied to the drive where C is the speed of light in a vacuum If I place my ellipsoids farther apart I will travel faster. If I place them closer together I will slow down. Changing the field geometry such that the field is offset in a direction other than forward would allow your ship to drift, strafe, and warp sideways and pull off all sorts of maneuvers. The offset and the sizes of the ellipsoids comprising the warp field will determine the velocity and direction of travel. To withstand a change in direction the ship must have sufficient cross-sectional strength/weight ratio in the direction of the change in acceleration. The drive is controlled by the positioning of the ellipses. The first set of inputs, X0,Y0,Z0 control the energy diverted to projecting the bubbles in each direction, determining the size of the bubbles. The second set of inputs , X1,Y1,Z1 controls the position of the forward bubble relative to the drive. Field divergence and velocity is given by the second set of inputs. To turn the drive off, cut the power. If the power level is insufficient to create a bubble which your ship fits inside your ship will not enter warp. If the field strength is not sufficient to maintain the bubble radius the ship will be crippled by the shearing force. Energy usage will be given by the total volume of the bubble divided by the aspect ratio of the bubble, direction of travel to max radius perpendicular to the direction of travel multiplied by the field divergence. Protip: Use the same mechanic except with a single ellipsoid when you implement shield bubbles to save work. This will lead to the following situation: The captain tells the engineer to outrun the other ship The engineer is concerned because you run the risk of overheating the engines The captain doesn't care and just wants to go faster Either the ship explodes or everything works out ok depending on both the engineers competence and the designers competence A staple situation of modern space drama which would only appear in a cutscene in any other game.
×
×
  • Create New...