Some would probably say 'tsk tsk tsk!' at what you have done. But, really, it's inevitably not a bad idea. It also takes care of 'problems' for hp, mana, and move limits as well.
However, there are some hardcodes in ROM that cap out at around 32k or 65k (1024*64). An example is get_random_room, where they get a room like so: room = get_room_index (number_range (0, 65535)); -- only checks up to an unsigned int range--you'll need to change this manually. Another example is in olc_act.c: MEDIT (medit_group) Another 64k deal. There may be other such treacheries throughout the code, I'm not sure. -- Jeremy ----- Original Message ----- From: "Cyhawk" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, January 25, 2004 3:21 AM Subject: Question regarding sh_int > On my quest to find more vnums (as my world takes up 25,000 as it is, > adding new areas is a true pain, my hats off to erwin for the perl one > liner to automate this) > and looking for a few "unlimited vnum" snips, i wondered.. and tried to > come up with a simple solution on my own. > > My solution, was to > #define sh_int int > in merc.h > > Low and behold, it worked.. Now.. my question is.. > > What sort of backlash am i looking at here? Aside from the incressed memory > usage (which from what i see, is a whole .4% on a 256 meg machine) > Do i have any long term issues i need to address? Was this a completely > foolish idea from a newbie coder? > > Now, as i understand it, sh_int was created as a short integer, for > memory/cpu considerations way back when i was still using my Atari ST > to surf around on gopher and BBSs, but with todays machines.. > /begin_bloat_ware/ is it really nessecary to micromanage everything? /end/ > > Feel free to slap me silly if this is just utterly the wrong approch to the > issue at hand. > > -Thri > > > -- > ROM mailing list > [email protected] > http://www.rom.org/cgi-bin/mailman/listinfo/rom
