ID:784151
 
Before I make a feature suggestion of this I like to discuss it here.

While I was recoding a game(rather not name it) I had to use basically the same code for lots of skills except change a couple of vars to make different damage. I realise that I could make 1 proc and have it handle all the skills but it kind of seems complicated for a language that supposed to be easy to use. I think that there should be a feature where I could have multiple objects be assigned to a same script or proc but so that this way I could assign objects from an inspector or something like that and based on each object I could change the variable values of it.

It could be as simple as declaring an object in a group called animals and naming the object dog. Then I could go to the inspector and assign the variables there instead of going and writting myvar = 2 or something all the time I create an object of the same group. Also maybe assigning variables could be done better from the inspector like attaching sound files to variables and playing them easier rather than defining them within script and then playing them.

Kind of seems redundant since variables can be assigned easy but still be a nice feature to have.

Anyways feel free to discuss and give your opinion.

(BTW I probably wandered off topic in the last big paragraph to dont tell me it has nothing to do with the topic)
Do you mean something like this?

skill
var
damage = 10

proc
doDamage(mob/enemy)
enemy.health -= damage

hurricaneKickOfDeathAndDisease
damage = 100000000006

everlastingPunchOfForeverPains
damage = 3

notVeryImpressiveJabOfHurtingALittleBit
damage = 55
Ye sort of. You have to write damage = something in everyone of those and thats only 1 variable you gotta change. Some people might have 10,20 etc for the damage which might need to be changed. The inspector type of thing is useful in Unity so it could be useful in Byond(well not as much since Unity can define a objects property to the component and byond has no such properties).
I don't think it's very hard to just look at the variables you've defined and set them. It really doesn't take much to type things out.

What I think an inspector is (I didn't look it up much) is something like the New Instance feature in the map editor, except it writes out the code for a completely new object. This is actually a kind of thing you can create; a DM program that writes DM code for you. It's even been done before, if I recall correctly. They we're called Auto Coders and allowed you to specify what kind of object you wanted and let you modify properties using an interface. You could then save the generated code and include it in your project.
In response to Dj dovis
Dj dovis wrote:
Ye sort of. You have to write damage = something in everyone of those and thats only 1 variable you gotta change. Some people might have 10,20 etc for the damage which might need to be changed.

I'm not really sure how you expect to make this easier than it already is. If you're at the point where it's easier (or makes sense) for you to just automate the defining of these values, maybe you need to reconsider how you're handling the data. If you don't feel it's worth your time manually setting new fields for different subtypes, obviously it's not THAT important to set them, so write it so you don't have to.

// const.dm, or something
var
const
WEAPON_DAMAGE_PER_LEVEL = 12 // or something
VENDER_VALUE_PER_LEVEL = 100 // or something

// item.dm
item
var
level = 1

weapon
//var
//damage = 12
//vendorValue = 100

proc
getDamage()
return WEAPON_DAMAGE_PER_LEVEL * level

getVendorValue()
return VENDOR_VALUE_PER_LEVEL * level

swordOfALittleDoom
level = 1.5
//damage = 18
//vendorValue = 150

swordOfUltimateDoooooom
level = 2
//damage = 24
//vendorValue = 200

swordOfUltimaterDoooooooooooom
level = 22
//damage = 264
//vendorValue = 2200
As Keeth has indicated, you can already accomplish this using a mixture of inheritance and sensible design. If you're going to need to set a bunch of 20 or 30 variables, reconsider how you're doing the thing you are doing.

There's no need for a 'feature' to write code for you to compensate for bad design; you still have to read that code and manually edit it later if something goes wrong anyway.