Aux Scaling Bug (2/23)

borticuscryptic

Hi, everybody!

I couldn't figure out the best place to post this, so I'm just making a new thread.

I'm here to confirm that the current scaling effects of Auxiliary Power are very not correct in the current Tribble build.

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

Yeah, that's a bad boo-boo on my part. I'm working on the fix right now (lots and lots of find-and-replace), and hope to have it in the next Tribble build. I just wanted to confirm your suspicions that something was amiss, and possibly set some minds at ease in that regard.

odinforever20000

YAY!!!..Now to see the changes ..whenever that happens.

dragonsbrethren

Whew! Thanks for the update, this is definitely my biggest concern with the whole revamp.

ddesjardins

Thanks for the update!

lucho80

borticuscryptic wrote: »

Hi, everybody!

I couldn't figure out the best place to post this, so I'm just making a new thread.

I'm here to confirm that the current scaling effects of Auxiliary Power are very not correct in the current Tribble build.

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

Yeah, that's a bad boo-boo on my part. I'm working on the fix right now (lots and lots of find-and-replace), and hope to have it in the next Tribble build. I just wanted to confirm your suspicions that something was amiss, and possibly set some minds at ease in that regard.

Thanks for providing the equation. That was one that I was missing so now Ill be able to calc Tachyon Beam and Tykens Rift and add them to my flow caps drain calculations.

peqlegh

Glad to hear! :-)

ortsim

All my decimal point!

Thanks, that makes me feel quite a bit better about science skills.

alcyoneserene

So very glad to hear it was caught and corrected. Look forward to seeing new science testing stats once this makes the next patch.

mustrumridcully0

I blame India. They invented the 0. If they hadn't done this, errors like this could be easily avoided.

culexofborg

This is gonna be a bit off topic but this thread is a good example.

This whole skill revamp situation and the fact that very dedicated and involved developers like borticuscryptic maintaining an open dialog with us like this has rather reassured me that maybe Cryptic as a whole actually does care about its users. Of course we have our community manager laughingtrendy who puts in WAY too many hours but to have a developer do the same is fantastic. It is just really cool to be able to interact in this way.

I think borticus specifically should be commended on how they have handled and continued keeping us up to date and even going so far as to do several build recreations for people despite a select few who haven't been as nice as they should have been.

With these types of awesome interactions with their give and take and back and forth.. I am sure Star Trek Online will continue doing well.

e30ernest

Hi Borticus. Thank you for the update on this. I look forward to testing this once character copies are re-enabled.

sheldonlcooper

Yeah as much as I am against the revamp I give credit to Borticus for taking a very engaged and interactive approach to it. It's obvious that he cares very much about the project.

cerealplayer

borticuscryptic wrote: »

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

[..] I'm working on the fix right now (lots and lots of find-and-replace),

Sorry to be that guy Bort, but man, that's a third-year SOFTENG lesson at the most: never, EVER, hard-code constants into the sourcecode. That 0.5 in the code should really be a constant CONST_BASELINE_AUX_MOD, properly defined in a single header file.

bumperthumper

cerealplayer wrote: »

borticuscryptic wrote: »

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

[..] I'm working on the fix right now (lots and lots of find-and-replace),

Sorry to be that guy Bort, but man, that's a third-year SOFTENG lesson at the most: never, EVER, hard-code constants into the sourcecode. That 0.5 in the code should really be a constant CONST_BASELINE_AUX_MOD, properly defined in a single header file.

I was actually thinking about this also. As a web design/developer I'd switch that to a "class", or possibly even an "id". Of course, this is a different application, so a different language, but you can catch my drift.

I've had to rework builds that others have hard-coded and it isn't very much fun. I don't know how far down the rabbit hole you've gone so far with search and replace, but if you're not THAT far down it yet, you may want to just go back and set something like that up for future rewrites to make your job easier down the road.

Thank you for taking the to time to deal with the mathy-maths! I have no clue many hairs you've pulled out so far.

