Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use SeedRng some places where it isn't necessary #6156

Merged
merged 4 commits into from
Feb 3, 2025

Conversation

tertu-m
Copy link
Collaborator

@tertu-m tertu-m commented Jan 31, 2025

Description

I personally believe that reseeding the global random number generator(s) for local purposes is not a good idea, and Emerald does it when it would not have been necessary. This removes some of the places where this is done.
It also adds u32 LocalRandom32(rng_value_t *); while one could argue that LocalRandom doesn't need to exist anymore, I like the idea that if for some reason the PRNG were to change again, the names of the functions people actually use would remain accurate.

Feature(s) this PR does NOT handle:

Battle recordings and contests still set the global RNG seed even though they shouldn't need to change it permanently. I'll think about how to handle this.

Discord contact info

tertu

Comment on lines 1000 to 1001
for (i = 0; i < itemIndex; i++)
LocalRandom(&rand);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to understand what's happening here.
Is it just advancing LocalRandom itemIndex times?
It feels like it's unnecessary, but it's what the previous behavior was too (which isn't a great judge to be fair).

Copy link
Collaborator Author

@tertu-m tertu-m Feb 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are only four random seeds for each pyramid floor, but you can have up to 8 trainers on a given floor, so some seeds would need to be shared. It's burning random numbers so each pair of trainers does not (necessarily) give the same item; perhaps it isn't doing so in the most efficient way. I think I'll rewrite this chunk of code to work similarly but slightly differently.

Copy link
Collaborator

@hedara90 hedara90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything tested worked.

@hedara90 hedara90 merged commit 14178ed into rh-hideout:upcoming Feb 3, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants