Three questions...

Page: 1 2
Jul 1 2009, 4:23 pm
In response to Spunky_Girl
You're still accessing the list without knowing if it's out of bounds. Add a simple check just to make sure.
mob/player
    var/tmp/list/skill_slots
    verb/Skill_Bar(n as num)
        set hidden = 1
        if(n<1||length(usr.skill_slots)<n)
            world<<"D:<"
            return
        var/obj/jutsu/j=src.skill_slots[n]
        if(j)j:activate(usr)
Jul 1 2009, 4:26 pm
In response to Spunky_Girl
 
obj/proc/activate(mob/player/p)
 ..()

/obj/skill/magic
   activate(mob/player/p)
        p<<"You have used magic!"

/obj/skill/ranged
    activate(mob/player/p)
        p<<"You have used ranged!"

/obj/skill/melee
    activate(mob/player/p)
        p<<"You have used melee!"
Jul 1 2009, 4:26 pm
In response to Ruben7
Why would the len ever be zero? When it's initialized, it's given a len of 8. And then the buttons that activate my Skill_Bar verb are pretty much labeled 1 through 8. No zeroes.
Jul 1 2009, 4:28 pm
In response to Spunky_Girl
It's not checking the length, it's checking if the bastards put a value under 1 into the input box.
Jul 1 2009, 4:30 pm
In response to Ruben7
What bastard? The player? The player does not control what goes into that input box. The buttons have an argument they pass into the verb.
Jul 1 2009, 4:30 pm
In response to Spunky_Girl
Oh, my bad then. Didn't notice it.
Jul 1 2009, 4:34 pm
In response to Ruben7
Doesn't ..() call the parent? Not the child? >_>
Jul 1 2009, 4:36 pm
In response to Spunky_Girl
<.< I just know that it works.
Jul 1 2009, 4:38 pm
In response to Ruben7
I don't see how it does to be honest...
Jul 1 2009, 4:49 pm
In response to Spunky_Girl
It's just defining the proc.. Each child can then call their own. "..()" Doesn't even have to be there. >.>
if(j) j:activate(src) // Jeff bitched
if(j) j.activate(src) // thar no more bitching

It should work without the semicolon as it is though, did you try just using a period?
Jul 1 2009, 4:51 pm
In response to Ruben7
Okay, yeah. Please do not return here again. :\
Jul 1 2009, 4:53 pm
In response to Spunky_Girl
Fine >.>
Jul 1 2009, 6:40 pm
In response to Spunky_Girl
That does not stop them from calling the verb. Nor does making it hidden.
Jul 2 2009, 6:49 am
In response to Spunky_Girl
Then you really need to work on your programming, then; inheritance is very important in programming in DM.
Jul 2 2009, 8:24 am
In response to Spunky_Girl
Correct, his usage of ..() there is absolutely pointless and will always do nothing, since there is never any parent to run in the declaration of a new proc. That call is just needed there - and the overriding of the proc is unrelated and works regardless.
As Jeff partly noted, inheritance and procedure overriding is very important in DM, it being an Object-Oriented programming language. You also do this all the time, but you haven't noticed. For example, when you do this: 
mob/Move()
  something

...you've overridden the Move() proc. You didn't declare it right there (and trying to do so would pop an error), it was already declared (built-in) and you've simply overridden it for a specific type, /mob.
It's important to use OOP correctly when making dynamic things like this (a skill system): it saves a lot of time, [insert various adjectives describing how great it is here, I'm too lazy at the moment]. You can find random examples of it in action here: [link], [link]. Another good example is my projectile demo, although the current version on the hub is outdated and not "perfect" enough (beware the comments flood!). Maybe I'll add more links later - ugh, it's kinda difficult to search for it specifically without going post-by-post, but code using good OOP is posted by me and others on the forums practically all the time. Here's a basic example of a good object-based skill system: 
mob/person
   var/list/skills
   verb/Use_Skill(obj/skill/S in src.skills) //the player selects (ANY) obj in the skills list
   if(S in src.skills) //validate the condition, this also makes this verb usable by NPCs
      if(src.PP < src.cost)
         src << "You don't have enough PP!"
         return 0
      //if there is enough PP...
      S.Activate(src)

obj/skill
   ...
   var
      cost = 1 //say in PP, or whatever
      //whatever other properties are common to all skills
   proc/Activate(mob/person/M)
      //do things common to all skills here
      M.PP -= src.cost
      viewers(M) << "[M] uses his '[src]' skill!"
   fire_shoot_skill
      cost = 10
      Activate(mob/person/P) //override the proc to do stuff specific to this skill
         ..() //do the common stuff (calls the parent above)
         P.Shoot(/obj/projectile/fire)
   teleport_skill
      cost = 15
      Activate(mob/person/User)
         ..()
         var/T = some turf...
         src.Move(T)
Jul 2 2009, 9:19 am
In response to Kaioken
But all the skills (with maybe a couple acceptions) have totally different programming to them. Some may have "shouts", some may do damage, others may be buffs to the user, etc. And I like to keep them separated in the object tree for organization purposes (so when I expand the tree, I don't have like a hundred entries to sift through).
Jul 2 2009, 10:29 am
In response to Spunky_Girl
Spunky_Girl wrote:
But all the skills (with maybe a couple acceptions) have totally different programming to them.

That's no issue. Everything that's different is just handled by overriding the activation proc and adding to it. You can do virtually anything, since you may put whatever you want in your override.

Some may have "shouts", some may do damage, others may be buffs to the user, etc.

And all of those types can even also be generalized. Look at the code in the effects system example I've linked to in my previous post. It has a bunch of different effect types implemented.

And I like to keep them separated in the object tree for organization purposes (so when I expand the tree, I don't have like a hundred entries to sift through).

It's more organized to have the same types of things grouped together, no? =P Anyway, that's only a very minor preference issue - using parent_type may help with that, I'm not sure at the moment. It can surely help to make your type paths shorter if you want, though.
Page: 1 2