01 Dec, 2008, Igabod wrote in the 1st comment:
Votes: 0
in the stock low4 code do_train has a max of 50 set for everything. i can change it to 100 with no problems but i want to change that to 1000. when i do that however, anytime i train hp 1000 the mud crashes. is there something i'm missing? i'm sure it's something really small and stupid. Also, does anybody know where i can find the instructions for making the max hp possible to be higher than 30,000? i remember doing this for another low4 mud years ago but i can't remember exactly what i have to do.
01 Dec, 2008, David Haley wrote in the 2nd comment:
Votes: 0
What are the data types involved? And have you tried running this through gdb to identity exactly where the crash occurs?
01 Dec, 2008, Zeno wrote in the 3rd comment:
Votes: 0
Tried using gdb to debug why it is crashing?
01 Dec, 2008, KaVir wrote in the 4th comment:
Votes: 0
It's because do_train uses recursion. You should change it to a loop.
02 Dec, 2008, Igabod wrote in the 5th comment:
Votes: 0
i asked here first cause thats a lot easier due to the fact that i'm positive many people have come across this before. i was sorta hoping for a more newbie-friendly answer however seeing as how i have no clue what recursion means in this case. maybe i should have specified that i'm not a trained programmer, just a tinkerer. i'm sure kavir's answer is the correct one seeing as how this is a godwars based code, i'm just not as adept at coding as he obviously assumed i am.
02 Dec, 2008, David Haley wrote in the 6th comment:
Votes: 0
Recursion is when functions call each other repetitively until some condition is met. Every time a function is called, a new frame (or context if you will) is pushed onto the program stack. You can only push so many frames onto the program stack before you run out of space. Assuming that KaVir is correct (and as you say there's no reason to believe he's not) the problem is that this function uses recursion to do its job, meaning that if it has to go to a depth of 1000, it is very likely using up too much stack space.

For a guide to gdb, I would recommend this article by Nick Gammon.
06 Dec, 2008, Igabod wrote in the 7th comment:
Votes: 0
Ok, so now I'll ask the other question that didn't get answered again. Does anybody know where I can find the instructions for making the max hp possible to be higher than 30,000? I remember doing this for another low4 mud years ago but I can't remember exactly what I have to do. I think it had something to do with changing all the int's to sh_ints or something. It's been too long for me to remember.
06 Dec, 2008, Littlehorn wrote in the 8th comment:
Votes: 0
Igabod said:
Ok, so now I'll ask the other question that didn't get answered again. Does anybody know where I can find the instructions for making the max hp possible to be higher than 30,000? I remember doing this for another low4 mud years ago but I can't remember exactly what I have to do. I think it had something to do with changing all the int's to sh_ints or something. It's been too long for me to remember.


short int
signed: -32768 to 32767
unsigned: 0 to 65535

int
signed: -2147483648 to 2147483647
unsigned: 0 to 4294967295
06 Dec, 2008, Igabod wrote in the 9th comment:
Votes: 0
ok…. and where am i supposed to do this? And what does this mean? And how does this make it so the max hp can be 100,000 rather than 30,000? I'm not following here at all.
06 Dec, 2008, Littlehorn wrote in the 10th comment:
Votes: 0
Igabod said:
ok…. and where am i supposed to do this? And what does this mean?


Bah let me finish posting haha!

Quote
When programming, we store the variables in our computer's memory, but the computer has to know what kind of data we want to store in them, since it is not going to occupy the same amount of memory to store a simple number than to store a single letter or a large number, and they are not going to be interpreted the same way.

The memory in our computers is organized in bytes. A byte is the minimum amount of memory that we can manage in C++. A byte can store a relatively small amount of data: one single character or a small integer (generally an integer between 0 and 255). In addition, the computer can manipulate more complex data types that come from grouping several bytes, such as long numbers or non-integer numbers.

Next you have a summary of the basic fundamental data types in C++, as well as the range of values that can be represented with each one:


Not too sure where yours could be but it's most commonly found in your merc.h file in char_data as quoted below:

