ID:176392
 
I have a mob/monster/var/list/monst_battlelist. In a mob/proc I need to use this variable. Since it is a mob/proc, and not a mob/monster/proc, I used ":" instead of ".", yet I still get compile errors saying it is a undefined variable. Why is this and how do I fix it? (as always, help much appreciated)

-Loduwijk
You cast the /mob to a /mob/monster.

var/mob/monster/monst = M
Loduwijk wrote:
I have a mob/monster/var/list/monst_battlelist. In a mob/proc I need to use this variable. Since it is a mob/proc, and not a mob/monster/proc, I used ":" instead of ".", yet I still get compile errors saying it is a undefined variable. Why is this and how do I fix it? (as always, help much appreciated)

First, don't post in Code Problems without code.

Second, don't use the : operator just because . isn't working for you; it means you're doing something sloppily and wrong. If you show us the code we can show you ways to do it right. But if you don't, then don't expect much.

Lummox JR
In response to Lummox JR
Sorry, I was distracted by someone while typing and did not even realize that I forgot to put in any code (my bad), not that it matters much, because seeing the actual code won't tell you a lot more than I allready have, but I will let you decide that for yourself. It definitely was a code problem though, wheather I showed any code or not. And also, I did not simply use ":" because "." was not working. I used it because I thought it was what I needed, I do not simply add things like that recklessly and expect you people to figure it out for me, I only come here as a last resort. But you would not know about that because, like you said, I forgot the code.

//my code
mob/monster/var/list/monst_battlelist = list(list of battlecommands in here)
mob/proc/fight()
command = pick(src:monst_battlelist)
//battle functions according to what it picked
In response to Loduwijk
Loduwijk wrote:
Sorry, I was distracted by someone while typing and did not even realize that I forgot to put in any code (my bad), not that it matters much, because seeing the actual code won't tell you a lot more than I allready have, but I will let you decide that for yourself. It definitely was a code problem though, wheather I showed any code or not. And also, I did not simply use ":" because "." was not working. I used it because I thought it was what I needed, I do not simply add things like that recklessly and expect you people to figure it out for me, I only come here as a last resort. But you would not know about that because, like you said, I forgot the code.

//my code
mob/monster/var/list/monst_battlelist = list(list of battlecommands in here)
mob/proc/fight()
command = pick(src:monst_battlelist)
//battle functions according to what it picked

Well, the obvious question is why you made this a proc for ordinary mobs if it's intended for monsters. And if it's not intended just for monsters, why is it using a monster-only var?

You see, the problem is in the design, not the code.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Well, the obvious question is why you made this a proc for ordinary mobs if it's intended for monsters. And if it's not intended just for monsters, why is it using a monster-only var?

You see, the problem is in the design, not the code.

Lummox JR

First of all, you have not made any attempts to help me. You have only made derogatory remarks towards my code; "the problem is in the design, not the code." I take that as a very rude comment. If you were actually trying to help then I would not mind a comment like that. What I am looking for is someone to give helpful remarks, for example, if someone said "Hey, you misspelled the variable name in your proc.", or "You know, I once had this happen, and it was caused by...". Those sort of remarks are helpful.

Now, if you still wish to debate this topic further, then by all means reply with your take on things, but please do not reply with any more rude comments.

I did take the afformentioned comment as an attack on me, but maybe you did not mean it as one. That is the problem with the internet: you cannot percieve the other person's expressions and thus take the exact meaning from their words. If I am mistaken about your drive for replying then I am sorry for my false assumptions.

Now, to be even more specific since it seems I did not give enough detail before, the proc is defined under mob, but yes, it is used by both /mob and mob/monster, and it uses a variable exclusive to mob/monster. The reason that I did this, instead of overriding the monster's version of the proc is because I pass a list of mobs into the procedure as an argument, and it only uses the code with that variable if one of the mobs in question happens to be a mob/monster. I thought that I was using the colon properly, and I could not figure out what was wrong with it, that is why I asked for help.

-Loduwijk
In response to Loduwijk
Loduwijk wrote:
First of all, you have not made any attempts to help me. You have only made derogatory remarks towards my code; "the problem is in the design, not the code." I take that as a very rude comment.

