ID:143869
 
Code:
/*All that I apparently need to show...
Variable P is players/Player, a child class of mob with its own variables.
Variable M is obj/Team, which stores the players and other values.
The 'budget' variable of M is part of the Team subclass, which can't be accessed easily
without using : */


P.keep+=round((P.TSI-P.keep+(M:budget/100))/400)


Problem description: This line (and the others you don't know of, but they can't because the code is stopped obviously) generated a "Undefined operation" error at runtime. It has worked before, but it won't now. All of the values used are numbers, defined and also known to be from previous testing.

Does anyone know what is going on, or do I need to post more?


The whole idea is that the Keep variable is increased by a rounded and extended calcuation - The TSI is taken away from the current Keep value which is added to the Budget divided by 100. The result then divided by 400, and then it will be rounded.

First define budget under obj/Team (instead of a subclass) with the default value of 0 (instead of null)... then replace the : with .

obj/Team
var/budget = 0
Team_69
budget = 2121


P.keep+=round((P.TSI-P.keep+(M.budget/100))/400)


Make sure that budget has been defined as a number, var/budget=0, instead of null, var/budget, since the null value could give errors in the calculation/
In response to GhostAnime
GhostAnime wrote:
First define budget under obj/Team (instead of a subclass) with the default value of 0 (instead of null)... then replace the : with .

obj/Team
> var/budget = 0
> Team_69
> budget = 2121
>
>
> P.keep+=round((P.TSI-P.keep+(M.budget/100))/400)

Make sure that budget has been defined as a number, var/budget=0, instead of null, var/budget, since the null value could give errors in the calculation/

Well, I meant I defined Budget under THAT subclass (obj/Team) but I can see where I screwed up.

And I can't use . or I get a missing expression error. Thats why I used :
In response to RedlineM203
The only use of the : operator is when you don't define a variable's type properly. So, for example, if you have var/obj/M, you need to use the colon. You shouldn't, though, because you SHOULD have var/obj/Team/M, and then you can just use the . operator.
In response to Garthor
Either way, I still have a Undefined Operation error.

My style of coding is 'If it works, its good enough.' all I want is to find how what is going on, and get Dream Maker out as quickly as possible, so don't suggest anything that won't have a chance of solving my problem.
In response to RedlineM203
My style of advice is, "if they're doing something incredibly stupid, beat them over the head with it until they do something that isn't half-retarded."

Now, that something incredibly stupid you're doing at the moment is your philosophy of "if it barely sometimes works in certain situations, it's fine." This is SO unbelievably wrong that I am having to metaphorically PHYSICALLY RESTRAIN myself from metaphorically hurting you.

If you do things the RIGHT way, then you will have FEWER problems, an easier time FIXING problems, an easier time MAKING CHANGES, and an easier time GETTING HELP. However, if you choose to an arrogant little snot who refuses to take advice, then you're going to come back here every day asking for help on something that's broken for the same reason the last ten things broke, but you'll refuse to let us help you fix it because it's not your "style of coding."

I spat that last phrase, by the way. Because it's dumb.
In response to Garthor
I took your advice, I fixed it to how you wanted, it failed.

Its still the same now.

Garthor wrote:
Now, that something incredibly stupid you're doing at the moment is your philosophy of "if it barely sometimes works in certain situations, it's fine." This is SO unbelievably wrong that I am having to metaphorically PHYSICALLY RESTRAIN myself from metaphorically hurting you.

How do you even know that I think stuff that 'barely sometimes works' is fine? All I said was, "If it works, its fine."

I should of said, "If it works how I want it to, its fine."

Which is the full, now uncut statement. Hell, this is the first error I've seen in any of my coding which I can't solve in several months. And its obviously something unsolvable by me because of the following reasons:

1. It didn't show up in DM
2. The code was used before with brilliant results
3. I never even knew there was an error called "Undefined Operation"

In response to RedlineM203
But you fixed the abuse of the : operator, right? The reason why "if it works, it's fine" isn't true is for the same reason we have building codes. A building that is standing is not sufficient. It has to CONTINUE standing, even in poor conditions.

Now, so long as you fixed that...

You're getting an undefined operation error because you're trying to perform arithmetic operations on variables which are not numbers. The only three variables you've got there are P.TSI, P.keep, and P.budget. However, the only operations you are performing on TSI and keep are addition and subtraction, both of which are defined for all types (though not necessarily possible), and would cause a type mismatch error.

So, the problem lies squarely with P.budget. While - now that you've removed the colon - the line of code you have has no errors, somewhere else you are changing P.budget to a non-number (a string, perhaps, or an object, if you wrote O instead of O.value or somesuch). This gives you the fun task of finding out where, exactly, you are setting P.budget to a non-numerical value.
In response to RedlineM203
RedlineM203 wrote:
All I said was, "If it works, its fine."

Tell that to a couple with the man suffering from premature ejaculation.
In response to Garthor
Garthor wrote:
So, the problem lies squarely with P.budget.

M.budget. And M:budget was right too, just not 'effective'.

While - now that you've removed the colon - the line of code you have has no errors

Had none in the first place, but this error we speak of now.

