ID:2113648
 
(See the best response by Nadrew.)
Problem description:
my goto statements don't activate after a spawn proc...anyone knows why?

Code:
struggle2
spawn(30)
src.Owner<<"4.5"
goto struggle2

mob/Login()
start
spawn(10)
src << "tick"
goto start

Works for me.
In response to Kaiochao
it used to work for me before, but i copied a block of code (practically the same thing except for changed variable names and such for a similar purpose) and it stopped working. It had me very confused when i finally found the error and the source segment was working but not that one.
Best response
You should probably be avoiding the usage of goto in favor of loops anyways, in DM the usage of goto is rarely ever needed and only leads to hard-to-follow code.
v_v, I remember seeing that somewhere else before, I suppose I'll just re-code it differently.
Spawns should be considered separate procs. Using goto to leave the spawned proc is the kind of voodoo magic that should be avoided
In response to MrStonedOne
Okay, looks like all replies point to abandoning that method, thanks for taking your time to help me out.
Using goto to leave the spawned proc is the kind of voodoo magic that should be avoided

Spawns themselves are voodoo magic that should be avoided... where possible.

The neat thing about why this works: @Everybody but MSO (who knows how this works)

Imagine a book. You put a bookmark on page 47. I put a bookmark on page 51. We both decide to read the book at the same time, so I buy a second copy and put a bookmark on page 47 and then hand it to you. Obviously, you have no problems reading the book from the point that you were and the story makes sense. But you move forward to page 98 and move your bookmark to that point. I then pick up your book. Regardless of which book is which, page 51 is still there and I can continue. The bookmark is simply a marker of place where we can pick up.

That's all goto is. It is a bookmark. Your progress in the book is not the bookmark. It is the intangible concept of how far you are in the book. The bookmark itself is only a reminder of where you were so that you can resume reading later. Reading past the bookmark doesn't mean that the page or bookmark isn't there anymore. You can always go back to that point because your progress through the book is only linear because you elect to think of it that way.

Now imagine a cookbook. There is no obligation to go through the cookbook recipe by recipe in order. You can jump around anywhere you want.

A function can be thought of in two ways: As a very organized choose your own adventure novel, with the ending changing based on conditional branches, or as a cookbook: A loose set of instructions strung together only by their overall subject.

Code is best understood when organized methodically, and therefore the cookbook scheme has fallen out of popularity as the computing constraints that once made that methodology prominent have become no more.

Even so, there very much are cases where gotos can be a highly convenient way to organize code at the cost of readability. Just don't let any programming snobs hear you say that.

Also, there's the fact that literally every branching pattern that has replaced the use of goto in the modern is basically just a goto hidden behind syntactic sugar. It's worthless knowledge though unless you are into VM design.

A proc's code only exists in one place in memory. As such, when a proc is running, it's really just the contents of: The entry point, the execution position, the arguments, the stack, and the local memory. The code of the proc is independent of the current state of the proc amid execution. So the goto is syntactically valid, but questionable.
In response to Ter13
sorry for the wait, i'll try to avoid this from now on, i only wish i knew this before my project reached the scale its at right now
is 'continue' just as sinful or can i use it as a safe alternative?
In response to Cheesy pants
Cheesy pants wrote:
is 'continue' just as sinful or can i use it as a safe alternative?

The continue and break keywords are part of normal loop code, so they're the best choices to use in a loop. If you're not in a loop of course, neither of them make any sense.

Goto isn't inherently evil, just easy to abuse. In the old days of programming, everybody used goto and it resulted in lots and lots of spaghetti logic and impossible-to-maintain code. As newer languages appeared that made it easier to avoid using goto, it fell out of favor for that reason. But goto is still highly useful, and its absence from several high-profile languages is regrettable; there are still situations where it's the very best tool for the job.

In the case of this thread, goto is really not the right choice; this is a loop that can be accomplished a different way.
ok, thank you for the explanation
What you are really trying to accomplish is best done by a spawned while loop.

spawn()
while(sleep(30)) //I recommend also adding a condition that will end the loop if necessary
(do something here)


The loop as provided will proceed forever until the world restarts. Putting an end condition into the while() that checks some variable or function that can tell the loop to end is probably wise, since adding neverending loops like this can be dangerous.

When doing this it can also be wise to set usr = null and src = null so that your loop will not prevent garbage collection, though that will also make the loop outlast the atom that created it, which can be undesirable.
In response to Clusterfack
I don't think while(sleep(30)) is a safe construct, because sleep() doesn't return a value. The condition in the while() has to be true for it to loop.

What you would want instead for an infinite loop would be:

spawn()
while(1)
...
sleep(30)
I did something similar to what you have here, but used estimate for the condition from the world clock to run the loop, and then apply the real condition in an if, applying a break if its true, its like -

while(ticks<value)
if(condition)
break
sleep(10)


Is that okay?
That would work fine. However, you could save a line and do this:

while(!condition && ticks < value)
...
sleep(10)

You don't have to combine things in the while(). It's usually cleaner, but sometimes I'll separate conditions like you did when I think it improves clarity.
Thanks for the tips, this really helped me with some of my long-lived problems