Pro-tip: Start wearing a hat at work so you don't pull out your hair. Ricky didn't wear a hat. Don't be Ricky.

kasraken

Thank you for posting so promptly about the action being taken. I had faith in you and the team as always, I am glad your on top of this issue.

lucho80

cerealplayer wrote: »

borticuscryptic wrote: »

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

[..] I'm working on the fix right now (lots and lots of find-and-replace),

Sorry to be that guy Bort, but man, that's a third-year SOFTENG lesson at the most: never, EVER, hard-code constants into the sourcecode. That 0.5 in the code should really be a constant CONST_BASELINE_AUX_MOD, properly defined in a single header file.

Unfortunately, the system might be so bad he has to handle each ability separately. Other stuff I've learned through the years from reading the forums.

1) Doffs with multiple bonuses (I think there might be only 1) have to roll the chances at the same time and both will proc if one roll succeeds.

2) If they ever decide to fix the doffing assignment chances, they have to change each one individually much like what Borticus has to fix right now with each ability.

There are more limitations. I don't think he can just code a global variable and be done with things.

I do have a question, will all power levels work like the Aux scaling or it's just Aux being changed?

chastity1337

Hey Borticus -

Thanks for keeping us posted. As a dedicated Science captain, I've been seriously worried about this.

alcyoneserene

Still very worried about the changes negatively impacting Science as a whole, specifically the drain results as tested by Lucho, and this part in the Feb 19 patch notes:

The benefits gained from Shield Subsystem Power and Auxiliary Subsystem Power have been altered.
Benefits gained from Shield power have been reduced, but new Skills have been introduced that allow these benefits to increase beyond their previous caps.
Benefits gained from Auxiliary power have been rescaled, so that low-Aux grants more benefit and high-Aux grants less benefit.
This new scale pivots around 100 Aux Power, at which point no differences are present.

Surely it isn't just Shield subsystem power that will acquire new skills to make up for the loss, but Aux subsystem power too?

mustrumridcully0

cerealplayer wrote: »

borticuscryptic wrote: »

The internal calculation is currently written as:
((AuxPower * .005) + .05)

It is supposed to be:
((AuxPower * .005) + .5)

[..] I'm working on the fix right now (lots and lots of find-and-replace),

Sorry to be that guy Bort, but man, that's a third-year SOFTENG lesson at the most: never, EVER, hard-code constants into the sourcecode. That 0.5 in the code should really be a constant CONST_BASELINE_AUX_MOD, properly defined in a single header file.

I suspect that borticus is working with what the system enables him to do here.

Because if I had to

((AuxPower * .005) [b]+ .5)

a third time anywhere, I would try to make it a seperate method and just call it from everywhere I need it. (The constant idea isn't bad either, but if the whole calculation repeats itself, you have to think further). Failing a method, I might do a macro (but I come from the Java/C# world and only later started doing C++, so Macros are still something I don't use all that often.)

But some dev remarks in the past suggest that things like powers and items are not "code" in the classic sense, and are more data that is put in a database. It might be very similar and still is a form of programming in the end (even if not everyone would call it that), but this likely means it's something half-way proprietary and not a full blown programming language with all the abilities that would entail..

eyceaether

I will never understand why game companies don't give the developers the time they need to design a flexible engine for their game. There is no reason in the depths of hell for a variable that can possibly change in the future to be hard-coded in such a way that a Dev has to spend time by hand doing that, unless we're talking time and engine constraints. But we're talking about a Proprietary engine developed by the same company that develops this game... so what the hell man.

I didn't even do well in my Computer Science classes and I can see that. I blame management. This doesn't seem like something a developer would want to do...

borticuscryptic

Suffice it to say that this conversation isn't really applicable. None of you have handled our engine, so don't really have context for what you're talking about. And honestly, it's pretty irrelevant to the bigger picture anyway.

We use pointers and variables all the time. Aux scaling hasn't been one of those because it hasn't always been uniform. That's really all there is to say about that.

megrae