Somewhere else you are changing P.budget to a non-number (a string

10000 isn't a number now?

I know what I've done and been doing. The initial value for a Team is 10000, and the only time that is changed is by using a verb which you select a Team and change their budget.

Which means 40000 isn't a number anymore either then.

Hell, I'm gonna check right now.
EDIT: Checked right now, all 10000s or otherwise 40000.

Every number in the expression is defined as a number or changed to a number early on.
In response to RedlineM203
RedlineM203 wrote:
Garthor wrote:
So, the problem lies squarely with P.budget.

M.budget. And M:budget was right too, just not 'effective'.

Good gads man. You've been programming in DM long enough to know not to do this.

M:budget was not right because it was not one of the rare scenarios where using the colon operator is a good idea. In any case where you can in any way avoid the colon, you should, and for one simple reason:

Duh!

A secondary, related reason is that abusing the : operator basically shifts potential compile-time errors into becoming potential runtime errors. Ask yourself where you'd rather catch the problem.

Thus, using : instead of . is not equivalent, not just as good or close to it. It is not a neutral choice; it is a wrong one. Abusing the operator in no way improves your code.

Every number in the expression is defined as a number or changed to a number early on.

Are you sure about that? Best to check what the actual values are. I think you'll be surprised to learn that one of those numbers is not a number at all.

In newer versions of BYOND, "undefined operation" and "type mismatch" reports the types involved. However I can throw you a bone here in that "undefined operation" is used only by the * and / operators. The term you're dividing by 400 can't be incorrect or you'd have a type mismatch error before that, so it has to be P.budget after all.

Lummox JR
In response to Lummox JR
I already said what my coding style was, and : was the only thing that worked at time of useage. It was good enough at the time, and it still is now, though you 'crap' cleaners are forcing me out of it.


Lummox JR wrote:
In newer versions of BYOND, "undefined operation" and "type mismatch" reports the types involved. However I can throw you a bone here in that "undefined operation" is used only by the * and / operators. The term you're dividing by 400 can't be incorrect or you'd have a type mismatch error before that, so it has to be P.budget after all.


Which was checked to be 10000 or 40000 AGES ago, and reported on. Hell, I even checked the other values.

I've got the latest version of BYOND, and NO reports are shown, debug mode on or off.
In response to RedlineM203
RedlineM203 wrote:
I already said what my coding style was, and : was the only thing that worked at time of useage. It was good enough at the time, and it still is now, though you 'crap' cleaners are forcing me out of it.

Abuse of language elements isn't a style; it's a flaw. There are lots of different ways to have a unique code style and still write solid code. Favoring a perfectly legitimate usage over another perfectly legitimate usage, now that's a style.

By definition, using the wrong operator and writing brittle code is never "good enough". It's not that : is the only thing that worked for you; it's that you didn't bother doing the very minimal prep for . to work.

Lummox JR wrote:
In newer versions of BYOND, "undefined operation" and "type mismatch" reports the types involved. However I can throw you a bone here in that "undefined operation" is used only by the * and / operators. The term you're dividing by 400 can't be incorrect or you'd have a type mismatch error before that, so it has to be P.budget after all.

Which was checked to be 10000 or 40000 AGES ago, and reported on. Hell, I even checked the other values.

Can you verify that those are actually numbers and not, say, text? If one of the values is "40000" for example, not 40000, BYOND is gonna complain about it.

I've got the latest version of BYOND, and NO reports are shown, debug mode on or off.

You have the latest public release. The updated runtime error messages appear in BYOND 4.0. I said "newer versions" meaning newer than the one you had, though I don't think I clarified that properly. Basically I was just pointing out that in the future when you compile, you won't have that ambiguity anymore.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Abuse of language elements isn't a style; it's a flaw. There are lots of different ways to have a unique code style and still write solid code. Favoring a perfectly legitimate usage over another perfectly legitimate usage, now that's a style.
By definition, using the wrong operator and writing brittle code is never "good enough". It's not that : is the only thing that worked for you; it's that you didn't bother doing the very minimal prep for . to work.

But still, it works how I want it to, and so it was good enough. Leave it at that, because it works, if improperly. Nobody else is going to see it. Just me.

You have the latest public release. The updated runtime error messages appear in BYOND 4.0. I said "newer versions" meaning newer than the one you had, though I don't think I clarified that properly. Basically I was just pointing out that in the future when you compile, you won't have that ambiguity anymore.

Can't blame me for being ignorant there. You never mentioned BYOND 4.0.

Can you verify that those are actually numbers and not, say, text? If one of the values is "40000" for example, not 40000, BYOND is gonna complain about it.

I went and did that, and damn, it was text. Well, I dunno. I just added an extra part to the code (not the part where the extract should be) to see if it was or wasn't a number. I think my budget changing verb allowed any values at the time I tried it out, right before I added "as num" to get rid of that. I guess it was changed to numbers in text, and then I forgot that part of the code wasn't polished enough. (I use savefiles for the system, and it was hanging there for maybe 7 days)
In response to RedlineM203
RedlineM203 wrote:
Lummox JR wrote:
Abuse of language elements isn't a style; it's a flaw. There are lots of different ways to have a unique code style and still write solid code. Favoring a perfectly legitimate usage over another perfectly legitimate usage, now that's a style.
By definition, using the wrong operator and writing brittle code is never "good enough". It's not that : is the only thing that worked for you; it's that you didn't bother doing the very minimal prep for . to work.

But still, it works how I want it to, and so it was good enough. Leave it at that, because it works, if improperly. Nobody else is going to see it. Just me.

This is the Code Problems forum. When you post code here, we tell you what problems you have. If you don't want people to point out problems in your code, then you don't post your code here.
In response to Garthor
Garthor wrote:
This is the Code Problems forum. When you post code here, we tell you what problems you have. If you don't want people to point out problems in your code, then you don't post your code here.

I'll take all my code to Classified Ads then, see how you like it. <_<