05 Sep, 2009, Riayi wrote in the 1st comment:
Votes: 0
I've installed a FirstMud server, and have modified it a bit and corrected a few bugs. I noticed elves are supposedly vulnerable to iron, yet in fight.c there is no check for the material the weapon is made of. In the old Rom mailing list there is an incomplete discussion that doesn't really help me a lot. Both handler.c and fight.c contain code relevant to damage type imms and vulns… what I have tried to do is add this to handler.c:
immune_t check_material(CharData * ch, ObjData * obj, weap_material)
{
immune_t immune, def;
flag_t bit;

immune = IMMUNE_NONE;
def = IS_NORMAL;

obj = get_eq_char(ch, WEAR_WIELD);
weap_material = obj->material;
if (obj != NULL)
{
switch (weap_material)
{
case iron:
case silver:
case gold:
if (IsSet(ch->imm_flags, IMM_IRON))
def = IS_IMMUNE;
else if (IsSet(ch->res_flags, RES_IRON))
def = IS_RESISTANT;
else if (IsSet(ch->vuln_flags, VULN_IRON))
def = IS_VULNERABLE;
else if (IsSet(ch->dire_vuln_flags, DIRE_VULN_IRON))
def = IS_DIRE_VULNERABLE;
if (IsSet(ch->imm_flags, IMM_SILVER))
def = IS_IMMUNE;
else if (IsSet(ch->res_flags, RES_SILVER))
def = IS_RESISTANT;
else if (IsSet(ch->vuln_flags, VULN_SILVER))
def = IS_VULNERABLE;
else if (IsSet(ch->dire_vuln_flags, DIRE_VULN_SILVER))
def = IS_DIRE_VULNERABLE;
if (IsSet(ch->imm_flags, IMM_GOLD))
def = IS_IMMUNE;
else if (IsSet(ch->res_flags, RES_GOLD))
def = IS_RESISTANT;
else if (IsSet(ch->vuln_flags, VULN_GOLD))
def = IS_VULNERABLE;
else if (IsSet(ch->dire_vuln_flags, DIRE_VULN_GOLD))
def = IS_DIRE_VULNERABLE;
break;
default:
def = IS_NORMAL;
break;
}
}

switch (weap_material)
{
case (silver):
bit = IMM_SILVER;
break;
case (iron):
bit = IMM_IRON;
break;
case (gold):
bit = IMM_GOLD;
break;
default:
return def;
}

if (IsSet(ch->imm_flags, bit))
immune = IS_IMMUNE;
else if (IsSet(ch->res_flags, bit) && immune != IS_IMMUNE)
immune = IS_RESISTANT;
if (IsSet(ch->dire_vuln_flags, bit))
immune = IS_DIRE_VULNERABLE;
else if (IsSet(ch->vuln_flags, bit) && immune != IS_DIRE_VULNERABLE)
{
if (immune == IS_IMMUNE)
immune = IS_RESISTANT;
else if (immune == IS_RESISTANT)
immune = IS_NORMAL;
else if (immune == IS_VULNERABLE)
immune = IS_VULNERABLE;
}

if (immune == IMMUNE_NONE)
return def;
else
return immune;
}

In defines.h I defined weapon materials like so:
typedef enum
{
iron,
silver,
gold
}
weap_material;

And in fight.c the code to check the material is this:
switch (check_material(victim, weap_material))
{
case (IS_IMMUNE):
immune = true;
dam = 0;
break;
case (IS_RESISTANT):
dam -= dam / 3;
break;
case (IS_VULNERABLE):
dam += dam / 2;
break;
case (IS_DIRE_VULNERABLE):
dam += dam;
break;
default:
break;
}

