ID:157068
 
I have a group of players in my game that i want to be "Agents". They have there own way of fighting from the ordinary players but i dont want them to have tabs like fighting or training in statpannels because i dont want them to have access to the regular players abilities.Is there a way to do this?
Easiest way is just to give them different mobs.
In response to Garthor
Yeah, if the 'agents' are fixed, just create special mobs for them and set the key var of those mobs to their keys. Make their mobs a child of the main player mob and just override their fighting system.
In response to Warlord Fred
Make the verb, but when the players log in, and they are not the agent, remove the verb from them.

mob
Login()
if(usr.key=="Ishuri")
return
else
src.verbs -= /mob/verb/agent_verb_1


or, to make life easier, add the agent verbs in a parent.
src.verbs -= typesof(/mob/agent/verb)
In response to Garthor
Garthor wrote:
Easiest way is just to give them different mobs.

What makes you think, so it is the easiest way?o.O

This 'can' increase the time taken by the already slow del instruction to take a longer time.(I think, bcz Lummox JR said the more larger you game is the more time it takes, bcz del causes some scanning.)(and it could only increase by 0.00001% but who cares it increases!).But whatever thats not the main point.

giving different mobs could and may cause errors in other areas.So its really easy to just provide a global list.

mob/Login()
if(src.key in My_Agents)
src.verbs+=typesof(mob/agents/verb) // giving them only the verbs of the agents


Add or Remove a key : whenever you want.

@Garthor: is that more easy or what you said is.I couldn't find your way more efficient nor easy.But I m sure you must have a good explanation.
In response to Soul Sign
Soul Sign wrote:
Garthor wrote:
Easiest way is just to give them different mobs.
What makes you think, so it is the easiest way?o.O

It's rather simple. Make agent clients have a /mob/agent path as their mob and they would have access to the variables, verbs, etc. defined under it. No adding verbs needed.

giving different mobs could and may cause errors in other areas.So its really easy to just provide a global list.

Any examples? The only reason I can think of is bad programming practices that can cause this. And what global list are you talking about?


@Garthor: is that more easy or what you said is.I couldn't find your way more efficient nor easy.But I m sure you must have a good explanation.

mob
agent
verb/OMG_GUN() // all /mob/agent will have this verb
rebel
verb/Loud_Noise() // all /mob/rebel will have this verb
verb/Say() // All /mob children, including agent & rebel, will have this verb
No checking lists, no adding/removing verbs...
In response to GhostAnime
GhostAnime wrote:
mob
> agent
> verb/OMG_GUN() // all /mob/agent will have this verb
> rebel
> verb/Loud_Noise() // all /mob/rebel will have this verb
> verb/Say() // All /mob children, including agent & rebel, will have this verb
No checking lists, no adding/removing verbs...

In that case also a checking list comes up.You ask me How?
I say" He said only specific people receive the agent power and he has to mention the keys which will get those. So "=P"!

In your case we will have to decide who gets to be /mob and who gets to be /mob/agent/. And there is a checking list there.(Hope you understand -.-)!

And yes your right no adding/removing verbs.But creating an Agent type mob is not as easy as you say.You would have understood if you had experience with Big_Projects.Some times depending upon who the programmer programmed - the Agent mob could be filtered out of some major proc.

You see we never know who is dumb, it could be me or you or anyone around us!!.(so always take precaution)
mob // Player
mob/Agent //Player and Agent
mob/NPC //
mob/Internal_ProcMob //
proc/Some_DumbFilter(mob/M) // a proc for filtering other type of mobs and you want explicitly Players
if(M.type!=/mob) return 0 // this will return 1 for agents also
return 1
//I already called that a dumb proc! it can be filtered via .client or .key


You see if such a proc even exists then the Programmer will say Oops! How the heck? And he will ponder for days why some of his procs are not working well for agents!

So why take the risk when you can do it the easy and better way?
In response to Soul Sign
Because your way is worse, and anybody with any degree of experience (and I mean experience, not reading code written by monkeys) would agree.

Using horrible coding practices as an excuse for using MORE horrible coding practices makes me just really depressed.
In response to Garthor
Garthor I need an explanation why it is worse.if you don't have then you have no point!
In response to Soul Sign
Because your approach is attempting to take two distinct objects ("regular player" and "agent") and mash them into a single type. This is poor object-oriented design.

