The blue book & expected lists

ID:144251
 
Feb 10 2007, 1:22 pm
Code:
//chapter 1

mob
    Login()
        world<<"Hello world!"
    verb
        smile()
            world<<"[usr] smiles"
            
//chapter 2

turf {
    lava {
        icon='lava.dmi'
    }
    
} /*A simply demonstration of another type of indentation: turf/trap
                                                               tar; hole; lava*/


//chapter 3
#define favorite_car "honda"
mob
    verb
        ownit() //overriding this, i find it messy if i go: verb/owner_of_the_games_favorite_car()
            name="What is the owners favorite car today?"
            usr<<favorite_car
            

obj
    car
        name = "\improper honda" //an  object; not a person
        gender="neuter" //This is default; not really nescissary to put this
        desc="A popular car"
        suffix = "low gas efficiency"
        text = "C" //If your seeing the map as letters, the car will be represented as C
        icon = 'car.dmi'
        icon_state="honda"
        dir = NORTH //Default is south
        overlays='bumpersticker.dmi' //Somone stuck a bumper sticker to the honda!! ***Problem (expected list??)
        underlays='engine.dmi' //If the car blows up, can you guess what will be left? ***^^^^***
        invisibility=0 //Default not an invisa car
        luminosity = 2 //Somone forgot their car light on!!
        opacity=1 //Unfortunatly, you arn't superman; you can't see through the car
        density=1 //self explanitory
        contents=/obj/Cigerettelighter //Ok - heres something i dont understand.. I understand that contents is\
        a list, but why can't I have a cigerette lighter in the list?
        verb
            start_car()
                set src in view(1)
                world<<"[src] starts the car!"
                world<<"<small><b>\red vroom!!!</b></small>"
        //There is no reason to set a type; the care is obviously a obj
        //I will not be including location either because i'm adding them to the map myself.
        
        
    Cigerettelighter
    
//Ok; these were the first 3 chapters


Problem description:

Ok, i'm going through the blue book for the 5th time now, (probably with just as low understanding as the 3rd time I went through it (which was pretty low)) and this time I figured I would read each chapter again and do some things with each of them, hoping to become more intermediate rather than newbie. I have run into two unfortunate errors and am not excactly sure how to revise them. I have the problems commented and would appreciate help. Also, if there is any fix-ups either than that that you could mention, that would be great! Thanks

Feb 10 2007, 1:35 pm
Um... what are the two unfortunate errors in question? You have to give us some information before we can help you.

Lummox JR
Feb 10 2007, 2:20 pm (Edited on Feb 10 2007, 6:53 pm)
The problems were commented; they are the overlays and underlays and the contents. It's after the commented chapter 3
Feb 10 2007, 10:36 pm
In response to Beatmewithastick
Beatmewithastick wrote:
The problems were commented; they are the overlays and underlays and the contents. It's after the commented chapter 3

Everything is commented in your code. To get real help you need to be specific on what's going wrong.

Lummox JR
Feb 10 2007, 10:40 pm
In response to Beatmewithastick
overlays and underlays are lists - you can't set them to constant values, and you can't set them at runtime.

When the car is created (Via the New() proc), you'll have to add the icons to the overlays and underlays list. Try overriding the New() proc. Be sure to call the default procedure at the top, just in case!
Feb 11 2007, 1:49 am
You've mistaken how to deal with lists =)

A list is like a box, you can add and remove from it. If you set the list to something, you change what box you're dealing with.

You're setting a list to be equal to an icon file, f.ex - Which is not what you want.