Well don't, because it wasn't meant that way. I haven't been able to help to this point because what's there makes zero sense, and it can't be helped. So I asked, quite reasonably, what you were trying to do because the way the code is presented there seems to be no explanation for the choice of making the proc for general mobs if it's used only for monsters and uses a monster-only var. It's a valid question and it is a design flaw.

If you were actually trying to help then I would not mind a comment like that. What I am looking for is someone to give helpful remarks, for example, if someone said "Hey, you misspelled the variable name in your proc.", or "You know, I once had this happen, and it was caused by...". Those sort of remarks are helpful.

Well, those won't be forthcoming in this code, because this code has different problems than those. The problem is a design decision that doesn't make sense. And if you can explain why you did it the way you did, then it might be possible to explain a different way to do it.

Now, if you still wish to debate this topic further, then by all means reply with your take on things, but please do not reply with any more rude comments.

No rudeness was intended and it takes a big stretch to interpret it that way. It's not rude to say you have a bad design if in fact you do, nor is it rude to call the use of the : operator "sloppy". It doesn't do wonders for the ego, to be sure, but it wasn't an insult; it's just the truth about the code. Calm down, please.

Now, to be even more specific since it seems I did not give enough detail before, the proc is defined under mob, but yes, it is used by both /mob and mob/monster, and it uses a variable exclusive to mob/monster. The reason that I did this, instead of overriding the monster's version of the proc is because I pass a list of mobs into the procedure as an argument, and it only uses the code with that variable if one of the mobs in question happens to be a mob/monster. I thought that I was using the colon properly, and I could not figure out what was wrong with it, that is why I asked for help.

Then the problem is that you should have overridden the proc, instead of trying to do it all in the main general proc. What might be the case is that you might have to split up your proc into several sub-procs or sections, where one of the sub-procs is the one you actually override, like this:
mob/proc/fight()
var/mob/target=PickTarget()
...
In this case it'd be the PickTarget() proc that would be overridden, while fight() might then be able to stay the same for everybody.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Well don't, because it wasn't meant that way. I haven't been able to help to this point because what's there makes zero sense, and it can't be helped. So I asked, quite reasonably, what you were trying to do because the way the code is presented there seems to be no explanation for the choice of making the proc for general mobs if it's used only for monsters and uses a monster-only var. It's a valid question and it is a design flaw.

Though my question was, and still is, if anyone might be able to help me with the fact that my one variable was not working, regardless of whether or not it is a good way to accomplish my task.
Well, those won't be forthcoming in this code, because this code has different problems than those. The problem is a design decision that doesn't make sense. And if you can explain why you did it the way you did, then it might be possible to explain a different way to do it.

I am not looking for a different way to do it. I could easily change my code and get my proc to work how I want, but I am still learning byond code, and would rather understand why my code does not work than what I should do because it does not. But you did not know that, and I do thank you for trying to help in that regard. Please do not think that I am unapritiative. I sence that you assume I am being unapretiative just like I took your comment to be an insult.
No rudeness was intended and it takes a big stretch to interpret it that way. It's not rude to say you have a bad design if in fact you do, nor is it rude to call the use of the : operator "sloppy". It doesn't do wonders for the ego, to be sure, but it wasn't an insult; it's just the truth about the code. Calm down, please.
I am not in need to calm down, I am not worked up. It was not a big stretch to interpret it as rudeness, but I did even say after that that I may be misinterpretting your statement. You seem to have left out the part in my reply where I said that people cannot see your face on the internet and don't know what you are implying, so you could be trying to be nice, yet someone might mistakinly take it as an insult. In that part you left out, I even apologised ahead of time if I was wrong about your intentions.
Then the problem is that you should have overridden the proc, instead of trying to do it all in the main general proc. What might be the case is that you might have to split up your proc into several sub-procs or sections, where one of the sub-procs is the one you actually override, like this:
mob/proc/fight()
> var/mob/target=PickTarget()
> ...
In this case it'd be the PickTarget() proc that would be overridden, while fight() might then be able to stay the same for everybody.
Lummox JR

I allready do have all of the other things, like picking targets, in seperate procedures. I guess I will end up overriding the monster procedures though.

And as to my original question. I may end up overriding the procedures, but I still wanted to see if someone could possible have helped me. The code in fault, I suppose, is probably something else, but I just wondered why it would say "undefined variable" at all when I used a runtime search operator and not a compile time one.

-Loduwijk
In response to Loduwijk
Loduwijk wrote:
Though my question was, and still is, if anyone might be able to help me with the fact that my one variable was not working, regardless of whether or not it is a good way to accomplish my task.

You miss the point: There's no way except by hacky workarounds to get the code to work. It'd make the result extremely error-prone without really improving anything.

I am not looking for a different way to do it. I could easily change my code and get my proc to work how I want, but I am still learning byond code, and would rather understand why my code does not work than what I should do because it does not. But you did not know that, and I do thank you for trying to help in that regard. Please do not think that I am unapritiative. I sence that you assume I am being unapretiative just like I took your comment to be an insult.

Not unappreciative as such--just not quite getting the picture. I was actually explaining the why as well as how to fix it. Why it doesn't work isn't simply a matter of one little thing being out of place; it's the design flaw that's the problem. What you did was to try to lump stuff into one big proc that should have been handled via overrides. You were trying to use something in the main type that belonged to the subtype, so it's not like there was a correct way to do what you were trying to do, but rather that trying it that way was the real problem.

I allready do have all of the other things, like picking targets, in seperate procedures. I guess I will end up overriding the monster procedures though.

And as to my original question. I may end up overriding the procedures, but I still wanted to see if someone could possible have helped me. The code in fault, I suppose, is probably something else, but I just wondered why it would say "undefined variable" at all when I used a runtime search operator and not a compile time one.

You're still not getting it.
It's not that the code was wrong, but that the approach was wrong. You're basically asking for a right way to do the wrong thing, and there isn't one; a wrong way to do the right thing would have been fixable by the type of advice you were expecting.

The reason for the error was simply that you tried to mix types in a way that even the : operator couldn't fix. There's not really any better explanation available than that.

Lummox JR
In response to Lummox JR
You keep saying "You simply shouldn't do it that way." I understand that, and I probably won't, I simply want to know why that won't work. In your last reply you mentioned that it was because I used the operator in the manner that I did, but it is supposed to access a variable even if the reference in question isn't the one naturally to have that, and I understand about the errors and such I would potentially have, but I am no longer asking this because I want to get the code to work in that manner, rather, as I stated in my last reply, I just want to know how I would get it to work in the way I was trying to do it. I understand that it is bad design and all, but I am still trying to learn this byond language, and as such I asked how to accomplish that feat even if it is the worst way to go about it. It could be so bad of a design structure that you could call it crap and be correct literally, yet I still want to know how I would do it, and why my way does not work. I understand that it is the wrong way to do things, I just want to know, basically, if it even could possibly be made to work that way, even if it would result in a million runtime errors every minute. If it simply cannot be done, because it is totally, 100% impossible, then say so. But if there is the remote chance that it could be made to work, and you know that, then simply say that it would be possible but you do not want to waste your time on it, that I would have to figure it out on my own or wait for years untill someone else does feal like wasting their time on me.

So, are you saying that it is totally impossible to even get it to work to the point that I could get it compiled? Or is their to do it so that it would work, but it would be not only bad design but "crappy" design. Because like I said, I will probably end up doing it different, yet I am not going to do it different simply because I am too ignorant to do it my way.

-Loduwijk
In response to Loduwijk
Loduwijk wrote:
You keep saying "You simply shouldn't do it that way." I understand that, and I probably won't, I simply want to know why that won't work. In your last reply you mentioned that it was because I used the operator in the manner that I did, but it is supposed to access a variable even if the reference in question isn't the one naturally to have that, and I understand about the errors and such I would potentially have, but I am no longer asking this because I want to get the code to work in that manner, rather, as I stated in my last reply, I just want to know how I would get it to work in the way I was trying to do it.

I'm telling you you can't get it to work in the way you were trying to do it. The only way to deal with that is to use very complex code that would only amplify any bugs you might have. It'd be all but impossible to debug, and if you're still learning to program, then you'd be better off abandoning the project entirely than to continue on this course.

And I did not say that it's because you used the operator the way you did. I said specifically that what you were doing was something the operator couldn't compensate for. In other words, the approach is so cockeyed that the most forgiving operator in the DM language won't work with it. That's what I've been trying to say, and what you haven't been getting.

You keep asking how to get it to work the way you were trying to do it. That's like asking how to build a milk carton out of sticks in a way that will actually hold milk. Maybe it can be done, but only with great difficulty. You're asking for a quick fix to a problem that doesn't have one.

