Jump to content

oreganor

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by oreganor

  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.
  16. I get that you are trying them to follow you through Jumpgates... ...If you are using your Jumpdrive you NEED to be sure every single follower can jump at least as far as you do and all are in Escort or Follow. Regarding Jumpgates... There are all kind of weird things going on with them. My observational advice: - Use ships that are smaller than the Gates or much bigger... If you use ones that are close in size, the AI flying them will decide to "bounce" against them instead of going through. - If you try to make multiple followers to use the Jumpgate, generally, only the 1st one will go through... The others will "loose track". It's funny the fact that if you make them follow each other, like a conga line, all of them go through the JG... Just be sure you separate more than 3k from the gate so each one that enters immediatly moves away from the Gate landing zone. ATM sectors WITHOUT a player in them become inactive until you return, so those ships following you "cease to exist" as active ships some time after you leave a sector... ...It would kill any CPU to simmulate with the granularity you see when you are there the entire ammount of created sectors of the typical Avorion Galaxy... ...This doesn't means that the Dev can't SIMMULATE what happens there in raw terms, but that requires an independent layer of code that simply isn't present ATM, AFAIK. Returning to Fleets... TBH, atm they are just for screenshots... At least in combat, a human player is FAR FAR FAR more efficient fighting alone. Freighters, miners and salvagers are ok... But you don't need to go around with combat ships. EDIT: Forgot the most important tip... Get used with the RTS command mode (Just scroll back until you get a flat vision of the current system). There you have a new way to command ships: - Select one or drag a box to select multiple. - Single right click will do a context based action based on what you click: a) Empty space. All ships will move there. b) Friendly. All ships will follow that target. c) Enemy. All ships will attack that target. d) Jumpgate. All ships will use that gate to jump to the next sector (WATCHIT because if you jump AFTER them you will collide with ALL OF THEM when you arrive at the next sector. Use your drone to scout the other side to prevent costly repair bills ;) ). If you keep your right button pressed a small menu will appear, instead with "Escort", "Attack" and "Stop" commands that are self explanatory. AFAIK there is no key to directly go to the RTS mode... So it's a bit cumbersome having to use the scrollwheel... But it's worthy to organize your followers insector.
  17. And that do not change at all the fact that the armor block next to it... Has around 8 times as much HP as the corner... That's why IFG current implementation only masks the problem, do not fix it. I will highlight again the important part of the phrase you chose to ignore: [...]current IFG is that they do nothing at addressing RELATIVE weakness of blocks[...] With the remarkable difference that you are splitting the same volume HP between 4 blocks... Which measn that to trigger a block destruction you require 1/4 the damage... It's preaty simple, have you tried to smooth whatever ship you have... Expose it to fire WITHOUT any IFG and then proceed to replace the "nice" corners with equivalent blocks? Erm... Have you checked what REALLY happens on a collision in a given section WITH and without current IFG? Please do so... Put in simple words... A collision that affects 1/10th of the volume of a ship is instant death with IFG... Meanwhile, without it... Just results in 10% of the volume lost (even less... Because when the colliding blocks break, the ship usually slides, slowing down thus making the following bumps less damaging)... But do not trust what I write... Simply test it... But be sure that you keep your Galaxy with collision damage on... Obviously if you remove this factor, you simply can't see the fatal flaw this implementation will show when players exploit it. I think I didn't explain correctly... Let me put a simple example with just 2 blocks. 1 Armor block (10 hp) plus a thruster block (1 hp) BOTH protected by IFG: - Current system: the Armor blocks requires 100 damage to become destroyed and the thruster block requires 10 hp. Focused fire or damage on a this zone is able to trigger 10 times the damage on the rest of the ship this blocks are "worth for". - My proposal: THE ENTIRE PACK of Armor + Thruster require 11 points of damage to become destroyed... The ammount of damage received and overall effect DO NOT change the effective HP of the zone and it becomes impossible to destroy a complete ship just by focusing damage on a single spot. I hope I was clearer with the numerical explanation... There is no HP alteration nor extra vulnetability on a certain zone... The IFGs I propose are just a quality of life so THE WAY A GIVEN ZONE IS SPLIT INTO BLOCKS, do not make it extra weak or force the player to constantly have to replace small parts by simple grazing shots in combat. Thanks for the condescendent tone... But I think you aren't reading what I was proposing... I hope the rest of this forum users pay more attention to what's written before going around fabricating arguments.
  18. There is no Cube Meta on PvP... ...Remove instant long range weapons (railguns in this case) and anything with a regular shape that can't strafe its smaller length in the time a bullet takes to arrive is dead meat to ships a fraction of its size. You can store A LOT on that volume if you wish... But can't escape mass, and as your shape is perfectly regular you can't benefit of strafing over a smaller lentgh to avoid enemy incoming fire, your rotation speeds will be mediocre at least, which, in turn, will force you to waste a lot of that precious volume into more thrusters. ...If railguns stay ingame, then PvP will be a simple DPS check and there the Cubes will rule, that's true... But for as long as manual aiming plays a role, the collision section you present to your enemy and how fast you can move it is what matters.
  19. I think that the flaw on current IFG is that they do nothing at addressing relative weakness of blocks (Try to use corners to "smooth" any design and, unless you scale the whole ship up, they will be destroyed easily anyways)... It just scales it up, on top of making collisions EXTREMELY deadly. They should operate as HP normalizers and subentity creators. - The blocks affected by an IFG should all behave as a single HP pool that gets destroyed as a single entity, no artificial scaling up. - On a collision, the max HP lost should be the one from the pool affected by the nearest IFG. ATM fully IFG protected ships are instakilled by a ramming maneuver with a ship with a dedicated ram WITHOUT IFG protection. In PvP this will be abused beyond imagination (Specially with velocity control module on). Players should have more control over this. - The volume protected by an IFG shouldn't be a sphere centered into the block itself, should be a cubic volume with the generating IFG in the center of one of its faces (So an IFG block protects other blocks IN FRONT of it, instead of all around it). The length of the sides should be proportional to the IFG volume. That way ship creators could get better control of which parts they want to protect WITHOUT compromising more HP than they want for the sake of weak block protection. With a system like this: - Collision vulnerability can be fine tuned by the ship creators in a better way. - Possition of Thrusters (or purely aesthetic elements) will not be influenced by battle performance, just by aesthetic preferences, as they can be put into the surface and still enjoy the protection of a shared HP pool with healthier blocks like armor. - Offers the possibility to create "envelopes" thick enough to prevent the "phasing bullet" problem that currently is so common. When a bullet "goes through" (because of lag) your external hull and kills a weak component that, in theory, was protected by armor. - Material dependence could be as simple as with Turrets (Blocks of higher material than the IFG will not be protected by it... Or the IFG couldn't be installed if a material it has to protect is of higher Tier), or more complex, like bonuses to protected volume and/or bonuses to overall HP (Similar as how they behave now... But to a lesser extent). - Sadly, implementing this would be complex as damage resolution should be swaped from a direct block HP reduction to a "splash" effect were damage is proportionally shared between blocks based on their max HP so all blocks "protected" by the same IFG reach 0% HP at the same time. This is more CPU intensive than the current scaling approach.
  20. Yeah, well... The problem here is that Homeworld AI only had to care about a single sector... ...I don't know the plans of the Dev fully... But I read on the last Inerview that he has in mind Out Of Sector simmulation (at least production from Factories)... ...Combine the above with the potential scenario on a MP server of 1 active sector per player... ...And you may understand that CPU cycles are a VERY valuable commodity for this game, hence why primitive AI behavours have to be simple and rough, once all demanding features are in place and a target hardware is selected, then you can consider increasing the complexity of any algorithm... AI behaviour falls in this category, I'm afraid.
  21. It happens to me with High Fire RoF weapons or... ...Barrages from multiple guns (Particularly apparent with ships armed with multiple cannon or railgun turrets). Seems to me it's linked to the number of projectiles that arrive in a short period to the target, not to how many a given turrent can spill. It may be related to something that happens commonly with wrecks if you use autonomous salvaging turrets... Serverside the wrecks get destroyed but clientside you see turrets shooting to empty space, the damage numbers appearing in another random empty space, while the intended target floats somewhere in between... ...Put in other words, the possition of the target, clientside, is not the same as serverside.
  22. ATM AI can have 3 modes of been ordered to move around: - Fly - Flylinear - Attack The problem is that Attack command always assumes that the target will shoot back so the ship is always moving around even after reaching weapon's fire range, while there are attack operations that are applied against passive targets, mainly mining and salvaging. So I would suggest a 4th Flight AI state to be added: - Gathering Which can behave more or less as Attack but with 2 important changes: - Stop completely once attack range is reached. - Rotate so maximum ammount of relevant (mining for roids and salvagers for wrecks) turrets can hit the target. Additionally 3 QoL features could be also implemented: - Anti Friendly Fire break. If the shoot action triggers friendly fire, abort current target. - Anti stall. If the target is still alive after Hit Points / DPS seconds, abort current target. - Adding full firepower property to the "Gathering" ShipAI mode. If on, the ship will use every single available turret against the target, if off, only the relevant turrets will be used. EDIT: The "abort current target" may require extra data so scripts can check when a gathering operation ended successfully or not... Maybe AI state can be swaped to "None"? So from script pow, something like this could work: -- Pseudocode ai = ShipAI(ship.index) ai.SetGather(target) If NOT valid(target) and ai.state == AIState.Gather then -- Current target was destroyed successfully elseif valid(target) and ai.state == AIState.None then -- Gathering operation aborted end
  23. oreganor

    Jumpgate Bugs

    A collection of jumpgates "strange behaviours" and straight bugs reproduceable: - Entering a JG with the camera looking in a different direction than towards it, results in a constant velocity applied AFTER arrving to the new sector. Easy to reproduce: Accelerate forward towards a JG, and in the last moment rotate your ship and use the matching strafe to enter the JG "laterally". Try to stop your ship on the next sector to make the bug apparent. In game "fix": Open and close build menu for the affected ship. - Multiple ships following the same one result in only 1 of the followers able to jumpthrough, the rest will "loose track" of the original formation leader. Meanwhile if the same ships are linked in a train so each one follows just 1 other ship, all of them cross the JG successfully. - Ships with a dimension close to the size of the JG permanently "bounce" against it without crossing. Meanwhile smaller ships and much bigger ones cross without problems. Looks like the AI in Fly State, when the ships have dimensions that are aproximately the same as the JG, detetcs a "collision" too soon and makes the ship stop, backpedal and try again... Sometimes, when the ship approaches the gate from the lateral it jumps... But can take forever to happen. - Jumpgate arrival do not check for pressence of mass. It's strange that jumpdrives put all ships spread around their Spheres to avoid collisions, while JG do not care if the space a ship will arrive into is already occupied.
  24. While awaiting for the fix... Remember that ejecting your cargo puts the newer one at the bottom of the list, so you can eject until you "scroll" your inventory. Sadly this do not help at getting accurate data of total loaded volume, because the top bar calculates what's visible, but at least will allow you to control which cargo you want to keep controlled. One warning, if while in this state you try to unbrand on a smuggler station it will not work at all and you will loose access to "sell stolen goods" option until you reload... ...Remember to eject cargo so you have less than 15 types BEFORE attempting an "unbrand" operation.
  25. I found a way that more or less works so I post it here as a code example for ppl interested: -- We check if a wreckage is moving too fast to pursue it -- We use squared distances and functions to reduce computational needs function isslowwreck(wreck) local v = Velocity(wreck.index) if not valid(v) then return true elseif length2(v.velocityf) < 5 * 5 then return true end return false end
×
×
  • Create New...