Some questions about DM

Oct 29 2014, 11:42 am

goto is an immediate branch to another section of code (in the same proc, that is), breaking any loops and scopes that the current position in code reading would have been nested into. While in this case it's not a very good idea to do so, it does have its applications where a conditional statement seems silly to use for.

This is an example of using goto conditional scopes are absent.

proc/SomeScript()
    var/running = TRUE
    world << "Beginning script."
    label_start
    world << "Some section of code."
    sleep(100)
    if (!Game.clients.len) running = FALSE
    if (running) goto label_start
    world << "Ending script."

goto is a powerful command, giving the user the power to transfer code flow to anywhere he or she would like. The deadliness of goto on the user, however, is that it can warrant hard-to-read code, and yield infinite loops which can take ages to debug. This is called "spaghetti code." Because scopes are not usually present when using goto, trying to figure out how things work without encapsulation adds extra frustration.

But, since goto is a primitive, simple yet effective command, it does have very good purposes. It holds true that if you know what you are doing, goto is a programmer's best friend. The safe programmer would most likely not use it, though. goto is perfect for creating loops of your own without ever needing to use for(), while(), do(), etc.. Everything can be handled by branching code to labels using goto.

loops like for() do not exist in bytecode. Only goto. That being said, using goto is a lot like working with assembly, and translates proportionally to bytecode.

Example of using a makeshift for() loop, but it would make more sense to use for() instead.

proc/LoopExample()
    

    var/i = 0
    var/j = 0
    
    outer_loop
    i++
    if (i >= 10) goto exit
    j=0
    
    inner_loop
    j++
    if (j >= 10) goto outer_loop

    world       << "[i],[j]"
    goto        inner_loop
    
    exit
    world << i*j
    
client/New()
    ..()
    LoopExample()

Oct 29 2014, 11:44 am (Edited on Oct 29 2014, 11:51 am)

In response to Multiverse7

Kaiochao

Ideally, the finished product should be free of runtime errors; and things that fail silently are doing so according to the design, not from lack of robustness.

However, most BYOND games never become finished products, so clearly it doesn't matter how many runtime errors you get, since the plan is to continue developing/maintaining/fixing the code indefinitely, (or until you give up).

edit: It's times like these when I miss the branching thread view. This forum is still capable of it ("In response to [OP] (#[reply number])" and it would make "derailing" virtually impossible. Not necessarily that this conversation is being derailed, but because there are multiple conversations going on at once.

Oct 29 2014, 12:23 pm
Laser50	Oh, no, I was very much aware that we have a garbage collector. Except it doesn't really do it's job that well. And even if it does, it could be improved.

Oct 29 2014, 12:35 pm In response to Mr_Goober
Multiverse7	If you are writing in a language with very minimal looping abilities, then you have an excuse to use `goto`, but in DM, why would you ever actually need to use it? What can `goto` do that `for() && while() && do while() && break && continue` can't?

Oct 29 2014, 12:35 pm (Edited on Oct 29 2014, 12:42 pm)

In response to Kaiochao

Multiverse7

Kaiochao wrote:

Ideally, the finished product should be free of runtime errors; and things that fail silently are doing so according to the design, not from lack of robustness.

However, most BYOND games never become finished products, so clearly it doesn't matter how many runtime errors you get, since the plan is to continue developing/maintaining/fixing the code indefinitely, (or until you give up).

Don't be so negative. BYOND needs progressive ideas, not discouraging rants. Once I consider a product to be finished, I will make it impossible for the errors to actually show up, by hiding the default output control and making good use of client.control_freak.

edit: It's times like these when I miss the branching thread view. This forum is still capable of it ("In response to [OP] (#[reply number])" and it would make "derailing" virtually impossible. Not necessarily that this conversation is being derailed, but because there are multiple conversations going on at once.

There's no point in complaining now. This forum is going to be reduced, and Reddit has a basic branching system going on anyway.

Oct 29 2014, 1:01 pm

In response to Multiverse7

Kaiochao

Multiverse7 wrote:

Don't be so negative. BYOND needs progressive ideas, not discouraging rants.

OK.

Once I consider a product to be finished, I will make it impossible for the errors to actually show up, by hiding the default output control and making good use of client.control_freak.

In other words, you finish a product by hiding all the error messages, but still leave in the actual errors. This is what happens when you "give up" (as I put it before), or decide that the remaining bugs (yes, they're bugs) are not worth the effort to fix (which is fine).

The point I was making is that you can easily avoid runtime errors from using the colon operator by not using the colon operator. I'm not saying the finished product should be absolutely bug-free.

There's no point in complaining now. This forum is going to be reduced, and Reddit has a basic branching system going on anyway.

- Complaining doesn't need to lead anywhere.
- The extent of the website reduction is still speculative.
- The relevant subreddits aren't very active yet. :(

Oct 29 2014, 1:31 pm

In response to Kaiochao

Multiverse7

Kaiochao wrote:

In other words, you finish a product by hiding all the error messages, but still leave in the actual errors. This is what happens when you "give up" (as I put it before), or decide that the remaining bugs (yes, they're bugs) are not worth the effort to fix (which is fine).

You can probably find bugs in every software product ever released, but I wouldn't say that the developers of those products "gave up".

The point I was making is that you can easily avoid runtime errors from using the colon operator by not using the colon operator. I'm not saying the finished product should be absolutely bug-free.

I will avoid errors by using the : operator correctly, just like I would with any other feature of the language that might potentially generate errors. You seem to be suggesting that the : operator is relatively more prone to producing errors than most other features, but I don't think that's the case.

- Complaining doesn't need to lead anywhere.

fair enough

- The extent of the website reduction is still speculative.

Trying to predict the future is almost always speculative.

- The relevant subreddits aren't very active yet. :(

They need some promotion. I have some interesting ideas...

Oct 30 2014, 6:28 am
Victorqr	What do you mean asynchronous procs, wouldn't that cause the system to crash? I didn't know istype was bad for performance. Also in Byond is there some kind of main() or a game loop, like a proc that runs when the game starts? and lastly is it good practice for a single player game to call the game loop at Login()?

Oct 30 2014, 9:38 am

In response to Victorqr

Laser50

Victorqr wrote:

What do you mean asynchronous procs, wouldn't that cause the system to crash?
I didn't know istype was bad for performance.
Also in Byond is there some kind of main() or a game loop, like a proc that runs when the game starts?
and lastly is it good practice for a single player game to call the game loop at Login()?

Asynchronous, or rather, the BYOND way is making a loop run in a way that it gives plenty of room in-between for other things to run. If I recall that right.

And no, there is no main() loop. You'd have to make that yourself by making a loop in world/new() or elsewhere.

And the 3rd.. It depends on what the loop is for.

Nov 2 2014, 1:11 pm

FKI

GatewayRa wrote:

Honestly I think the most destructive thing a person typically does on BYOND isn't relevant to object creation/deletion, instead it's the tallying of asynchronous operations trying to run at the same time, through spawn() or waitfor = 0. I see it happen a lot by how people handle their NPCS and whenever somebody integrates Forum Account's movement libraries.

Would you say it's possible to build a large, fast game without the use of spawn() and the waitfor setting? Could it hold a fair amount (100 is fair, IMO) of players and run optimally as well?

What I've been putting to heavy use lately is Stephen's Event Schedule and not using spawn() at all. I still do use waitfor though. I'm interested in knowing any solutions you may have where the topic of spawn() and waitfor is concerned (in other words, how should you go about building a large, active game without holding up the queue).

What would you suggest, if anything?

Nov 16 2014, 3:49 am

Victorqr

Guys when since vars are void pointers when I do this
var a,b,c;
c=a+b
what happens is a+b is evaluated and then that value is assigned to c right??

because I was testing something with python whose variables are references and instead of assigning the value of a+b to c it created a new variable with a+b value and changed c to reference the new object

Tested that with a loop on python and my program used 1.5 gb RAM.......

Nov 16 2014, 10:15 am
Victorqr	Thank god they're passed by value! Yeah I hate it too, university makes me study it...

Nov 28 2014, 4:31 pm (Edited on Nov 28 2014, 4:40 pm)

In response to Doohl

Toadfish

Doohl wrote:

My biggest tip is to recycle objects. Probably one of the most CPU intensive things you can do is construct and destruct objects. If you have an instance where you are creating and destroying a lot of them, simply create a queue where objects go when they're not being used.

In and of itself this should actually not be a big deal. The process of creating a new object in itself is mostly a matter of memory allocation. The issue is if the object's immediate initialization process (what happens in New()) is CPU-intensive, so if you have an intensive object like that it's often desirable to recycle it. However, if you recycle too many objects instead of freeing memory when you don't need it, your program will get bogged down.

Recycling objects also leads to memory leaks, because often you will lose track of what pointers you have pointing to the object and end up having a phantom object just wandering in memory with no way to access it. Also, you will have to make sure every recyclable object's processes "stop" once you put it in queue, so they won't be running in the background and wasting system resources - not an easy thing to pay attention to.

In general I would say it's a good idea to *not* recycle objects that don't take a lot of processing power to initialize.