I understand that it is bad design and all, but I am still trying to learn this byond language, and as such I asked how to accomplish that feat even if it is the worst way to go about it.

Which is pointless to tell you if you're learning. It's pointless any way you look at it, but worse for a beginner because the answer won't teach you anything.

It could be so bad of a design structure that you could call it crap and be correct literally, yet I still want to know how I would do it, and why my way does not work.

I already explained why, but I'll try to give it another shot.
In short, BYOND was not designed with a datum hierarchy and procedure inheritance just so all code could be lumped into a master proc for the main type. What you're trying to do is contrary to the very design of the language.

The operation you're asking the game to perform is equivalent to asking someone a question about their great great grandchild who hasn't been born. This is how the hierarchies work; subtypes look above themselves, but parent types don't really look below.

That's the detailed explanation.

I understand that it is the wrong way to do things, I just want to know, basically, if it even could possibly be made to work that way, even if it would result in a million runtime errors every minute.

How loose is your definition of "work", then? If it's spawning errors it's not working.

If it simply cannot be done, because it is totally, 100% impossible, then say so. But if there is the remote chance that it could be made to work, and you know that, then simply say that it would be possible but you do not want to waste your time on it, that I would have to figure it out on my own or wait for years untill someone else does feal like wasting their time on me.

BYOND is flexible enough that it is in fact possible, and I said so. The way to do it is so hacky and convoluted, though, that it's not only going to cause major problems, but it's clearly outside your ability. (I don't mean that to put you down by saying that. Based on the understanding you've demonstrated that's just the truth.) And even if someone gave you code that would magically fix your problem, you wouldn't understand it and the first bug would break you. And if you did understand it, the parade of bugs this approach would cause would be beyond your skill to fix. And the next time you asked for help, you'd get people scratching their heads because the code would simply not make sense.

Why are you so bent on getting it to work by the current approach? All this is going to do is hamstring your project. You'll make no further progress without stumbling over the same problems again and again, and any future attempt to get help will just fail completely. The way to fix this is simple; the way to get the wrong way to function haltingly is complex.

So, are you saying that it is totally impossible to even get it to work to the point that I could get it compiled? Or is their to do it so that it would work, but it would be not only bad design but "crappy" design.

It would be beyond crappy design. A simple crappy design flaw can sometimes be worked around so that ultimately it doesn't make much difference. This is about ten times worse than that, and it's downright mulish to stick to it. Let this go, man.

Because like I said, I will probably end up doing it different, yet I am not going to do it different simply because I am too ignorant to do it my way.

Your "way" isn't much of a way at all. It's not that you're too ignorant to make your approach work. It's that it's way way way too difficult to make your approach work, and ignorance is what got you into it. Stubbornness is the only thing that can keep you locked into it, because if you knew what you were doing at all you'd abandon this approach and go another way.

You say you're "learning", but you refuse to learn. It's not simply that you should be using a different approach; it's that the effort involved in getting yours to "work" (inasmuch as it can be called that) is totally unwarranted. I don't understand why you're insisting on this track.

Lummox JR
In response to Lummox JR
Allright, I have been civil up to this point, but I am tired of your crap, I have read many of your debates before, and you usually seem to keep things fine, but you keep bringing things back to what I keep saying I don't want. I am learning byond, but I am definitely not a beginner. I have been programming using byond for almost a year and a half now (the identity thing says that it was made December 2 years ago, but I don't know why, as I know for a fact that It was actually September, but that is beside the point). I am not simply asking for someone to hand me code, but even if they did, I can assure you that I probably would understand it. I may be fairly new to byond, only being here for about a year and a half, but I have been programming computers since I was very young on my fathers old Commodore64, I know that is not the same thing, but my point is that you keep trying to say that it would be bad programming, and that I should not even be concerned with it, because I would get all confused, or whatever it was you were implying. I am not some invalid, and if you are not going to help me then please cut the crap, and stop saying that you aren't giving me any because then that would just start a whole new debate about that and I am getting sick of it. I love to debate, but not when the other person debates mindlessly and simply refuses to give up. I allready admitted my mistakes, now if you could just be man enough and cut the crap as well then the world would be a better place. And don't tell me to calm down again, I am not worked up, in fact I am not even mad at you. It takes much more than something this trivial to set me off. Even if I were a beginner at programming you did not need to go through all that just to say that I probably would not understand. Now it is after 11 here and I am very tired, maybe I will edit this post and fix it up tommarow when I am more awake. Anyway, my point is, I am not a beginner, I have used all these procs and operators before, it is just that sometimes when I try to use them in a way that I have never done so before I ask for a little bit of help. And even if my way is bad I would still like to know why (which is what you keep talking about, so that is good there), and also I would like to know a little bit about it so that I know why. I don't want people just telling me that it is bad. Nobody learns that way. I help byond beginners all the time, I spend half my online time doing that, and I have tons of people with me on their pagers and instant messanger lists because they know that I try to explain things to them and actually help them understand things, not just tell them that they need to do it this way or that, and I help many byonders with their problems in this way. I know what I am doing.

