On 5 Jul 2002, Tom Whiting wrote:
> > the way. And what codebase Rom Rot etc..?
> Once again, read email before asking.
> Porting OLC2 to Rot, while possible, is most likely NOT going to be
> happening.. As it was, porting 1.8 was bad enough
hehe i know people who put olc2.0 into something i wouldn't even call C
CircleMUD List: Oasis OLC 2.0 Bug
Oasis OLC 2.0 Bug. From: Griffin Hernandez ([EMAIL PROTECTED]) Date:
10/16/01:
Next message: Phillip Tran: "[ADMIN][INFO][LONG] Perform_Violence ...
www.circlemud.org/maillist/2001-10/0074.html - 4k - Cached - Similar pages
need i say more?
j/k :P
> > I dont think we wanna dig threw the archives trying to find a nice little
> > customize bug. Theres prolly 100 or more.
> Again, read the emails before asking, and run your mail through a spell
> checker.
> If you don't have a solution for the problem, it's best to just keep to
> yourself, allowing others that DO have one to help solve it.
>
>
> > > I've been reading up on this bug in the archives, but
> > > all of the bug fixes seem to just lead to more
> > > problems. Has anyone encountered this problem?
> No (and I AM running olc2, have been for almost 2 years, had almost
> little problems with it that couldn't be solved with a little common
> sense:P).
>
> Here's a couple of solutions for you:
> A> Go through your customization code, make sure that you have done
> everything CORRECTLY.
Awe i think if they weren't set correctly he would get skills on some
classes and not others. Oh no it crashed.
> B> Take out customization completely (unless you're running a full pk
> mud, or plan on encouraging it heavily, it's not the best.). This will
> only temporarily solve the problem however.
Hello D&D who are you!?
> C> Go through ALL of your spellgroups and make sure they're set
> correctly. If you've added classes or groups, that's probably your
> problem.
Awe when choosing a class the mud crashes?
Hrm something wrong with this. How did you come up with this. Never
mind maybe the case CON_GEN_GROUPS chooses the class too?
>
> More than likely, the problem is NOT with customization, but with a
> separate function INSIDE of customization. Did you patch this into a
> STOCK mud, or did you wait and add things, THEN adding OLC?
haha got Code?
hrm now for some real truth.
GEN_DATA *new_gen_data(void)
{
GEN_DATA *gen;
if (gen_data_free == NULL)
gen = alloc_perm(sizeof(*gen));
else
{
gen = gen_data_free;
gen_data_free = gen_data_free->next;
}
+#if defined( FIRST_BOOT )
VALIDATE( gen );
+#else
+ gen->group_chosen = ( bool * ) malloc( sizeof(
bool ) * MAX_GROUP );
+ gen->group_chosen[MAX_GROUP-1] = 0;
+ gen->skill_chosen = ( bool * ) malloc( sizeof(
bool ) * MAX_SKILL );
+ gen->skill_chosen[MAX_SKILL-1] = 0;
+ VALIDATE(gen);
+#endif
return gen;
}
the VALIDATE(gen); here would not be in use if you do not have the
-FIRST_BOOT in your makefile. And since you just added it my guess
you have followed the instructions on the install file and took
-FIRST_BOOT out of the makefile?
as for VALIDATE
#define VALIDATE(data) ((data)->valid = TRUE)
hrm lets see here a data pointer call macro.
you should be able to get away with removing the #define FIRST_BOOT
comment out the
/* +#else
+ gen->group_chosen = ( bool * ) malloc( sizeof(bool ) * MAX_GROUP );
+ gen->group_chosen[MAX_GROUP-1] = 0;
+ gen->skill_chosen = ( bool * ) malloc( sizeof(bool ) * MAX_SKILL );
+ gen->skill_chosen[MAX_SKILL-1] = 0;
+ VALIDATE(gen);
+#endif */
if you still have all the FIRST_BOOT defines in your code
just follow ivans directions. about the FIRST_BOOT
if you took out the useless code thats left after the OLC 2.01 install
just
make it look like this
/* +#if defined( FIRST_BOOT ) */
VALIDATE( gen );
/* +#else
+ gen->group_chosen = ( bool * ) malloc( sizeof(bool ) * MAX_GROUP );
+ gen->group_chosen[MAX_GROUP-1] = 0;
+ gen->skill_chosen = ( bool * ) malloc( sizeof(bool ) * MAX_SKILL );
+ gen->skill_chosen[MAX_SKILL-1] = 0;
+ VALIDATE(gen);
+#endif */
return gen;
}
clean compile for safetys sake.
bring the mud up. kill it.
then just change it back to the way you had it.
You should be ok.
And if that fails.
Maybe someone on the list knows more about gen_data then i do.
And they can put you together a quick if else check to see the
new validate of the new number of groups and number of skills
if they exist or not.
EOF
