ID:2141766
 
(See the best response by Nadrew.)
Code:
var/a=roll(1,6)
var/a=roll(1d6)


proc/Pokeball()
var/B=roll(1d20)
if(1<=B<10)
world<< "Get Pokeball"
if(10<=B<16)
world<< "Get Greatball"
if(16<=B<19)
world<< "Get Ultraball"
if(19<=B)
world<< "Get Masterball"


Problem description:

Which of these do I use, both are giving errors and i need to narrow down the problem
The problem is you're not formatting your if() statements properly. You also have everything after var/B indented too far.

// or
if(variable >= value || other_variable <= value)
// and
if(variable >= value && other_variable <= value)

You should also be containing those variables and procs within /mob and not globally.

And better yet, you can use prob() for probability rolls instead of dice rolls.
Ok, i think i got the dice thing down but i still have errors preventing me from seeing
Can I use 'goto' to proc something outside the verb its in?
Can I use 'goto' to proc something outside the verb its in?

No.
Goto is a tricky beast. That you're asking that question says you shouldn't be using it yet.

In low-level machine code, goto is everywhere--and it's often used to hop from one function to another, as long as the programmer or compiler knows that the other function will do the same sorts of cleanup as the first one. But in a structured language this is obviously unsafe, which is why pretty much no language since BASIC has been overly friendly to this kind of jump.

In modern languages that support goto, the destination is limited to the same function the statement is in. BYOND follows the same pattern for the same reasons. If we did have a cross-proc goto, it would involve tearing down the current list of arguments and local vars, and then creating a new one with blank values to match the new proc. That's way too much work to put into supporting something that's ill-advised at the best of times.

The key to using goto is knowing when not to use it, and that's like 99% of cases.
So in other words, my verb is going to be massive in length and hard to rectify should any problems arise
In response to Demonheroexcell
Demonheroexcell wrote:
So in other words, my verb is going to be massive in length and hard to rectify should any problems arise

The length depends a lot on what you're doing and what logic you use to achieve it; in most cases massive length can be avoided.

But misusing goto will indeed lead to code that's hard to fix if any problems come up. It's a very powerful tool with a very limited set of uses. Typically there's a way to handle the logic that's far more elegant.
In response to Demonheroexcell
Although "goto" isn't appropriate for jumping between procs, you can still... call procs, pass arguments, use return values. I can't say much more since I don't know what the verb is or how you're trying to use your procs.

As for the Pokeball() proc, it might be appropriate to use the "in-to" operator:
if(B in 1 to 9) 
// pokeball
else if(B in 10 to 15)
// greatball
// etc.

Or even switch():
switch(B)
if(1 to 9)
// pokeball
if(10 to 15)
// greatball
// etc.

mob/verb/Item()
set category = "ITEM"
var/A=roll(ndice=1, 6)
if(A=1)
var/B=roll(ndice=1,20)
if(B >= 1 && B <= 9)
world<< "Get Pokeball"
if(B >= 10 && B <= 15)
world<< "Get Greatball"
if(B >= 16 && B <= 18)
world<< "Get Ultraball"
if(B >= 19)
world<< "Get Masterball"
if(A=2)
var/C=roll(ndice=1, 20)
if(C >= 1 && C <= 9)
world<< "Get Potion"
if(C >= 10 && C <= 15)
world<< "Get Super Potion"
if(C >= 16 && C <= 18)
var/D=roll(ndice=1,2)
if(D = 1)
world<< "Get Hyper Potion"
if(D = 2)
world<< "Get Revive"
if(C >= 19)
var/E=roll(ndice=1,3)
if(E=1)
world<< "Get Max Potion"
if(E=2)
world<< "Get Full Restore"
if(E=3)
world<< "Get Max Revive"


Verbs.dm:3:warning: A: variable defined but not used
Verbs.dm:21:warning: D: variable defined but not used
Verbs.dm:27:warning: E: variable defined but not used
Exactly what it says, you're defining the variables and never using them anywhere. You're only using B and C. The reason they aren't being considered used is that you're using "=" in the if() and not "==", one sets a value, the other compares it.
Ohhhhh, thank you so much

Now i have
'arglist: arglist() or named arguments cannot be used here'
on the dice rolls
Best response
Like I said earlier though, you could vastly simplify the whole process using a combination of pick(), and prob(), it would also make it a whole lot easier to expand on in the future.

if(prob(70)) // 70% chance
var/picked_loot = pick("Pokeball",prob(50); "Greatball",prob(30); "Ultraball", prob(10); "Masterball")

else if(prob(40)) // If the 70% fails, there'll be a 40% chance of this happening
// Do stuff here.

else // If the 70% and 40% both fail, this'll be reached.
// Most likely not finding anything goes here.


That pick() will select a random item from its arguments based on the prob() usage, there'll be a 10% chance of finding a master ball, 30% of finding an ultra ball, 50% of a greatball, and if all of those fail, a regular Pokeball.
In response to Demonheroexcell
Demonheroexcell wrote:
'arglist: arglist() or named arguments cannot be used here'
on the dice rolls

You can't use named arguments with roll().
// allowed
roll(1, 3)

// not allowed
roll(ndice = 1, 3)