-Loduwijk
In response to Loduwijk
Loduwijk wrote:
Allright, I have been civil up to this point, but I am tired of your crap, I have read many of your debates before, and you usually seem to keep things fine, but you keep bringing things back to what I keep saying I don't want. I am learning byond, but I am definitely not a beginner. I have been programming using byond for almost a year and a half now (the identity thing says that it was made December 2 years ago, but I don't know why, as I know for a fact that It was actually September, but that is beside the point).

What difference does it make the time you've been programming, if you've learned so little? You're still a novice.

Yes, I keep bringing things back to what you keep saying you don't want, because what you want is outside of the realm of feasibility. You're asking to do not just the very very difficult, but the completely insane. "How can we build a spaceship out of banana peels?!" Maybe that can be done, but you learn nothing by attempting to do so.

As it is, you should stop insisting that you're "learning" anything, because a learner does not persist in a dead end when there's a perfectly viable alternative. What you're trying to do is akin to hacking your way through a dense forest with a machete in a week when you can walk around it in 10 minutes. And saying you want to know how so you can "learn" is not an excuse, or even a cogent argument, because it could teach you nothing. There is no possible way to profit by the experience except to finish it, and since that's the case you may as well take the short way around, and learn something in the process. If you're not gonna do that, stop professing to learn.

I am not simply asking for someone to hand me code, but even if they did, I can assure you that I probably would understand it.

Given the difficulty of a workaround and the wrongheadedness of the approach, no, you probably wouldn't. But even if you did, it makes no difference because it is of no value to you.

You are asking for someone to hand you code, and don't you dare claim otherwise. You've repeatedly and consistently tried to force your way through the path you already chose, no matter how much or how often you were told that path is all but impassable. All you keep asking is "Okay, maybe I'm doing this the wrong way, but how can I get it to work that way?" That's a code beg flat out. There's no tutorial process that's gonna put sense into what you're doing, and all you're looking for is for a piece of code you can use that lets you continue in the mistakes you've made without learning from them.

I may be fairly new to byond, only being here for about a year and a half, but I have been programming computers since I was very young on my fathers old Commodore64, I know that is not the same thing, but my point is that you keep trying to say that it would be bad programming, and that I should not even be concerned with it, because I would get all confused, or whatever it was you were implying.

Based on your inability so far to understand or respond coherently to the above arguments, repeated several times, I submit that any brute-force approach to pushing through the problem your way would indeed be over your head.

I was programming from a young age too. What of it? It's not the time spent at the task that matters, but what you took away. If you keep bashing your head against this particular wall you might eventually break through, but I've been showing you the doorway right next to you for hours now. Knowing how to turn a doorknob is valuable and will help you the next time you want to get out of a room; bashing through will land you in the same situation next time, but with a headache, a skull fracture, and a frickin' hole in your house.

It's more than that it would be complicated or confusing that I recommend away from this. It's convoluted and an absolutely backwards, twisted, knotted around, and French-braided approach. And even if you understand it just fine that way, it's way too much trouble to do for the effect involved, and will cause you many many problems down the road.

But the fact that you can't seem to dig out of the hole on your own is a good indication that you wouldn't in fact have a good grasp of how this "works" if it was made to function.

I am not some invalid, and if you are not going to help me then please cut the crap, and stop saying that you aren't giving me any because then that would just start a whole new debate about that and I am getting sick of it.

I'm not trying to say you are one! But you're darn well headed that way by trying to plow into a phone pole. Go around! Do it the right way! For crying out loud, man, there's a simple solution and it doesn't make you less of a person to use it.