I want to know why they are making each point of aux power over 100 weaker than each point under 100 when lots of science based gear is about getting more aux power, and the ability to get more than 125 max.

I also really want to know why this is not being applied to other power levels.. ESPECIALLY Weapon power. Fair is Fair, if you want to do this to Science, I want this done to weapons too.

eyceaether

borticuscryptic wrote: »

Suffice it to say that this conversation isn't really applicable. None of you have handled our engine, so don't really have context for what you're talking about. And honestly, it's pretty irrelevant to the bigger picture anyway.

We use pointers and variables all the time. Aux scaling hasn't been one of those because it hasn't always been uniform. That's really all there is to say about that.

OK, fair point. But, a developer having to use find and replace to update the same exact number by hand through their code in order to change a constant is indicative of something. If the engine has limitations that to this day haven't been expanded, again, that's rushed engine work by the people who created the game engine in the first place... And since most people would rather not put out rushed work if they don't have to, then that's a project manager/director thing. And if they were under pressure then that's a suits thing.

I understand resources are limited, so things get prioritized. I also understand updating an engine is costly and time consuming, and may not be worth the R&D if the product isn't bringing in enough revenue... So I get that the situation is more complex than it would appear.

However, I'm pretty sure you would rather be doing something more productive than Find and Replace...

borticuscryptic

megrae wrote: »

I want to know why they are making each point of aux power over 100 weaker than each point under 100

First of all, the bonus from each point of Aux is uniform, regardless if that point is above or below the 100 mark. What this changed was the end-points of an overall chart.

Here's a visual representation:



As to the "why" of the change... the primary reasons are readability, predictability, and simplification of mechanics for the sake of player understanding.

The old scaling calculation was:

(((AuxPwr*.5)/75)+.333)

Can you make sense of that at a glance? What it resulted in a bonus that scaled as such:
0 pwr = .333333
25 pwr = .5
50 pwr = .666667
75 pwr = .833333
100 pwr = 1
125 pwr = 1.16667

Or, stated another way, the base modifier from Aux was 0.333333 and every 1 Point of AuxPwr granted a multiplier of 0.006667... or translated yet more:

Each point of AuxPwr gave 2/3 of 1% bonus above baseline effectiveness.

I dunno about you, but attempting calculations that include "2/3" in my head isn't easy.

Under the newly updated calculation, it could instead be described as:

Each point of AuxPwr gives a 1/2 of 1% bonus above baseline effectiveness.

0.5, or "half" -- that's really easy to use in napkin math.

Additionally, while the latter is a weaker bonus per point, that "baseline effectiveness" was also boosted by ~50% of its previous value (0.5, up from 0.33333).

In summary... this change wasn't orchestrated as a means of "nerfing Science," but rather as a way to move more of the game's underlying mechanics into an easier-to-understand format. That fact that it simultaneously raises the baseline effectiveness of low-Aux builds is an accepted side effect, rather than being a goal that we set out to meet.

mustrumridcully0

borticuscryptic wrote: »

megrae wrote: »

I want to know why they are making each point of aux power over 100 weaker than each point under 100

First of all, the bonus from each point of Aux is uniform, regardless if that point is above or below the 100 mark. What this changed was the end-points of an overall chart.

Here's a visual representation:



As to the "why" of the change... the primary reasons are readability, predictability, and simplification of mechanics for the sake of player understanding.

The old scaling calculation was:

(((AuxPwr*.5)/75)+.333)

Can you make sense of that at a glance? What it resulted in a bonus that scaled as such:
0 pwr = .333333
25 pwr = .5
50 pwr = .666667
75 pwr = .833333
100 pwr = 1
125 pwr = 1.16667

Or, stated another way, the base modifier from Aux was 0.333333 and every 1 Point of AuxPwr granted a multiplier of 0.006667... or translated yet more:

Each point of AuxPwr gave 2/3 of 1% bonus above baseline effectiveness.

I dunno about you, but attempting calculations that include "2/3" in my head isn't easy.

