Creating the topic and reserving posts, will fill in later.
I have a lot of ideas so I rather make one single post with a lot of changes than as many changes.
internal links
Linearize the effects
Abstract
This is about making ships and modules effects bonuses additive rather than multiplicative.
Issues
This aims at addressing the issues :
- stacking penalty is a complex system that aims to reduce the exponential increase of some modules. It is not needed and nobody can tell for sure how things actually work - unless they test that thing specifically.
- several skills/ effect have increased potency the more you invest in them. if you have two modules that reduce cap recharge rate by 50%, and your cap recharge is base 100, one module gives +100, the second one gives +200.
- ability to add specifc effect on weapons, to differenciate them even more
Implementation
We check fist the general formula, and then some specific examples.
The actual implementation must be done on a step-by-step basis. For some effects it’s just not usable
General formula
Instead of using the raw value modified by effects, we use :
effect =
( base + flat_bonus )
× ( 100 + skill_inc) / ( 100 + skill_dec )
× ( 100 + eff_inc × 100 / ( 100 + eff_coerc) ) / ( 100 + eff_red × 100 / ( 100 + eff_resil ) )
, with
- base is the value we have now. It can be or not modified by other effects, which in that case would not be additive. This helps migrate from a model to another.
- flat_bonus is the flat values added. Typically shield extenders’ shield and sig increase go in here, as well as plates’ mass.
- skill_inc is the increase provided by skills.
- skill_dec is the decrease provided by skills.
- eff_inc is the sum of the increase provided by effect.
- eff_coerc is the sum of coercion effect, basically the neutering of the increase
- eff_dec is the sum of the decreases provided by effect.
- eff_resil is the sum of resilience effect, basically the neutering of the decrease
All values besides the base have a default value of 0.
If the effect considered is negative ( sig radius, mass, resonance) then the coercive and resilience effects are swapped.
Example 1 : speed
The propmods are weird so we discard them.
We however consider the speed increasing modules / rigs and the counterpart webification.
Discarding propmods
We don’t consider AB/MWD because they already have a double multiplicative effect :
speed ×= (100+module_mult) / 100 × ship_thrust /ship_mass
- with mass being modified before the speed is changed
- as well as ship_thrust using the module mass and thrust.
So this part is kept as a modification of the base value in the formula.
Overdrive
Let’s consider the overdrive T2. Its attribute is +12.5% to max speed. If we consider the module should be as strong as bow with one fitted only, that is we want parity with one module (p=1), then the new attribute speed_eff_inc of the module, that would also be added to ship when fitting that module, is also +12.5 .
| # fitted | inc% now | inc% change |
|---|---|---|
| 0 | 0 | 0 |
| 1 | 12.5 | 12.5 |
| 2 | 24.72 | 25 |
| 3 | 33.62 | 37.5 |
| 4 | 38.35 | 50 |
If we consider the module should be as strong with 4 modules fitted(p=4), then the new value would be 38.35/4 = 9.59
basically inc = ( ( (100+m) / 100 )^p -1 ) ×100/p for non penalized modules.
this value of p is a choice to be made.
Stasis webifier/grappler
Let’s consider the stasis webifier II with -60% max velocity bonus.
This would affect the eff_dec of the ship targeted. The value to match it is
eff_dec = 100×(100/(100+mult) -1 ), with mult the bonus (here -60).
Table :
| mult (% decrease) | additive decrease |
|---|---|
| -10 | 11.11 |
| -20 | 25 |
| -30 | 42.86 |
| -40 | 66.67 |
| -50 | 100 |
| -60 | 150 |
| -70 | 233.3 |
| -80 | 400 |
| -90 | 900 |
| -100 | +inf |
So basically when changing the implementation, the webifier II get a +150 to speed decrease on target to keep the same effect.
The issue here, is for serpentis effect : +50% to 150 means a 225 speed decrease, which is way below what is required to have the present -90% ( that is, 900 speed decrease). So the obvious change is to add another effect that increases the speed reduction attribute by 500% (150 × 6 =900 )
However, stacking those modules would be weaker,
- now two -50% modules multiply speed by 0.283 ; with that change it would multiply speed by 0.333
- now two -60% modules multiply speed by 0.191 ; with that change it would multiply speed by 0.25
- now two -90% modules multiply speed by 0.0218 ; with that change it would multiply speed by 0.0526
resilience and coercion effects
The overdrive would also provide some speed resilience (like, 25) that would reduce the effect of incoming webs. With 4 modules each with 25 base resilience it means the effect of webs is halved . Different faction modules could have different values for resilience, making more choices available for fitting.
In the same way, different webs/grapplers/burst/scrambler would also apply different speed coercion effect. like base is +40 for M0, +30 for scoped, +50 for T2, and add +10 for navy and +20 for pirate
Example 2 : resonance
It’s pretty much the same as webification before, but simpler because there is no negative effect besides env.
It’s weird because it’s a negative effect , more resonance = more damage incoming. (highisgood=false)
The base is ship_value multiplied by env effect and DC/siege/RAH.
Nothing updates the value with skill so we keep as is (default 0)
What changes however is the effect of rigs/modules that affect “resistances”. Just like the web, a module that has a -20 to armor em resistance would instead apply a +25 to armor_mult_em_eff_dec - effectivelly adding 25% to your rep and EHP on the armor layer.
I don’t think we should add coercion here because it would feel weird.
Example 3 : cap/shield recharge
Only talking about cap, shield is the same.
Cap regen
The present formula is basically
gain = t × 10 × C / T × ( sqrt(c/C) - c/C )
- t the server tick diff
- C the ship max cap
- c the ship actual cap
- T the ship recharge time
There are two ways to increase the recharge (of course at t and c/C given) : increase C or decrease T.
We can translate the decrease of recharge time into actual increase of the recharge rate.
Base value in linear
The base value becomes C/T , with C containing cap battery flat effect and T the BASE ship cap recharge time.
Skill effects
Regarding the skills, we want to have the same effect at max skill level. So the “capacitor systems operation” that give a -25% to recharge time at level V, so a +33.33% to cap recharge rate, should instead give +6.667 to recharge rate per skill level. This translates to a -6.25 reduction to recharge time at level 1, therefore the skill would be more effective at lower skill levels - but the exact same at higher ones .
Modules effect, parity level.
Regarding the modules, we need to know where we want parity. Just like overdrive before, depending on the number of items we want to achieve parity, the new value of each individual item would be different.
A CapacitorControlCircuit T2 is -20% to recharge time, so one module is +25% recharge rate. Two modules however are +56.25% recharge rate, and three are +95% . If we want parity at one module, then the new attribute cap_recharge_increase is +25 ; if we want parity=2, it is +28.12 and for partity at 3 modules, it’s +32.
Basically for an item with multiplier m (here -20) and desired parity at p (eg 3) then the new increase attribute inc should be inc = ((100/(100−m))^p−1)×100÷p .
As many fit use several modules of the same effect for correct usage, I believe a parity of 4 should be used for shield regen and 3 for cap regen. This would however greatly increase the efficiency of the individual modules, typically the CCC for a p=3 parity would go from +25% to +32% effect for a single module fit, that is +28% module efficiency. If we go for parity p=4 then it’s +44% efficiency for a single module (but same efficiency at 4 modules installed)
Migration
Basically, the migration of the modules would be
- add ship attribute and module attribute
- update the recharge formula to take the ship recharge_rate_inc attribute into account.
- add a dogma effect to update the ship attribute from a module
- add the attribute recharge_rate_inc to all items that decrease recharge time, with value based on the parity level expected.
- update those modules to have the new effect and remove the old one.
Opened options
Since the skills effects are now all “positive effect”, it’s now possible to have skills over 5 without imbalance the game (no more -105% to sig bloom for MWD at interceptor VII ^^ ).
The coercion effects can be added to weapon in the game to differenciate them.
- cap coercion can be added to lasers,
- velocity coercion can be added to projectiles,
- local and remote rep coercion can be added to hybrid.
With lower values for smaller guns, like 8/12/18/27 for small/medium/large/XL (+50% per size up)
1 Like
Shield and armor as a partial protection
This proposal aims at making the dual shield and armor tanking viable, while also reducing the effectiveness of one-layer tanks and allow to hull tank.
Basically, no defensive layer (armor, shield) protects the hull from 100% damage. The bigger the layer the more damage is absorbed, and the bigger the incoming damage, the lower the part of damage is absorbed.
There are two models : a base one that is more complicated, but maybe more fair, and a simplified one. In the simplified one, shield does not protect armor ; in the complicated one, shield protect hull and armor, armor protects hull only.
Base model
Formula
Considering a damage ds of a given type (does not matter which) reaches the shield of a ship with shield s, shield resonnance rs ; with armor point a, armor resonance rr ; with hull resonnance rh ; then
- the shield absorbs ds × s / (ds+s) damage, then reduced by its resonance ; the rest, that is da = ds × ds / (ds+s) passes through the shield towards the armor
- the armor absorbs da × a /(da+a) damage, then reduced by its resonance ; the rest, that is dh = da × da / (da + a) passes through the armor towards the hull
- the hull takes dh , then reduced by its resonance.
Example
Considering a ship with 1000 points in shield, armor, hull, and 0.5 resonance (-50% to all resists).
considering an incoming shot of 100 damage.
- the shield absorbs 100×1000 / 1100 = 90.9 damage, which are then reduced by resonance so the shield loss is 45.45 , 9.1 go through
- the armor absorbs 9.1×1000 / 1009.1 = 9.02 damage, again reduced by resonance so armor loss is 4.51
- the hull take the remaining 0.092 damage, reduced by resonance so hull damage is 0.046
Second damage instance of the group
- the shield absorbs 100×954 / 1054 = 90.5 damage, which are then reduced by resonance so the shield loss is 45.25, 9.5 go through
- the armor absorbs 9.5×995.5 / 1005 = 9.4 damage, again reduced by resonance so armor loss is 4.7
- the hull take the remaining 0.1 damage, reduced by resonance so hull damage is 0.05
Simplified model
This simplifies the damage application as all the computations are made in a single pass. However more damage is redirected to the hull.
Formula
Each part of damage absorbed by a layer is equal to layer_hp/(damage+shield+armor).
- shield loses d ×s / (d+s+a) × rs
- armor loses d ×a / (d+s+a) × ra
- hull loses d ×d / (d+s+a) × rh
We can factor the d / (d+s+a) as shared, then layers take shared × hp × resonance as damage, hull takes shared ×d×resonance…
Example
incoming 100 damage, 1000 hp shield/armor, 0.5 resonance everywhere
- first hit removes 100×1000/(100+1000+1000)×0.5 = 23.81 hp to shield and armor, 100×100 / /(100+1000+1000)×0.5 = 2.38 damage to hull.
Google sheet helps makes the simulation
8 shots of 100 damage
That’s basically what happens when a 8-guns ships shoots at that target.
| hit | 1.00 | 2.00 | 3.00 | 4.00 | 5.00 | 6.00 | 7.00 | 8.00 | |
|---|---|---|---|---|---|---|---|---|---|
| incoming damage | 100.00 | 100.00 | 100.00 | 100.00 | 100.00 | 100.00 | 100.00 | 100.00 | |
| shield hp | 1000.00 | 976.19 | 952.41 | 928.66 | 904.93 | 881.24 | 857.58 | 833.96 | 810.38 |
| armor hp | 1000.00 | 976.19 | 952.41 | 928.66 | 904.93 | 881.24 | 857.58 | 833.96 | 810.38 |
| hull hp | 1000.00 | 997.62 | 995.18 | 992.69 | 990.13 | 987.52 | 984.83 | 982.08 | 979.25 |
| shared | 0.05 | 0.05 | 0.05 | 0.05 | 0.05 | 0.05 | 0.06 | 0.06 | |
| shield damage | 23.81 | 23.78 | 23.75 | 23.72 | 23.69 | 23.66 | 23.62 | 23.59 | |
| armor damage | 23.81 | 23.78 | 23.75 | 23.72 | 23.69 | 23.66 | 23.62 | 23.59 | |
| hull damage | 2.38 | 2.44 | 2.49 | 2.55 | 2.62 | 2.68 | 2.75 | 2.83 |
Most of the damage (379 / 400 ) is soaked by the two defense layers
2 shots of 400 damage
| hit | 1.00 | 2.00 | |
|---|---|---|---|
| incoming damage | 400.00 | 400.00 | |
| shield hp | 1000.00 | 916.67 | 834.58 |
| armor hp | 1000.00 | 916.67 | 834.58 |
| hull hp | 1000.00 | 966.67 | 930.85 |
| shared | 0.17 | 0.18 | |
| shield damage | 83.33 | 82.09 | |
| armor damage | 83.33 | 82.09 | |
| hull damage | 33.33 | 35.82 |
Here 330 out of 400 damage is into layers.
1 shot of 800 damage
| hit | 1.00 | |
|---|---|---|
| incoming damage | 800.00 | |
| shield hp | 1000.00 | 857.14 |
| armor hp | 1000.00 | 857.14 |
| hull hp | 1000.00 | 885.71 |
| shared | 0.29 | |
| shield damage | 142.86 | |
| armor damage | 142.86 | |
| hull damage | 114.29 |
Here 285 / 400 damage are absorbed by layers.
Analyzis
The more shots used to apply the same damage, the less % is applied ot the hull. Is it good or bad ? We can always make up justifications later, that what rational means.
What it means is that a high variance makes it more possible to do good damage to the hull.
One shot
If a target is one-shot (by a single damage instance) it means that the damage applied to hull and multiplied by resonance, equals the hull hitpoints h :
d × d / (a+s+d) × r = h
=> d² -hd/r -h(a+s)/r=0
The solution is d = h/2r + sqrt( (h/2r)² + h(a+s)/r ). With 0 shield and 0 armor it becomes d= h/2r + h/2r = h/r = hull EHP. With e = h/r this becomes d = e/2 + sqrt( (e/2)² + e×(a+s) ) = e/2 + sqrt( e×(e/4 + a+s) )
Layer regen
Since it’s not possible to fully protect one’s hull, it needs to gain some regen. I propose a constant armor and hull recharge rate, that is layer_max/recharge_time, with an armor recharge time of 240s for s, 360s for m, 540s for L, 810s for XL ; and triple that for hull recharge time.
This is mere number. Remember that the base value for shield is divided by 2.5 and then again reduced by skills.
Stability
Assuming a layer takes ONE hit with ONE damage type every second, with resonance r, it remains stable if the damage taken by that layer is equals to the regen in one second. regen is then d× h / (d+h+other_layer_hp) × r .
1 Like
Navigation
Several small changes
Common base speed
Small ships go fast, medium go slower, large go very slow, then caps move instant ? WTF CCP ?
=> base warp speed is the same for all ships. A T1 frigate warps exactly as fast as a titan.
Let’s take 4 AU/s as a baseline (cruiser speed).
T2 and T3 ships get 5 AU/s
interceptors, T3 ships with WS sub, angel cartel ships get 6 AU/s
Removal of warp deceleration limit
Just remove it. It means that when you go full WS you enter decelaration after 3s, then you are limited by the deceleration limit only and spend 10s decelerating on the last 6AU. It’s useless.
Delay between warp
The moment you exit warp invul, you have a small delay before entering warp again. Delay increases with ship size ? The goal is to reduce usability, so need, of tactical bookmark.
Removal of insta undocks
When you exit structure or station, you automatically already face your target, in the order
- if you have a fleet in system with a pending order “warp to” affected to your wing or fleet, towards that order (if that order is not the station of course)
- if you have a route set, towards the next gate or dockable of that route.
- if you have a mission in system, towards the closest one
- if you have a fleet, towards your fleet commander
- as usual, using a dock point.
Removal of insta docks
Increase station dock range by 500 m
Better orders
Existing formula
A ships accelerates to a max speed with an exponential formula, this matches a linear friction model with
- T the thrust = Vm×10^6 / i
- R the resistance of the void = V ×10^6 / i
with
- V, Vm are speed, max speed in m/s
- i the inertia modifier of your ship
It matches since at vm=v then both forces are equal value, and at v=0 dv/dt = F/M = Vm×10^6/iM according to Acceleration - EVE University Wiki (derivative at t=0)
Since this is a linear friction model, it means the trajectory can be split on the 3 dimensions. It’s not the case for quadratic friction models, so even if friction is usually quadratic at high speed it’s a simplification that allows for fast computation.
If your ship has a direction (a=angle x-y, b=angle x-z) given, a max speed vm, then the max speed on each axis is
- vmx=vm×cos(a)×cos(b)
- vmy=vm×sin(a)×cos(b)
- vmz=vm×sin(b)
for which you can then apply the formula given on the wiki. We can then talk about vx since that can be later applied to the other axis separately.
Note : this formula works for a and v0 having the same direction (=signum), otherwise you start in the past. So from this formula you can have the vx/vmx (which can be negative), which gives you the time elapsed since acceleration (can be negative if you are going in the wrong direction) with the wiki formula.
using this base time, we have the position on the axis x after time t , Px(t) = d(tx+t)
TODO
Basically change the orbit and keep at range to take target and own speed and acceleration into account. It’s very easy because eve drag is linear, so we can evaluate the function on each axis independently.
Ships role changes
More distinct roles between ship sizes, and also tech roles
Weapon range bonus
remove all weapon range bonus from non -T1 ships. Only T1 ships are designed to have projection.
Basic tech effect changes (general guideline)
- all T2 ships are based on the stats of the T1 version, with a few modification
- T2 “fast” (interceptors, covert ships, BO) have smaller T2 resist increase, +2 AU/s and -25% mass.
- T2 “combat” have the full T2 resist increase, +1 AU/s
- then depending on exact T2 it has more stats like CPU, etc.
Assault ships
- lose any range bonus
- “fast” type have increased speed, reduced sig bloom, increased tracking
- “bulk” tank has increased ADC duration, increased DPS, increased rep.
Change to BC and ds
Basically those ships become “swiss knife”, with increased damage, tank, over their smaller class but with reduced agility.
- each “turret” ship goes to 4 turrets + 2 launchers + 2 utility
- each “missile” ship goes to 4 launchers + 2 turrets + 2 utility.
- DS become as fast as frigate, but less nimble ; BC become as fast as cruisers, but less nimble.
- BC and DS are given a new module : automated defense platform that, when active, behaves like the FOF missile (on each cycle, attacks the closest hostile enemy in range) . The idea is to allow them to defang attacking drones. limited to 2 per ship. One small version and one medium version, with very good tracking , short range, low DPS, but able to 2-shot a T1 drone (except the T1 tanky drone, caldari I think ? Which should be 3-shot).
Drones
Multiply drone capacity by 10. Drones are ammo, they die it’s ok just throw more. Don’t increase bandwith though.
Also increase T1 drones speed by 10% and reduce HP by -25%
T1 are fast, T2 are hard-hitting but slower (but more hps), faction are expensive but elusive, tanky and T1-level DPS.
Then add an option to launch another drone when one dies. with same order, from same group. This option can be activated by group.
However, drones go out limited at 1 every 2 s for small, one very 5 for M, one very 10s for large and sentries.
What’s more, you can only have 5 drones disconnected in space at a time. You can choose if the excess drones become neutral or explode.
Specific bay
Give ALL ship a base ammo bay, also a fuel bay, a consumable bay, and a deployable bay.
Make “specific effect” use fuel : bastion, MJD, cloak use fuel. This means that ships need to operate close to their supply area when working for a long time. I suggest a target resplenish time of 1h. Logistic support ships (command destroyers, command ships and BOps) would have an increased capacity to accommodate resupplying the fleet for longer time
Add a “target amount” option for those bays, also for the drone bay. Those values are those present in a fit, so if I build a fit with eg 10 hobgoblins, then the target amount of hobs is 10 for the ship. And an “repair & autofill” button on stations and structures to automatically take from your own hangar into the ship.
Also make it possible to specify a container as “used to refil” so that refiling takes from that (or those) container before your hangar.
Consumable and deployable bay is important because it allows to specify in the fit and thus, at refil time, what you need to bring. Nothing worse than to realize you forgot to bring the filaments or the drugs or the bubble you just used.
PVP in HS
Rework safety
- remove ability to switch safety to red in HS. You need to find a WH or gate to LS/NS to safety red. Can still suspect.
- FacPo hunts red safeties in HS.
- of course when you lose ship, undock, change ship your safety reverts to green. You can also do it manually.
Loot right not shared among fleet members
When a ship is destroyed, only players that had a timer with the pilot are allowed to loot it. No more waiting with an alt in a DST. If you want to loot, you need to defend the loot until you can come back, or have your alt become suspect.
Of course this means removal of abandoning cans, except those that you dropped yourself.
This should also be applied to PVE. No more alt looting stuff : drop a MTU and come back in another ship.
Prevent overshot gain
This is not only for HS but anti-alpha.
Every second a ship took damage, this ship acquires 4 stacks of “drop ratio”, up to 100 (so after 25s of constant fire).
Every second a ship does not take damage, it loses 1 stack.
When a ship dies, the loot probability for each item is multiplied by the number of stacks and divided by 100. If you alpha a ship, then 0% loot. If you take 13s to kill it with one shot per second, then 50% of the loot.
Drop ratio impacted by ss
This would affect PVE and PVP.
Each system has a wastage ratio. This wastage ratio is 0.5 + truesec/2 : in 1.0 the wastage is 100% : you don’t loot a fthing.
Could also use the present function of reward multiplier (1.63-truesec IIRC) as loot multiplier, but of course divided by the maxvalue (=2.63) . So in 1.0 this would be 0.63/2.63 = 23.9% and in -1.0 100%.
Industry and production
Mutaplasmids
- Players can create acceptance level for couple (variation, mutaplasmid). eg “web T2+ gravid with strengthj >=62” or “web T2 + gravid with 11km range and <50CPU usage”.
- accepted mutations can be put inside fits. stats are defined considering worst acceptable item. (so in precious first case, str = 62)
- Allows to use a mutated item instead of the basic item . So you can use the same broken item again. In that case, the item id remains the same, but the attributes change.
- when crafting using mutaplasmid, let players specify
- acceptance levels used. eg the two previous.
- number of base item used (so max item produced). The first one can be a mutated item to recract, but next one must be the base item of the first one.
- number of mutaplasmids used. The slider has maximum value of number available for player.
- this interface should also give the number of expected result based on the acceptance level. Typically a 3-attribute mutaplasmid that can give -20% to +20% on the three attributes, has a 1/8 chance to produce a mutation with all attributes positives. So if my acceptance is “all positive” and I choose to create 6 items, then it should tell me “average 48 required mutaplasmids required”
- Use system cost index to add tax on mutated items. EIV is adjusted(mutaplasmid)+adjusted(base), multiplier is 1 (not 0.02 like it is for copy/invention/research)
- Also using a mutaplasmid takes an industry job for 1000s/ mutaplasmid used.
Mining
This is a huge one. First we need to affirm our model of mining, what is wrong, what needs to change.
Goals for mining
Mining is an activity that allows players to “mine” asteroids to acquire resources they can then use to build, or sell other players. This is more akin to harvesting than mining.
This activity is aimed as being slow-paced one, with a large amount of resources to avoid competition. NPCs interactions are very limited, however nothing prevents player interactions. This means players can play together or against the others.
However since that activity is very simple, it is also easily botted, removing the tedious of the activity as well as the interactions with other players.
The goal of those changes is to make the activity less tedious and less bottable.
Changes
- Mining lasers automatically switches target when their roid is depleted. They are activated on the closest targeted roid that matches their crystal, if any. This means there is no need for tedious action “click again”. Placement is the key (and target management). Also the server stops the laser from mining a roid whenever this roid is empty (no more mining empty roid unless you are several players on it)
- When someone warps to the mining site, there is a noise (eg small capacitor charging) so there is no need to V every 10s to check if someone is warping.
- When a roid is depleted, it deals 2 instances of damage in a 30km and a 60km area based on target sig(this is to not prevent ventures and drones from being useful) . The wider one deals 4 times less damage (radius ×2). This means, the more grouped you are, the more damage you take. The goal is not to kill ships but to force them to step away. Basically this would deal no damage to hull. Another effect could be to increase laser mining cycle by 50% ? The issue is that this would require more ships, not less. Maybe apply the effect on the beginning of the cycle ? This means you could grief people by activate/deactivate your laser.
- divide the ore per roid by two, multiply the number of roids by two.
Production
Base materials for production and salvaging
Instead of having BASE reduction with ME/TE, make it be a WASTAGE reduction :
- each item has a required quantity of each item to produce it. Typically 80% of the present items requirement, rounded up.
- base waste is 25% ADDED waste on the required quantity. 80% ×(100+25)/100=100% , so actual quantity is the same.
- waste is applied rounded down.
- ME level of BP applies a reduction on those 25% waste : waste = base×100/(100+ME×7) . At ME=10 this gives 0.75+0.25/(1+.7) = 0.897 of present requirements .
- structure bonus apply the same way. instead of 1% reduction in material requirements, we have a 7 reduction in material wastage.
- this allows to research ME above 10.
Same for reprocessing :
- each type has a % wastage. The higher the tech level , the higher the wastage, with a maximum value of 37.5% (to get from 80% minimum required types to 50% present reprocess value).
- When reprocessing an item
- types that are required as quantity 1 are salvaged as their sub types instead . This means that a T2 huggin which requires a bellicose is salvaged as if it required the items of the bellicose instead of the bellicose itself.
- then a wastage is applied, rounded up, based on the % wastage of each type. and applied the scrapmetal skill. The huggin is reprocessed to say 1000 tritanium, tritanium has a 10% wastage, then the wastage of tritanium during reprocessing is 1000×10/(100+1.25×scrapmetal). 1.25 is here to keep same maximum ratio for 37.5% type waste at scrapmetal 5.
- this allows to train scrapmetal above 5.
Market
Tax specifically 0.01 isking
CCP already tried to prevent bots from spamming order updates with relist fees. However, it had the opposite effect, as it made small-order spam and constant babysitting more effective - two traits that are found on bots.
The idea is to be sure players lose money when they cut an order by a small amount. The difficult part is to not make it prone to abuse, eg if a player spams a lot of small orders with varying prices then there is no room for competition.
Implementation : considering a 10% threshold, and only SO orders (almost same for BO but region-wide)
When a player places or update an order, he pays more isk than he would have not gained by cutting under the threshold.
example : there is a 1000 isk SO . I place a 999 isk SO. Then I have to pay the broker an additional fee of basically the difference to the threshold : since I cut very close, then the full difference , that is 10% of my order, will be added to the broker fee.
example 2 : there is a 100isk, 2 volume SO, as well as a 105isk, 2volume SO ; I place a SO of 5 volume at price 99.
- two of my volume are matched against the 2 of the 100isk order : they are 1 isk below, with threshold 10 so a fee of 18 is added for both.
- two of my volume are matched against the 2 of 105 isk : they are 6 isk below, with threshold 10.5 so 4.5×2=9 isk added to the broker fee for both.
- the next of my volume is not matched against an existing offer, so no fee for this one.
This should avoid littering market with small orders, since the smaller your order and the closer to an existing one, the more (in %) your fees will be.
Price randomisation
This is the same problem as above, but a different approach. Instead of adding a tax, we make the price of the order be changed depending on near other orders.
Idea
The main goal is that if you try to cut, then you may fail.
The goals are :
- The more other close orders there are, the higher chance of variation
so that placing a second order to cut has more chance to fail. - The closer we are to other orders, the higher the chance of variation
This means that if you are on the edge of “being close” you have lower chance to be have a change - The bigger the other orders, the more likely yours is changed
This avoids small orders spamming.
Formula
We start with a few definition.
- the close threshold ct is a variable that defines the % of an order into which another one is close. It is default 20%, with a non-alpha skill that can reduce it to 10%.
- the dispersion d is a game variable that defines how much we consider the closeness. typically it is one, and is used to power the closeness variable.
- the proximity p(a,b) of a price b to a price a indicates how close b is to a, in base 1. It is basically (a×ct/100 - abs(b-a) ) / (a×ct/100) , to the power of d .
- the weight *w(a,b)*of an order b to an order a is how heavily the order b impacts the probability of change of the order a. It is p(a.price,b.price)×b.volume_remain . Since we can use 1-item volume, then the weight is a float.
Then, when an order a is created/updated , we find the actual price :
- list all the orders of same type and is_buy_order in the region
- for each order b that is close to a and is not a, assign it its cumulated weight (start weight is 0) cumul(b)
- then add the weight of a (which is a.volume_remain) to the last order cumulated weight to get the cumulated weight of a
- roll a dice between 0 and cumul(a) . The order that replaces the price of a is the one with the highest cumul for which the cumul is < dice. If none, then the price is not changed.
In termes of SQL, this should be something like
select
o.price,
pow( 1 - abs(o.price-price) / (price*ct/100), d) * o.volume_remain weight
from
orders o
where
o.type_id=type_id
and o.is_buy_order <> is_buy_order
and o.order_id <> order_id
order by weight desc
(with a sum over if you want the sum directly)
“order by weight desc” makes it less costly to find the new value if there is a change.
Example
Here we assume a ct=10% threshold and d=1 dispersion.
I want to place/update an order of 10 trit at 3.99 isk while there is an existing order of 10 trit at 4.0 isk. In that case, I have a 50% chance to have my order replaced to 4.0 isk instead : the other order has a proximity of [ (0.399 -0.01)/0.399 ]^1 = 0.975 so a weight of 9.75, while my order has a weight of 10 => 49.37% chance to be changed
Same new/updated order but there also is another order of 10 trit at 4.05. This order has a weight of 10× [ (0.399 -0.06)/0.399 ]^1 = 8.45 . Total weight of all orders is 28.2 so my order has a chance of 10/28.2 = 35% to not be changed.
Constant evolution
This model has two variables (base threshold and dispersion) that can be modified dynamically to prevent people (or bots) from adapting to the known variables, without the need to restart the server. Of course the delay between updates should also be random. Typically a 2-20 threshold range and 0.6-1.5 dispersion range seems good, with an update delay in minutes between 15 and 300(5h) . A 10h-period watchdog should be present to restart the job if it did not schedule itself correctly.
Also, the two variables should be updated in two different jobs (so with two different update times)
If this is not enough, we can add other variables to evolve. eg the self_weight sw multiplies the weight of the new order by this value. Range should be 1-1.5 .
Repeatable orders
Orders have a new “repeat_qtty” attributes. When the order is finished, then a new order is automatically created with the same attributes. For example I can create one SO of 5000 tritanium for 5isk, or one SO of 1000 tritanium and a repeat_quantity of 4000 .
In the later case, if someone purchases 900, the order has 100 remaining ; if the next purchase is of 500, only 100 are taken from the existing order, 400 next are taken from another order, and THEN a new order is created, qtty 1000/100, price 5 , broker fees are deduces, repeat_qtty is 3000 .
This allows to hide what you actually sell.
1 Like
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved
- reserved