If you set a list equal to something which is not a list, you're telling DM to change its type. In this case, you're dealing with internally defined lists and DM isn't letting you. Had you defined a list yourself, there would've been no error (Until you tried to use the list as a list, and it wasn't), so be careful about that.

Long story short, you could f.ex. replace the overlays line with: overlays = list('bumpersticker.dmi')

Or you could add it at run-time:
mob/Login()
    overlays += 'bumpersticker.dmi'


Also note something important. The same theory applies to the contents list : However, you're trying to add a type path, not an actual object.

A type path refers to the (as the name implies) path of an object in your code. However, you need to create a new object from that path - Adding a type path doesn't automatically do that for you. There is a handy procedure called newlist() which you can use, but you should definately read the F1/reference entry for it, so you know what it does. These two situations are completely identical, as far as outcome is concerned:

obj/torch
obj/armor
mob/Login()
    . = ..()
    contents += list(new /obj/torch, new obj/armor)



obj/torch
obj/armor
mob/Login()
    . = ..()
    contents = newlist(/obj/torch, /obj/armor)


I hope that helps.
Feb 11 2007, 1:57 am
In response to Alathon
Alathon wrote:
Long story short, you could f.ex. replace the overlays line with: overlays = list('bumpersticker.dmi')

No. You CAN'T set the built-in lists directly; as they're not even real list objects, rather some list operators and functions work on them (but not all).


Also note something important. The same theory applies to the contents list : However, you're trying to add a type path, not an actual object.

Note that IIRC adding a type path to the 'overlays' is valid and it works.
Feb 11 2007, 3:20 am
In response to Kaioken
Kaioken wrote:
No. You CAN'T set the built-in lists directly; as they're not even real list objects, rather some list operators and functions work on them (but not all).

Try the below in a new project. Assign an icon to bumpersticker.dmi, and turf.dmi. Draw a 10x10 map, then run it.

mob/Login()
    overlays = list('bumpersticker.dmi')
    ..()


turf/test
    icon = 'turf.dmi'
Feb 11 2007, 4:49 am
In response to Alathon
Whoops! That's good to know, thanks for correcting. I've previously read on the forums that you couldn't directly set the var of the built-in [psuedo-?]lists, surely not to a new list, I haven't actually tested it though, my bad.

Now I have tested all the built-in lists, for the sport of it, and knowledge. :P
Here are the results:

CAN DIRECTLY MODIFY:
atom.contents,
atom.overlays

CAN'T DIRECTLY MODIFY:
atom.verbs,
client.verbs,
mob.group,
savefile.dir

CAN'T MODIFY AT ALL(neither add/remove items nor directly set):
proc.args
(verb.args)
world.contents
datum.vars(can only modify existing associated values,of course)

That's it, I believe I've gotten them all.
Feb 11 2007, 7:51 am (Edited on Feb 11 2007, 8:07 am)
In response to Alathon
Wow, thanks for explaining it to me like that; "A list is a box". I have a much easier time when people explain things like that. Thanks. EDIT: 
obj
    car
        contents=newlist(/obj/Cigerettelighter)
        verb
            start_car()
                set src in view(1)
                world<<"[usr] starts the car!"
                world<<"<small><b>\red vroom!!!</b></small>"
            look_inside()
                set src in view(1)
                usr<<"You see a [src.contents]"
Ok, whenever I use the verb "look inside" I get: You see a /list. 'contents=newlist(obj/Cigerettelighter) I don't really want to add it on run-time. I just want all cars to have them along with the potential to hold more things.
Feb 11 2007, 8:13 am
In response to Beatmewithastick
Beatmewithastick wrote:
Ok, whenever I use the verb "look inside" I get: You see a /list.

Right, thats because outputting a list to text will show that.

Going with the box theory, you're going to want to go through the items in the box and show them each. Since the cars contents contains objs (/obj/Cigarettelighter is an /obj), thats what you're going to want to look at:

for(var/obj/O in src.contents) // For every /obj in src.contents; Reference it by 'O' in the loop
    usr << "You see [O.name]"
Feb 11 2007, 8:40 am (Edited on Feb 11 2007, 9:03 am)
In response to Alathon
Hey; that makes sence, thanks for sticking with the box theory. Thinking about it, what I was doing was telling the player that they were seeing the box but not the objects inside.

Why do I need the var/obj/O? why not just obj/O? because arn't the variables already there?

EDIT: moving along (while waiting) I decided I would try another verb that goes along with this: 
            stash_cash_in_car(n as num)
                set src in view(1)
                for(n)
                    if(!n) break; return
                n--
                contents+=newlist(/obj/money)
Unfortunatly, when I check the car, it only tells me I have a cigerette lighter; no moneys. I know I can do it with a var, but I just want a bunch of objs called money. If I was going about doing it with

Also, I tried fooling around with doing it with variables and it doesn't work too well for me >_>
        verb
            start_car()
                set src in view(1)
                world<<"[usr] starts the car!"
                world<<"<small><b>\red vroom!!!</b></small>"
            look_inside()
                set src in view(1)
                for(var/obj/O in src.contents)
                    usr<<"You see [O.name], and [src.money] shineys"
            stash_cash_in_car(n as num)
                set src in view(1)
                for(n)
                    if(!n) break; return
                n--
                contents+=newlist(/obj/money)
            stash_variable_in_car(n as num)
                set src in view(1)
                if(!n) usr<<"That's a stupid joke; depositing nothing? Wow, you sure know how to save"
                if(usr.money<n) usr<<"you don't have that kind of money!"
                if(usr.money>n)
                    usr.money-=n
                    src.money+=n
                    usr<<"you have succesfully deposited [n] green things"
            get_variable_from_car(n as num)
                set src in view(1)
                if(!n) usr<<"Uh huh..."
                if(src.money<n) usr<<"The car doesn't hold that much money"
                if(src.money>n)
                    usr.money+=n
                    src.money-=n
                    usr<<"You have robbed the car [n] green stuff"
Feb 11 2007, 8:51 am
In response to Beatmewithastick
Beatmewithastick wrote:
Why do I need the var/obj/O? why not just obj/O? because arn't the variables already there?

var/obj/O tells DM to assign a variable to the keyword 'O', and to believe that its of the type /obj.
Feb 12 2007, 2:01 am
In response to Beatmewithastick
bump... I edited one of my posts. Does that show it as unread to everyone again? Just incase, i'm doing this until it's confirmed.
Feb 12 2007, 2:48 am (Edited on Feb 12 2007, 2:57 am)
In response to Beatmewithastick
Beatmewithastick wrote:
bump... I edited one of my posts. Does that show it as unread to everyone again? Just incase, i'm doing this until it's confirmed.

No; edits don't unflag a post as read.

As for your problem, its tied to indentation. If you really want 1 object per money (which I'd advise against; at most I'd make an object called money, with a variable called amount), you need to make sure that everything related to the for() loop is indented under the for() loop as such:

for(condition)
    expression_one
    expression_two
    expression_three
    ...


What you have looks like this, for comparison:
for(condition)
    expression_one
expression_two
expression_three
...


DM needs to know what belongs to what; In DM, one way to do that is via indentation. Anything indented below something else 'belongs' to that.

As for your actual implementation, try creating an obj/money with a variable called amount. When the player deposits money, try and locate() an /obj/money. If one exists, increase the amount variable by what the player is depositing. If one doesn't, create a new one in the cars contents, then set the amount variable to what they're depositing.

When programming, I find it helps to break functions down into how they need to best be executed. For your problem, I'd probably see it like this:

1) Does the player have enough money to deposit what they want? If no, abort now and tell the player. Note that you checked if money was OVER the amount; what you want is over or equal to, >=
2) Store locate(obj/money) in a variable
3) If the variable isn't true, create a new obj/money there.

At this point, we know for certain that the player has enough money and an obj/money exists. Its now safe to do the following:

4) Subtract amount from players money; Add amount to
obj/money's amount variable