You CAN make a game without ever creating a single new type. Every mob can be a /mob, every obj can be an /obj (in fact, you could just make every obj a /mob instead), and every turf a /turf. This would, however, be monumentally stupid.

I don't feel like writing out an entire explanation on what object-oriented design means (because you obviously don't know). I guess I can just search Google and give you the first three results and then start being sarcastic when you refuse to read them.

http://en.wikipedia.org/wiki/Object-oriented_design
http://www.oodesign.com/
http://www.glenmccl.com/ood_cmp.htm
In response to Garthor
Garthor wrote:
Because your approach is attempting to take two distinct objects ("regular player" and "agent") and mash them into a single type. This is poor object-oriented design.

Right! My approach isn't OOP but its more effective since you just hand over the verbs to an Agent and rest of the mob is same as other mobs. Do you know what this means ????
Think........
UNIFORMITY! and do you know what UNIFORMITY means ?
Think.........
STABILITY!

You CAN make a game without ever creating a single new type. Every mob can be a /mob, every obj can be an /obj (in fact, you could just make every obj a /mob instead), and every turf a /turf. This would, however, be monumentally stupid.
I can't oppose this dumb statement, because you are going to the way extreme end, and answering such questions would only make me look like dumb.

I don't feel like writing out an entire explanation on what object-oriented design means (because you obviously don't know). I guess I can just search Google and give you the first three results and then start being sarcastic when you refuse to read them.

Do you know what instantiating is? If you ever even worked with OOPs then you should feel how important Instantiating is.Which you don't seem to be knowing.And I don't feel like even giving a link about what you do at least one time for each and every class you create in OOP.

Look at what you mean to do. Your creating a whole another class for just giving few dumb verbs!!??

EDIT:
Ohh damn.. I didn't read that part "They have there own way of fighting from the ordinary players but i dont want them to have tabs like fighting or training in statpannels because i dont want them to have access to the regular players abilities". -.-

But otherwise you don't need to create a whole new type of mob.Since this can cause the game to grow causing del to slow!(by 0.000000001%) =P

@Garthor: My apology! ;) I didn't see that part! My fate: I was born as a human :(

EDIT2:
How do you demonstrate this ?
client/New()
// what in here to so so that the mob.type would be an agent?
In response to Soul Sign
Soul Sign wrote:
Garthor wrote:
Because your approach is attempting to take two distinct objects ("regular player" and "agent") and mash them into a single type. This is poor object-oriented design.

Right! My approach isn't OOP but its more effective since you just hand over the verbs to an Agent and rest of the mob is same as other mobs. Do you know what this means ????
Think........
UNIFORMITY! and do you know what UNIFORMITY means ?
Think.........
STABILITY!

Oh yes, stability. Up until the point where you need to determine at runtime whether somebody's an Agent. Whoops, you changed the list mid-game, now the game THINKS they are but they aren't until they next login! Okay, we'll save it in a variable... WHOOPS now they're an Agent after we've removed them from the list!

And, again, proper design would maintain "uniformity". Posting an example of incredibly mind-bogglingly stupid design is not a point in favor of your own same design.


You CAN make a game without ever creating a single new type. Every mob can be a /mob, every obj can be an /obj (in fact, you could just make every obj a /mob instead), and every turf a /turf. This would, however, be monumentally stupid.
I can't oppose this dumb statement, because you are going to the way extreme end, and answering such questions would only make me look like dumb.

Reducto ad absurdum is a perfectly valid debate tactic. In this case, I'm drawing your attention to the fact that you would, in pretty much every other case, agree with me, and that you are simply choosing to do something in a different (and worse) way for no particular reason here.


I don't feel like writing out an entire explanation on what object-oriented design means (because you obviously don't know). I guess I can just search Google and give you the first three results and then start being sarcastic when you refuse to read them.

Do you know what instantiating is? If you ever even worked with OOPs then you should feel how important Instantiating is.Which you don't seem to be knowing.And I don't feel like even giving a link about what you do at least one time for each and every class you create in OOP.

Instantiation is the allocation of a block of memory representing some object, according to a template. In BYOND, it is achieved either through the new keyword or the rarely-used newlist() procedure. It is not something you do at least one time for each and every class you create "in OOP". In fact, your own example is one where a class exists without instantiation. Another, more common example is the concept of abstract classes, which cannot be instantiated, though BYOND has no provision for this.