Under the newly updated calculation, it could instead be described as:

Each point of AuxPwr gives a 1/2 of 1% bonus above baseline effectiveness.

0.5, or "half" -- that's really easy to use in napkin math.

Additionally, while the latter is a weaker bonus per point, that "baseline effectiveness" was also boosted by ~50% of its previous value (0.5, up from 0.33333).

In summary... this change wasn't orchestrated as a means of "nerfing Science," but rather as a way to move more of the game's underlying mechanics into an easier-to-understand format. That fact that it simultaneously raises the baseline effectiveness of low-Aux builds is an accepted side effect, rather than being a goal that we set out to meet.

Interesting.

But I guess this change isn't a sign that you're looking into the effect of other power levels. By comparison for example, weapon power seems just way more potent and any non-torpedo build will default to the highest value, plus any overcapping potential you can get - where as before or after the change, sacrificing a bit aux was never a real problem. (Arguably not even for Science builds sometimes).

But well, IIRC, the math for weapon power is pretty "clean" and easy to follow. (Weapon Damage only gets complicated due to the different types of buffs and it not always clear which buff is which category).

I always wonder if Engine shouldn't affect a few more powers... There aren't many that would really thematically fit, but Eject Warp Plasma or Attack Patterns could kinda make sense...

alexraptorr

I don't like this at all. I've invested A LOT in getting a nice "Epic" quality warp core that can push 130 aux, and now that investment is being heavily devalued.

What happend to "players loose nothing"? because that's exactly what's happening here.

angrytarg

borticuscryptic wrote: »

(...)
In summary... this change wasn't orchestrated as a means of "nerfing Science," but rather as a way to move more of the game's underlying mechanics into an easier-to-understand format. That fact that it simultaneously raises the baseline effectiveness of low-Aux builds is an accepted side effect, rather than being a goal that we set out to meet.

I get what you are saying, but these calculations weren't documented anywhere in the first place. I'm not saying these changes are bad or anything, rather neutral about it, but we players didn't know how the calculation work. Some people tested it and wrote how many damage or drain +1 aux does on the wiki but somehow I doubt that these changes make the system more comprehensible when there's no documentation about it to begin with.​​

dabelgrave

Based on the chart, I can see there won't be much noticeable difference at 125 except maybe in parsing, but what about when using things like OSS3 to boost your power up to 175ish? What is currently a benefit of 1.5 ends up getting bumped down to 1.375, which could be a very noticeable difference in the effectiveness of various abilities.​​

fleudermaus

megrae wrote: »

I want to know why they are making each point of aux power over 100 weaker than each point under 100 when lots of science based gear is about getting more aux power, and the ability to get more than 125 max.

I also really want to know why this is not being applied to other power levels.. ESPECIALLY Weapon power. Fair is Fair, if you want to do this to Science, I want this done to weapons too.

EXACTLY!!!!

The degree of nerfing here directed against SCIENCE specifically is interesting. Tacs are hitting unbelievable DPS numbers but you are wasting time making the lowest DPS class even WEAKER...

lucho80

Glad equations are going simpler. Now if the Tetryon Glider and Tetryon Beams with shield drains equations could get the same simplifying treatment.

dabelgrave wrote: »

Based on the chart, I can see there won't be much noticeable difference at 125 except maybe in parsing, but what about when using things like OSS3 to boost your power up to 175ish? What is currently a benefit of 1.5 ends up getting bumped down to 1.375, which could be a very noticeable difference in the effectiveness of various abilities.​​

OSS3 is way over the top anyway, but I will agree with others. It would be nice if weapons power didn't seem to be that much more powerful than other power level's effects.

entnx01

Could someone please post an example of a couple effects, 1 damage-based and 1 not damage-based, where this modifier change hurts the build significantly? I'd like to see the before and after calculations to really see what's going on. I see modifiers changing by a loss of .125 @ 175 Aux, yet me and my brain have never understood STO damage and non-damage math when dealing with modifiers like this.

Thanks!