struct    char_data
{
<clipped out most of other code>
sh_int hit;
sh_int max_hit;
sh_int mana;
sh_int max_mana;
sh_int move;
sh_int max_move;


Increasing the data type on hit; to int would increase it.
06 Dec, 2008, Kayle wrote in the 11th comment:
Votes: 0
You would need to increase both hit and max_hit to be able to train above 32k+change. Or I believe the limit is 64k+change on 64bit systems.
06 Dec, 2008, Igabod wrote in the 12th comment:
Votes: 0
wow, lots of warnings arose from doing that. mostly long int format, different type arg (arg 3) stuff. i'm pretty sure i know how to fix this but i'm also sure that my fix isn't the best way to do it and is extremely time consuming due to the large number of these warnings. Any advice on something better than going through the code to each of those lines and putting (int) in front of each of the args in question?

[edit to add] After some testing I found out that now when a character gets mortally wounded their HP goes to 4294967286 but this is in red (as it does when the hp is at -10 like it's supposed to be) the character is still in the mortally wounded position however.
06 Dec, 2008, Littlehorn wrote in the 13th comment:
Votes: 0
Igabod said:
wow, lots of warnings arose from doing that. mostly long int format, different type arg (arg 3) stuff. i'm pretty sure i know how to fix this but i'm also sure that my fix isn't the best way to do it and is extremely time consuming due to the large number of these warnings. Any advice on something better than going through the code to each of those lines and putting (int) in front of each of the args in question?


Copy the code you changed here. It should not have any errors from simply changing sh_int to just int on hit and max_hit. Unless user error.

Code should look like this:

sh_int             wait;
sh_int daze;
int hit;
int max_hit;
sh_int mana;
06 Dec, 2008, Igabod wrote in the 14th comment:
Votes: 0
sh_int             agg;
int hit;
int max_hit;
int mana;
int max_mana;
int move;
int max_move;
int gold;


just to let you know, i'm using a godwars/low4 codebase
06 Dec, 2008, Sharmair wrote in the 15th comment:
Votes: 0
If you have any functions that take the hp, mana or move data as a sh_int, they should be changed to take int. I mean in the function prototype and function definition. I can't off hand think of any place you would want to cast to int though. As far as getting that large value for negative numbers, it looks like you are using an unsigned int someplace (the largest unsigned int value maps to -1 as a signed value). You might also have to change some hard coded limit values like in the edit function that might still range limit your input to 32,000 or there abouts.
07 Dec, 2008, KaVir wrote in the 16th comment:
Votes: 0
Littlehorn said:
short int
signed: -32768 to 32767
unsigned: 0 to 65535

int
signed: -2147483648 to 2147483647
unsigned: 0 to 4294967295


Sorry to sound pedandic, but I feel compelled to reply for the sake of correctness.

The range is platform dependant, but the minimum range guaranteed by the C standard is -32767 to 32767 for a signed short int, and -2147483647 to 2147483647 for a signed int.
07 Dec, 2008, Littlehorn wrote in the 17th comment:
Votes: 0
KaVir said:
Littlehorn said:
short int
signed: -32768 to 32767
unsigned: 0 to 65535

int
signed: -2147483648 to 2147483647
unsigned: 0 to 4294967295


Sorry to sound pedandic, but I feel compelled to reply for the sake of correctness.

The range is platform dependant, but the minimum range guaranteed by the C standard is -32767 to 32767 for a signed short int, and -2147483647 to 2147483647 for a signed int.


Sorry, I don't recall the exact values off the top of my head. Only quoting the 5 million other web sites on data types and there ranges. Forgive me KaVir. :thinking:
07 Dec, 2008, David Haley wrote in the 18th comment:
Votes: 0
I believe that in practice, the numbers that Littlehorn gave are correct in all cases, for all practical intents and purposes. The standard defines the range as having the same number on both ends so that things work on platforms that use a sign bit (instead of e.g. twos-complement representation). But in practice, this is very rarely the case.

It's also worth noting that the difference between -32767 and -32768 would/should very rarely matter in practice, though.
07 Dec, 2008, Littlehorn wrote in the 19th comment:
Votes: 0
DavidHaley said:
I believe that in practice, the numbers that Littlehorn gave are correct in all cases, for all practical intents and purposes. The standard defines the range as having the same number on both ends so that things work on platforms that use a sign bit (instead of e.g. twos-complement representation). But in practice, this is very rarely the case.

It's also worth noting that the difference between -32767 and -32768 would/should very rarely matter in practice, though.


It wasn't worth mentioning, you were right.
07 Dec, 2008, Igabod wrote in the 20th comment:
Votes: 0
Littlehorn said:
DavidHaley said:
I believe that in practice, the numbers that Littlehorn gave are correct in all cases, for all practical intents and purposes. The standard defines the range as having the same number on both ends so that things work on platforms that use a sign bit (instead of e.g. twos-complement representation). But in practice, this is very rarely the case.

It's also worth noting that the difference between -32767 and -32768 would/should very rarely matter in practice, though.


It wasn't worth mentioning, you were right.

You misread what he said apparently, you should re-read that. Also that was needlessly rude. I would suggest you abstain from being rude to people on here that actually know what they're talking about. This isn't a community where you can just go about being rude like that for no reason. That might fly on mudconnect.com but not here. I also notice a little bit of an attitude in your response to Kavir which is extremely stupid because he SHOULD know what he's talking about on this subject, being the originator of the code we're talking about. If you want people to take you seriously here you should definately not do this.

As a side note, why is my computer putting a red line under definately? The red line means it's spelled wrong but I'm pretty sure it's not. How odd…
0.0/46