Look at what you mean to do. Your creating a whole another class for just giving few dumb verbs!!??

You did precisely the same thing:

   src.verbs+=typesof(mob/agents/verb) // giving them only the verbs of the agents


mob/agents, here, is another type. Which you have created. Literally just for holding a few dumb verbs.

EDIT:
Ohh damn.. I didn't read that part "They have there own way of fighting from the ordinary players but i dont want them to have tabs like fighting or training in statpannels because i dont want them to have access to the regular players abilities". -.-

Yes, sometimes you want to add functionality, and it makes things a million times easier if you used a proper, object-oriented design to begin with.

But otherwise you don't need to create a whole new type of mob.Since this can cause the game to grow causing del to slow!(by 0.000000001%) =P

@Garthor: My apology! ;) I didn't see that part! My fate: I was born as a human :(

As I've already said, this is something you've already done. Furthermore, I highly doubt that doing so would have any effect on the speed of del, and this is simply a result of you grossly misinterpreting what Lummox JR has said.
In response to Soul Sign
Please be quiet. You don't have a god damned clue what you're talking about. Go research object-oriented programming, and be quiet like a good little boy while the grownups talk.

Also, even though this is still ridiculously-much a work-in-progress, you might be able to learn something from it.
As suggested previously (under the slight argument) there are seemingly two differing ways of handling this problem but I believe the only way out of the two to achieve what you want is by making a new type for the chosen players.

To minimise errors it should inherit from the regular player type and have its procedures overridden.
E.g.
mob/player
// Variables and Procedures
mob/player/agent
// Overridden Procedures


The select players who are agents can be assigned the agent mob in a variety of ways. The way I would choose is by checking their key in client/New() and then assigning them an appropriate mob.
In response to Garthor
Garthor wrote:
@Garthor: My apology! ;) I didn't see that part! My fate: I was born as a human :(

As I've already said, this is something you've already done. Furthermore, I highly doubt that doing so would have any effect on the speed of del, and this is simply a result of you grossly misinterpreting what Lummox JR has said.

No, because I read wrong/didn't read. And moreover I did mention (0.00000001%).

Of course you guys all are my Seniors!

@Popiz
Your a 100% right.But I ve found this the best way to learn."Argue"!!lol
In response to Soul Sign
You do know DM is an OO language, and so tends to make your life easier if you use it as such. There is a reason business took a shift to OO language way back in ... 2000 and has been using them ever since. Maintainability, separation of concerns, good code re-use, shorter time to market (game release in this case). I'm not sure what position you're debating this design from, but you're in discussion with computer science majors and one of the programmers of BYOND there, on the issue of BYOND and it's OO language, DM.

My experience with safety critical software also suggests the design you proposed is ... less than ideal, and doesn't scale well.
In response to Stephen001
Stephen001 wrote:
You do know DM is an OO language, and so tends to make your life easier if you use it as such.

Yes.. I do.


There is a reason business took a shift to OO language way back in ... 2000 and has been using them ever since. Maintainability, separation of concerns, good code re-use, shorter time to market (game release in this case). I'm not sure what position you're debating this design from, but you're in discussion with computer science majors and one of the programmers of BYOND there, on the issue of BYOND and it's OO language, DM.

My experience with safety critical software also suggests the design you proposed is ... less than ideal, and doesn't scale well.


Exactly speaking, I didn't read the aim well.So my mind was only composed of some dumb verbs.And also bcz I ve been reading mainly BYOND reference.(It advised me to just put a variable called special_features and bool check them for adding features(here)).Later only I carefully read.. and understood that there was more than just verbs in the aim.

Yeah, I know the People whom I am talking to - have tons of knowledge, which is the reason why I am talking to them.
My brain's nerves got tangled up with each other.. oopsy..
In response to Soul Sign
I think even if it was just verbs, it'd be worth their while to make a sub-type as was recommended. The main reason is games are not just static things, they grow and change over time as you add / remove features. Special player benefits being the kind of thing that is likely to change, so a sub-type lets you easily add remove verbs/procs/variables later on when development.
In response to Stephen001
Accepted!
In response to Soul Sign
@ Stephen001

Alot of people just go about and remake a game from scratch when they find a new way to do certain things that makes the coding easier. I don't know whether that's a good or bad idea.