Are you trying to do something vastly more complex, vastly more unworkable just to prove to yourself or others that you're up to the task? Is there any reason at all you insist on trying to get something to work the wrong way?

YES you can stick the peg in the hole sideways, if you saw it down into sort of a circular shape first. Or you can just orient the peg right in the first place and stick it in. This is what I'm trying to get across.

I love to debate, but not when the other person debates mindlessly and simply refuses to give up. I allready admitted my mistakes, now if you could just be man enough and cut the crap as well then the world would be a better place. And don't tell me to calm down again, I am not worked up, in fact I am not even mad at you. It takes much more than something this trivial to set me off. Even if I were a beginner at programming you did not need to go through all that just to say that I probably would not understand.

You're not even understanding what I've been saying for the last several posts. There's no "probably" about it.

In repeating yourself you have become the doctor joke personified:

"Doctor, my arm hurts when I do this."
"Then don't do that."

Your code isn't working for the same reason it hurts to disjoint a shoulder. You're using the wrong tool for the job, and you keep insisting on a bad bodge to do it with that tool, without just picking up the right tool and being done with it in 10 seconds. Gads, man, you could have had this problem fixed by now if you'd stop complaining that the solution you were told isn't what you wanted. It will solve your problem without compromising your game, and that's all you need; it's a better solution than we can sometimes offer people. All you have to do is abandon a design that has clearly failed you, and switch to one that's not much different but will work correctly, and it doesn't affect your game's features in any way except to make it work.

As I've been trying to tell you over and over again, it's the design that's broken, not the code. You will learn nothing by duct-taping over the problem, even if it was as simple as that. And that seems to be exactly what you want, but that isn't possible.

Is that what you wanted to hear? Is it? It may be possible to get your design to work, haltingly and badly, but it is not possible to simply show you something to fix it, any more than you could be taught surgery to replace a broken bone instead of being told not to stick your leg in the crushy thing.

Now it is after 11 here and I am very tired, maybe I will edit this post and fix it up tommarow when I am more awake. Anyway, my point is, I am not a beginner, I have used all these procs and operators before, it is just that sometimes when I try to use them in a way that I have never done so before I ask for a little bit of help.

You're still a beginner. There's no shame in that. It doesn't matter that you've used all these things before. This is not intermediate-level programming or even the discussion I would be having with someone of that level.

And even if my way is bad I would still like to know why (which is what you keep talking about, so that is good there), and also I would like to know a little bit about it so that I know why. I don't want people just telling me that it is bad. Nobody learns that way.

<font size=+2>I told you why in the last post, in a detailed explanation. Kindly read it.</font>

I help byond beginners all the time, I spend half my online time doing that, and I have tons of people with me on their pagers and instant messanger lists because they know that I try to explain things to them and actually help them understand things, not just tell them that they need to do it this way or that, and I help many byonders with their problems in this way. I know what I am doing.

If you knew what you were doing, this conversation would never have started, let alone dragged out as it has. I'm going back to the door analogy: You're trying to hit your head on the wall to break it instead of going through the door. As I told you in the last post, your whole problem stems from simply ignoring BYOND's datum hierarchy and the way inheritance works. The problem is one of stuffing everything into one proc in what's equivalent to a giant if/else or switch block instead of using more direct mechanisms. But the bigger problem is that no matter how many times I tell you that, you seem not to have read or comprehended it.

There is nothing at all to learn from the method you're trying to use. Stop telling yourself that you're trying to learn, because you're not; you're trying to make sense of a nonsense situation. You're trying to find logic in the illogical, and there isn't any. If you wanted to learn, you'd abandon the track that steered you wrong and take up one that will work. Then you can understand why that works, and maybe come to understand through that, or later down the road, why the first approach was wrong.

And don't you say one more word to the effect that I haven't told you "why" this isn't working, since I have. If the explanation I gave wasn't sufficient, I'd be more than happy (give or take) to try to flesh it out for you, but don't just ignore it.

