Rebalanced Mission Rewards

[M Rufen Power]

That's not cool, IMO. Yet another nerf to deal with.

Just deal with your decision to lay back. I wish people would sometimes snap out of the nerf dilema, not everything is a nerf per say. For me the solution is simple, just get on with what you have. I don't care about attributes anymore but pure skills so I won't be picking the token options. In the end I have my own agenda besides a dev's adjustments. Just enjoy the game which ever way you can.

 

[Joat]

It has to be the token trader that is the problem. We already gain fractional attributes all the time. It shouldn't be that hard to change.

Wouldn't suprise me if the progress process is a seperate part, and the value
we use are integers that isn't influenced by the actual value in the progressbar.
100MT(or any value MA see fit for a increase) can only increase the integers,
it doesn't increase the progressbar.
Well, this is just a theory, but it should fit why we only can increase integers,
and not parts of it.

 

[Coelacanth]

It is a change that had to happen though.

As it was, at least one planet partner was giving more and more attributes as rewards for super easy missions. Had that been allowed to continue, we would soon have people travelling around to different planets and getting 100+ in all attributes within a few months. All work and accomplishment in skilling up high attributes would disappear.

True, but I guess I see it as my accepting a mission is like accepting a contract. I accepted it based on reward "X", so any missions I was in the process of accomplishing should've delivered the promised rewards--at least up to the current approaching stage of that mission.

MA should've honored existing missions that were already begun without changing the rewards, and only nerfed/changed rewards for all missions that hadn't been started yet.

 

[Serica]

It has to be the token trader that is the problem. We already gain fractional attributes all the time. It shouldn't be that hard to change.

Kim has said:

With current technical limitations it wasn't possible to make the quest reward fractional stat points, I'll put in a request to add support for this in the future.
...

so there is a chance for future change.

...

MA should've honored existing missions that were already begun without changing the rewards, and only nerfed/changed rewards for all missions that hadn't been started yet.

We were given FIVE MONTHS notice of the intention to change the mission rewards, and the Calypso development team went well out of their way to run special spawns of darn near everything to make it easier for anyone to finish the missions they wanted to in that time. I've never seen them bend over backwards so much to help the players adapt to a change.

 

[Talania]

We were given FIVE MONTHS notice of the intention to change the mission rewards, and the Calypso development team went well out of their way to run special spawns of darn near everything to make it easier for anyone to finish the missions they wanted to in that time. I've never seen them bend over backwards so much to help the players adapt to a change.

Five months is maybe an okay time if you have an unlimited ped card and 6 hours or more a day to grind them but not everyone has an unlimited ped card or that much time. It was a very drastic change that could have been done differently.

 

[Fifth]

He seems to be saying that you can't have 99.5 agility and just turn in 50 agility tokens to get to 100, because it's not possible to turn in only 50 tokens, they have to be turned in 100 at a time. So he also seems to be saying that you will always be stuck at xxx.5 agility in this example because it's so hard to gain agility naturally at that level, so the .5 part of that agility is wasted.

Exactly.
This explanation is too good actually, now even all the casual players can understand it..

Well, the token system itself was a step forward, no doubt.
If they would now make us able to add tokens one by one it would be perfect.

 

[jaywalker]

We were given FIVE MONTHS notice of the intention to change the mission rewards, and the Calypso development team went well out of their way to run special spawns of darn near everything to make it easier for anyone to finish the missions they wanted to in that time. I've never seen them bend over backwards so much to help the players adapt to a change.

Five months is maybe an okay time if you have an unlimited ped card and 6 hours or more a day to grind them but not everyone has an unlimited ped card or that much time. It was a very drastic change that could have been done differently.

Indeed. It took me nearly a month of full-time-play, and lot more PED than I normally spend to complete just one of the 10k missions...one that I woukd have approached in a very eco-conscious way if not for the announcement.

