Page 6 of 6 FirstFirst ... 456
Results 51 to 60 of 60

Thread: Schripting Advice (Tutorial)

  1. #51

    Default

    I agree with Todesengel, mostly, except there are standards and they are considered to be the true way.
    Also there is the Language limitation it self, which would be the ultimate true way.
    And there is the late code vs the early code in game, which shows where the developers did aim towards.
    There is the Zeitgeist of the times when the game was developed and there is the Zeitgeist of now,
    which I would like to think that it has learned a few things and improved upon them.

    @Major A
    I would have to add a entire new page to the Document to accommodate some more details how to do good
    commenting on certain passages of code, and I do not have that much content to really justify that new page.
    After all I am trying to keep it short, but informative and useful, so I have decided against adding more about
    the subject of comments at this time.

  2. #52

    Post

    I have updated the document, fixed a few typos, a few minor errors in code and added a new chapter for waitexec and waitthread.
    Last edited by chrissstrahl; September 15th, 2019 at 06:45 PM.

  3. #53
    Senior Member Major A's Avatar
    Join Date
    Aug 2014
    Location
    Indiana, USA
    Posts
    110

    Default

    NICE! will read soon, but getting it now.

    ASUS P8B75-M * Quadcore 3.1GHz * 32GB ram * GT740 4GB video * Logitech USB Marble Mouse=Trackball * System - ArchLinux-EndeavourOS, KDE Plasma Desktop * Triple monitor

  4. #54
    Purple Developer Purple Elephant1au's Avatar
    Join Date
    Feb 2012
    Location
    Australia
    Posts
    1,269

    Default

    Great work on this guide.
    I have added a few comments to sections, most are just typos that need fixing, others are my opinions on certain parts, but I thought it was a well written guide and should come in handy for new developers ( and some old ones ).
    Attached Files Attached Files

    Purple's Playground
    OBJ :
    103.29.85.127:12203
    xfire: purpleelephant1au
    email: purpleelephant1au@gmail.com
    skydrive: PurpleElephantSkydrive




  5. #55

    Default

    Zones - I have added your suggestion, but I keep using zones, because it makes the tutorial easier to digest, everyone knows what a Zone is.
    Variable scope might be more accurate but I don't want people to have their brain on fire before they did even start coding.

    On the main function subject, I have changed my sentence a little bit, because I think it was in fact misleading.
    As far as I remember if you exec a file without a explicit function name it will execute until it hits "end", regardless the name of the functions or labels (does not have to be named main). This would mean it executes all code no matter what until the first end(or end of file), regardless if you have any function at all in the file.
    My advice would still be to place a main function if you plan on executing files without direct function call.

    Good catch on water rock fire.

    NO LOCAL STRINGS - I added where to find the file :P

    NAMING - Well, yes, I was thinking a lot about this and I figured it would be better to get a concept of datatypes, this is why I would rather have people including the type in the name if they are new it will help.

    Did you know Germans use a comma instead of a period :P

    Thanks, it seems I have missed many typos, and input is alyways good.

    I have added a note to type casting.
    Attached Files Attached Files

  6. #56
    Developer RyBack's Avatar
    Join Date
    Apr 2014
    Location
    In Front of the screen
    Posts
    1,603

    Default

    Quote Originally Posted by chrissstrahl View Post
    NAMING - Well, yes, I was thinking a lot about this and I figured it would be better to get a concept of datatypes, this is why I would rather have people including the type in the name if they are new it will help.
    local.string_missionText -> local.sMissionText
    level.integer_missionStatus -> level.iMissionStatus

    that's better

  7. #57

    Default

    Theres one thing you have missed and is very usefull, is you can get a thread when you use like this local.thread = local so you can end a thread is coming from another place.

  8. #58

    Default

    @RayBack - I think you made a good suggestion there. This could work as a compromise.
    @DoubleKill - Yes, you are right, in fact I discord something today I am not yet sure how it works that belongs into that category.

    Not sure what end does here, any suggestions ?
    PHP Code:
    thread playwaitface
    local
    .waitfacethread parm.previousthread
    wait 3
    local
    .waitfacethread end 

  9. #59

    Default

    It kills the ScriptThread listener (the thread) stored in local.waitfacethread. Remove or delete would do the same thing. It's like doing:


    local end


    for the current thread, but it's pointless as end on its own does the same thing. But in your example it can be very useful.

    Also, I don't think I saw group scope/thread groups explained anywhere? This could be useful too . It also ties in with what you've already explained. For example, waitexec doesn't necessarily run all the code, just the code in the starting thread group.

    E.g. if you changed your example to:


    startLoop:
    //this simply starts a loop in a diferent thread
    $player thread someLoop
    end

    someLoop:
    //this loop runs forever
    while( 1 )
    {
    waitframe
    }
    end


    it would finish with waitexec because defining the self object for a new thread (in this case, using the player entity) creates a new thread group for the someLoop function.

    If you are passing the self object that the previous thread has, you don't need to explicitly include it in the next thread call:


    main:
    $player thread DoStuff1
    end

    DoStuff1:
    self.done_stuff1 = 1
    thread DoStuff2
    end

    DoStuff2:
    self.done_stuff2 = 1
    end


    It will pass the self object of the current thread group into all other threads unless you redefine the self object again. Essentially, threads belong to the same thread group as long as they are in the same file and self is implicitly equal to the parent thread.

    And in regards to variables in general, I like to view them as just adding properties to an object (so, essentially the scripting language doesn't really have 'true' variables). local, level, group and game are all just a type of entity/object that you add properties to, just like player objects. local is always the ScriptThread object its called in, group is the ScriptClass object, and so on... Which means $player.something is pretty much the same as local.something or group.something etc... They are all properties defined on a specific object/entity. Obviously they aren't the same type of entity/listener/object, but it's an easy way to view it. Which leads me onto the question of whether entity types should be at least noted? E.g. Entity vs SimpleArchivedEntity (players vs player starts, for example). One eats into the server entity limit and the other doesn't. 'maxentities' can be changed to increase the server entity limit btw.

    Oh, and quick question, with the table on the previous page:

    exec myFolder/myFile.scr::myFunction | thread myFolder/myFile.scr
    I assume you mean exec myFolder/myFile.scr ?
    Last edited by 1337Smithy; September 20th, 2019 at 01:24 AM.

  10. #60

    Default

    Yes, good catch with exec and thread!

    It would take a few tests and some time to text and follow up on the waitexec stuff you just posted to get the full scope of it, how ever, I am already pretty busy and can't put the effort in this detail right now, maybe if I don't forget it on the next big update
    Attached Files Attached Files

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •