Hopefully this will fix the low system memory warning i've been getting in the message centre recently
crafting in hunting
[h=3]Performance Update[/h]
The MindArk development and engineering teams continue to work hard on improving the stability and performance of the Entropia Universe system and to resolve the recent lag issues.
Originally Posted Here
Our primary focus is to solve the remaining performance issues as soon as possible, resulting in other development projects being postponed and/or deprioritized.
Every time I see this I have to laugh... Logic is lost on so many people. The threat with selling your gear is an empty one, since it is zero-sum to the company. You can only sell something if there is a buyer, and nobody buys something they don't believe has a future. The only way to really deprive the company is writing off whatever you spent on it and go on strike or just abandon the game. Who does this, really? See. Now come down from that high horse.
It is implicit in the act of selling that someone else is buying, hence the deposits continue, only with the next one instead. Likely beginning with a healthy chunk if your gear has significant value, while the company keeps sitting on your money for months until payout. The only way to deprive them of continued business is walking away without passing it on, possibly "selling" everything to TT which I don't think was meant here. This would hurt the player more than the company, therefore is unlikely to be executed and the threatening with it inconsequential. People who say this overestimate their leverage. It's like the kid saying "If you don't do X I'll hold my breath until I'm blue in the face." This is what is meant by the "high horse". I don't understand why some read into this I would defend them or deny the problems exist. They do and it's taking way too long and is super annoying and looks unprofessional no matter whether it's anyone's fault or not. Only what I don't assume is lack of motivation to fix it since their revenue must be already hurt because turnover is directly hampered by these technical problems. Claiming "they don't care" as some like to have it is therefore also inconsequential.It is implicit in the act of selling your gear that there will be no further deposits and a large future withdrawal. So It is more than "zero-sum" for the company. I don't think getting frustrated enough because of lag to quit is considered being on a "high horse" either.
ramblings
It's obvious...
Never heard of that one...and i have a "old" pc with 8gb ram,1gb video ram
... lots of things do not occur to people, however, right across the spectrum from muppet to genius.
I am a bit dubious about the increased level of complexity being this, though.
What information was passed on before? HP dealt to mob = update new mob health.
What information must be passed on now? HP dealt to mob (obviously still required) + cost incurred by the player for the action.
In itself I wouldn't say a doubling should create the massive lags, but if the loot server or PED secure server is now involved each shot instead of after a kill once only, then that could be the new massive headache between MA's servers.
If so, the solution would surely be to buffer the cost count on the same system as is monitoring the HP of the mob under attack. If people have not been able to hack the mob hp monitor so far, then I don't see why a cost monitor should not also be safe.
But who knows, and who knows if some sense by some of us may provide the spark that helps them with a solution...?
I'm talking about the loot payback, rather than the actual damage updating.
Before, you would be paid back (or rather, the average would tend to) the equivalent of 3.25dpp. So a 1000 hp mob would have an average loot of 1000/3.25 = 307pec. If you do 2000 damage (even to the same mob via regen, with some upper boundary limits) you would get 614pec. Simple for the system to calculate - it's one data collector (dmg dealt) divided by a static return number, before that number is passed to the overall loot algorithm (the one which gives you a range of loots from novas to ATHs).
Now, the system is actively collecting all costs associated, before modulating with your efficiency number(s), multiplying by .95, then feeding that into the loot algorithm. So you're going from a static input/output, to a dynamic one. The system has to collect all of the costs associated (weapon cost, maybe finisher/tagger costs, armour costs, fap costs) and then feed those into the loot algorithm.
I'm fairly sure this is where the lag is being generated from - it's a (relatively) much more complex system.
Oh, plus, I'm only talking about TT in -> TT out. Who knows what effect the "loot composition" via dpp is having.
Now, the system is actively collecting all costs associated, before modulating with your efficiency number(s), multiplying by .95, then feeding that into the loot algorithm. So you're going from a static input/output, to a dynamic one. The system has to collect all of the costs associated (weapon cost, maybe finisher/tagger costs, armour costs, fap costs) and then feed those into the loot algorithm.
Oh, plus, I'm only talking about TT in -> TT out. Who knows what effect the "loot composition" via dpp is having.
I'm talking about the loot payback, rather than the actual damage updating.
Before, you would be paid back (or rather, the average would tend to) the equivalent of 3.25dpp. So a 1000 hp mob would have an average loot of 1000/3.25 = 307pec. If you do 2000 damage (even to the same mob via regen, with some upper boundary limits) you would get 614pec. Simple for the system to calculate - it's one data collector (dmg dealt) divided by a static return number, before that number is passed to the overall loot algorithm (the one which gives you a range of loots from novas to ATHs).
Now, the system is actively collecting all costs associated, before modulating with your efficiency number(s), multiplying by .95, then feeding that into the loot algorithm. So you're going from a static input/output, to a dynamic one. The system has to collect all of the costs associated (weapon cost, maybe finisher/tagger costs, armour costs, fap costs) and then feed those into the loot algorithm.
I'm fairly sure this is where the lag is being generated from - it's a (relatively) much more complex system.
Oh, plus, I'm only talking about TT in -> TT out. Who knows what effect the "loot composition" via dpp is having.
For this to be true, the lag would have to have started at the exact same time Loot 2.0 was introduced. I can't confidently remember, but I thought the lag started some time later than the start of Loot 2.0.
the model now is not too much different from before. loot before also gave back armor decay partially (has been tested and proven numerous times) and the dpp also had an impact on the return, as shooting with piron ul guns returned more loot on average than an imk2 did.
Yes, what I meant is that collecting all costs involved is a further parameter which needs to be passed on in addition to a damage dealt parameter, so a doubling if collated client-side first, but still pretty static. However, if the server wants to know how you managed to spend those costs as well (percentages on armour, various weap swaps even...), then it does get much trickier - and you are right again to mention loot composition, as it might be what is making the mountain out of the molehill.
Personally I was assuming each mob has an ideal cost to kill known by the server, and whatever the cost the kill works out at can easily be used to determine the composition percentages of good lootoor loot at the same tt.
I thus don't believe the system really needs a dynamic feed of information - more info, yes, but not enough to cause the massive lags if kept clean.
Still, we can assume that you are right, and that loot 2.0 IS the main cause of the calculation lags - but it wouldn't have to be
For this to be true, the lag would have to have started at the exact same time Loot 2.0 was introduced. I can't confidently remember, but I thought the lag started some time later than the start of Loot 2.0.