Lummox JR
In response to Lummox JR
Please do not tell me to read what you said as if I have not. I have read every single word in every post in this thread. Although I could say that you may not have. You insist on looking to the past. I allready told you that I am not going to do the game that way. I have allready said that I will go about it a different way, I am not "banging my head" on anything. And I am definitely not a beginner either, I wish my computer didn't crash and lose everything when I tried to get back on the internet, then I would show you something that I worked on while I was away, but it is all gone. Not that any of that matters though, I am definitely not a beginner, whatever you may say. I totally understand everything in any lib that I download (I never download them for my own use, I allready can do whatever is in them, and I do do it myself, rather I download them when helping with someone elses code and they include a lib), I can explicitly recall in Deadron's Character Handling, at the top of the implementation.dm, it said "DO NOT MESS WITH THIS FILE UNLESS YOU ARE A CODE GURU", yet I understand everything in it perfectly, and could even write a similar thing myself. Yes, I know, that does not mean anything, because that lib is fairly simple to understand, but my point remanes, I am not a beginner. I know that the time you spend doing something does not make you good if you did not take anything from it, but that is not the case for me. Now I don't even know why I am arguing about this, it has nothing to do with the topic and it does not even matter if you do take me for a beginner, but do not give everyone else who reads these posts a false representation of me, and yes it is a false representation.

The only reason I continue with this is because you continually shoot down everything that I say. You have a way of doing it like a politition which most people find quite annoying. I don't know about you, but I do not like it when someone continually responds telling me that everything I said in my post is wrong, even if it is some trivial issue that is not even a fact, but is an oppinion. I have given you credit where it is due, I do not simply refute everything you say, and I would like it if you would be polite and do the same.

All I was asking for, like I said before, is for someone to explain the operator in question, because my assumption of it was that it does not check the variable that you use it with at compile-time, but rather does so during run-time, giving you a runtime-error if it does not fit right. If this view is not correct then I ask for someone to correct this view. If it is correct, then I would think that it should not matter how I use it in the code, as long is it is in a place where a variable can go, which it is, but this is obviously not the case, so if it has to do with that then I ask for someone to correct me there. I ask for this not because I want to use it, but because my understanding of this operator is obviously not as it should be, and I would like to know the correct way, even if only for future need of it.

-Loduwijk
In response to Loduwijk
Loduwijk wrote:

All I was asking for, like I said before, is for someone to explain the operator in question, because my assumption of it was that it does not check the variable that you use it with at compile-time, but rather does so during run-time, giving you a runtime-error if it does not fit right. If this view is not correct then I ask for someone to correct this view. If it is correct, then I would think that it should not matter how I use it in the code, as long is it is in a place where a variable can go, which it is, but this is obviously not the case, so if it has to do with that then I ask for someone to correct me there. I ask for this not because I want to use it, but because my understanding of this operator is obviously not as it should be, and I would like to know the correct way, even if only for future need of it.

-Loduwijk

Basically it lets you be lazy so you don't have to be "bothered" with making sure that you're acessing the correct variables for objects until you run your program.

However, beginner or not, you should take the time to learn some good programming techniques. Listen to what has been proposed: it will save you time and headaches later.
In response to Lummox JR
I am sorry for that last post, it was very late and I was extremely tired. I know that does not account for my actions though so I appologise, I was not quite my polite self in that post. I would have edited it in the morning but for some reason it won't let me (I get a logging failed page).

-Loduwijk
In response to tenkuu
That was no help, I allready said that that is what I thought it was for, and that is how I used it, so according to you my code should work.

-Loduwijk
In response to Loduwijk
Let me bring back an earlier response from Lummox. Read it and try to see how it applies to your problem:
"Well, the obvious question is why you made this a proc for ordinary mobs if it's intended for monsters. And if it's not intended just for monsters, why is it using a monster-only var?"

':' is not a magic operator that will get this to work for you. monst_battlelist is a monster variable, and unless your players are of type /mob/monster, they will never have access to it! Unless you have references to monsters, you're not going to be able to use monst_battlelist in the way that you're trying.
In response to tenkuu
Egad, man, perhaps if you ran the information Lummox JR is giving you, you would come out with the right answer? And you are taking things too seriously; Lighten up!
In response to Loduwijk
Loduwijk wrote:
Please do not tell me to read what you said as if I have not. I have read every single word in every post in this thread. Although I could say that you may not have.

You said repeatedly that I didn't tell you why your code wasn't working, when in fact I had explained why in detail, more than once. It's the fact that you're ignoring the way BYOND treats datum hierarchies that's responsible for this. Datums look up in the tree, not down. Yadda yadda yadda. I've been over it, and yet you keep telling me I haven't been.

You insist on looking to the past. I allready told you that I am not going to do the game that way. I have allready said that I will go about it a different way, I am not "banging my head" on anything.