I'm not sure exactly where the problem is, but the compiler says
Quote
fight.c:1183: error: cannot convert `CharData*' to `ObjData*' for argument `1' to `immune_t check_material(ObjData*)'
Any ideas on how to solve this? Or a better way to do it? I'm thankful for any help, as I only just recently started coding, and what little I have learned I have learned from the code itself only. Thanks.
05 Sep, 2009, David Haley wrote in the 2nd comment:
Votes: 0
There are a few issues here:

1- You have declared weap_material as a type (namely, an enumeration with three elements), but you are using it as a variable.
2- Your compiler error probably comes from having a declaration of check_material that takes a sole argument of type ObjData*, but you are using it with two arguments.
3- You are using check_material with two arguments, but you defined it as having three.
05 Sep, 2009, Sandi wrote in the 3rd comment:
Votes: 0
Also, it looks like you're sending obj and weap_material to 'check_material', then setting them to values you look up. The way you've written is, all 'check_material' needs is ch.


BTW, the reason this was never imp'd in ROM was, too many of the materials were set to 'oldstyle'. :smirk:
06 Sep, 2009, Ssolvarain wrote in the 4th comment:
Votes: 0
Sandi said:
BTW, the reason this was never imp'd in ROM was, too many of the materials were set to 'oldstyle'. :smirk:


Slave labor is a nono.
07 Sep, 2009, Riayi wrote in the 5th comment:
Votes: 0
And it'd have been so easy to replace all on the areas with iron, or something. So, this is all very interesting, and I thank you all or your kind help. Maybe I should have said that I'm not a programmer, and I'm doing all modifications to the source code based on common sense and previously used functions. All modifications (shorter hp/mana/move regain checks, new spells, new passive and offensive skills, new immortal commands, dire vulnerabilities, whatever) have worked so far, but… I'm at my current skills end. While I plan to eventually learn C++ in a formal, way, I have a few questions:

To David:
I declared weap_material as a type since dam_class is also a type in defines.h. Apparently, from checking where dam_class is used in fight.c, I could use weap_material to create a variable, like in
dam_class dam_type;
, right? dam_type is used after it's declared as a dam_class, so perhaps I could use weap_material as a type, then declare in bool damage weap_material weap_material_type, or something, right?
Let me backup and I'll check that…
07 Sep, 2009, Riayi wrote in the 6th comment:
Votes: 0
Ok, so now the error is
Quote
cannot convert `const char*' to `ObjData*' in assignment
cannot convert `ObjData*' to `weap_material' in assignment

this on the second and third lines of
obj = get_eq_char(ch, WEAR_WIELD);
obj = obj->material;
weap_material_type = obj->material;

I expect get_eq_char will get me the weapon wielded and store it in obj, and obj->material will assign the material of the weapon to obj. It's not working because the variable types are different, obviously, but, and this is a big but, is whether this checks are really getting me useful information. If I used the raw value of obj->material, would it be something like iron, silver, steel, etc? Or would it be something else? For that matter, can get_eq_char even be used to get the material? Or do I need to use something other than get_eq? It would seem (wishful thinking) that the solution _is_ closer, but damn, I really don't know for sure. Thanks for any insights.
07 Sep, 2009, David Haley wrote in the 7th comment:
Votes: 0
Please don't take this the wrong way, but it might be useful to follow some basic C tutorials. It seems that you are a little unsure of what types mean and how to use them or look them up. It's not clear to me what you are trying to do in the three lines you posted. If obj->material is a string (char*) you need to process it somehow to convert it to your enum. Perhaps material should be of the enum type, and not be a char* in the first place.

But yes, you cannot assign things of different types on top of other types like that.
07 Sep, 2009, Sandi wrote in the 8th comment:
Votes: 0
First, allow me to second David's suggestion that you study C properly. I didn't. With 30 years of programming experience, my 'common sense' let me adapt various bits of ROM to my nefarious purposes quite easily. But now, my understanding of C is flawed and it often trips me up. I spend way too much time debugging things a person with a structured understanding of C would never even do. So please, start at the beginning and learn to do things right.

obj = get_eq_char(ch, WEAR_WIELD);

This works because 'obj' has been defined earlier as a type of OBJ_DATA, and thus has all the variables assigned to it that an object has.

obj = obj->material;

Firstly, you don't want to do this as you just assigned 'obj' in the previous line. Secondly, you can't do it because 'obj' needs to be OBJ_DATA, and obj-material is simply a string value.

weap_material_type = obj->material;

And this….. Why bother? Having made 'obj' the weapon your ch is wielding, 'obj->material' is the value you want to work with and unless you are going to use it a LOT, it's clearer when reading the code to keep referring to it as 'obj->material'. However…

I suspect the underlying problem you're having is a switch() will only work on integers, not on strings. Confining 'material' to predefined integers is problematic, however, and the decision was made long ago to allow Builders creative freedom in deciding what an object's material should be. What you should be playing with are the object flags such as NON_METAL.

Keep in mind switch() is only included for your readability - the compiler turns it into if/else statements, and if any involved preconditioning is required to use a switch(), it most likely will then be clearer to use appropriate if/ifelse/else's.


So, I suggest before leaving obj-material alone, you actually try to replace the existing object material descriptions with whatever you please. Then, once you've come to grips with how numerous, and how varied, the area files are, give some thought to using flags instead. (or decide it's not really worth it, as we did on the ROM list, so long ago)

