You could also keep track of the top room vnum, and use that.
This, of course, would force you to use your vnums consequetively and not go
all the way to the high end (which I can't see why you would want to)




> -----Original Message-----
> From: Jennifer King [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 27, 2003 1:45 PM
> To: Rom Mailing List
> Subject: RE: number_range problem
> 
> 
> If you're looking for ways to improve performance in 
> get_random_room, and
> if you're using olc, try looping through the area vnums first and then
> generating a random room from within that area's min and max 
> room vnums.
> This way you're only cycling through used vnums instead of billions of
> nonused ones.
> 
> ---
> RogueDragon @ A Merging of Fates MUD
> telnet://mud.merging.org:5454
> icq: 2072355 (inactive atm), yim: roguedragon, aim: roguedragon69
> ---
> Windows - Where do you want to go today?
> Linux   - Where do you want to go tomorrow?
> FreeBSD - When are they going to catch up?
> 
> On Wed, 26 Mar 2003, Hiddukel wrote:
> 
> > Thank you both for your replies.  I changed power to a long 
> long and it
> > is working perfectly.  I understand that there *could* be a 
> performance
> > loss from doing that as you are looping much more times 
> checking invalid
> > rooms, however I have run a test using this and generating 100 valid
> > random room vnums using get_random_room and I notice no 
> performance hit,
> > it gives me 100 results immediatly.  That is not to say 
> that there is
> > not a performance hit though as I'm sure there is, but in a 
> mud I can't
> > see that this particular hit will affect overall 
> performance enough to
> > not use it as it stands.
> >
> > Once again thank you for the fix and information regarding 
> the operand.
> >
> > Matt Bradbury
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Michael
> > Barton
> > Sent: Wednesday, March 26, 2003 07:39 PM
> > To: Tiikuli; Hiddukel
> > Cc: 'Rom Mailing List'
> > Subject: Re: number_range problem
> >
> > > I bet that it hangs because the value overflows (becomes 
> negative),
> > thus
> > > never actually reaching 'to'.
> >
> > Yeah, slight problem here... I'm not sure there's an easy 
> way to fix it
> > without changing power to a "long long", which could impact
> > performance..
> > You can fake it, of course.
> >
> >   long vnum;
> >   vnum = number_range(0, 21474) * 100000;
> >   vnum += number_range(0, 83647);
> >   room = get_room_index(vnum);
> >
> > er.. it's really not a very good algorithm if you've only 
> filled, say,
> > 0.01%
> > of 2 billion rooms, though.  It could take a while to find 
> a valid room
> > in
> > all that.
> >
> > --Palrich.
> >
> >
> > --
> > ROM mailing list
> > [email protected]
> > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
> >
> >
> > --
> > ROM mailing list
> > [email protected]
> > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
> 
> -- 
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
> 

Reply via email to