Wonders

[snoopy369]

Hmm, I thought I had seen an xml variable describing how a scout adjusted the rolls (by a certain fixed number). Perhaps I misread the meaning of it...

[Locutus]

The code's in CvPlayer::doGoody

[Ming]

Originally posted by Locutus
Correction: when you move onto a goody hut, the game will do ten 'attempts' to pop it. Every attempt it'll randomly select something from the lists I posted above and look if the player/unit in question meets the requirements that may be associated with that outcome (i.e. Scouts can't pop Barbs, you can't get Settlers in OCC, you can only get certain techs from huts so you those should still be available, etc). Only if it fails on all ten attempts you get nothing. So a Scout doesn't necessarily give you nothing if the outcome would otherwise have been Barbs.

Thank you... I wondered how scouts were dealt with.

[snoopy369]

Originally posted by Locutus
The code's in CvPlayer::doGoody

I'd check but i'm not at home I wonder where I saw the other bit. I probably misunderstood the value that changes how many rerolls you get, I suppose? Or is there a variable that defines what a 'bad' outcome is (as opposed to being hardcoded)?

[Locutus]

The number of rolls is set in GlobalDefines.xml as NUM_DO_GOODY_ATTEMPTS. It seems a bit high for what you had in mind, but it's possible. There's a gazillion of these generic settings though of which you really don't know what they do unless you study the source code, it's often quite easy to make the wrong assumption.

What's a bad outcome is defined in Civ4GoodyInfo.xml, the tag is called bBad so that's hard to misinterpret

[joncnunn]

At 10 re-rolls, then on Diety with 8 / 20 = 40% illegal rolls for scouts, then you have a .4 ^ 10 of getting an empty hut = 0.01048756%
so it will occansionly happen, just not very often indeed.

[Locutus]

There are a whole slew of requirements for different outcomes, Scouts not being able to pop barbs is only one. E.g. you apparently can't get free XP in the first ten turns of the game (and of course the unit has to be able to receive promotions), you can obviously only get the Healing outcome if you're damaged, as I mentioned only certain tech are available from huts so later in the game you may already have them all, if it's a free unit that unit has to be available to that civ (I'm guessing that means if you have a Warrior UU you can't get Warriors from huts) and within the first 20 turns of the game you can't get combat units from huts (you can't get them at all in MP).

There's a couple more like that, at any given time you probably fail at least a few different requirements. Most of them are situational though so there's no fixed chance of getting an empty hut. But yeah, as a general rule it should happen occasionally though it's rare (there's no requirements on gold or maps so even on Deity it can never be more than 0.6% and that's exceptionally high).

[Kuciwalker]

E.g. you apparently can't get free XP in the first ten turns of the game

re: the rerolls, that seems a kind of silly way to do it. It's not that complex to do one roll that's guaranteed to land on a valid option.

[Locutus]

Actually, off the top of my head I can't think of anything that would be more elegant than this. Yes, it *can* be done of course, but it would probably make for very ugly, messy code (and that's one thing that you won't find a lot of in the SDK) and it wouldn't be nearly as efficient (of course coming up empty after 10 rolls isn't be very efficient but on average I doubt you'd need more than 2 or 3 rolls, allowing you to skip the bulk of the requirement-checking).

[Kuciwalker]

I never said it would be elegent, but really, it takes about 10 lines. It's not like you care about runtime, this function will get called ten, maybe twenty times over the course of the entire game?

[snoopy369]

Um, the most efficient way is the way I had it originally. Just have each difficulty with an xml option "iNumBad" and order the goodie results by good->bad, then have the scout generate a num from iNumBad+1 to 20 instead of from 1 to 20... One roll, guaranteed good result

[Locutus]

Originally posted by Kuciwalker
It's not like you care about runtime, this function will get called ten, maybe twenty times over the course of the entire game?

It´s exactly this attitude that´s causing so much modern software to totally unnecessarily hog ridiculous amounts of resources. If the whole game was programmed with that mindset the game would have twice the minimum specs it currently has.

Originally posted by snoopy369
Um, the most efficient way is the way I had it originally. Just have each difficulty with an xml option "iNumBad" and order the goodie results by good->bad, then have the scout generate a num from iNumBad+1 to 20 instead of from 1 to 20... One roll, guaranteed good result

No, that would only work if Scouts were your only concern. As I said, there´s a whole slow of other requirements that you need to take into account (and you have to keep moddability in mind as well).

[Kuciwalker]

Originally posted by snoopy369
Um, the most efficient way is the way I had it originally. Just have each difficulty with an xml option "iNumBad" and order the goodie results by good->bad, then have the scout generate a num from iNumBad+1 to 20 instead of from 1 to 20... One roll, guaranteed good result

Except there are cases where other options (e.g. tech) are unavailable, so simple ordering won't work.

[Kuciwalker]

It´s exactly this attitude that´s causing so much modern software to totally unnecessarily hog ridiculous amounts of resources. If the whole game was programmed with that mindset the game would have twice the minimum specs it currently has.

That's ridiculous. Optimization properly goes from the most resource-intensive tasks to the least. There are maybe 20 calls in the entire game to a function that is O(1), a SMALL O(1). You seriously think making it a very slightly larger O(1) (maybe 2, 4x as large) is the sort of thing that would push up minimum specs? Face it, 95% of the processor time is going to be devoted to AI, trade-route calculations, and graphics. Even if you triple the runtime EVERYTHING in the remaining 5%, you get... a 10% performance hit.

var* outcomes; // global variable

var goodyHut() {
    int n = 0; // number of excluded possibilities.
    for(int i = 0; i < 20; i++) if(excluded(var[i])) n++;
    int r = rng(20-n);
    for(int i = 0; i < 20-n; i++)
        if(excluded(var[i])) { i++; r++; }
        else if(r == i) return var[i];
    return -1;
}

[joncnunn]

Actually, I think it's extremely nonelegant to be rerolling the same function on an illegal roll 10 times. Sure it makes the code size smaller, but worst case analysis shows much worse execution time than a single random function call that only takes into consideration the real options. Code execution speed is much more important the code size.

Originally posted by Locutus
Actually, off the top of my head I can't think of anything that would be more elegant than this. Yes, it *can* be done of course, but it would probably make for very ugly, messy code (and that's one thing that you won't find a lot of in the SDK) and it wouldn't be nearly as efficient (of course coming up empty after 10 rolls isn't be very efficient but on average I doubt you'd need more than 2 or 3 rolls, allowing you to skip the bulk of the requirement-checking).