Jump to content

How does BabyImprintAmountMultiplier work?


SAS

Recommended Posts

  • Replies 89
  • Created
  • Last Reply
7 hours ago, invincibleqc said:

 

The output is correct because into a raise of 9 hours, there is only one 8 meaning the game assume 1 imprint at 100% * 0.335 = 33.5% (rounded and displayed as 34% in-game). Basically, the entire raise is divided by 8 regardless of the configured interval.

 

 

@invincibleqc thank you very much for that careful analysis. I see several issues with this then. First of all, I don't have more flexibility I actually have less. Second we still have this:

11 hours ago, invincibleqc said:

In other words, I suspect they still have a sanity check somewhere that ensure there is at least always 1 imprint required which returns 100% in such cases which currently doesn't properly apply the BabyImprintAmountMultiplier. Once that is fixed, we should be able to negate that by dividing our maturation speed multiplier as mentioned above.

But actually this isn't the case according to your latest post. Because, if understand you correctly, in their genius decided to toss out a value used for years (and still in their own documentation), and simply ceiling time intervals less than 1.0 of 8 to 1.0 yielding the 100% imprint. I'll say exactly what I did in November. Our imprint intervals and values were very carefully tuned for the experience we wanted to offer. And once again, it is completely broken to satisfy some obscure request that I have yet to even see a reference to in this discussion. Why did they change it in the first place? Have they even seen the enhancement queue?? It almost seems they keep screwing with the breeding(ahem) on behalf of some silent party that can't even be bothered to comment here. In that case they can take the new variable and ram it so far I care, I would like my BabyCuddleIntervalMultiplier back thank you very much WC. I think they either need to make it work like I originally posted, or else drop it.

 

Here it is again (slightly tweaked for invincibleqc :):   )

ceiling (BabyImprintAmountMultiplier * (100 / (TotalMaturationTime / cuddleInterval)))

limit (total_imprint + imprint, total_imprint, 100%)     # this is the only sanity check we should need

 

In other words, a momentary aesthetic imprint displayed as putting the dino theoretically a bit over 100% would be far more tolerable than this actual rubbish we have now. The displayed imprints aren't totally accurate anyway.

 

Link to comment
Share on other sites

  • Volunteer Moderator
3 hours ago, singalty said:

I see several issues with this then. First of all, I don't have more flexibility I actually have less.

I don't see how you would have less flexibility over the previous system. If that specific case where 100% is returned would simply apply the BabyImprintAmountMultiplier for example, using the snippet I posted above from:

    if not required:
        return 100

To:

    if not required:
        return 100 * imprint_amount

We would then have all the tools we need to fully customize imprinting to our liking. And having much more flexibility because now the intervals and the amount are independently configurable as opposed to having them affecting each others. For example, you like the intervals you have set but some tames are too tight to achieve 100%? Simply increase the amount multiplier to give more spare time without affecting the intervals, etc.

3 hours ago, singalty said:

Why did they change it in the first place? Have they even seen the enhancement queue?? It almost seems they keep screwing with the breeding(ahem) on behalf of some silent party that can't even be bothered to comment here.

Actually, I believe it has been on their radar since the last Extra Life event. The community playing on officials was very noisy about the increased rates not giving them enough spare time for imprint. Take for example a Giga with 7x mature speed and 1x interval it used to be:

Total maturation: 1 days, 16 hours, 5 minutes
Cuddles required: 5
Cuddles percentage: 20.0
Cuddle interval: 8 hours

Imprinting progression:
        - Imprint #1:
                 Precise: 20.0%
                 Networked: 20.0%
                 Displayed: 20%
                 Maturation left: 1 days, 8 hours, 5 minutes.
        - Imprint #2:
                 Precise: 40.0%
                 Networked: 40.0%
                 Displayed: 40%
                 Maturation left: 1 days, 5 minutes.
        - Imprint #3:
                 Precise: 60.0%
                 Networked: 60.0%
                 Displayed: 60%
                 Maturation left: 16 hours, 5 minutes.
        - Imprint #4:
                 Precise: 80.0%
                 Networked: 80.0%
                 Displayed: 80%
                 Maturation left: 8 hours, 5 minutes.
        - Imprint #5:
                 Precise: 100%
                 Networked: 100%
                 Displayed: 100%
                 Maturation left: 5 minutes.

Meaning you only had 1 minute to do each imprint and if it was taking you any longer to walk, get your kibbles, or whatever, then you were unable to get 100% and was only able to achieve 80%. So, 2 days after the event started or so, they made the change explained there:

Which then caused the issues for unofficials that are discussed in that thread so that changes was reverted later. And now they are revisiting those concerns of imprinting being too tight with various combinations of imprinting settings by giving full control over the imprinting amount with that new multiplier. If that wasn't for the bug profiled above allowing for 100%, everything would be working fine and you would have much more flexibility over imprinting.

What are your current multipliers? Let's run some tests and see what the possibilities would be using your actual figures.

Link to comment
Share on other sites

Current imprinting mechanics feels like it's a crutch. My main concerns are uneven spare time per imprint for different creatures that can't be fine tuned and that I must sacrifice my ability to imprint several smaller creatures to have reasonable timers for the rest, ie "zero imprint" creatures with their raising timers lower than one imprint interval. I think bUseSingleplayerSettings isn't allowing imprinting even more creatures than my settings.

Link to comment
Share on other sites

  • Volunteer Moderator
15 minutes ago, SAS said:

My main concerns are uneven spare time per imprint for different creatures that can't be fine tuned and that I must sacrifice my ability to imprint several smaller creatures to have reasonable timers for the rest, ie "zero imprint" creatures with their raising timers lower than one imprint interval.

That's actually a good point. Even with the new multiplier raises that have a total maturation < interval time cannot be imprinted at all. A simple solution, could be to simply allow them for a single 100% imprint when claimed in that case. Another, could be to ensure the raise is always a bit longer than the interval by capping the minimum maturation time to at least 1 configured interval + some pre-defined spare time.

Link to comment
Share on other sites

Actually setting an imprint interval and minimum spare time interval per imprint and deriving the number of needed imprints from those feels like a better solution than current, you have a very good point. As well as "short raises" to ask for a single 100% imprint right after claiming. These two ideas, in my opinion, would vastly improve the current mechanics leaving me without any issues with it.

Link to comment
Share on other sites

  • Volunteer Moderator
51 minutes ago, SAS said:

Actually setting an imprint interval and minimum spare time interval per imprint and deriving the number of needed imprints from those feels like a better solution than current, you have a very good point. As well as "short raises" to ask for a single 100% imprint right after claiming. These two ideas, in my opinion, would vastly improve the current mechanics leaving me without any issues with it.

This sure sounds like the more simple and robust solutions for an all-cases fix related to imprinting short raises imo. For example, taking the function I posted above it could simply do the following to adjust for spare time:

from math import floor

# Amount of seconds players have to make each imprint
BabyImprintSpareSeconds = 300

def get_imprint_percentage(
    total_maturation, maturation_speed, imprint_amount):
    required = floor(
        (total_maturation / maturation_speed) /
        ((8 * 60 * 60) + BabyImprintSpareSeconds)
    )
    if not required:
        return 100 * imprint_amount
    return round((100 / required) * imprint_amount, 6)

print(f'{get_imprint_percentage(1010101, 7, 1)}%')

This would output 25% rather than 20%, because it would now account for 25 minutes spare making it drop to 4 imprints required rather than 5 because there wasn't enough spare time to make all 5. I personally can't think of another solution that do not involve per-specie overrides. ?

Link to comment
Share on other sites

5 hours ago, invincibleqc said:

Meaning you only had 1 minute to do each imprint and if it was taking you any longer to walk, get your kibbles, or whatever, then you were unable to get 100% and was only able to achieve 80%.

 

Okay that's a fair point. You can currently tweak it a little around the dinos people raise most but it's not a total solution. But I thought that was what BabyImprintAmountMultiplier was supposed to cushion and work with the existing setup. Right I just see everything broken again.

 

Quote

I don't see how you would have less flexibility over the previous system.

Not if they're rounding increments to eight hours it's not. I can't believe they hard-coded what is to me such an arbitrary value into the equation, it's brain-dead. You're starting to make a lot of unproven assumptions here. So far I have seen two different/conflicting explanations of the same update from you while reality is imprinting is broken and documentation hasn't been updated. The formula should be one short line of psuedo-code, with maybe a one line sanity check. Three or four lines?? For this little problem?? KISS me mate, any benefits to consistency is vastly outweighed by over-complexity.. assuming the current "bug" is even unintentional, that documentation will still be properly updated (not just a quick footnote to a patch-note, jeeez) and our broken imprints will all be fixed again. Don't get me wrong, it's great if it happens but so far..

 

Link to comment
Share on other sites

5 hours ago, invincibleqc said:

What are your current multipliers? Let's run some tests and see what the possibilities would be using your actual figures.

 

OK It was very straightforward:

16x raising (actually slightly under, tweaked currently against the beaver as a mid-range dino but lets just go with 16x for simplicity)
hourly imprints, precisely every 60 minutes. Every dino imprints including dodo and lystro (who would want to, but we checked)

 

Link to comment
Share on other sites

  • Volunteer Moderator
1 hour ago, singalty said:

 

Okay that's a fair point. You can currently tweak it a little around the dinos people raise most but it's not a total solution. But I thought that was what BabyImprintAmountMultiplier was supposed to cushion and work with the existing setup. Right I just see everything broken again.

 

Not if they're rounding increments to eight hours it's not. I can't believe they hard-coded what is to me such an arbitrary value into the equation, it's brain-dead. You're starting to make a lot of unproven assumptions here. So far I have seen two different/conflicting explanations of the same update from you while reality is imprinting is broken and documentation hasn't been updated. The formula should be one short line of psuedo-code, with maybe a one line sanity check. Three or four lines?? For this little problem?? KISS me mate, any benefits to consistency is vastly outweighed by over-complexity.. assuming the current "bug" is even unintentional, that documentation will still be properly updated (not just a quick footnote to a patch-note, jeeez) and our broken imprints will all be fixed again. Don't get me wrong, it's great if it happens but so far..

 

Huh, chill?

I never claimed anything I said to be verified facts. Which the "I believe", "I suspect", etc. were making it rather obvious that I was making assumptions. That is actually called; bug investigating. Which consists of exploring theories and evolve based on test results/new information and eliminate them as the investigation progress.

Believe it or not, simply saying "it's broken" isn't really helpful. Providing reproducible contexts as to why we think it is, expected vs obtained results, data that backs it up, probable causes, and brainstorming solutions is helping the devs more than you can think.

Anyways, all I was trying to do by contributing to this topic is be helpful. I'm all for debating theories and make some testings. But I'm definitely too old to have some petty argument over it so, I'm out. Good luck!

Link to comment
Share on other sites

1 hour ago, invincibleqc said:

 

Anyways, all I was trying to do by contributing to this topic is be helpful. I'm all for debating theories and make some testings. But I'm definitely too old to have some petty argument over it so, I'm out. Good luck!

 

I'm not trying to argue with you @invincibleqc   but you aren't the only one allowed to state an opinion here and try not to take discussions so personally, regardless of your age :). I noticed several folks here seem to be taking your "beliefs" as facts without question and I'm just point out a) they actually aren't and b) if they are, what WC is doing is the worst way to deal with the issue. Far from just saying "it's broken" I've actually stated what a reasonable solution would be, and I stay by it. TBH I cringe every time WC changes something in the breeding because it always seems to wind up in this mess, not working, no documentation, everyone  wondering how and when it will be fixed. Last time they did this it was so rubbish they finally rolled it back. If I'm upset it's with WC not you. It might be hard for you to feel the same way if it's not your cluster that's broken.

