Jump to content

oreganor

Members
  • Posts

    31
  • Joined

  • Last visited

oreganor's Achievements

0

Reputation

  1. OP, just focus on burst weapons, either Cannons or Railguns. My current end-game (Operates next to the Galaxy Core) ship is a 4.93M3 Cylor Rider armed with 8 Burst Railguns & 11 Seekers with registered 600k Omicron (It's artificial and due to the strange way burst weapons DPS is evaluated) mainly made of Trinium (With the mandatory "Avorion Stone plates" to be able to mount Avorion Turrets)... So it's cheap (Well... Hull is... The cost of the weaponry, all crafted, is like 10x the cost of the hull :)... Not including the ammount of time dedicated at buying weapon components :( ). It's configured as a "darting" ship... High maneuverabilty, high up/down strafe (To take advantage of the classic Cylon Rider shape) so it matches the playstyle you mention. The problem with any darting attack maneuver is... That the game has the habit of failing to register entire volleys worth of damage. But when it works this ship wipes out 3 Small Xsontan at long range (Nominal Seeker range is 13k... But boosting towards the enemy you can hit approaching ones as far as 30k) and then it can wipeout 4 Big Xsontan ships before the Railguns Overheat at 5k... You can repeat this around each 30s, including the retreat maneuver to leave enemies out of range, while waiting for your weapons to cooldown. In my hands (ie if you maneuver to avoid hits) you can't die to even the greatest of Spawns in the middle of a dense Breeder Field... But If I let it in hands of the AI, as it only has 85k HP and 200kSHP (400kSHP with "Battle Mode" systems), it dies before even killing 4 Xsontans in a Big Wave spawn. So that's the current situation... Players are plagued by "0 damage" bugs, while AI simply plays the stationary turret gameplay... If you want a ship able to do BOTH... You have to use massive designs almost completely dedicated to HP & SHP... AI fares better with ships armed with constant stream weapons, although it uses Cannons very decently. Try high output lasers on your AI ships and/or cannon/seekers. AVOID mixing ranges on the same design... AI will NOT EVEN TRY TO SHOOT until the shortest weapon carried is in range (This includes any mining or salvaging turrent you have let there for "peacefull times").
  2. Building mode productivity could be improved with the addition of a few tools and tweaking current ones. All the small steps are coordinated to provide a final result, but each suggestion can operate also by itself: Selection Color should be different than current block under the cursor ATM "white outline" is used as either to mark a block as part of the current selection or to highlight the block "under the cursor". Would be much better to have a distinct outline color for each to clarify when a selection is been disabled by selecting a single block WITHOUT the multiple block selection tool active. Select ALL blocks of this type With this tool selected, each click on a block would select ALL blocks of the same type and material on the current ship. Further clicks should behave based on if the clicked block already belongs to the current selection: if it does then this type of block is removed from the current selection, if it does not, all blocks of the same type & material will be added. Modifier Key to apply a tool effect to the currently selected blocks instead of the one under the cursor A good candidate could be CTRL but the key in particular is not as important as its functionality. While this key is pressed, any tool that changes/edit a block under the cursor, will apply its effect into all blocks currently selected. Obvious current candidates are "paint tool" and "replace block". Create Group & Group list 2 Controls, in fact. A button to "store" the currently selected blocks as a "group". And a corresponding window with a list of all "groups" currently created for this ship. Each "delete block" operation should ALSO check EACH group definition to remove the block from it also, meanwhile, a delete operation on the group list will just remove the group definition, not any real blocks (Delete group should be a button on the Group list... Delete key should keep been reserved as currently, to delete the currently selected blocks). Clicks on the Group list will replace the currently selected blocks by the ones selected on the stored group. This is basically a Layer System on a block building game like Avorion. Group List: Hide/Unhide group "checkbox" Next to each group in the Group List there should be a checkbox to control if the group is displayed on the game or become hidden and unselectable by further editions until made visible again. Toggle Last Group visibility key A shortcut key should exist to toggle the visibility of the last group used by the player, instead of him having to go the list each time to toggle it. Alternatively a second checkbox could be added to each group in the group list to mark which ones will be toggled by each shortcut key press.
  3. This suggestion arrives late, most likely, seeing the planned release window... But I will go with it as this game, imho, is really calling for something like this. MISSING COMPONENT For the suggestion to work, first we need to solve the main difference between a figther and a regular ship ATM... The "Turret Plan". We need a way to store not only the block plan of a ship but also the distribution of turrets... This is not trivial to do and, compared to the rest of the suggestion, could be by far, the most "code intensive" feature of this suggestion because it's not just a matter of saving the data but to add specific features to build mode. What we will earn? The possibility to equip turrets DIRECTLY on the Ship UI ("P" key) as the slots can be ordered (And even previeved on the 3d model... Similarly as what happens now with damaged block) and turret surface coordinates are already known by the system. The idea is reusing the current way to "attach" turrets to a given design... But DO NOT use current turret inventory, but size-based templates. This way the player is just designing spots on his 3d model were turrets MAY BE (Optionally, if size-templates are used, he will also be marking the max size a turret on that spot can have). The rest of the process (And all max turret control checks) are done in the Ship UI... Were a player puts THE REAL turrets into the current "holes" and the system checks if the ammount do not exceed the current limits (either of control or by size of each slot, if they are implemented). This allows to save potential turret possitions into the XML of a ship and a nice previsualization were the user just drags'n drop real turrets and see them appearing in the surface of his ship. It will also open the road for "turret loadout" templates or specialized turret controllers based on "slot size" in the future, but that's beyond the scope of this suggestion. But as I said... This is just a requirement for the real suggestion, which follows. HANGAR REWORK First some safety/antiexploit meassures: - The minimum material used in the Hangar Blocks of a Mothership controls the MAXIMUM material ANY shuttle or fighter can have to be able to dock at the mothership. Example: If a mothership has 2 Hangars made of Trinium and Avorion respectively, fighters/shuttles with any ognium/avorion block WILL NOT be able to dock at this mothership. - For a design to be considered a valid fighter design has to be made of a SINGLE material. Also a max volume limit should exist, either as relative volume to mothership or as an absolute limit (ideally should be a server configuration option). - The max number of active turrets on a fighter design should be as if the slots equivalent to that volume were ocupied by a common quality dedicated controller. Now how to "aquire" a regular design as a figther (I will leave "shuttles" for later): - "Trusted Designs" as a list of serverside templates the players can buy at stores. Basically what we have now, with the remarkable difference that, thanks to Turret Plans, a player could have the option to choose the same template with DIFFERENT weapon loadouts. Fighter cost, tech level and turret performance could inherit average performance as if the turrets were made in a turret factory at the same distance from the core. For balance reassons players should be charged BOTH money and resources for each fighter they buy this way. - Shipyards. Players could create batches of their "fighter rdy" templates stored locally. Turret loadout should be restricted to the materials the SY have available, and should be selectable. A server configuration option should exist TO DISABLE this way to acquire fighters. - In BOTH cases, the pilot requirement to control each figther should be equal to 1/4 the total crew required to operate the same template as a regular ship (or shuttle, see below), minimum of 1. - Any performance symplification process happens now... As the complex template is just reduced to a visible model, a fixed set of flight model variables, a simple collision sphere/rectangle, weapon effect sources and a single pool of HP/SHP, and all turret hardpoints should be converted to fixed forward looking (Discarding the ones that ocluded by the model geometry... This is a step that can also be manually enforced by requesting ONLY fixed mount blocks... But as fighters just use common quality controllers... There shouldn't be a problem by allowing all available turrets to be abstracted as forward shooting). Now to shuttles... Shuttles are simply ships ordered to dock at another with enough hangar space to hold TWICE the total volume of the docking ship. While the "shuttle" remains docked: - The total Hangar Capacity of the Mothership is reduced by DOUBLE the docked shuttles volume. - Crew & Cargo & Turrets & Systems stay on the docked shuttle. - A barebones UI should allow to launch shuttles back to space. A more advanced one should allow for crew/cargo/turret/system transfers while docked. - A "shuttle" can't dock if it has hangar blocks itself. Optionally, some extra "realisms" checks could be incorporated about max dimensions of the ship-to-dock compared to the entrance allowance of the biggest Hangar Block currently available on the mothership.
  4. There is absolutely no reasson on why the client can't do this automatically after leaving build mode. I don't find any advantage of NOT doing this by default... But in the internet you always find some1 with specific tastes so... ...Add an option to NOT have this behaviour applied automatically and every1 happy.
  5. You don't need to create such an experiment... Happens all the time on sectors close to the core, at least in my galaxy. The current AI, sadly, is not a good test: - Ignores the highest DPS facing of the designs it pilots. - Have no clue on how to dodge incomming fire... It performs some intentional trayectory breaks while closing to weapon range... But once it reaches it, just tries to orbit the target if it wanders... Or simply parks there immobile... It also has the HORRIBLE habit of holding fire until the shortest weapon is in range... Instead of using each turret at the range that can hit their targets (Procedural enemies masks this by generating ships with a SINGLE type of turret... But you can painfully see this in action if, for example, you make the fatal mistake of leaving your mining/salvaging turrets on your combat vessel and order it to attack enemies). 4k is already "deadly range" for smaller ships... Instant weapons like lasers & railguns deny any kind of maneuvering as defense. That's why I focus on cannons... Those require skill BOTH at aiming and dodging and is the weapon a small profile ship could exploit against a bigger one, because can be used from OUTSIDE instant weapon range. But that's the whole point... Ship size, and all the benefits it brings for a single player, can't be removed/lessened... Because a player have to spend more time saving resources and risks more by flying those Capitals... It has to come with a benefit. It's the delicate problem of how to counter one, if the needs arise, what needs to be carefully considered... A single player piloting a single big ship cannot just die by another single player piloting a ship much cheaper... ...But you can't NEVER go to the extreme of allowing such ammount of power so a single player can counter multiple ones easily because it has an initial advantage of resources... You have to create a meta that allows newer players to "cut the distance"... Hence why I like the current approach. Otherwise this game would clone the typical failure of most MMO RPGs... Which just encourage a rush to reach "high end" (ie Max Level) to later go back and grief players that are still accumulating "the resources" to be able to deal 1 on 1 with an enemy... ...OFC that's more challenging having to relay on multiple players to beat the Big Lone Wolf... But at least is an option that requires less resources on the current system... And a REAL reasson to gather together once Alliances are a reality.
  6. On a PvP environment, sadly, there are 2 factors that will cripple all stationary defenses/structures and will require specific meassures to prevent exploiting if it's expected to have players trying to build/keep stations: - Speed Control Removal system. Small ships at high speeds can inflict massive ammounts of collision damage with a fraction of the cost. With the artificial speed limits in, even as anti-newtonian as they are, they restrict high speeds to big ships due to how the engine block behaves. - "Hastened" Seeker Launchers. Launcher proyectile inherits the speed of the platform used to launch them... Attempting any kind of "speed assisted" long range launch aimed at anything would require perfect aligment, which is a lengthy process to do, specially under fire... Seeker launchers do not have that problem, making them the weapon with potential farther range ATM... Stationary defenses will not stand a chance against ships out of weapon range launching their seekers at high speeds towards them. This 2 specific issues have easy solutions... But in BOTH cases require modification of the current mechanics, specifially aimed at static structures (Entities WITHOUT engines, nor thrusters). An example: - Inertial Increase Fields. The opposite of the Inertial Blocks we have... A defense block able to project a field that damages objects in the vicinity moving at high speeds. For simplicity (And less lethality), instead they can nullify the SCR system effect, puting all nearby ships directly at their max speed and draining their capacitors if their previous speed was higher than the normal "restricted" limit. - ECM fields. Able to disrupt homing capabilities of seekers in the vicinity making them change direction... Or for simplicity, that makes seekers to explode at a certain range from the structure... Or even simpler, deny the lock on any structure protected by this.
  7. The issue with collisions (And most likely all damage) is that it "bleeds through"... ...I have done single collision impact tests at different speeds and sizes (I used simple shaped massive ship made of stone as my "asteroid"and a simple ship with a sacrifice block separated to be sure that only a single block collided laterally, to prevent multiple hits on the direction of moving), even If I also blamed IFGs for this, they aren't the Main culcript (I repeat, I have the feeling that all the damage is done like this... But no single weapon is able to do as much damage in a single block as a collision): - Collision damage applies ALL ITS damage to the whole HP of the ship FIRST and later to the block it collided... Doesn't matter if you use IFGs or not. That means that at sufficient speeds and against sufficiently massive objects your root cube will be instantly destroyed BEFORE any further consideration happens even on a single hit in a far block. - IFGs allow for MULTIPLE fast collisions on the same block... The way damage is reported as a single number on fast ocurring hits may mask the fact that block is actually colliding multiple times, that's why it looks IFGs are more damaging... If that block wouldn't be protected by IFG would have been destroyed on the 1st hit, allowing the ship to keep moving WITHOUT further collisions. - It's quite frequent that a single block collision, triggers the adequate dynamic behavior (Sudden rotation, deceleration, etc) WITHOUT any damage been applied. This helps at increasing the "randomness" of collisions. I hate been "vague" about "frequent" but so far I haven't noticed any pattern on when this "fake collisions" happen. EDIT: Notice that in my tests I was using the same massive object (That was barely damaged)... So this "fake collisions" may be an intended mechanism to protect massive objects from multiple collisions from the same smaller object, or may be a genuine bug.
  8. Maybe I didn't explain it correctly... Ohm is Futile wrote: OFC that the same ammount of players per side should win the ones with bigger ships... ...But that's not what I'm talking about. I'm talking of what to do when the Bully of the server comes to your door with a gigantic ship simply because he WAS FIRST on the server. That's why it's balanced now... Because with enough players in far smaller ships with a fraction of the resources you take down that big ship... ...A PvP game that doesn't work as this, is dead before even starting... Some tittles make this mistake, and they kill the initial flux of players in no time. I get the feeling that creative players want to mimic the big powerful multiturret capital ships they have seen on their prefered Scifi... Meanwhile the problem comes when PvP griefers get this same net operative advantage that can make life misserable to ENTIRE GROUPS of players. LordMaddog wrote: With cannons? I highly doubt it. Brigadon wrote: Erm... And how that changes with the size of the ship? What matters is the DPS applied... And as ATM, there is no non-linear protection mechanism that operate based on different damage sources, doesn't matter if the X turrets required to beat Y regen rate... Are on a single ship or split between 10... And you have seen, if you have the players, it's far cheaper to field those X turrets in multiple smaller ships than on a single big one. Ohm is Futile wrote: Erm... The fact that WHILE rotating you are denying your own shooting capabilities and the fact that your "dodge technique" will just make yourself a target following a stable trayectory? Try that on the current game... Even AI shooting cannons with its basic predictive behaviour (Target Lead = Target Relative Speed * Bullet Travel Time) will hit you all the time. In fact, your tactic HEAVILY favors the multiple ships against a single Big one... Because the current target can do that (Forfeiting his firepower) while the rest keep attacking the Big one. Dodging fire is about moving your smaller axis back and forth so you become unpredictable... Can be done by increasing YOUR ACCELERATION and reducing your "dodge axis"... The Bigger the ship the harder this become (in fact this simple factor ALSO helps fighting the "cube syndrome")... And it's not accidental... That's why there are instant weapons on the game that deny this fact... And that's why SO FAR they have less range than the proyectiles... The Dev seems to be perfectly aware of this, while at the same time provides the tool for ppl to "customize" their experience between Big vs Small on their servers... They just need to "remove" this key factors. EDIT: Sorry for the multiquoting... I'm used to forums that also link the user also on partial quotes, I added them manually... Hope it gets clearer this way.
  9. A few comments: - Ships are designed as blocks linked together. Meaning that a "match to corner" would never be able to be implemented easily because can't be described easily by a primitive shape plus 3 scaling factors. In theory, we can have curved primitives that later are scaled (In the same way that we have triangular, etc) but the problem will still remain as blocks are attached primarily with a single surface. - Currently the game allows for blocks attached to different normals to overlap to a very generous extent. This can be used to blend them in a nicer way FOR A GIVEN CURRENT OVERALL SCALE. If you scale the model, the attachment points move and, unless your scaling operations are strictly symertical (using the Q key), all "manual blending" will be displaced. This "feature" (That can be exploited to "create" extra volume on ships) may or may not stay... The procedural generation uses it plenty, so there is a high chance that stays on the final version. - When creating "curves", that can be scaled "nicely", it's safer to use pairs of triangular sections rotated so they create "curved struts" and attach them at the extremes to regular surfaces... You should never try to attach curved struts between themselves or to perpendicular structures in the "middle", if you have scaling in mind.
  10. Unless you abuse bugged factories you don't have instant weapons that can outrange a cannon... The problem of ANY 15 slot ships is the size that presents as target... ...Do the following excersise: - Check the ammount of resources that monstrosity costs. - Get a 3 slot ship of the same materials. Divide the resources of your 15 slot machine with the cost of a 3 slot to know how many ships your opposing fleet can build. - As both can mount equal weaponry... Now use cannons (the 2nd longest range weapon on the game) on both. - Now compare how easily your Monstrosity can be hit and compare to the next to nothing chances to hit any small ship at long range with cannons. On a server were players actually have to gather those resources... Instead of creative were resources are irrelevant... ...Who do you think will win a war? The relative scale betwen the "Monstrosity" and the smaller ship fleet that can kill it is just controlled by how many players the "small scale" fleet can field. And maneuverability is not rotation alone... Strafing also... I would like to see the inertia of that "Monstrosity" compared to the 3 slot ships. That's why I distinguished PvE from PvP... On a PvP server environment... Balance is ok, even if a player is able to hoard the ammount of resources to build a "Monstrosity" ... Others can take it down with a fraction of the same resources.
  11. On a multiplayer game you CAN'T let a single player control the ULTIMATE DeathStar... ...Or you will be encouraging stablished player harrassment of new ones. Peak firepower needs to be ALWAYS on the side that has more players in it, and, if possible, the side that has combat initiative (Basically the side that can choose to flee). ATM, with maneuverability and number of turrets favoring small multiple ships, this is balanced... As a single player piloting a big powerfull ship can certainly bully a single player in a smaller one IF the smaller one can't flee... Meanwhile, if the same player tries to use his DeathStar to wipeout a sector containing the stations of a small group of players... They can band together in smaller ships that field more turrets, are harder to hit and, more important, require a fraction of the resources of the Deathstar... Thus giving a chance to survive for new players arriving to "hostile" servers. This game is trying to perform the stunt of bringing creative, trade, exploration, combat and pvp players ALL together to the same product... To manage this, "status quo" like this one needs to be enforced. On the other side, if you want to increase the number of turrets on a custom server... You don't have to mess with complex balance... Just increase the ammount of turrets each control system provides and voilá, you can make your own Imperial Class Star Destroyer ;).
  12. ATM... Combat effectiveness between players is balanced IMO because of the following factors: - 2 free turrets per ship plus system slot scaling favors smaller ships. - Number of turrets is dominated by the above scaling factor ATM as Energy Generation and Crew Space requirements are smaller in comparisson. - Instant/Seeking weapons range (Railgun, Lasers, Launchers) is shorter than proyectile weapons (Cannons or "Speeded-up" Launchers). - Maneuverability worsens gradually the bigger the ships are. - Shield Damage & Hull Damage are, ATM, linear systems regarding different sources. This means small agile kiters operating outside "deadly range" (ie instant/seeking wepons range) are the best source of DPS per unit of resources spent... IF the faction/group/guild can field as much human pilots as required. Meanwhile in PvE, current AI do not know how to keep its range which means the outcome of an engagement were deadly weapons are used (Instant/Seeking) is a matter of DPS vs TTD... ...Due to how Hull HP & Shield HP scales with the ammount of system slots, combined with the gradual degradation on DPS a "cloud" of small ships suffers when facing a single big enemy... Bias is on the Big Ships side, so far. So far looks ok to me... As in PvP, the side with more pilots have the upper hand while on PvE it's not reallistic to expect at this moment in Development a sophisticated combat AI, there are more pressing uses for those CPU cycles regarding Galaxy Simmulation.
  13. On the documentation, ShipAI entities have 2 interesting functions that could help you: function registerEnemyEntity(int index) function unregisterEnemyEntity(int index) I havent' tested them personally... But in theory if you have a shipA and shipB, this pseudocode will make them enemies to each other independently of the faction they belong to, and if there is no other nearby hostile entity close, they will attack each other: local aiA = ShipAI(shipA.index) local aiB = ShipAI(shipB.index) aiA.registerEnemyEntity(ShipB.index) aiB.registerEnemyEntity(ShipA.index) -- Put both to aggresive aiA.setAggressive aiB.setAggressive Far from home this week... So can't access my gaming desktop to check 100% that works, but hope it helps you as a starting point.
  14. I don't know if I'm playing a different game or what but... ...Even the current procedural generator spills once in a while a ship incredibly hard to be hit... and is not a cube... ...I call them "mace" designs (Remind me a lot to the Nebulon-B Frigate in Star Wars). It's a simple principle, concentrate all your volume at the extreme of a long thin axis, add "counterweights" on the farther point of the thin axis so your CoM is into the thin section... voilá. Thanks to the way torque is applied in the game ATM... Good luck hiting that thing while rotating from ANY side... In fact, due to the way current IFGs work, if you let that "mace" get close and the designer is carefull enough to NOT use an IFG on the "counterweight"... It can hit you literally as a mace, ignoring shields and taking advantage of the mad linear speed at the extreme of the thin section at angular speeds close to 1r/s... If you make the mistake of protecting ALL your cube with IFGs... You can die in a single hit. ...The recent change on thrusters is not a nerf to rotation at all... In fact, thanks to the new bidirectional thrusters, designers of oddly shaped ships have the freedom to select which axis a given thruster can modify WITH INDEPENDENCE of were that thruster is placed. Precisely before, when only omnithrusters were available, symetrical ships were the way to go regarding total thruster volume. Selecting your dodging axis and be fast at it, it's trivial thanks to bithrusters now. In fact your design of that freighter (Which looks very nice, congrats... Very "B-Wingish" :) )... Started as a cube... But you realized how incredibly efficient "cross-shaped" designs have become thanks to thrusters... ...Remains to be seen how good recently added gyros/inertial damperers will become once beta patch ends its tweak cycle... This last 2 are REAL Cube Meta enforcers, as both are strictly volume-to-performance blocks.
  15. Just get enough cannons and kill anything at range... By the time you get enough money and resources to assemble a fleet able to deal with a Boss Escorts (or even the typical Big Xsotan spawn when you are next to the core) you better make your own ship bigger and more agile and look for a decent Turret Factory to make your own weapons... ...6xBurst Cannons + 6xRailguns + a bunch of Seeker Missiles to kill those anoying 10% hp straglers that stop to let their friends get closer... And you are set. EDIT: If at some point, AI is teached how to strafe and how to use Boosters... Then a fleet may become resource-viable... For now, a player that keeps his distance flying a decent combat ship worth just a fraction of the resources you risk in hands of the suicidal AI, is far more efficient, I'm afraid.
×
×
  • Create New...