(BTW, gold can't hold an edge worth a damn!)


Whatever, have fun coding!
Sandi


PS: I believe Hades Kane actually did implement materials in his ROM deriv, perhaps if you decide to go through with this could approach him for some tips.
07 Sep, 2009, Riayi wrote in the 9th comment:
Votes: 0
Thank you for your help. I realize studying C is the way to go, but… I don't have the time or money to do it at present, so that'll have to wait. No, I have no clear understanding of anything in code, yet, it follows a logic order and that'll have to do. This is a hobby for me, and a learning exercise in programming as well. When I finish internal medicine I might consider getting some formal training. On to the next. I will not be using any prebuilt areas, so I'm ok with manually adding materials to all the weapons in my mud, as it's an integral part of the religion and of some of the races here. Also, I know both gold and silver are poor materials for weapons, but hey! It's fantasy, so ensorcelled gold is not a big stretch of the imagination. I am not planning to put this on hold until I really study C… where's the fun in waiting? I enjoy debugging stuff (even if the bugs'd have been easily avoided by a real coder), asking around, and looking at the decompiler valiantly struggle with my files. I guess I'll look up Hades Kane, and check if he has some pointers. Thanks!
07 Sep, 2009, David Haley wrote in the 10th comment:
Votes: 0
You don't need to get formal training at a university or something like that; there are a lot of free introductory C tutorials out there that would take less time to go through than you probably have spent on this already. Googling for "C tutorial" would be a good place to start. I know what it feels like to want to just get started, but from personal experience – with my own learning, and from watching other people learn – you will spend far less time if you invest just a little bit in reading tutorials. You will have fewer questions, and when you do, you will be better equipped to not only ask concise, to-the-point questions, but also to understand and act upon the answers.

In this instance, you need to understand what enumerations are; how to store one; how to convert a builder-entered string to an enumeration; which means understanding how strings work in C; how comparisons with strings work; and so forth. It's not all incredibly difficult, and you are correct that in some sense it's all just logic in the end of the day, but there's a lot of stuff going on at the same time.
08 Sep, 2009, Davion wrote in the 11th comment:
Votes: 0
Quote
With 30 years of programming experience, my 'common sense' let me adapt various bits of ROM to my nefarious purposes quite easily.


:surprised:
08 Sep, 2009, Sandi wrote in the 12th comment:
Votes: 0
Before there was C, there was COBOL. :redface:
08 Sep, 2009, Malek Kervanes wrote in the 13th comment:
Votes: 0
So say we all

(crew yells) SO SAY WE ALL!

*ducks and covers*
10 Sep, 2009, Riayi wrote in the 14th comment:
Votes: 0
Well, turns out it _was_ easier to eliminate materials from objects and go with flags… I'd guess to the player it'll look about the same, anyhow. It seems that is what Hades Kane did in his mud. Who'd have guessed? So it's working now and even if it's relatively untidy code, it compiles and is working!
10 Sep, 2009, Riayi wrote in the 15th comment:
Votes: 0
Also, thanks for all the advice… I guess I AM a little pigheaded, and wanted to do that without reading C++…. talk about stubborn. So that's it, and I got a great tutorial from cplusplus.com, which I plan to start reading soon. Sandi, you where right… even if there were only a few area files, it was a pain to remove materials from them all. Be seeing you!
10 Sep, 2009, David Haley wrote in the 16th comment:
Votes: 0
Riayi said:
Well, turns out it _was_ easier to eliminate materials from objects and go with flags… I'd guess to the player it'll look about the same, anyhow.

This is one of the most important lessons to learn when writing game code: the point is to deliver a product to players. You can have the fanciest algorithm in the world, or something completely simple, but if both give the same impression, players won't notice the difference. If you're designing something for yourself, then by all means do what's fun for you; if you're designing a game for players, always keep in mind that the end result is what matters, not the code you use to implement it. (Writing clean code is still important, of course.)
10 Sep, 2009, Hades_Kane wrote in the 17th comment:
Votes: 0
Riayi said:
even if there were only a few area files, it was a pain to remove materials from them all.


Did you do it manually?

One way to update areas when you make code changes is to do it in steps… for example…

I decide to take out materials, so I modify my code to still load them, but not to save them. I reboot/copyover at this point. I go back into the code and now change it so that the material value won't read on load. Compile, but I don't reboot yet. Then I asave world and all of my area files have been modified to where the material value is not saved. Then, I copyover/reboot in the changes and when the game loads, the materials value is gone.

I'm not sure what method you took, but once you do this a few times and can do it pretty easily, it becomes pretty easy to be able to add or subtract things from your area files this way and can be a great time saver.

Lord knows in my early days I did plenty of going through every area file to manually update things…

Also, glad to see I could be of some help :)
0.0/17