Also , those who bang on about all the notice we were given tend to forget that no details of the changes were released til the last minute and they contained a number of completely unexpected changes. Thus those of us who took advantage of the mission spawns,often found that we had made the wrong decisions as to which missions to complete. You have to admit it was daft, to say the least, to give us that opportunity before releasing the appropriate information


I might add that many of us had several of the longer missions open, and did intend to complete them all. As many of the missions mobs were not worth hunting except for the reward at the end, it was a blow to find that we'd wasted our PED on getting as far as we did, because the new rewards just didn't offer sufficient incentive.

jay

 

[Joat]

Exactly.
This explanation is too good actually, now even all the casual players can understand it..

Well, the token system itself was a step forward, no doubt.
If they would now make us able to add tokens one by one it would be perfect.

Lets hope they do find a solution for us to increase attributes with single MTs, but as
I wrote in the other post, 100 MTs probably increase the integers.
With current system I guess they have to give MTs a tt-value similar to a skills and skillchip
if it gonna work to increase attributes with a lesser value than 100 MT, but that will do
so 50MTs for someone with 40 agility will get a very different increase than someone
with 120 agility.
My guess is that the system for skills and attributes do only handle integers from fixed values,
while the system for prof stands and HP are able to handle percentage.

 

[Fifth]

Lets hope they do find a solution for us to increase attributes with single MTs, but as
I wrote in the other post, 100 MTs probably increase the integers.
With current system I guess they have to give MTs a tt-value similar to a skills and skillchip
if it gonna work to increase attributes with a lesser value than 100 MT, but that will do
so 50MTs for someone with 40 agility will get a very different increase than someone
with 120 agility.
My guess is that the system for skills and attributes do only handle integers from fixed values,
while the system for prof stands and HP are able to handle percentage.

Oh it isn't really that hard to implement.
100 attribute tokens already works as a relative value - relative to one full attribute point, no matter how many attribute gains would be needed to fill it.
Following the same logic, if 100 tokens gives 1 full point then 1 token can give 1% of that - no matter if u at lvl 40 or lvl 120




ok ok, i admit, it's actually just a bump for this thread

 

[valentin]

Stange that Protoron mission dont has any attributes to give.

 

[Joat]

Oh it isn't really that hard to implement.
100 attribute tokens already works as a relative value - relative to one full attribute point, no matter how many attribute gains would be needed to fill it.
Following the same logic, if 100 tokens gives 1 full point then 1 token can give 1% of that - no matter if u at lvl 40 or lvl 120




ok ok, i admit, it's actually just a bump for this thread

I doubt it works that way so you could increase the progressbar value in per cent atm,
my guess is that they use the integers for the increase now.
But it should be possible to solve this with some new code thou'.
So maybe in 2018-2019 we'll see a solution for this...

 

[Xen]

I doubt it works that way so you could increase the progressbar value in per cent atm,
my guess is that they use the integers for the increase now.
But it should be possible to solve this with some new code thou'.
So maybe in 2018-2019 we'll see a solution for this...

Don't understand this thinking at all.

It's obvious that attributes are not measured in just integers, otherwise how would they display progress?

So it's really simple, you turn in 10 attribute tokens, you get .10 levels of that attribute.

 

[Audrey Cheerful]

Don't understand this thinking at all.

It's obvious that attributes are not measured in just integers, otherwise how would they display progress?

So it's really simple, you turn in 10 attribute tokens, you get .10 levels of that attribute.

Really, no matter how it is represented in their database, there is absolutely no technical reason why this shouldn't be possible.

 

[Joat]

Don't understand this thinking at all.

It's obvious that attributes are not measured in just integers, otherwise how would they display progress?

So it's really simple, you turn in 10 attribute tokens, you get .10 levels of that attribute.

Ok, just as an example, so don't hang up on these values I use as they are just
to illustrate what I mean..