But you keep asking how to get something that won't work to work. You're asking me how to jury-rig a vast and complex workaround for the way you were doing it, as if there's something to learn from that; there isn't. And you've shown no indication that you actually plan to go it any other way, but only that you're willing to go back and revise the design if you can't get the current one to work. Well, I can save a lot of time by telling you you can't.

And I am definitely not a beginner either, I wish my computer didn't crash and lose everything when I tried to get back on the internet, then I would show you something that I worked on while I was away, but it is all gone. Not that any of that matters though, I am definitely not a beginner, whatever you may say. I totally understand everything in any lib that I download (I never download them for my own use, I allready can do whatever is in them, and I do do it myself, rather I download them when helping with someone elses code and they include a lib), I can explicitly recall in Deadron's Character Handling, at the top of the implementation.dm, it said "DO NOT MESS WITH THIS FILE UNLESS YOU ARE A CODE GURU", yet I understand everything in it perfectly, and could even write a similar thing myself. Yes, I know, that does not mean anything, because that lib is fairly simple to understand, but my point remanes, I am not a beginner. I know that the time you spend doing something does not make you good if you did not take anything from it, but that is not the case for me.

You seem to be stuck on the idea that there's a stigma to being a novice, and you're trying very hard to insist you're not a beginner. The approach you took to this code says otherwise; not even an off day is enough to explain it. You may have significant experience, you may understand much of what you see, but the thought processes are those of a novice.

Heck, I've spent umpteen posts trying to explain "it won't work that way" because the fact that there is a staggeringly complex solution doesn't make it "won't" enough for you. In engineering terms, if you're told something can't be done it's because if there is a way to do it, it'd take more time and/or money and/or effort by orders of magnitude than what can be invested in a perfectly good alternate approach.
You can't build a giant catapult to fling things into space. If it's possible, it's way out on the very edge of possible, but for all practical purposes that "can't" is solid.

Now I don't even know why I am arguing about this, it has nothing to do with the topic and it does not even matter if you do take me for a beginner, but do not give everyone else who reads these posts a false representation of me, and yes it is a false representation.

I really don't give a crap whether other people take you for a beginner or not. The fact that you don't take yourself to be one is obviously half the problem. You've told yourself that there must be some way to get your existing method to work, and so you've locked yourself into asking for that way over and over again. Both the method you chose and the tenacity to which you've stuck to it are indicative of novice thinking.

A person can do a lot of programming and never rise above a beginner level. All you really have to do is never push past a certain point of complexity. While no doubt savefiles and other came easy to you, clearly the hierarchical structure of BYOND has thrown you off. For the problem you're trying to tackle, for some reason you took it in mind to ignore that hierarchy and work without it, using the : operator as a quick fix.

All I was asking for, like I said before, is for someone to explain the operator in question, because my assumption of it was that it does not check the variable that you use it with at compile-time, but rather does so during run-time, giving you a runtime-error if it does not fit right. If this view is not correct then I ask for someone to correct this view.

That much is correct. However at no point do I recall the substance of your question being "Does or does not the : operator work this way?" Rather, you asked how you could modify your code as-is to work.

If it is correct, then I would think that it should not matter how I use it in the code, as long is it is in a place where a variable can go, which it is, but this is obviously not the case, so if it has to do with that then I ask for someone to correct me there. I ask for this not because I want to use it, but because my understanding of this operator is obviously not as it should be, and I would like to know the correct way, even if only for future need of it.

It's not the understanding of the operator that's your problem, as such; it's that you credited it with too much. As it is, this operator is dangerous because it allows wide drift out of the hierarchy, the structure of which can help keep bugs out of your code. You made a design decision to drift way away from that hierarchy, and then decided to use the : operator to facilitate that.

The bottom line is, the couple lines of code you showed us shouldn't have been a problem if enough other code around them was properly accounting for types. But this, as I said, is jury-rigging. This is why I've said so much that there's nothing to learn from getting this approach to run; you've focused in on the wrong problem, and the solution lies elsewhere. Even if you got it to work as it is, it wouldn't teach you anything. The only real lesson to be learned is that lumping all child code into a parent proc is a bad idea, and it's so much better (and easier) to take advantage of object inheritance. But that's kind of taken for granted by an intermediate programmer.

Lummox JR
Page: 1 2