Reworking.

ID:1267895
 
May 19 2013, 1:51 am
Well, I would say anyone who knows me and is familiar with the demos/libraries I have created also know the demos/libraries aren't worth the bytes they consist of. This is a point I would say I am not ashamed of, beings each demo was made while I was learning (and somewhat document my progress), the simple approach permits easy analysis, and if anything; they show a good example of poor practice.

I digress. This post is a simple one. As anyone would, when I came back to BYOND after my short lived hiatus, I looked over all my demos simply curious as to how they looked.

Upon the review, I decided to rework my demo Ease Drop (noting that it should be renamed but wont). I re-scripted the entire system and basically made it completely better.

If memory serves me, this is how the original looked:
mob/verb/Say(t as text)
 view(src)<<"[src] says: [t]"
 for(var/mob/m in world)
  if(m.hearer==1)
   m<<"[src] says to view: [t]"


while, the rework looks like this:

mob/verb/say(msg as text)
    var/VIEW=view(usr)
    VIEW<<"[src] says: [msg]"
    adminListeners-VIEW<<"[src] says to view: [msg]"


(I still somewhat wonder if even the new system could be improved upon)

I'm not sure about the rest of BYOND, but over the years my belief has evolved into one where the more loops you have the more times you should be slapped. Of course, not all loops can be avoided. However, if there is a means to do something without a loop, do it.

Now, the Ease Drop demo was one, and now I've reworked another entirely(Button Combos). While there was no major programming practice issues with Button Combos, it did lack quality and was very out-dated (made before BYOND beta, so the script document was used for macros).

I must admit that I'm enjoying the re-creation of old-creations. I'm thinking one day each of the many demos I've created will be re-scripted. However, it took "years" for me to start reworking so who knows?

As for now, I figure the two are a good start. I would like to suggest that everyone on BYOND take a look at any demo/library they've made two years ago or later. If you are anything like me(which you probably aren't), then you have learned much more about the language and good practice, and should apply them to your old releases. It is essential to remember that all new comers and even some who have been here a little use the demos presented to learn the language, and even mimic the techniques.

In closing, I'd like to say that I apologize for the rant. I just felt like making a post ;p.
May 19 2013, 7:35 am
Yut Put wrote:
> mob/verb/say(msg as text)
>     var/VIEW=ohearers(src,world.view)
>     VIEW<<"[src] says: [msg]"
>     adminListeners-VIEW<<"[src] says to view: [msg]"
>

anyway, if you can't program something like this, then you probably just need to learn how to program. this the is kind of demo nobody would use unless they were either severely mentally impaired or simply had a very poor understanding of DM

Or.. that wants to learn through Libraries.
May 19 2013, 7:50 am
It's not ease drop, it's eavesdrop.
May 19 2013, 5:28 pm
The concept isn't simply say, but an admin version of say. Anyone can know that view()<<"WORDS" means to display text to view, but to grasp that view() actually returns a list is another matter. If someone is learning like I learned, they read very little and depend on demos to help them understand things. They learn through constructing and deconstructing scripts. Also, the fact remains that there are a thousand easy-to-make demos out there. Just because it's a demo does not mean it needs to be complex.

I don't know, just the whole conversation is irritating.

Also, Neimo, I know it's eavesdrop :p. It clearly state that it needs to be renamed but won't. It's not going to be re-named because over 400 people have downloaded the old crappy version and I would rather them be able to update it if they were silly enough to use it.
May 21 2013, 6:05 pm
MAX & anything final in java are all caps by convention. :P
So it is commonly accepted.
May 22 2013, 12:22 am
Well, anything static in Java, actually. Final variables aren't inherently capitalised by convention, static are https://github.com/hibernate/hibernate-orm/blob/master/ hibernate-entitymanager/src/main/java/org/hibernate/jpa/spi/ BaseQueryImpl.java

Fireking's concern here I guess, is VIEW isn't a static value, it's actually very much a list of dynamic contents. I would agree, it does look a little odd, particularly in what's learning material.
May 25 2013, 11:56 pm
It seems as though the post has fallen victim to judgements related to languages that have nothing to do with DM :p. Other than pet peeves, there is utterly nothing wrong with the demo and the post seems to have influenced a penis measuring contest.
May 26 2013, 5:18 am
Well, the problem is basically a matter of educational material.

http://en.wikipedia.org/wiki/ Coding_conventions#Software_maintenance

http://en.wikipedia.org/wiki/Coding_conventions#Quality

Basically, we'd rather not have odd coding style practices work their way into Developer Help, which means being duly critical of released learning materials. It doesn't help the one learning, and does us (collectively) no favours either.
May 26 2013, 5:23 am
I suppose I agree with you on that point.
May 26 2013, 5:33 am
I will say in your defence, that your specific example isn't "bad" particularly. I can obviously see where VIEW is assigned, so I know just what exactly it is, that isn't not some hardcoded list etc.

The issue would be if that practice were used in a longer procedure, because by sight reading you come across where VIEW is used and go "View? So ... how big is this view, what does it encompass? Why does it appear to be some fixed list?". Where-as it's actually hearers, not view, and across the entire world. In your example it was view(), so the naming did make a bit more sense.
Jun 6 2013, 10:35 am
doing it this way works perfectly... but how would you get it so that when logging out with the toggle on, it stays on after relogging?
Jun 16 2013, 4:53 am
In response to Shadow_Galaxy
Well Shadow, that's actually a good point I overlooked! I'm not sure if it's a BYOND bug, but I noticed awhile ago that if an atom is in a list then deleted it creates a null slot instead of removing the item from the list.

To answer your question though; it could best be done by creating a separate list with the keys stored. When the individual logs in the key list is checked to determine if they should be added to the listeners list.

That or, to not allow mob deletion upon logout :p..
Sep 17 2013, 7:51 pm
 
atom/proc/Angle_Dist(Ang1,Ang2,buffer)
    var angle = (abs(Ang1 - Ang2))%360
    if(angle > 180)
        angle = 360 - angle
    if(angle<=buffer)
        .=1
    ..()