this is the error quest.dm:48:error: proc definition not allowed inside another proc
the line is marked with this ///\\\
Quest
var
mob/sponsor
quest_obj_type
reward_obj_type
desc
proc
Check()
var/mob/M
var/obj/0
for(M in view(sponsor,1))
0 = locate(quest_obj_type) in M
if(O)
Reward(M,0)
return 1
Reward(mob/M,obj/0)
/// var/obj/R = new reward_obj_type(M)\\\
O.Move(sponsor)
M << "You have completed the quest!"
M << "[sponsor] takes [0] and rewards you with \an [R]."
mob/king
var/quests[0]
verb/beg()
set src in view()
var/Quest/q = RandQuest()
usr << q.desc
quests += q
verb/bow()
set src in view()
var/Quest/q
for(q in quests)
if(q.Check())
quests -= q
return
proc/RandQuest()
var/qtype = pick(typesof(/Quest) - /Quest)
var/Quest/q = new qtype()
q.sponsor = src
return q
ID:149990
 Jan 11 2002, 8:07 am
|
|
i dont get what your saying,i do partly but not enough to undrerstand(its hard to get indentation perfect on the forum, i think you know that)
| |
Don't get snippy with me... I didn't say you had the indentation wrong to hurt your feelings, I said you had it wrong because you asked what was wrong with your code.
To rephrase what I said before: the error you get says that you can't make a new proc inside another proc, right? In case you don't know: Check() is a proc defined by this code. So is Reward(). In case you don't know: when you indent something one step further than the last indentation, this means you're defining whatever's on this new line as "under" or "belonging to" the previous level of indentation. If I write code like this: mob proc/eat() it doesn't define just a proc called eat(), it defines it as mob.eat(), whereas if I write: mob proc/eat() the eat() proc doesn't belong to anyone, it's on the same level as mob rather than under it. The problem with your code appears to be that you've defined Reward() as belonging to Check(), when they both should belong to Quest... one proc cannot own another. | |
I just looked at the code you put in the first post in this thread... you've got the number 0 in some places and the letter O in others! Do you even understand a tenth of what it is you're doing? I mean, you've got the code laid out for you, formatting and all, exactly as it should be typed, in the Blue Book. I've spent all the time I'm willing to, helping you debug perfectly functional code.
| |
its not perfectly funtional i copied exactly from the book and it didnt work(you have to trust me on that) the version i copied and pasted to the forum was a version i was trying to figure out and thats why there were O's in 0's places just pretend those are zero's
| |
They SHOULD BE the letter O!
--makes the sign of the evil eye to ward herself against incompetence and backs away slowly-- | |
Tapion1 wrote:
in the book it really looks like a zero.... A zero can't represent an object. A zero is only used where a number is needed... So everywhere you are using zero for an object, replace it with O, or a different name to be less confusing. (And yes, a certain author takes some blame for using a single-character easily-confused variable name!) | |
Because of the typeface they use for code! Regardless of what it looks like, you should be able to figure out what it is by context... zero is a number. You declare the parameters (variables):
mob/M, obj/? You declare the first one, which corresponds to a mob, as a letter, right? In fact, it's the first letter of the word Mob... it doesn't have to be, it just is for convenience... a variable name can be anything... well, almost anything. It cannot be a number (such as zero!) So, we have mob/M and area/A and turf/T and obj/ZERO? How much sense does that make? How did you make it to page 182 of the Blue Book without understanding such basic things as indentation, inheritance, and assignment of variable names? | |
lol,thanks deadron (np, i know now)but now i get these.....quest.dm:42:error:sponsor:bad var
quest.dm:42:error:in :expected 1 argument to 'in' quest.dm:42:error:for :invalid variable name: reserved word quest.dm:43:error:quest_obj_type:undefined type: quest_obj_type quest.dm:45:error:Reward:bad proc quest.dm:47:error:mob:bad var quest.dm:47:error:obj:bad var quest.dm:47:error:Reward:bad proc quest.dm:48:error:reward_obj_type:undefined type: reward_obj_type quest.dm:48:error:M:invalid variable quest.dm:48:error:= :expected a constant expression quest.dm:49:error:sponsor:bad var quest.dm:51:error:sponsor:bad var quest.dm:77:error:quest_obj_type:undefined type: quest_obj_type quest.dm:78:error:reward_obj_type:undefined type: reward_obj_type quest.dm:79:error:desc:undefined type: desc quest.dm:59:error:q.desc:undefined type: q.desc quest.dm:66:error:q.Check:bad proc quest.dm:73:error:q.sponsor:bad var -_- | |
Lesbian Assassin wrote:
It cannot be a number (such as zero!) So, we have mob/M and area/A and turf/T and obj/ZERO? How much sense does that make? I don't think there's any intuitive reason that a number couldn't be a variable... But switching back and forth between zero and a letter doesn't make much sense (nor does Dantom using single letter variables in a book...someone should have edited that thing!...um) Anyway, Tapion, you really would be served by starting at the beginning of the book. It does kind of sound like you didn't. | |
I don't think there's any intuitive reason that a number couldn't be a variable... 7 = 3 10 = 7 if (7 + 3 == 10) ... Puzzle that one out for me? | |
Tapion1 wrote:
lol,thanks deadron (np, i know now)but now i get these.....quest.dm:42:error:sponsor:bad var Your life will be much better if you start from the beginning of the book. It's one of the best beginning programming books ever, and the first example is like 3 lines long! By starting there, you'll encounter these problems in an easier to figure out way. It's not uncommon (me included) to look at the beginning of a book like this and say "That's too simple! I'll skip all that and get to the good stuff." But there's a reason that simple stuff is up front, and you really should take the time to go through it. | |
Lesbian Assassin wrote:
I don't think there's any intuitive reason that a number couldn't be a variable... Most people don't get quite that far in thinking about these things when they are new to programming... Anyway, as you pointed out the main need was for him to start from the beginning, which it looks like he's going to do. | |
Look at what the error says you're doing that's not allowed... defining a proc inside another proc, right? Now, look at your code:
/// var/obj/R = new reward_obj_type(M)\\\
If the indentation you gave is anything close to accurate, you have the entire code for Reward indented under the heading of the Check proc. Is Reward() a property of Check()? No, it's a proc. What should it be defined under?