Albro1 wrote:
You can branch all kill-able mobs off of /mob/combatant, in that example. Even the player mob (by setting world.mob. Void Games wrote: Would i have to use the world itself or use it inside combatant? Jittai wrote: world.mob sets the default mob players get much like world.turf sets the default turf type. Not sure what you're asking. | |
IS what i used above what you are talking about by setting the default mob? and also i mean using what i showed in the dm ie the world thing or using it something like (some code .world.mob?
| |
When you have a variable:
mob/var/hp = 100
And you try to refer to it later, how do you access it? mob.hp So, yes. world.mob is that. On the forums we don't like doing world every time we want to say a variable. It's much easier to do world.mob. Now, please elaborate on your confusion, because we have laid out a lot of information every time you've asked a question and you always seem to be confused about something. | |
my confusion was how you worded what you mean, i did not know you meant world mob=/mob/ect with world.mob that's about it, thanks for clearing that up
| |
He wanted to know if just typing world.mob=/mob/combatant is sufficient. Which in this case it would be.
On a related topic, can you input multiple mob children into world.mob by let's say world.mob=/mob/combatant,/mob/enforcement Or is that an invalid action to make? | |
No.
world.mob is the default type of mob the world will create when creating mobs for clients. In the case of wanting a title screen, I create a specific type of mob that handles title screen, character creation, and login functions, then creates a player mob type and connects the client to it. | |
I don't think there's really anything wrong with putting the shopkeeper type under mob/npc but having damage routines be general. That's every bit as valid as putting only combatant mobs under a special type, and in many cases makes more sense. I actually favor defining attack and damage routines under all mobs. Those routines should really all be generic, so that mobs and monsters play by pretty much the same rules. Shopkeepers merely play by a variant of those rules; it makes sense they'd override them.
These are my Big Three when it comes to bad habits: usr abuse: The usr var has no place in procs. Pseudo-verbs like mob/Click() get a pass, provided nothing funky has been done to the click process. Move() does not. goto abuse: The intelligent use of goto is something usually only intermediate to advanced programmers ever need to worry about. Anyone else should avoid it. It's meant for situations that don't apply to 99% of code. : operator abuse: A lot of users misuse the : operator and rely on it too heavily. I use this a lot myself, but the difference is experience. This operator will make the compiler stop complaining about problems it sees with wrong types, but that just pushes those problems off to runtime. Often this shows up in cases where a user has made a mess of their design, like defining things in the wrong scope. Beyond those, the biggest mistake I tend to see is when users make their code handle a million specific situations rather than examining it for ways to make it more general or robust. For instance, projectile creation that does all the work in the calling routine is wrong. When you want to find the turf in a given direction, using a switch with each direction and then calling locate() a bunch of times instead of just using get_step() from the beginning is wrong. | |
if that's what he means i already use it for something else i don't see how it could help with this tho