Quote
Originally posted by Azratax2:
This is really clever.
How do you get all those crons to run in order? Just thier RID order?
The way they're set up, the only conflict is between the 2nd and 5th crons, but I think Nova runs them in RId order, so by the time the 2nd has finished running, the criteria no longer exist for the 5th to run. I could guarantee it by chucking in another bit.
Quote
I do worry about the effect on proformance of having even a few of these counters running. Does it cause any noticible delay when you have counters that start at like 1000 like you gave an example of? If the delay isnt a problem, then this is a real win for large counters.
Good question. I haven't tried yet, but it's only going to run once a day at most. Should try it out some time.
Quote
**NCB counters still have an advantage for applications in which you need different things responding to different values (ie, where A would only happen if counter >5, and b would only happen if counter>8 etc), unless i am missing some way to expand on the Boyd Outfit Counter. **
The Boyd Outfit Resource Counter, or BORC for short is capable of doing this as well with a few tweaks. Basically you run 2 BORCs, sharing some of the resources. The BORC BORC setup would be:
Enable On ............ On Start ...... On End .. CIC Entry
O2 & !b0 .............. D2 G3 G4 ................... Yes ........ Moves total into outfits 3 and 4
O1 & O3 ............... D1 D3 ........ b0 .......... Yes ........ Compares counter, total in 3 by decr until 1 is zero
!O3 & b0 .............. trigger 1 ..................... No ........ If counter>=total then trigger fires
b1 & !O3 & O4 ..... G2 D4 ......................... Yes ........ Rezeroes 4 and restores the total in 2
O3 & O4 .............. G1 G2 D4 ... !b0 .......... Yes ........ If counter<total then total is moved back to outfit 2
O1 & O3 .............. D1 D3 ......................... Yes ........ Sets counter back to pre-calc status
O5 & !b0 .............. D5 G3 G4 ................... Yes ........ Moves total into outfits 3 and 4
O1 & O3 ............... D1 D3 ........ b0 .......... Yes ....... Compares counter, total in 3 by decr until 1 is zero
!O3 & b0 .............. trigger 2 ..................... No ........ If counter>=total then trigger fires
b1 & !O3 & O4 ..... G5 D4 ......................... Yes ....... Rezeroes 4 and restores the total in 2
O3 & O4 .............. G1 G5 D4 ... !b0 .......... Yes ........ If counter<total then total is moved back to outfit 2
O1 & O3 .............. D1 D3 ......................... Yes ........ Sets counter back to pre-calc status
Uses double the crons, 1 extra outfit, no extra ncbs, runs off the same counter. It is possible, depending on whether or not a cron can run twice in one day, that 2 crons could be dropped.
In order to duplicate this using (url="http://"http://www.ambrosiasw.com/webboard/Forum9/HTML/002708.html")Regulus' method(/url) you would simply add a cron for each value you want to check, providing significant resource savings once you start running more than 2 checks. It does, however, have the disadvantage of being a 'equal to only' system i.e. won't trigger for counter values greater than the total you're looking for and isn't very human readable. Though it would be simple enough to program some crons to convert an ncb counter into a quantity of an outfit and vice-versa.
If you're doing multiple checks on one counter for exactly equal to values and are happy with simply adding 1 each day, then ncb counters rule, resourcewise. If you're looking for greater than or equal checks, running multiple independent counters or need to add more than 1 to your counter each day, then you should be BORCing. Though ncb counters could add more than 1 a day with additional crons. Essentially you'd have 2 sets of bits, 1 representing the counter, another representing the value to be added and then add the two. I think you'd need n(n+1)/2 crons for it. And you still wouldn't get >= checking.
Interestingly, in order to get certain mathematical operations such as multiplication to work on 1 single day, a combination of ncb counters and BORCing would be required. For instance if we have 2 numbers we want to multiply, each n bits long, but stored as an outfit quantity, we would convert one to a set of bits, then use an additional n+3 crons to perform the multiplication and tidy up. Unfortunately, the conversion seems to be a 2+5(n-2) = 5n-8 cron process at the moment, giving a total of 6n-5 To multiply one 4 bit number by another (not necessarily 4 bit) number, you would need 19 crons.
I've roughly sketched out a system where you multiply a pair of n bit numbers in an ncb system, allowing for a 2n answer and it scales very unpleasantly, requiring over 6n bits and a large number of n^2 crons, or possibly n^3. Either way, it's messy and as far as I can see, impractical. The only decent way to do multiplication that I can tihnk of is by BORCing an ncb counter.
------------------
(url="http://"http://homepage.mac.com/jonathanboyd/evn/index.html")Classic4Nova plug-in(/url)