Player1 has 20agi, Player2 has 120agi. They both use same type of gun.
They happens to get a increase with same base value (as skills has different values
for gains, I guess attributes might have them too.)
Lets say that value is 3,2.
Player1 has a slowdown limitation of 100, while Player2 has a slowdown limitation
of 10000. So Player1 gets a increase of 0,032 while Player2 gets a increase of 0,00032.
These values are the ones to increase the progressbar for the next point atm, there
are no code to handle a percentage of this increase.
Thats why I say they use integers since there is no need to recalculate the increase
between Player1 and Player2.

So, this is basicly about the system to increase values that limits the increase
from MTs, not values used for various features, such as HP and so on.

To fix this so 10MTs could be used for a increase of 0,10 they have to create code that
recalculate the slowdown so it gets right no matter what point we are at, otherwise
would Player1 get 0,001 and Player2 will get 0,00001...
It's not a big thing to fix, it's just that it doesn't excist today.
Well, this is how I see it ofc, could be another reason thou'... but if they do have
a code that can handle this, wouldn't we have that type of increase already?

 

[Talania]

Ok, just as an example, so don't hang up on these values I use as they are just
to illustrate what I mean..

Player1 has 20agi, Player2 has 120agi. They both use same type of gun.
They happens to get a increase with same base value (as skills has different values
for gains, I guess attributes might have them too.)
Lets say that value is 3,2.
Player1 has a slowdown limitation of 100, while Player2 has a slowdown limitation
of 10000. So Player1 gets a increase of 0,032 while Player2 gets a increase of 0,00032.
These values are the ones to increase the progressbar for the next point atm, there
are no code to handle a percentage of this increase.
Thats why I say they use integers since there is no need to recalculate the increase
between Player1 and Player2.

So, this is basicly about the system to increase values that limits the increase
from MTs, not values used for various features, such as HP and so on.

To fix this so 10MTs could be used for a increase of 0,10 they have to create code that
recalculate the slowdown so it gets right no matter what point we are at, otherwise
would Player1 get 0,001 and Player2 will get 0,00001...
It's not a big thing to fix, it's just that it doesn't excist today.
Well, this is how I see it ofc, could be another reason thou'... but if they do have
a code that can handle this, wouldn't we have that type of increase already?

All they have to do is give 0.01000 to both and it would be fine.

 

[Cail]

Ok, just as an example, so don't hang up on these values I use as they are just
to illustrate what I mean..

Player1 has 20agi, Player2 has 120agi. They both use same type of gun.
They happens to get a increase with same base value (as skills has different values
for gains, I guess attributes might have them too.)
Lets say that value is 3,2.
Player1 has a slowdown limitation of 100, while Player2 has a slowdown limitation
of 10000. So Player1 gets a increase of 0,032 while Player2 gets a increase of 0,00032.
These values are the ones to increase the progressbar for the next point atm, there
are no code to handle a percentage of this increase.
Thats why I say they use integers since there is no need to recalculate the increase
between Player1 and Player2.

So, this is basicly about the system to increase values that limits the increase
from MTs, not values used for various features, such as HP and so on.

To fix this so 10MTs could be used for a increase of 0,10 they have to create code that
recalculate the slowdown so it gets right no matter what point we are at, otherwise
would Player1 get 0,001 and Player2 will get 0,00001...
It's not a big thing to fix, it's just that it doesn't excist today.
Well, this is how I see it ofc, could be another reason thou'... but if they do have
a code that can handle this, wouldn't we have that type of increase already?

Shouldn't be too hard since they already do give various amounts of skills from missions... and they work pretty much the same way.

All they have to do is give 0.01000 to both and it would be fine.

And, that

 

[remontoire]

The problem appears to be (to me anyways) not that the system cannot add a fractional amount of an attribute, but that the mission system only lets you code for accepting a set amount of tokens and calling the underlying system with a predefined number for attribute (or skill) increase. That is, the mission system doesn't allow you to read the dynamic amount of tokens you gave to the npc and then make a call to the skill system with that number.

So you must do :

try (accept_items(agility_token, 100)) 
{
increase_attribute(agility, 1.0);
} 
otherwise 
{
bailout();
}

and you cannot do :

try (x = accept_items(agility_token)) 
{
increase_attribute(agility, x/100.0); 
} 
otherwise 
{ 
bailout();
}

in the mission "script".

 

[Joat]

All they have to do is give 0.01000 to both and it would be fine.

Shouldn't be too hard since they already do give various amounts of skills from missions... and they work pretty much the same way.


And, that

No, I doubt it would be to hard to implement.
The difference with skillreward is that skillreward do use a "fixed" number that increase the
progressbar realtive to the slowdown limitation.
35ped Evade reward for Player1 with 1200points will get Evade to approx 3363, while
Player2 with 5100points will end up at approx 5407.
A attribute reward of 0,10 is a number based on percentage and not a "fixed" number.
If both Player1 and Player2 gonna get a increase of 0,1 attribute, the value has to
be relative to each players value in the slowdown limitation.
My guess is that the limitation in system today, is that there are no code to recalculate
this, since there hasn't been any need for it earlier.

The problem appears to be (to me anyways) not that the system cannot add a fractional amount of an attribute, but that the mission system only lets you code for accepting a set amount of tokens and calling the underlying system with a predefined number for attribute (or skill) increase. That is, the mission system doesn't allow you to read the dynamic amount of tokens you gave to the npc and then make a call to the skill system with that number.

So you must do :

try (accept_items(agility_token, 100)) 
{
increase_attribute(agility, 1.0);
} 
otherwise 
{
bailout();
}

and you cannot do :

try (x = accept_items(agility_token)) 
{
increase_attribute(agility, x/100.0); 
} 
otherwise 
{ 
bailout();
}

in the mission "script".

My guess is that it is actualy the oposite, system can handle 10 MT but it can't
handle the value needed to increase the progressbar with 10% of a attribute.
But the logic in your example is probably in use now, so it deny us to increase
attribute relative to the amount of MTs given to NPC, but still, I doubt that is
the main issue to be able to increase parts of attributes.

 

[Talania]

No, I doubt it would be to hard to implement.
The difference with skillreward is that skillreward do use a "fixed" number that increase the
progressbar realtive to the slowdown limitation.
35ped Evade reward for Player1 with 1200points will get Evade to approx 3363, while
Player2 with 5100points will end up at approx 5407.
A attribute reward of 0,10 is a number based on percentage and not a "fixed" number.
If both Player1 and Player2 gonna get a increase of 0,1 attribute, the value has to
be relative to each players value in the slowdown limitation.
My guess is that the limitation in system today, is that there are no code to recalculate
this, since there hasn't been any need for it earlier.



My guess is that it is actualy the oposite, system can handle 10 MT but it can't
handle the value needed to increase the progressbar with 10% of a attribute.
But the logic in your example is probably in use now, so it deny us to increase
attribute relative to the amount of MTs given to NPC, but still, I doubt that is
the main issue to be able to increase parts of attributes.

None of this makes any sense since if what you are saying is true then how does the attribute go up 1 whole point when the decimal is 1.00000 rather then 0.10000. If what you are trying to say is how the system has to work then the player with a high attribute already is not going to get 1 full increase because it would be decreased based on all your math you provide.

 

[Joat]

None of this makes any sense since if what you are saying is true then how does the attribute go up 1 whole point when the decimal is 1.00000 rather then 0.10000. If what you are trying to say is how the system has to work then the player with a high attribute already is not going to get 1 full increase because it would be decreased based oTn all your math you provide.

If you actualy read what I wrote earlier you had seen the answer there.
So I'll try again: They increase it with integers!

 

[valentin]

Have to ask...Whay dont the Protoron mission dont have any attribute token in the end because if you Think its one of the biggest and most expencivest mission to do.