19 Sep, 2008, Guest wrote in the 2nd comment:
for( counter = 0; counter < MAX_DAM_TYPE - 1; counter++ )
I think this should be changed to remove the -1 part from the center condition. At some point I clearly ran into this with AFKMud and solved it that way.
19 Sep, 2008, The_Fury wrote in the 3rd comment:
Yeah that didn't change anything, I have been hitting my head about this for the last hour, i think i will take a break download AFK and see exactly what you did Samson. I might see something that i have missed.
The only thing i see thats different is the returns on the menu functions, all the rest loks the same to me, and taking out the returns did nothing.
The only thing i see thats different is the returns on the menu functions, all the rest loks the same to me, and taking out the returns did nothing.
19 Sep, 2008, Davion wrote in the 4th comment:
Where does it set whatever variables being switch'd to OEDIT_VALUE_5. Looks like this works a lot like character creation, so maybe in "case OEDIT_VALUE_4", it's not progressing them through the switch statement.
19 Sep, 2008, Chris Bailey wrote in the 5th comment:
void oedit_disp_damage_type_menu( DESCRIPTOR_DATA * d )
{
char buf[MAX_STRING_LENGTH];
CHAR_DATA *ch = d->character;
OLC_MODE( d ) = OLC_VALUE_5
int counter, col = 0;
ch_printf_color( d->character,"&D——————————————————————————–\n\r");
ch_printf_color( d->character,"&c Damage Type Menu EldhaMUD OLC\n\r", 0 );
ch_printf_color( d->character,"&D——————————————————————————–\n\r");
for( counter = 0; counter < MAX_DAM_TYPE - 1; counter++ )
{
sprintf( buf, "&P%2d&w) %-20.20s ", counter, attack_table[counter] );
if( ++col % 2 == 0 )
strcat( buf, "\n\r" );
send_to_char_color( buf, ch );
}
send_to_char( "\n\rEnter weapon damage type: ", ch );
return;
}
I believe OLC_MODE should be set up there at the top of the function but it seems redundant as it's set in parent menu before it call disp_damage_type_menu. Fury and I tried several variations of this code last night (for hours) and came up with nothing.
19 Sep, 2008, The_Fury wrote in the 6th comment:
Davion said:
Where does it set whatever variables being switch'd to OEDIT_VALUE_5. Looks like this works a lot like character creation, so maybe in "case OEDIT_VALUE_4", it's not progressing them through the switch statement.
case OEDIT_VALUE_4:
number = atoi( arg );
switch ( obj->item_type )
{
case ITEM_PILL:
case ITEM_SCROLL:
case ITEM_POTION:
case ITEM_WAND:
case ITEM_STAFF:
min_val = -1;
max_val = top_sn - 1;
if( !is_number( arg ) )
number = skill_lookup( arg );
break;
case ITEM_WEAPON:
min_val = 0;
max_val = WEP_MAX - 1;
if( number < min_val || number > max_val )
{
oedit_disp_val4_menu( d );
return;
}
break;
default:
min_val = -32000;
max_val = 32000;
break;
}
obj->value[3] = URANGE( min_val, number, max_val );
olc_log( d, "Changed v3 to %d", obj->value[3] );
if( IS_OBJ_STAT( obj, ITEM_PROTOTYPE ) )
obj->pIndexData->value[3] = obj->value[3];
oedit_disp_val5_menu( d ); <———–This is Called and in there its set to OLC_MODE( d ) = OEDIT_VALUE_5;
break;
case OEDIT_VALUE_5:
number = atoi( arg );
switch ( obj->item_type )
{
case ITEM_SALVE:
if( !is_number( arg ) )
number = skill_lookup( arg );
min_val = -1;
max_val = top_sn - 1;
break;
case ITEM_FOOD:
min_val = 0;
max_val = 32000;
break;
case ITEM_WEAPON:
ch_printf_color( d->character,"VALUE5 item weapon case\n\r");
min_val = 0;
max_val = MAX_DAM_TYPE;
if( number < min_val || number > max_val )
{
oedit_disp_val5_menu( d );
return;
}
break;
default:
min_val = -32000;
max_val = 32000;
break;
}
Ok Davion is on the right path here, because i know its not ever entering the case OEDIT_VALUE_5; from oedit_disp_val5_menu, it calls oedit_disp_damage_type_menu and then after that defaults back to the main menu, at no point is it entering the case, tho it should to by my thought as its set the right value in the oedit_disp_val5_menu function.
19 Sep, 2008, Davion wrote in the 7th comment:
Maybe it's not even getting that far! See if " olc_log( d, "Changed v3 to %d", obj->value[3] );" appears in your logs.
19 Sep, 2008, The_Fury wrote in the 8th comment:
Fri Sep 19 18:25:40 2008 :: Log Fury: OBJ(4000): Changed v0 to 1
Fri Sep 19 18:25:40 2008 :: Log Fury: OBJ(4000): Changed v1 to 2
Fri Sep 19 18:25:41 2008 :: Log Fury: OBJ(4000): Changed v2 to 3
Fri Sep 19 18:25:42 2008 :: Log Fury: OBJ(4000): Changed v3 to 4
Its just not hitting V4,
Fri Sep 19 18:25:40 2008 :: Log Fury: OBJ(4000): Changed v1 to 2
Fri Sep 19 18:25:41 2008 :: Log Fury: OBJ(4000): Changed v2 to 3
Fri Sep 19 18:25:42 2008 :: Log Fury: OBJ(4000): Changed v3 to 4
Its just not hitting V4,
19 Sep, 2008, Davion wrote in the 9th comment:
Ok, then most likely it's getting there, just the default case in oedit_display_val5_menu is sending them to oedit_disp_menu(). Maybe somethings going wrong here->
Throw in some random logging in there to see if that's where it jumps out. Also print the obj->item_type, ITEM_WEAPON, and OEDIT_VALUE_5, I guess. Make sure they're all correct.
OBJ_DATA *obj = d->character->dest_buf;
Throw in some random logging in there to see if that's where it jumps out. Also print the obj->item_type, ITEM_WEAPON, and OEDIT_VALUE_5, I guess. Make sure they're all correct.
19 Sep, 2008, The_Fury wrote in the 10th comment:
I will teach myself breakpoints tomorrow when i got some more time and step my way through the whole thing to see where its falling out, from my initial testing by putting in a bunch of sent_to_char's i know its going from case OEDIT_VALUE_4, to oedit_disp_val5_menu where it enters the WEAPONS case and calls oedit_disp_damage_type_menu and then hits the default menu call at the bottom of the parse function, so its not every entering the OEDIT_VALUE_5 case.
Not sure why yet, but i will read nicks GDB guide for the 5th time and then breakpoint the hell out of the whole thing to see what the hell is going on.
Thanks all for the input so far,
Not sure why yet, but i will read nicks GDB guide for the 5th time and then breakpoint the hell out of the whole thing to see what the hell is going on.
Thanks all for the input so far,
19 Sep, 2008, Davion wrote in the 11th comment:
Wanna dump that entire function containing the switch statement into the pastebin? I'll skim it and see if I spot anything (I've never actually seen OasisOLC before)
19 Sep, 2008, The_Fury wrote in the 12th comment:
If you like i can send you the whole code, got svn? i will let you pull a copy down to look over.
When it enters oedit_disp_val5_menu before it hits the switch.
d->olc->mode OLC MODE 17 :
OEDIT_VALUE_5 == OLC VALUE 17 :
dest buffer practice sword :
The data seems correct but it still does not drop into the OEDIT_VALUE_5 case in the parse function.
When it enters oedit_disp_val5_menu before it hits the switch.
d->olc->mode OLC MODE 17 :
OEDIT_VALUE_5 == OLC VALUE 17 :
dest buffer practice sword :
The data seems correct but it still does not drop into the OEDIT_VALUE_5 case in the parse function.
19 Sep, 2008, Davion wrote in the 13th comment:
The_Fury said:
If you like i can send you the whole code, got svn? i will let you pull a copy down to look over.
I don't! Or I do… not sure. Never really used it :S. You can e-mail it to me at davionkalhen@gmail.com or link me…
19 Sep, 2008, The_Fury wrote in the 14th comment:
sent you a PM, you can view it on the web with svn_view hehe and if you have svn add that before the http in a shell and you can pull down a copy to play with.
20 Sep, 2008, Davion wrote in the 15th comment:
I dunno if this is it, but atm, this is all that sticks out.
In all the other cases, these functions never call the OLC_MODE macro. Try removing that. Might be leftovers though, from testing.
void oedit_disp_damage_type_menu( DESCRIPTOR_DATA * d )
{
char buf[MAX_STRING_LENGTH];
CHAR_DATA *ch = d->character;
int counter, col = 0;
ch_printf_color( d->character,"&D——————————————————————————–\n\r");
ch_printf_color( d->character,"&c Damage Type Menu EldhaMUD OLC\n\r" );
ch_printf_color( d->character,"&D——————————————————————————–\n\r");
for( counter = 0; counter < MAX_DAM_TYPE; counter++ )
{
sprintf( buf, "&P%2d&w) %-20.20s ", counter, attack_table[counter] );
if( ++col % 2 == 0 )
strcat( buf, "\n\r" );
send_to_char_color( buf, ch );
}
send_to_char( "\n\rEnter weapon damage type: ", ch );
OLC_MODE( d ) = OEDIT_VALUE_5;
return;
}
In all the other cases, these functions never call the OLC_MODE macro. Try removing that. Might be leftovers though, from testing.
20 Sep, 2008, The_Fury wrote in the 16th comment:
Yeah thats from testing, i have tryed that in and out and in other places in that function and still it falls through the parse case.
20 Sep, 2008, Davion wrote in the 17th comment:
Heh, wow. I can't even believe I caught it ;)
In oedit_parse()
Go to your new set of case's, in case OEDIT_VALUE_5, change that last break, to a return;.
If you don't return it reaches the bottom of the function which calls oedit_disp_menu();
In oedit_parse()
Go to your new set of case's, in case OEDIT_VALUE_5, change that last break, to a return;.
case OEDIT_VALUE_5:
number = atoi( arg );
switch ( obj->item_type )
{
case ITEM_SALVE:
if( !is_number( arg ) )
number = skill_lookup( arg );
min_val = -1;
max_val = top_sn - 1;
break;
case ITEM_FOOD:
min_val = 0;
max_val = 32000;
break;
case ITEM_WEAPON:
ch_printf_color( d->character,"VALUE5 item weapon case\n\r");
min_val = 0;
max_val = MAX_DAM_TYPE;
if( number < min_val || number > max_val )
{
oedit_disp_val5_menu( d );
return;
}
break;
default:
min_val = -32000;
max_val = 32000;
break;
}
obj->value[4] = URANGE( min_val, number, max_val );
olc_log( d, "Changed v4 to %d", obj->value[4] );
if( IS_OBJ_STAT( obj, ITEM_PROTOTYPE ) )
obj->pIndexData->value[4] = obj->value[4];
ch_printf_color( d->character,"calling dis 6\n\r");
oedit_disp_val6_menu( d );
return;
If you don't return it reaches the bottom of the function which calls oedit_disp_menu();
20 Sep, 2008, The_Fury wrote in the 18th comment:
Ummm that didnt work for me, did you test it? Because to me it seems its not even entering that case and all the other cases all break as well, wouldnt it mean that those should fail alos if that was the case.
20 Sep, 2008, Davion wrote in the 19th comment:
Ya, I tested. worked for me…
Make sure you check the others for the very same issue. olc_disp_menu() calls OLC_MODE() and sets it to main menu, which is why it sends you to the menu and doesn't respond to proper arguments for dam type. So check case OEDIT_VALUE_4 too
Condition : 100
Number of damage dice : 5
Size of damage dice : 11
——————————————————————————–
Weapons Type Menu EldhaMUD OLC
——————————————————————————–
0) Barehand 1) Sword
2) Dagger 3) Whip
4) Talon 5) Hammer
6) Archery 7) Blowgun
8) Sling 9) Axe
10) Spear 11) Staff
12) Polearm
Enter weapon type: 1
——————————————————————————–
Damage Type Menu EldhaMUD OLC
——————————————————————————–
0) hit 1) slash
2) stab 3) hack
4) crush 5) lash
6) pierce 7) thrust
8) slice 9) (null)
Enter weapon damage type: 0
VALUE5 item weapon case
calling dis 6
——————————————————————————–
Objects Main Menu EldhaMUD OLC
——————————————————————————–
– Item number : [96]
1) Name : Steel Masakari of Fate
2) S-Desc : a Steel Masakari of Fate
3) L-Desc :-
A Steel Masakari of Fate
4) A-Desc :-
5) Type : Weapon
6) Extra flags :
7) Wear flags : take wield
8) Weight : 15
9) Cost : 300
A) Rent(unused): 0
B) Timer : 0
C) Level : 3
D) Layers : 0
E) Values : 100 5 11 1 0 0
F) Affect menu
G) Extra descriptions menu
Q) Quit
Make sure you check the others for the very same issue. olc_disp_menu() calls OLC_MODE() and sets it to main menu, which is why it sends you to the menu and doesn't respond to proper arguments for dam type. So check case OEDIT_VALUE_4 too
20 Sep, 2008, The_Fury wrote in the 20th comment:
Can you comment where you have edited it and commit it to the repository, i will look at it again later. svn commit -m "Davions Changes"
I gotta go get ready for a wedding, i have already wasted too much time today and I thank you very much for taking a look at this and working out what was the problem, If you were in Aussie i would buy you a beer. HEH.
I gotta go get ready for a wedding, i have already wasted too much time today and I thank you very much for taking a look at this and working out what was the problem, If you were in Aussie i would buy you a beer. HEH.
Random Picks
Number of damage dice : 2 <—V1
Size of damage dice : 2 <—V2
——————————————————————————–
Weapons Type Menu EldhaMUD OLC <—V3
——————————————————————————–
0) Barehand 1) Sword
2) Dagger 3) Whip
4) Talon 5) Hammer
6) Archery 7) Blowgun
8) Sling 9) Axe
10) Spear 11) Staff
12) Polearm
Enter weapon type: 2
——————————————————————————–
Damage Type Menu EldhaMUD OLC <—V4
——————————————————————————–
0) hit 1) slash
2) stab 3) hack
4) crush 5) lash
6) pierce 7) thrust
8) slice
Enter weapon damage type:
– Item number : [4000]
1) Name : practice sword
2) S-Desc : a practice sword
3) L-Desc :-
q
4) A-Desc :-
5) Type : Weapon
6) Extra flags : metal antilife antidecay antigrowth
7) Wear flags : take wield
8) Weight : 1
9) Cost : 0
A) Rent(unused): 0
B) Timer : 0
C) Level : 45
D) Layers : 0
E) Values : 2 2 2 2 1 0
F) Affect menu
G) Extra descriptions menu
Q) Quit
Enter choice :
As you can see by the above game output, when it gets to damage type it just falls through back to the main menu.
For the life of me i cannot work out whats going on here. Anyone got any ideas for me, or want to take a look at all the code? LOL.