Not really familiar with this one

ID:140001
 
Jun 20 2010, 2:17 pm
ok so i'm getting kinda confused, i've had this problem before and i fixed it but i don't remember how. Anyway...

the error is:
Code\Turfs.dm:105:error: expected expression


it says its in this area O.o
turf
    Beach_Cave
        Dirt
            icon = 'Dirt.dmi'
            dirt1
                icon_state = "1"
            dirt2
                icon_state = "2"
            dirt3
                icon_state = "3"
            dirt4
                icon_state = "4"
            dirt5
                icon_state = "5"
            normal
                icon_state = "6"
            dirt7
                icon_state = "7"
            dirt8
                icon_state = "8"
            dirt9
                icon_state = "9"



but it started when i added the attributes code which is
#define normal 1
#define fire 2
#define water 3
#define electric 4
#define grass 5
#define ice 6
#define fighting 7
#define poison 8
#define ground 9
#define flying 10
#define psychic 11
#define bug 12
#define rock 13
#define ghost 14
#define dragon 15
#define dark 16
#define steel 17


var/list/atr=list(\
list(1,1,1,1,1,1,2,1,1,1,1,1,1,0,1,1,1),
list(1,0.5,2,1,0.5,0.5,1,1,2,1,1,0.5,2,1,1,1,0.5),
list(1,0.5,0.5,2,2,0.5,1,1,1,1,1,1,1,1,1,1,0.5),
list(1,1,1,0.5,1,1,1,1,2,0.5,1,1,1,1,1,1,0.5),
list(1,2,0.5,0.5,0.5,2,1,2,0.5,2,1,2,1,1,1,1,1),
list(1,2,1,1,1,0.5,2,1,1,1,1,1,2,1,1,1,2),
list(1,1,1,1,1,1,1,1,1,2,2,0.5,0.5,1,1,0.5,1),
list(1,1,1,1,0.5,1,0.5,0.5,2,1,2,0.5,1,1,1,1,1),
list(1,1,2,0,2,2,1,0.5,1,1,1,1,0.5,1,1,1,1),
list(1,1,1,2,0.5,2,0.5,1,0,1,1,0.5,2,1,1,1,1),
list(1,1,1,1,1,1,0.5,1,1,1,0.5,2,1,2,1,2,1),
list(1,2,1,1,0.5,1,0.5,1,0.5,2,1,1,2,1,1,1,1),
list(0.5,0.5,2,1,2,1,2,0.5,2,0.5,1,1,1,1,1,1,2),
list(0,1,1,1,1,1,0,0.5,1,1,1,0.5,1,2,1,2,1),
list(1,0.5,0.5,0.5,0.5,2,1,1,1,1,1,1,1,1,2,1,1),
list(1,1,1,1,1,1,2,1,1,1,0,2,1,0.5,1,0.5,1),
list(0.5,2,1,1,0.5,0.5,2,0,2,0.5,0.5,0.5,0.5,0.5,0.5,0.5,0.5)
)

proc
    change_type(type)
        if(type == "normal") return normal
        if(type == "fire") return fire
        if(type == "water") return water
        if(type == "electric") return electric
        if(type == "grass") return grass
        if(type == "ice") return ice
        if(type == "fighting") return fighting
        if(type == "poison") return  poison
        if(type == "ground") return ground
        if(type == "flying") return flying
        if(type == "psychic") return psychic
        if(type == "bug") return bug
        if(type == "rock") return rock
        if(type == "ghost") return ghost
        if(type == "dragon") return dragon
        if(type == "dark") return dark
        if(type == "steel") return steel
        if(type == "none") return normal


the attribute code alone and when i remove turf code works fine, but when i remove the attributes code the turf code works fine...Can anyone help me fix this?
Jun 20 2010, 3:44 pm
-BUMP-
Jun 20 2010, 4:50 pm
In response to Masschaos100
FIXED
Jun 20 2010, 4:51 pm
The problem is how you defined those type, primary normal. You made normal = 1 so when you typed in /turf/Beach_Cave/Dirt/normal, DM sees it as /turf/Beach_Cave/Dirt/1 <-- and that's your problem

What you should do that most other developers do is make the defined variables in UPPERCASE. It avoids troubles like this... alternatively, rename the turf "normal" to "Normal".

For the future, it would be nice to comment where line 105 was.

Hint: instead of all those if(type==), it would be wise to have a switch()... and what about the second element type for the Pokemon?

Edit: Heh, got your help a minute after >_>'
Jun 20 2010, 4:56 pm
In response to GhostAnime
thanks a lot, and btw for the second element type, the proc i made takes it into consideration :)
Jun 21 2010, 6:33 am (Edited on Jun 21 2010, 7:48 am)
May I suggest using bitflags for the two-type settings?
#define NORMAL 1
#define FIRE 2
#define WATER 4
#define ELECTRIC 8
#define GRASS 16
#define ICE 32
#define FIGHTING 64
#define POISON 128
#define GROUND 256
#define FLYING 512
#define PSYCHIC 1024
#define BUG 2048
#define ROCK 4096
#define GHOST 8192
#define DRAGON 6384
#define DARK 32768
#define STEEL 65536

proc
    get_type(type)
        .=0
        for(var/i=1,i<=STEEL,i*=2)
            if(type&i) .&=i

The return value for get_type could be checked with &TYPE (from the define listing) for what type(s) it may have.
Heck, this doesn't even limit you to just two types! (Anyone up for a Fire/Flying/Dragon Charizard??)

You could do something similar with type effectiveness too, which I imagine is what those huge lists are for. Having a value for all 17 types is nightmarish, so I suggest putting values just for type-matchups that are special (not normal damage).
 //I didn't do all 17 types because that'd be huge...
#define NORMAL_WEAK 64        //bitflag for FIGHTING
#define NORMAL_STRONG 0      //no advantages
#define NORMAL_IMMUNE 8192  //bitflag for GHOST
#define FIRE_WEAK 4356      //bitflags for: WATER+GROUND+ROCK
#define FIRE_STRONG 67632    //GRASS+ICE+BUG+STEEL
#define FIRE_IMMUNE 0        //no immunities

Once you set up all three for each type, then you can do checks like this in the damage modifier checks.
if(type&NORMAL)
    if(NORMAL_IMMUNE&atk_type) return 0
    if(NORMAL_WEAK&atk_type) atk_dmg*=2

I wager you don't even need the TYPE_STRONG in this case, but it never hurts to have more information available to you easily.

I've only just begun to use bitflags myself, so my actual experience is only so-so. But I'm rather confident all the numbers are correctly setup and the & operator is used properly.
Anyone more experienced is welcome to criticize.

EDIT:
Small note, you could include ability changes in the above code snippet (the type&NORMAL one) as well. For example, Thick-Fat reducing Ice & Fire damage. Don't forget things like Foresight and Moldbreaker bypassing immunities!
Same goes for weather effects, although that is independent from the defending pokemon.
Jun 21 2010, 10:29 am
In response to Cthulh
BYOND only handles bit operations up to 16 bits, so that won't work here. And I don't know why you are proposing a different solution for the strength/weakness table when he already has a perfectly serviceable one.