Quote:
|
Originally Posted by tysok
So it's not 100% everything one could hope for, but it's pretty darn close... It would take extra programming, and be a pain in the back side probably to make it so. I wouldn't expect it to be so either... but wanted to make sure I understood what it could do.
From that post you linked me to (which is what I quoted from on the first post here) it read like it might or might not randomize for those specific conditions as well... I really didn't think it would.
From my latest, last post:
"Randomizer says line 1 is regular, 2 is regular, 3 is regular, 4 is regular, 5 is grand slam. First home run is regular, so gets line 1. Second home run is grand slam so it skips to line 5. The third home run is regular, but since it skippeed 2,3, and 4 for the grand slam I'd get line 1 again."
So you could actually shoot yourself in the foot (for staying away from seeing more than one occasion of the same call in the same day) by adding conditions to everything like that.
|
Well, yeah, I see your point. If your HOMERUN category had only five messages structured as you describe, then message 1 would appear for home run #1 and again for home run #3. But if your category has a high number of objects that are used for home run calls then the likelihood of message 1 appearing twice in the same game is pretty close to zero.
In the database currently, the HOMERUN category has more than 80 entries, and it's only one of several categories that could be called when a home run occurs. You could cut out half of the existing messages (or replace them with grand slam calls if you like) and still have enough possibilities to get you through several games' worth of PbP in the same game session.
Just to be sure we're clear on this: I'm practically certain that the "kind" of home run (solo, 2-run, 3-run, GS) is identified by a piece of text that comes from the game code. If I'm correct, then any grand slam call you create in your personal XML file would be redundant with what the game already provides. This would also mean that the two messages in the database that specifically mention grand slam would cause that same sort of redundancy--if either one of them happened to be the next message in the queue when a GS occurs.
As a result of all this reasoning, I'm leaning toward deleting the two GS messages from the database, because there is a slim chance (around 2 in 80-something) that they will cause a double GS call. I would hate to get rid of Dave Niehaus's "grand salami" call, though. . . .