And I never asked anybody for help on this, it's obviously total SNAFU and everyone can see it. All the best mate.

Link to comment
Share on other sites

This latest update appears to have fixed the broken BabyImprintAmountMultiplier. My server with it's 150x maturation and 0.012x baby cuddle interval multipliers now gives the correct % imprint at the correct imprint intervals.

Just thought I'd gives heads up for those who may wish to revert back to their boosted rates.

Link to comment
Share on other sites

5 hours ago, NZScruffy said:

This latest update appears to have fixed the broken BabyImprintAmountMultiplier. My server with it's 150x maturation and 0.012x baby cuddle interval multipliers now gives the correct % imprint at the correct imprint intervals.

Just thought I'd gives heads up for those who may wish to revert back to their boosted rates.

Is your BabyImprintAmountMultiplier set to 1.0? Just wondering if you had adjusted that as well.

Link to comment
Share on other sites

Mine is set at 1.10 and seems to be working exactly as I was previously hoping:

imprint1.thumb.jpg.764e290477a92ed08e77c6d5d6bf7f44.jpg

In other words, the imprint normally would be 14%, increased to 15.4% then ceilinged to the next highest integer.

 

I haven't tested all dinos (wheh) and have yet to confirm the sanity check will limit back to 100% after all the imprints are done, but at this point I have to say it's actually looking pretty good..

UPDATE: The sanity check works too, it's actually built into the imprint calculation like before BabyImprintAmountMultiplier was even implemented, so that the last imprint is correctly displayed as only the difference required to 100%. Really good job..

 

I would like to take a moment and thank wildcard for taking this to heart and delivery such a quick fix. Thank you.

 

 

Link to comment
Share on other sites

  • Volunteer Moderator
1 hour ago, singalty said:

In other words, the imprint normally would be 14%, increased to 15.4% then ceilinged to the next highest integer.

Actually, all they did is throw back BabyCuddleIntervalMultiplier into the mix like they did the last time it was removed. You are seeing 14% and 16% because the value displayed by your client is rounded to the nearest integer. This is the progression of your Theriz with your settings and BabyImprintAmountMultiplier set to 1.0:

Spoiler

Total maturation: 7 hours, 14 minutes, 1 seconds
Cuddles required: 7
Cuddles percentage: 14.285714285714286
Cuddle interval: 1 hours

Imprinting progression:
        - Imprint #1:
                 Precise: 14.285714285714286%
                 Networked: 14.2857%
                 Displayed: 14%
                 Maturation left: 6 hours, 14 minutes, 1 seconds.
        - Imprint #2:
                 Precise: 28.571428571428573%
                 Networked: 28.5714%
                 Displayed: 29%
                 Maturation left: 5 hours, 14 minutes, 1 seconds.
        - Imprint #3:
                 Precise: 42.85714285714286%
                 Networked: 42.8571%
                 Displayed: 43%
                 Maturation left: 4 hours, 14 minutes, 1 seconds.
        - Imprint #4:
                 Precise: 57.142857142857146%
                 Networked: 57.1429%
                 Displayed: 57%
                 Maturation left: 3 hours, 14 minutes, 1 seconds.
        - Imprint #5:
                 Precise: 71.42857142857143%
                 Networked: 71.4286%
                 Displayed: 71%
                 Maturation left: 2 hours, 14 minutes, 1 seconds.
        - Imprint #6:
                 Precise: 85.71428571428572%
                 Networked: 85.7143%
                 Displayed: 86%
                 Maturation left: 1 hours, 14 minutes, 1 seconds.
        - Imprint #7:
                 Precise: 100%
                 Networked: 100%
                 Displayed: 100%
                 Maturation left: 14 minutes, 1 seconds.

 

And here it is with BabyImprintAmountMultiplier set to 1.1:

Spoiler

Total maturation: 7 hours, 14 minutes, 1 seconds
Cuddles required: 7
Cuddles percentage: 15.714285714285717
Cuddle interval: 1 hours

Imprinting progression:
        - Imprint #1:
                 Precise: 15.714285714285717%
                 Networked: 15.7143%
                 Displayed: 16%
                 Maturation left: 6 hours, 14 minutes, 1 seconds.
        - Imprint #2:
                 Precise: 31.428571428571434%
                 Networked: 31.4286%
                 Displayed: 31%
                 Maturation left: 5 hours, 14 minutes, 1 seconds.
        - Imprint #3:
                 Precise: 47.14285714285715%
                 Networked: 47.1429%
                 Displayed: 47%
                 Maturation left: 4 hours, 14 minutes, 1 seconds.
        - Imprint #4:
                 Precise: 62.85714285714287%
                 Networked: 62.8571%
                 Displayed: 63%
                 Maturation left: 3 hours, 14 minutes, 1 seconds.
        - Imprint #5:
                 Precise: 78.57142857142858%
                 Networked: 78.5714%
                 Displayed: 79%
                 Maturation left: 2 hours, 14 minutes, 1 seconds.
        - Imprint #6:
                 Precise: 94.2857142857143%
                 Networked: 94.2857%
                 Displayed: 94%
                 Maturation left: 1 hours, 14 minutes, 1 seconds.
        - Imprint #7:
                 Precise: 100%
                 Networked: 100%
                 Displayed: 100%
                 Maturation left: 14 minutes, 1 seconds.

 

Where "Precise" is what is calculated by the server, "Networked" is what is transmitted to your client, and "Displayed" what is displayed by it. Although you are seeing 16% each imprint, after 2 you will see 31% displayed into its inventory because 15.7143 * 2 = 31.4286 and is rounded down to 31%.

Link to comment
Share on other sites

@invincibleqc welcome back, sorry I really can't remember BabyImprintAmountMultiplier ever being tried before. November was a totally different scheme as I recall.

 

21 minutes ago, invincibleqc said:

Where "Precise" is what is calculated by the server, "Networked" is what is transmitted to your client, and "Displayed" what is displayed by it. Although you are seeing 16% each imprint, after 2 you will see 31% displayed into its inventory because 15.7143 * 2 = 31.4286 and is rounded down to 31%.

Yeah, I know. When we look at the database details the imprint quality goes to the ten- hundred-thousandths value. But I'm not so sure about the rounding, currently the threis are at 63% sorry I don't recall what they were before but it's only one away from 64% so I can't be so wrong. Anyway, I don't want to split hairs about it but in general terms it works as I previously described.

 

Good enough?

Link to comment
Share on other sites

  • Volunteer Moderator
2 minutes ago, singalty said:

@invincibleqc welcome back, sorry I really can't remember BabyImprintAmountMultiplier ever being tried before. November was a totally different scheme as I recall.

Yes, but what I meant is that they removed the BabyImprintAmountMultiplier from the calculation back then, which caused similar issues we experienced this time (100%, etc.) so they ended up adding it back just like they did now.

5 minutes ago, singalty said:

Yeah, I know. When we look at the database details the imprint quality goes to the ten-thousandths value. But I'm not so sure about the rounding, currently the threis are at 63% sorry I don't recall what they were before but it's only one away from 64% so I can't be so wrong. Anyway, I don't want to split hairs about it but in general terms it works as I previously described.

It is quite easy to confirm, if you export your baby (Options → Export Dino) and look into your ../DinoExports/ directory you should see the networked quality. Does it match the table above or is it different?

Link to comment
Share on other sites

2 minutes ago, invincibleqc said:

It is quite easy to confirm, if you export your baby (Options → Export Dino) and look into your ../DinoExports/ directory you should see the networked quality. Does it match the table above or is it different?

 

OK, just tell me what you think it will be and I'll check ark-tools. But it won't change anything. When the differences between real and displayed are all added together, they easily account for the missing 1% which still agrees with what I posted before.

 

Link to comment
Share on other sites

11 minutes ago, invincibleqc said:

Which unfortunately mean it is the exact same tight-behaviour as before. :(

 

I don't see the problem. We have several variables to work with, all can be tuned and adjusted for the experience we want to share on our servers. I can't put my finger on how exactly we disagree here, for me it's a simple thing just to pick a threshold at which you want to start awarding players a free imprint. It's the only piece of the puzzle that was missing before and now I'm happy that it's done. It's also easy to understand and explain to others.

 

 

Link to comment
Share on other sites

  • Volunteer Moderator
34 minutes ago, singalty said:

I don't see the problem. We have several variables to work with, all can be tuned and adjusted for the experience we want to share on our servers. I can't put my finger on how exactly we disagree here, for me it's a simple thing just to pick a threshold at which you want to start awarding players a free imprint. It's the only piece of the puzzle that was missing before and now I'm happy that it's done. It's also easy to understand and explain to others.

Now that MatingIntervalMultiplier and BabyImprintAmountMultiplier are no longer independently configured and that the former affect the later, we are back to having inconsistent results across species because now the imprint amount is dynamic and dictated by the amount of interval required which is in turn dictated by the various maturation time of each species and then rounded down.

When it was static and based on a 8 hours interval, we had much more precision and flexibility because we knew our amount multiplier set to 1.0 was an 8 hours maturation worth of imprinting while now it is randomized and based on multiple other variables as listed above.

Link to comment
Share on other sites

33 minutes ago, invincibleqc said:

Now that MatingIntervalMultiplier and BabyImprintAmountMultiplier are no longer independently configured and that the former affect the later, we are back to having inconsistent results across species because now the imprint amount is dynamic and dictated by the amount of interval required which is in turn dictated by the various maturation time of each species and then rounded down.

 

I see. But don't you believe that inconsistency would be better handled at the root of the problem: the wildly inconsistent maturation times between dinos themselves - rather than keep trying to stuff a round peg down a square hole with timing tricks? Allow me to ask: wouldn't it make more sense to keep a straightforward breeding algorithm like what we have now and just change the real problem (as you see it):

 

 Ichthyornis     29     32     84     90     1:39     3:42     14:48     18:31     1d 13:02     18:00–48:00
Iguanodon     24     28     75     82     1:25     4:37     18:31     23:08     1d 22:17     18:00–48:00
Kairuku     22     30     72     86         1:30     2:48     11:13     14:01     1d 04:03     18:00–48:00
Kaprosuchus     29     35     84     95     1:59     3:42     14:48     18:31     1d 13:02     18:00–48:00
Kentrosaurus     24     30     75     86     2:46     5:08     20:34     1d 01:43     2d 03:26     18:00–48:00
Lystrosaurus     24     28     75     82     0:49     1:32     6:10     7:42     15:25     18:00–48:00
Magmasaur     90     110     194     230     4:59     18:31     3d 02:04     3d 20:35     7d 17:11     18:00–48:00
Megachelon     -75     75     -103     167     4:59     9:15     1d 13:02     1d 22:17     3d 20:35     18:00–48:00
Megalania     29     35     84     95     1:59     3:42     14:48     18:31     1d 13:02     18:00–48:00
Megalosaurus     26     32     79     90     1:39     9:15     1d 13:02     1d 22:17     3d 20:35     18:00–48:00

 

Perhaps aligning those values to perhaps 10- or 20- or even 30-minute even intervals in classifications similar to the recent kibble rework?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...