Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Okay, as promised in (url="http://"http://www.ambrosiasw.com/webboard/Forum9/HTML/004325.html#")this thread(/url), I had an iterative entry crön-ncb looping problem that was causing s˙st load time to be obscene. By using the sledgehammer approach of turning off all my iterative entry cröns, I was able to stop it.
So, here's my question.
What's the best way to do this:
Over a period of, say, four years, I want a, let's say, 40% chance of a ship's AppearOn ncb activated. Then, at the end of that four years, the ncb should definitely be turned on.
My attempt at using iterative entries caused this looping problem.
------------------ Starfleet Adventures: A Star Trek TC for EVN (url="http://"http://www.ev-nova.net/forums/viewtopic.php?t=145") Discussion Board (/url) Starfleet Adventures (url="http://"http://www.ev-nova.net/forums/viewtopic.php?t=71")Progress Log(/url) denki's Starfleet Adventures (url="http://"http://www.geocities.com/starfleet_adventures/")FAQ page(/url) It is better to feed the goat than it is today.
Hmm. That is a head scratcher. I don't think it can be done how you'd like it done.
The only thing I can think of for you to do is make a series of crons. First, have an overall cron, that will definately make the ship appear at the end of four years. The rest of the crons (for example purposes) will have a 1% activation rate, and a random select at the end. You can chain a few of these together, so they activate in series. If a given cron ends one way, it repeats, the other way, the next cron activates (or tries to do so-1% chance). So, this way, each cron would have an average delay of 100 days (1% per day = 50 days, 50% chance at the end of repeating = 100 days, I think. Maybe it's 75. you do the math). You could string 5 or so together, and voila, it could happen just about anywhere in the 4 year period. You could adjust the activation percent or the number of crons to adjust the percentage.
Of course, this method is cron-wasteful and imprecise, but it should give you passable results.
Damn 512 cron limit!
Hope that helps.
------------------ ~Charlie Sephil Saga Homepage: (url="http://"http://www.cwssoftware.com")www.cwssoftware.com(/url)
Hrm. Considering I have roughly 57 ships activated, deactivated, or, in some cases, activated and then later deactivated in this fashion, that would sure suck up the cröns somethin' fierce. Hrm, I say. Hrm.
Any other thoughts?
Quote
Originally posted by UncleTwitchy: **Any other thoughts? **
Maybe I'm missing something (brains maybe), but it seems like this would work using 2 cröns and one NCB per ship.
The first crön takes care of the absolute appearance at the end of 4 years and is the easy one. Set EnableOn to !b<appear>, Random to 100%, Duration to 1460, OnEnd to b<appear>.
The second crön is triggered by a date range established via the First-D/M/Y to Last-D/M/Y parameters based on when you want these appearance events started. Alternatively, you could simply trigger by setting EnableOn to !b<appear>. The 2nd crön sets Random to 40%, Duration to 0, OnEnd to b<appear>.
Maybe you can't spare 114 cröns, in which case you could group the ships such that an NCB/crön-pair would cause the appearance of multiple ships.
Naahh, that sounds too simple. I must be missing something.
------------------ . "Any statement that can not be verified by experience should be classified as non-sense." - English philosopher Alfred Jules Ayer
That's what I currently have, and it seems like it only evaluates whether or not to activate at the beginning date and that's it. I had a crön that spanned a four-year period with a 90% chance of activating -- just like you describe -- and there've been multiple instances when it wouldn't activate at all. One would think the odds of that occurring to be pretty slim, but, like I say, I had numerous examples of it failing to activate.
(This message has been edited by UncleTwitchy (edited 07-25-2003).)
That is indeed one of the weak points in the Nova bible documentation. When do a lot of the NCB(test) evaluations actually occur? OK, enough of just cerebrating. I'm going to abide by Dr. Ayer's maxim and go run a bunch of experiments. Be back in a few hours.
(This message has been edited by Arturo (edited 07-26-2003).)
Hmm. Apparently I've misinterpreted the date range. I always thought that the chance of activation was a daily chance of activation, not a total chance. But the bible does indeed say differently. Hmmm, and double hmm.
I created 10 crön resources with Random probabilities set from 10 to 100 in 10% increments. Then I took those ten cröns and applied four different sets of Date gate, Duration, and EnableOn conditions. So a total of 40 different cröns. Then I ran them through the following sequence: land, take off, pause, open pilot (to get pilotlog file updated). I repeated this sequence (copying log files at each pause step) enough times to see what was happening.
The good news is everything worked as I expected (almost). The bad news is I couldnt replicate Uncle Twitchys problem of a 90% probability never occurring. The table below shows the resulting information.
Random := 10,20,30,40,50,60,70,80,90,100 OnEnd := bNNN crön test 1 crön test 2 crön test 3 crön test4 First date:= 6/23/1177 6/23/1177 6/23/1177 0/0/0=TRUE Last date := 7/3/1177 7/3/1177 0/0/0=TRUE 0/0/0=TRUE Duration := 0 0 10 10 EnableOn := <blank>=TRUE !bNNN !bNNN !bNNN . evaluated daily once once once iterations 15 12 17 17 NCBs? all set no 30% no 10% all set
The first apparent fact is that if there is an EnableOn evaluation to be made, then the crön only gets evaluated once, although when that "once" happens is still determined by the Random probability value.
The second fact is that the probabilities seem to behave themselves and the two cases of an NCB not being set are within statistical norms. I could have run the iterations until all bits got set in every case, but I'd probably still be testing instead of reporting.
Sorry U.T., I was hoping I would discover some nasty interaction between the different crön trigger parameters that would explain your problem. C'est la vie. The only other thing that comes to mind right now is that you may have unintentionally used one or more NCBs for multiple conflicting purposes. I don't know if you've tried this, but a very good troubleshooting tool for large numbers of Nova resources is the ConText-to-spreadsheet technique. Incongruities leap out at you when you see all of the members of a given resource arranged next to each other. Just a thought.
(This message has been edited by Arturo (edited 07-25-2003).)
Well, since it does only ever get evaluated once (and my guess is that the one time is evaluated , it could very well be that those occasions did hit the 10% when it fails. I just need to make sure that the "definitely appears by this date" crön is properly setting the ncb it's supposed to set -- in this case, by removing any EvaluateOn references.
Pity about the evaluating only once if it has a EvaluateOn bit -- and if you turn on an iterative entry, it creates that looping problem.
Damn. Guess I'll just have to have fixed dates on every ship's appearance, then.
Pipeline, any thoughts? Did you guys try to do anything like this for the base Nova scenario?
A thought: Make two variants of the new shďp. Call them NewShďpA and NewShďpB. Make them identical except for their AppearOn test. NewShďpA Appear on will be bA, and NewShďpB AppearOn will be bB.
Fill your düde normally. When you get to the new ship, enter both NewShďpA and NewShďpB and split the appearance probability between them as you desire. Then use cröns to set bits A and B sequentially, so that the number of appearances of the new ship will increase more smoothly.
-reg
------------------ "Oh crap. I'm going to hell - I put the Bible next to Mein Kampf again." -Her Holiness, Pope Jenne "Kirby" Hubbs
Hey, not bad, but this is even easier -- two AppearOn bits that are evaluated as OR, i.e.:
Appear On: bA | bB.
That way the düdes don't get filled up as quickly... lots more ncbs than there are fields in the düde resources.
Ok, but I don't see how that accomplishes what you want. !a | b is just as "on" as a | b.; you don't get any added granularity when phasing the ship in.
Anyway, I'd be impressed if 16 shďp slots in a düde is insufficient for you, especially given that there's room for 4 (or is it more now?) düdes in each s˙st. One thing I'm grateful not to have to worry about in EVN is resource limits, since for all practical purposes it's impossible to meet most of them.
For some düdes, I do indeed push those limits -- and the 8 düde slots in the s˙sts are proving quite limiting in some instances...but it's okay, it's forcing me to think creatively.
At one stage, Nova did have a number of recurring cröns, but they were removed due to confused players.
all the best,
Dave
<Sidenote> The 8-dude limit can indeed be very limiting, since every ship in a dude has the same government. I've had to be very careful about picking dudes in many systems, since 20 to 30 different governments could quite legitimately appear in some of the major systems. One thing I'm doing is using lots and lots of fleets and 'generic' persons to flesh out the ranks. Quick question: the "uses escape pod" bit means the pers is not dead when you kill them, right? They'll show up again, right?</Sidenote>
Thanks for the research, Arturo. Very helpful.
Originally posted by Masamune: **< Sidenote>Quick question: the "uses escape pod" bit means the pers is not dead when you kill them, right? They'll show up again, right?</Sidenote> **
Yes, Wildwood Labratories has proven that the "Uses escape pod & has afterburner" flag bit essentially makes the përs immortal.
{idle-thought} When someone says they have a "Quick question", it always makes me wonder what a slow question would be.{/idle-thought}
------------------ "No man is an island ... he's a peninsula." - Jorma Kaukonen
Originally posted by Arturo: When someone says they have a "Quick question", it always makes me wonder what a slow question would be. (/B)
Presumably, it would be one that requires its own topic.