Jump to content
Game-Labs Forum

Poyraz

Tester
  • Posts

    143
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Poyraz

  1. lets say 200% unrest of the required amount, they might conquer the port with this open sea campaign without the need of a 25 v 25 instanced PB...

     

    This will result in the same 25 1st rates go into pvp around the port. I disagree. PB must dictate the final outcome. 

     

    This will be somehow offtopic, but

    1. It is just a coarse concept model. You can increase and adjust the target values accordingly.
    2. According to your assumption, the points are gained via PvP. Lets think even if so, and the defender won't show up on open sea to counter the attackers, then this means no points for zerg attacker to reach the extra 200% or higher targets.
    3. There is allways the final PB opportunity.
  2. This sounds more or less like the unrest concept in PotBS, which worked OK besides the lottery system to join the final battle.

     

    Stage 1: Constructing the assault project / Building assault fleet / Build up of unrest in PotBS

     

    Attacker tries to rise the unrest point, defender tries to decrease it like in PotBS with activities around the port in open sea as well as in instances around the port. If the attacker reaches a definite amount of unrest, than there will be a PB scheduled 48 hours later. (24 hours would be more responsive though)

     

    I would like to add, that if the attacker goes past a definite percentage of completion of assult fleet, lets say 50%, and the defender than can reduce it again until zero, the port should go under martial law protecting it from an attack for consecutive 3 days.

     

    So, the defender would actually have the opportunity to repel the attack on first stage in open sea.

     

    Also one more target and initiative for attacker might be, if they could reach, lets say 200% unrest of the required amount, they might conquer the port with this open sea campaign without the need of a 25 v 25 instanced PB, where only 50 people have the opportunity to join the war effort instead of many more.

     

    Stage 2: Final port battle in instance

     

    25 v 25 instanced battle for final result

  3. This might be the most modified game mechanic until now and I would like to share some more ideas here. I have seen in different threads similar ideas, and here is my total RoE package for a robust, fun and sustainable PvP environment on the open sea.

     

    The Concept:

    The main difference here for the initiation of OS engagements is, that the location is not only factor for determining the allocation of ships in the instance, but also the time itself.

     

    So, basically after the OS attacking, the instance is created. And any ship, outside this first initiation circle, would be joining to the instance as reinforcements. Until this point, it is similar to the current system.

     

    Ro_A.jpg

     

    The reinforcements on the other hand, would be again positional according to their open sea location, but the reinforcements would be relative further away to the engaging ships in the instance. I would like to use here the term cutter minutes, similar to light years, the distance a cutter would cover in one minute. For example, the first joiner would start in that instance 6 cutter minutes away (outer rims of orange circle) from the engaging ships. The reinforcement who joins after one minute of the start of the instance would be 6+1 minutes away (outer rims of green circle); the one who joins after 2 minutes of initiation would start 6+2 minutes away and so on.

     

    As a result, the more late you join a battle, the further away you would spawn from the initial battle location in the instance.

     

    What would this allow for the game?

    • The open sea battle instances could stay open for much longer times instead of just 2 minutes, which would increase the dynamism and activity of the open sea and rendering it more lively.
    • This would not end ganks, but if a captain is ganked close to a friendly port, there might be a chance for reinforcements to arrive at the horizon
    • On the other hand, it might also lay the groundwork for a good organized gank, using the positional reinforcement. However, the distance to reinforcement point depending on timer (6 + x minutes) would still give a chance for the ganked captain.
    • No BR limits
    • Smooth transition from open sea to the instance
    • Need and thrill of searching the horizon not only in open sea but also in the instance

    Attack Circle and Timer:

    The attack circle on open sea could be adjusted. A relative smaller circle and shorter timer, would increase the importance of the open sea positioning and engaging.

     

    Keeping the Target in Battle:

    At the current state, if you land a cannonball from 800 yard distance on the sails or hull and inflict some damage, you would reset the battle timer for the target. In most cases, this would result in a very long and boring chasing situation.

     

    The current tagging mechanism also gives opportunity to the griefers. To prevent those, a damage threshold could be applied like the need of inflicting minimum 1% damage to sails (or hull) to be able to reset the battle timer for the target. Similar measures were also taken in PotBS to prevent griefing.

     

    Even in the worst gank scenario, this would give the gankers at least several chances to attack the target for resetting the timer, whereas, the target also keeps its fair chance to be able to run away and click out.

     

    Instance Join Timer for Reinforcements:

    The timer for reinforcements could be easily increased in this concept. I would say a time between 5 and 10 minutes might be the optimal point.

     

    Ship Polars:

    Minor changes to the directional speed limits should be made according to the gameplay instead of realism here, I think. This means appointing different best speed directions for different ships, so that every ship could overtake others at a specific direction or similar to that.

     

    If we look below graph, Trincomalee curve (orange) is a good example being at some directions more slow and at some directions relative faster.

     

    graph.jpg

     

    In conclusion, I think all those rules together would render the open world much more lively and active place for PvP and RvR compared to the current situation.

    • Like 5
  4. So, and from that Poyraz exposion ( thanks! ), more speed provokes more pressure, water being water provokes immediate resistance so the turn radius is prolonged to win against that pressure. Lower speeds, less pressure less distance needed. Not sure about the timings if they do the 180º at the same time in reality.

    I do not think is correct is the circle motion and giving wind direction and reverse pull. Should be more egg'ish ?

    Drift (water or air )might be hard as hell to code in. The new IL-2 has it for airflow and sometimes results in odd behaviours.

     

    For the sake of simplicity, I would go with a circle :)

     

    If you would go for more realistic turn route, I would say it would look like more like a spiral shape instead of an ellipse, due to the variying speeds.

    • Like 1
  5. on accel the changes are obvious and they will make ships better

     

    the main question that we are dont have an answer is this

    slow turning vs fast turning on frigates and heavy vessels - how did it work in reality and what was for example the difference in turning radius and turning speed at 5 knots vs 10 knots vs 15 knots

     

    we tried everything to find how it worked then (or how it works now on large sailing vessels) but to no avail

     

    Turn Rate:

    Describing the turning maneuver is quite complex, including also drift in real life and turning around pivot point instead of weight or geometrical cenre. Considering, ships in NA would perform a regular and circular turn maneuver, the turn rate would be defined by the linear speed and characteristic turn radius as in the following formula.

     

    ω = V / R

     

    The linear speed part V, varries according the ships maximum speed, set sail amount, hull resisstance, etc.

     

    The turning radius R is the distance gained during the turning maneuver of the ship. However, it is mostly unique for every ship's hull design. Some of the factors affecting the turn radius are:

     

    1. Structural design and length of the vessel

    2. Draught and trim of vessel

    3. Propulsion power of sails

    4. Distribution and stowage of cargo

    5. Even keel or carrying a list

    6. Position of turning in relation to the available depth of water

    7. Amount of rudder angle required to complete the turn

    8. External forces affecting the drift angle

     

    The only case turning radius R differs from original value is close to the maximum speeds, due to the interaction between hull and water.

     

    According to those basic rules, there are two approach for implementing the variation of turn rate of a ship for different situations.

     

    A. Constant turn radius:

    With a constant turn radius, turn rate only depends on the speed. Slower speeds slower turn rate, higher speeds higher turn rate. Turn radius stays the same for the given ship. To implement the below formula can be used, where speed V is variable and turn radius R is constant.

     

    ω (V)  = V / R

     

    kuDKlDg.jpg

     

    B. Turn radius depending on speed:

    Like in real life turn rate depends both on speed and turn radius, which also changes according to speed. High speeds means higher turn radius, slow speeds means shorter turn radius. This approach is little bit complex, but on the other hand it might add the realism and depth in turning maneuvers. For this approach both speed and turn radius are variables in the formula to define the turn rate.

     

    ω (V, R)  = V / R

     

    The speed variable depends on the given ship, its maximum speed, its set sail percentage, hull resistance, ships polars (wind direction), etc, most of which are already implemented ingame.

     

    The turn radius variable depends on if the ship is sailing close to maximum speed or not. To define this change from the data here with a regression analysis, I would propose the following formula to define the turn radius over speed to get a curve as following. However, custom values can be added to modify a curve like this one, too.

     

    R (V)  =  ( -V2 / 125) + (V / 4)

     

     

    U33AlxF.jpg

     

     

    This simulates the turning radius at max speed larger and at slower speeds smaller. The turn radius and also turn rate can be shifted up at 0 speed to allow turning at land crashes, fully demasted situations, stucked at shallow positions and for other gameplay issues.

     

    With a varrying turn radius depending on speed, captains can adjust their turn circles according to the speed of their ships. It is more realistic, and also indirectly simulating the drift at speeds closer to the maximum speed. It would allow much more depth compared to the constant turn radius.

     

    If the turn rates would be according to the constant turn radius, the ship would sail on the same circle undepended from its speed. The speed would just change the time it takes to complete the maneuver.

     

    jjL1urC.jpg

     

     

    Conclusion:

     

    Finally, the change of turn rate over time should be similar to the graph below including acceleration and deceleration like in linear movement. I would presume a time between 2 to 8 seconds to gain maximum turn rate from Cutter to Santisima would be a good point to starts. This time is depending on the turn acceleration of the specific ship.

     

    Turning acceleration combined with linear acceleration would describe how agile a ship would be. Maximum speed at specific polars and turn rate are another criteria for defining the ship's limit speeds. Those two combined together with armor and gunpower values would allow to differentiate every type of ship with its advantages and disadvantages.

    wWUjIBP.jpg

  6. High speed = fast turn, large radius

    Low speed = slow turn, small radius

    With manual sails, anyways. Slow speed rudder-only turns should have large turning radius as well.

    Ryan confirmed this via PM once upon a time.

    And of course some ships weren't trimmed right and like to ignore the helm. Many French frigates loved to tack but hated to wear.

     

    Condisering the hydrodynamics (hull underwater) and ignoring the aerodynamisc (sails);

     

    If the interaction between water and ship hull would be constant, the turning radius would be same both for slow and high speed levels. At slower speed the ship would cover the same route but in longer times, which means slower turn rates. (degree/second). At higher speeds the ship would cover the same circle in shorter time, which would lead to higher turn rates. That is because turn rates describes the covered angle in a definite amount of time.

     

    However, in reality it is much more complex. While the speed gets higher, the interaction between hull and waterflow changes between laminar and turbulent flow range. This effecting the drag at hull and rudder, the turning circles might differ at maximum speed.

     

    To define the changing of the turning circles with the current model, the concept drift has to be introduced as well followed by turning around pivot point.

     

    At this point, I would assume going for constant turning circles together with varying turning speeds is the easy and lean way to go.

     

    PS: Some sea trial results could be found here. The turning radius is approximately same for all speed but maximum speed.

  7. on accel the changes are obvious and they will make ships better

     

    the main question that we are dont have an answer is this

    slow turning vs fast turning on frigates and heavy vessels - how did it work in reality and what was for example the difference in turning radius and turning speed at 5 knots vs 10 knots vs 15 knots

     

    we tried everything to find how it worked then (or how it works now on large sailing vessels) but to no avail

     

    You are right, there are so many parameters that even nowadays turning behaviors are defined after real sea trials. (Unfortunately no chance to sail Santisima or Victory today, but their replicas might give some insight) For instance, the rudder is only a trigger and has the duty to initiate the turning in a turning maneuver. After that the hull at bow below waterline acts as a huge shovel itself and rotates the ship's huge mass. The rudder ratio and hull shape are just two of many parameters in turning which are also mentioned here.

     

    Although the simulation is complex, one might say that the correlation between ship speed and turning could be defined as a second degree quadratic function. That is because the forces acting on rudder and ship's hull are changing depending on square of speed, V2.

     

    For example:

    5 knots => 1x turn rate

    10 knots => 4x turn rate

    15 knots => 9x turn rate

    • True. No arguing that.
    • Disagree. Adding variety on top of variety (turn acceleration on top of max turn speed) suffers from diminishing returns and thus ends up barely noticeable. Ships keep their "nible" or "bricky" status, as is now. 

     

    It has been done before. Have you ever played PotBS?

     

    All the time, it has been linear and angular acceleration, which were giving the characteristic and unique sailing profile to every single ship, not the linear or angular speed limits.

     

    If you make games with speed as control parameter and input, you will end up in arcade games.

     

    If you make games with acceleration (aka force) as control parameter input, you will end up in simulation games which are closer to real life pyhsics.

     

    • Disagree again. As above - the change wouldn't be big enough to change the current system. There are already more and less nimble vessels, claiming varying their turn acceleration will somehow completely change meta is ignorant.

     

    I am not just making some random number crunching. As I said, it was done before, compare trying to maneuver a SOL in PotBS and you will understand what I mean. In NA, rudder combined with manual sails, the SOL's are maneuvering like a charm at the moment.

     

    However, I know it is a matter of taste. Some people might like the concept of a truck accelerating as fast as a Formula1 car.

     

    On the contrary, I find it quite unreasonable and unrealistic.

     

    And for the meta concept of the game, soon everyone will be sailing Victories and Santisimas (somehow already) and currently there is no incentive to sail other ships than those first rates, but the fear of loosing the only one durability. Turning acceleration is one of the concepts which can create the dilemma of firepower-maneuverability for more variation.

     

    And due to all that I raise a question - are there really any improvements brought by this system that would excuse further slowing down of the gameplay?

     

    I raise another one - how does that "time to reach steady phase" translate into time-warped nature of NA? Would it even be noticeable within sped up time?

     

    Variety and diversity!

     

    If we read the turning graph in OP, we can see that the time up until the rudder fully deflected is much more shorter than the time until steady phase. We can assume it takes 10-15x more time than turning the rudder completely.

     

    Here we have already made a basic concept. Currently, turning the rudder takes approximately 1-2 seconds in game. This leads to the time until steady phase might be between 10 and 30 seconds. However, this is unique for the ship described in this graph. Every single ship would have its own turning graph in other words turning characteristics.

  8. The main idea here is to modify the behavior of ships during the turning maneuver, so that the turning would be simulated more realistic and intense like in real life, which would also bring much more variety and another dimension into the sailing, specifically in turning maneuvers.

     

    Turning Acceleration vs Linear Acceleration

    Currently ingame, the maximum turning speed of different ships vary according to the ships features and different sizes. The turn speed variance makes different ships feel like turning faster or slower. A Santisima is turning slower than a Cutter, which makes sense.

     

    However, there is a problem with the current turning dynamics. Currently in game, when you initiate a turning with A or D keys, the ship waits like 1 second and then suddenly reaches its maximum turn rate. This is the same for all ships from Cutter to Santisima.

     

    On the other hand in real life, there is another dimension than the speed itself. It is the acceleration. In analogy with linear acceleration, when an object starts turning, it builts its turning speed in a definite period of time according to the torque/moment applied on it. The similarity between linear and angular motion is also listed in below formulas.

     

    Now, If we compare the current turning speed with linear speed of the ships, it would mean that ships would reach their maximum speed in 1 second after they set full sails. A Santisima reaching 10 knots and a Cutter reaching 12 knots in one second after pressing the W key, which results in unrealistic and arcadish behavior. In other words, when you set sails, it takes some time like 40-50 seconds to achieve the maximum speed depending on the acceleration of the ship. As in linear motion, it is similar in angular motion. So, when you begin your turn, it would take some time up until you reach your maximum turn rate.

     

    331249.image4.png

     

    Turning acceleration is what we are lacking right now. This is the exact reason why turning ships in Naval Action feels kind of arcadish.
     

    Real Life
    In real life, it would take some time as shown in the graph below to reach a constant turning rate( r ), which is phase 3. During the phase 1 and 2, the turn rate increases for a definite amount of time.
     
    The dh graph here is the rudder angle. The turning behavior currently ingame, represents actually the change of rudder angle. As you can see from the graph, you won't reach to your maximum turning rate, as soon as the rudder is turned to its maximum angle. Some period of time had to pass by, until the ship responses on the deflected rudder angle.

    zewpTij.jpg
    Comparison
    Finally, I would like to add a comparison between the current turning behavior and the suggested one. As seen in animation below, the ship on right builds slowly its turn rate and after some time it reaches its maximum turn rate and it begin to turn with a constant turn rate. On the other hand, the ship on the left begin to turn with constant turn rate slightly after the start of the turn, which is the current state in NA.
     
    Turning acceleration feature if added, would add:

    • much more realistic ship behavior while sailing and turning,
    • much more variety to the ships, and each ship will have its own characteristics for turning. (Even similar ships with same maximum speed and maximum turn rate, one has higher turning acceleration than other. Even this would make the ship with higher turning acceleration more agile and nimble ==> much more variety)
    • a gain/loss factor for all ships, for instance a ship of line would bring more gun power in return of slower turning, whereas, frigates and smaller ships would act more agile and nimble in return of less armor and guns. (Not everyone would rush for biggest and strongest ship, which is Santisima right now. Some could use the maneuvurability of the frigates, some could chose sheer firepower of rated ships => much more variety and less monotony like Santisima spamed PB's)
    • Captains would need to plan their turns and moves in advance bringing more strategy and depth to sailing.

     

    This suggestion is actually the last part of the feedback for sailing dynamics in this thread.
     
    There were many other parameters mentioned in that thread, however, in my opinion turning acceleration is one of the most important concept which needs to be implemented to NA.

     

    d5dDziz.gif

    • Like 16
  9. Please remove the Nation tag when the smugler flag is enabled.

    and make it possible to get permanent upgrades when braking up a ship. e.g If I by dump luck :-) manage to capture an eceptionel player ship with eceptionel perm upgrades, I should be able to salvage them if I deside to break up the ship. maybe at one lvl lower, so an eceptionel upgrade would give you an mastercraftet after salvage

    This would just not work. With a 5 dura frigate, even if you won't salvage it, you would dublicate this permanent upgrade 5 times into the game world.
    • Like 1
  10. Kudos on your nice analysis Poyraz, this was an interesting and enjoyable read! ;)

    I am not a programmer, so this is a light suggestion: If you are going to simplify the spotting range in order to unburden the servers (as mentioned in the last paragraph of your analysis), then why not just eliminate htarget as a variable, and assign it an average value for simplicity, or at least assign it one of two predetermined values based upon the class number of the approaching ship? Class 1 through 4, and then 5 and above, for example.

    Thank you Jean, I am not a programmer myself. Regarding to your suggestion; the spotting range should definitely include the htarget, hence the Dtarget. The outer rim has the probability to have all type of ships inside, so it must be designed according to the tallest ship - worst case scenario - in the game. (However, a similar modification of Dtarget as in next pharagraphs can be thought)

    Lets assume we made it according to an average value or more specifically according to a 3rd rate. If there is a Santisima entering within the maximal visual range area that should be visible to the observer, but due to the average spotting range this Santisima won't be rendered by the client.

    On the other side of the coin, the distance to the horizon Dobserver would vary from ship to ship due to the height variance. The higher crows nest, the more Dobserver which results in wider inner rim and longer horizon line.

    Range_Cutter_Santi.jpg

    I think that we can't see far enougt in open sea for this features.

    Maybe if the range of view is increased and if telescope are added for open sea that could make a sense, not otherwise.

    I totally agree, that the view & drawing distance of the ships should be increased. The instant appearance of the ships is also disturbing the immersion.

    However, increased range would also cost some performance. A middle way should be found.

    The original post was set up according to the hardcore realism philosophy of Naval Action. However, there are different ways to overcome the cost of increased extra range. One of them is manipulating (scaling) the distance beyond the horizon (Dtarget). This distance might be set to a constant value or a percentage of the Dobserver. (Those will be still in reference to the tallest ship, Santisima for instance)

    In real life, the observer standing still and the target sailing with constant speed to the observer, the distance and time from point 1 to 3 is the same as from point 3 to the observer. However, the distance and dependently the time from 1 to 3 (outer rim) could be decreased lets say from 4 minutes to 1 minutes sailing distance for this instance, whereas the horizon distance (inner rim) would stay the same as 4 minutes.

    So, instead of a 8 minutes sailing equivalent spotting radius, we would end up with a 5 minutes long spotting range. The incremental appearance of the ship would happen in 1 minute instead of 4 minutes, but this would still be better than an instant appearance. The increased ship location data transfer would also be relatively reduced.

    What we traded off for this modification is below right picture. From point 1 to 3 (beyond the horizon), the shape of earth is changed into a more steep curve, whereas, from the horizon to the observer (onward the horizon) it is still realistic earth-like curvature. This, I think, is barely perceivable by players in ship cam mode.

    Reduced_Beyond_Horizon.jpg

    Last but not least, the drawing distance of the ships should be as close as possible to the horizon line of the game engine.

  11. The main idea here is to virtually simulate the curvature of earth in a 2D plane sea surface. To achieve this the z-axis (height) of the ships would be modified according to the x and y coordinates on the sea surface. So, at long distances only some part of masts and sails would be visible, whereas, at closer ranges whole ship would be visible.

    There have been a few other threads about the implementation of earth's curvature with pro and con arguments from players and developers. Here, I would like to discuss the concept, the model and the requirements in detail to evaluate the suggestion in every aspect.

    The Concept:
    Currently, the ships appear instantly in Naval Action as soon as they are in spotting range of the observer.

    Due to the round shape of earth, one should first see the top mast of a ship on the horizon. When she gets closer, you would see the whole mast and sails and finally the whole ship on the horizon line. If added this feature would bring more:

    • Realism via simulating earthlike curvature effect,
    • Immersion through searching for sails and flags on the horizon, seeing the ships behind the horizon incrementaly appearing,
    • Enhanced gameplay using the stealth effect behind the horizon,
    • Variety of ship features; the higher crows nest at the mast, the further the spotting for each different ship,

    However in trade of those gains, the effect on the server-client traffice should also be considered.

    The Model:
    Before going further, the parameters for defining the horizon, spotting distance, view of closer and longer objects can be seen in below wiki page.
    https://en.wikipedia.org/wiki/Horizon

    Now, the point 3 in below picture is where the horizon is laying for the observer (as well as the horizon point for the target for this instance). The points 1 and 2 are laying behind the horizon line for the observer, however, due the height of the target some parts of the mast might be seen even if the target is further behind the horizon. After ship passes point 3 and approaches to the observer like at point 4, the target is fully visible before the horizon line for the observer.



    Horizon2.jpg


    After ignoring the atmospheric refraction for the sake of simplicty, we end up with a spotting range of

    image.jpg

    Here, the spotting distance depends both on the height of the observer as well as the height of the target. Assume that an observer in the crows nest of Santisima which is 40 meter higher than sea level. He would have a horizon distance of 22,6 km.

    Now the target, he is trying to spot has 40 meters height masts. Although this target is behind the horizon line, due to the height of the target, the observer can spot that ship from 43,2 km distance.

    For point 2, how much should be the model brought down, is depending on how far it is from the observer's horizon line. Lets say target is 32,6 km further from the observer. The target lies 10 km behind the observers horizon line. According to the formula below:

    image.jpg

    only 7,8 meter from the top would be visible to the observer. So, the adjustment for z-axis would be 7,8 - 40 = - 33,2 meters.

    The Requirements:
    To implement this spotting concept, there has to be 2 different ranges which determines if the ship models should be brought below sea level or not. (if the target is further or closer than the horizon line)

    All location data of the ships within the maximum visible range will be shared with the client.

    Client would calculate, how much the rendered graphics of the ships laying further than the horizon of the observer (Dobserver) should be brought down on z-axis according to the formula above. No need to share the extra z-axis coordinate from server to the client.

    This script should be disabled as soon as the home key pressed for free camera. (Otherwise ships might be reported raising from the depths like Black Pearl)

    For a good visual impact and consistancy, the graphical horizon distance of the game (within the unity3d) and the spotting horizon of the observer should be as close as possible. The ideal is if they are exactly the same. However, due to performance issues the horizon of the observer might be held smaller in order to keep the data traffic relative low. An optimization of performance and visuality should be done here by the devs.

    Range.jpg

    • Like 11
  12. Another vote for increased view distance.

     

    Further enhancement could be applied for curvature of earth effect for hardcore realism. Considering z-axis being the height, the drawing point could be adjusted accordingly.

     

    x is observers height;

    y is targets height,

     

    The drawing distance would be dmax = 3,57 . {( x ^1/2) + ( y^1/2)}

    Horizon distance for x would be dx = 3,57 . ( x ^1/2)

     

    From the maximum distance dmax,  up until dx, the target y will be incremental increasingly visible.

    From dx up until next to the observer, the target will be fully visible.

     

    This basic formulas would simulate the view distance realisticly.

     

    Some RL values,

    • For an observer standing on the ground with h = 1.70 metres (5 ft 7 in), the horizon is at a distance of 4.7 kilometres (2.9 mi).
    • For an observer standing on the ground with h = 2 metres (6 ft 7 in), the horizon is at a distance of 5 kilometres (3.1 mi).
    • For an observer standing on the mast with h = 10 metres, the horizon is at a distance of 11,3 kilometres (6.9 mi).
    • For an observer standing on a hill or tower of 100 metres (330 ft) in height, the horizon is at a distance of 36 kilometres (22 mi).
    • For an observer standing at the top of the Burj Khalifa (828 metres (2,717 ft) in height), the horizon is at a distance of 103 kilometres (64 mi).
    • For an observer atop Mount Everest (8,848 metres (29,029 ft) in altitude), the horizon is at a distance of 336 kilometres (209 mi).
    • Like 1
  13. Limiting sides 1x vs 1,5x is quite OK for now.

    The ratio could be increased from 1,5 to 1,8ish though, whereas for small group pvp it still means two of the same tier ship can not gank one alone same tier ship. On the other hand for larger groups, it might still be more risky to fight 10 vs 18 instead of 10 vs 15 ( Assuming all same BR ships). So, it can also make the ganking fanatics less angry.

    Finally, the battle timer should be increased to 5 minutes again. Since the primary battle size condition is now BR limit, not the time.

  14. The other day, I was missioning under dutch flag around south of Fort Zoutman in a 3rd rate against a NPC pirate 3rd rate.

     

    Just after the timer ends, two pirate; Captain Reverse (Surprise) and Toothless Jack (Renomee) entered the battle instance. After spotting them, I instantly tried to disengage knowing that there is no chance to outrunning them. The only thing might be splitting the NPC 3rd rate, but it didn't work as well.

     

    They had kept pouding the stern and ripped of until the aft cannons are gone and than I turned into them to exchange the broadsides instead of sinking without a fight. In that 1v3 instance, the Renomee kept stern raking while the Surprise worked on my sails at long range and NPC 3rd rate on my hull. Thanks to the brick 3rd rate, I could only return one broadside of cannonballs against their 4 or 5 landing broadsides.

     

    But in the end they got on very low armor, but still kept closing greedly tanking with their bows. After some minutes, both Surprise and Renomee were below 5% armor on all sides and disengaged in different directions. There, I was sitting with no sails and half armor, but was able to keep the Renomee in battle until it sinks. The surprise going other direction could click out the instance.

     

    In the final, the npc gave me the window to click out after a fully missed broadside.

     

    It was a 70 minutes long, fun and intense battle. In the end pirates were defeated from the dutch waters, at least for that instance :)

     

    /gf and tiphat

     

    Screenshot_23_03_2016_00_35_31.jpg

  15. Historically in the English Navy any captain who lost his ship by choosing to fight against much larger odds would have to face a court-marshal

     

    Nelson took this risk at Trafalgar with the odds 33 vs 41 ships (19,5t vs 28,3t broadside weight) fighting outnumbered and outgunned.

     

    If he would lose the battle or his ship, he would have faced the court-marshal. But the risk he had taken, has maybe changed the history and gave him the present reputation and fame.

     

    Do you think it would be the same if the brits had 41 ships versus 33 ships of franco-spanish fleet?

     

    The answer is the very risk/reward gain proposed in this thread.

  16. This is a suggestion against ganking and to increase low risk/gain ratio in uneven PvP situations to create more incentive to fight instead of running away in different ad-hoc OS fight scenarios.

    If a battle rating system to enter instances, like the group strength in PotBS, might be added or not, is irrelevant for this concept. Here the battle ratings are being used to dynamicly adjust the XP and gold gain in various OS PvP fights.

    Dynamic PvP Reward System:

    After the battle is closed, the battle ratings for both sides are being used to calculate an extra PvP loot factor according to the BR ratio (Battle Rating) both for XP and gold. Lets say you are in a 3v1 battle and battle ratings are 200 for the attacker and 100 for the defender (one ship). The lonely ship might have a slight chance to sink enemy ship(s), but usualy this risk won't be taken by the majority of players. However, according to the extra loot factor introduced here, whatever damage he does, he could get double XP and gold for his efforts due to the fighting in an outnumbered and outgunned situation. On the otherside of the coin, each player of the ganking side would recieve half of the XP and gold compared to if they would sink the same ship in an even fight.

    To sum up, in a 200/100 ratio battle, this concept means double XP and gold for the defender and 0,5x less XP and for both attackers.

    PvP Loot Factor = BR of your team / BR of opposing team

    Final XP/Gold = Current Loot Gain / PvP Loot Factor

    Table

    Different scenarios can be seen from the table/graph.

    Graph

    This could be enough incentive to demote the ganking, however, if the ganking still occurs, this would also give the ganked side a reason to fight back despite the fact being outnumbered and outgunned.

    An example for the realization of similar concept, the Microsoft Gaming Zone used to have similar rating system for many years, for instance in the legendary Age of Empires series matchmaking. The proposed loot balancing/stabilizing concept according to battle ratings would be a nice feature for the good of the game.

    Poll removed by mod team for being non-essential to the discussion.

    • Like 10
  17. I have the same problem. Connection queue request failed.

     

    I have tried deleting the following lines and reinstalling the game. Neither of them worked.

     

    Any other tricks to overcome this error?

     

    Yarev, apologies for the delayed response.
     
    In your computer will be a log file.  I need you to please post an example so we can start troubleshooting.
     
    The log file is located at: C:\Program Files (x86)\Steam\steamapps\common\Naval Action\logs
    The file is called custom_log.txt.
     
    I need the following section (just one, not the entire log file):
     

    Please delete the same sections I did above, or you can PM it to me. Thanks.

×
×
  • Create New...