User Tag List

Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 31 to 40 of 42

Thread: ZScript additions for 2.51.

  1. #31
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    What are you crazy?! Everyone knows the correct color for an icon is lime green.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  2. #32
    How many licks to get to the center Chris Miller's Avatar
    Join Date
    Mar 2001
    Location
    of a Tootsie Roll Pop?
    Age
    46
    Posts
    3,510
    Mentioned
    94 Post(s)
    Tagged
    4 Thread(s)
    vBActivity - Stats
    Points
    5,662
    Level
    23
    vBActivity - Bars
    Lv. Percent
    37.91%
    Ecru is where it's at.

    Download Lands of Serenity today! You will be knocked comatose by its sheer awesomeness.
    The Titan's Quest, best played in the bathroom as the excitement can be somewhat...overwhelming.





    Official AGN Discord Channel

    Official ZC Dev Discord Channel

  3. #33
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    It's fine. At least people are posting more :) I guess I'm just lucky I didn't post a plan to change the color of the ZC icon.
    Rats, when I edited this to quote Gleeok, it ate my response.

    I believe it was: The sad, or funny thing, is that we are likely to be forced to change the icon for the GPL releases.

    I know I had something else in that response, but now I've forgotten what it was.

    Quote Originally Posted by Gleeok
    So, what am I getting at? Well, my main points...

    (1) -While making a quest I would of preferred to store all the scripts inside the quest file so long as it would be as convenient recompiling as just the "normal" standard way of writing "import myshiz.h" once and then just clicking the big red button every time I update it.

    (2) -As a previous avid scripter I would of preferred if the compiler was separate from ZQuest so I wouldn't have to keep ZQuest open all the time to tweak scripts and could just do it in ZC. This is the main reason I moved on to c++, because iteration time in ZC with scripting is damn slow. With c++ it takes 2 seconds to recompile, load assets, open an OpenGL window, etc.; with ZC you have to practice to get good at it, but then it still takes like 30 seconds.

    (3) -When releasing a quest I would prefer to have the option of storing an unmodified text copy in the quest file or not. While 1 MB (arguments sake) is not that much, a quest is not designed to have people open them up and extract things or recompile scripts.

    (4) PS: Why is everyone so keen on arguing with DD? It's a valid point. He probably could of wrote the code in the time it took to respond here so many times.

    (5) PPS: For the record, the angelscript system would do (would of done) all of the above.
    (numbering, mine)

    For the sake of sanity, I'll respond to each paragraph, and point, first numbering them.

    (1) I don't disagree with the idea, or the premise; merely with the implementation replacing the present import method. I would like to see this added, as a new directive. The idea of breaking how it now works, is not pretty. If the system somehow supported how it works now, and did this new stuff, that would also work, and I doubt anyone would complain, but look at the reactions, which are effectively as I predicted thus far.

    That said, this is not the only way of handling storing scripts with the quest, if archival preservation is the most important factor. If header organisation is the key element, I think that an includes path and standard C include directives would work better. That way, the user can determine what headers each script would use, and those would be processed when that script is processed; which would require rewriting the compiler to do passes per script, and likely cause havoc with how global declarations are handled.

    I've been down that road.

    (2) Oh yes. That would be lovely, but as yet, it does not exist. A script debugger and a complete set of IDE kit would be fantastic. I that wish you could find the IDE that you made years ago, so that we could work with it.

    (3) I agree. If we implement this in any regard, it needs to be an option, even if it is the default option.

    (4) Well, when people are more keen on arguing that something is unwise, a bad idea, or are passionate about their dislike of it, than on seeing it implemented; then it is an indication that the idea needs revision, prior to implementation.

    (5) True, however as I understand, the AS would be rn through a JIT compiler, and would not need the user to precompile it, just to test it, or check for errors. Presumably, it would have also included a more robust dev environment, to find syntactical (or logical, or other) issues, and correct them prior to running a quest. This is vastly different from the compiler halting from one bad keystroke, and needing to manually load files into the buffer on every fix-- an action that takes longer for the user to perform than the compiling itself.

    In the end, it comes down to breaking script compatibility, as far as I'm concerned. That must be avoided at all costs. If we can avoid that, and we can implement a system that allows reading the files externally, I don;t care how they are embedded. I would however, worry about the number of scripts involved. How many buffers are you going to allocate? What if the user has 2,500 scripts? 500 header files? At present, that is not an issue. They can compile as many as they wish, as long as they all fit into the main buffer string at the end of the day.

    Moreover, if you create a slot system, with one slot per file or one slot per script, then you artificially limit the number of single files involved. Flidd, my own engine uses hundreds of separate files. Because the packfile needs to know in advance how many slots are being saved, or read, a dynamic system isn't really feasible, and a static system would need to allocate a tremendous number of buffers, and could still fall short and be unable to load existing materials.

    Then, you need some kind of datatype association. Using a filename extension is not the right way to handle this. I , and several other users do not use .z and .zh exclusively. In fact, .z is a horrible extension, as it is a filetype association with ZLIB compression. Thus, headers and scripts would need a token to identify what they are, and what slot type to occupy.

    That could even be the cleanest way to handle this:
    Use one generic buffer for any file imported that lacks a categorisation token. If a file has a token <ZHEADER>, load it into a header buffer, or if it has a token <ZSCRIPT>, load it to a script buffer. That way, you retain the present import capability, and expand it to allow using the additional buffers. The parser has the capability to read tokens like thse, and shift modes for any of its internal operations, or directives. You can separately define how import "filename" works if the parser finds specific tokens.

  4. #34
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

    -DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
    -ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
    -See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

    That's my 2 cents.

    [edit]
    I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).
    Last edited by Gleeok; 01-08-2017 at 08:02 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  5. #35
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

    -DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
    -ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
    -See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

    That's my 2 cents.

    [edit]
    I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).
    No exclusion, certainly, but how would you instruct the parser as to what to store in each buffer? It needs some way to segregate headers, and scripts, to do what DD is suggesting.

    I'm not even keen on disabling it by default. I can think of three separate ways to handle adding this feature without in any way impacting the existing operation of the import directive. ( I've separately posted all three in the thread.)

    Thus far, a few suers have also asked for simultaneous support, and I don't know of any reason that we couldn't simultaneously support both modes of this. This allows users to adapt to, and shift to the new paradigm, without the fear of any older scripts ever breaking from the change. It also permits the most stubborn users to fall back on the present import method. Deprecating it slowly wouldn't really work, because that's the same outcome as disabling it now, and the user will always find old scripts that they want to use, which may rely on the old operation.

    There are still users, right now, downloading, and using scripts from 2007-8. ... You know how fun it is to support that nonsense.

    We can't support converting existing scripts from a dev end.

    Beyond that, if a user mixes and matches scripts that work with the standard 2.5 import scheme, and new scripts, say, that come out after we did something like this that are designed to use this scheme, those would not get along together if the option is a boolean setting of new/old import method.

    OTOH, If you use a parser directive token, or if you used a different directive token than import, then you can shift modes on the fly... That's another compelling reason to simultaneously support both, as otherwise you will create script incompatibility due to users mixing syntax generations, which would be bad. (-Cue Harold Ramis impression).

  6. #36
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Quote Originally Posted by Gleeok View Post
    Just to clarify my last post in regards to why (both sides -- loosely) are right and arguing is silly, in my opinion:

    -DarkDragon is correct that this is a useful feature. I really do wish it existed years ago.
    -ZC would have to support the old buffer approach to support backwards compatibility anyway, so might as well just disable it by default but not make it hidden to end-users so they could just toggle it however they want for the stuff stored for either their own personal versions or for release versions of their quest.
    -See how it works out in practice and let scripters mess with it a while before deprecating or completely removing the old system.

    That's my 2 cents.

    [edit]
    I commonly use .cs and .h for zscript files. I don't believe there is any file exclusion rules in ZScript; it will just load anything and try to read it as ascii (utf-8?).
    Sounds very reasonable to me.

  7. #37
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    This consists primarily of two things: Additions to the core ZScript bindings and interface, and additions or removals of library functions (eg; std.zh). I know there are also other popular .zh files since 2.50 was released: std_extra.zh, weapons.zh, etc.; are any of these worth adding (whole or piecemeal) directly into the 'std' library for the next release? Suggestions are also welcome.


    @ZoriaRPG - Would you mind giving us a brief summary list of the new ZScript functions you guys have added that you would like us to include into 2.51? This should also save some back and forth time in case some things needs to be discussed or modified. I'd like to put all of these changes in before anything else, if you don't mind.

    List as of now: http://pastebin.com/BgGn38TD

    There're clearly going to be things in there that won't go into the ZC core, or may need to be modified first; and other things remain to be completed, but that is the present state of additions in 2.future.

  8. #38
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    The ones that I use the most often are stdExtra.zh (by MoscowModder) and ffcscript.zh, ghost.zh and tango.zh (by Saffith).
    I have PMed MoscowModder asking for permission.

    Are there any others? For instance, Moosh's FFC script has a lot of high ratings at Pure. Are there enemies or items that are very widely used (Pegasus Boots?)

  9. #39
    Keese ywkls's Avatar
    Join Date
    Feb 2016
    Posts
    62
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    476
    Level
    7
    vBActivity - Bars
    Lv. Percent
    86.27%
    Quote Originally Posted by DarkDragon View Post
    I have PMed MoscowModder asking for permission.

    Are there any others? For instance, Moosh's FFC script has a lot of high ratings at Pure. Are there enemies or items that are very widely used (Pegasus Boots?)
    If you want some suggestions for other commonly used individual scripts, there are quite a few available. (And many most players expect to see in a quest these days.)

    Here's a few samples.

    Item Pickup Message- Probably the most basic of basic scripts, but something not built into ZC.

    Item Bundle Pickup Script- Lets you pick up more than one item at once.

    I don't know how easy Moosh's NPC script is to use, to be honest. I wrote one myself, but it's just a slight rewrite of scripts that others have submitted.

    The only working Pegasus Boots script I know of is here. It was created for me by special request and is mostly free of bugs. (You can get Link to face the wrong direction while using them, which leads to some odd graphical errors.)

    A couple of fairly easy scripts to apply to enemies are the Ball and Chain and the Big Enemy scripts. (I should note that Big Enemy is the way to do things only if a scripter doesn't know how to use ghost.zh.)

    The database at PureZC has a wide variety of enemy scripts. I'd suggest you download the relevant example quests and try them out. Some may require rewrites to match the behaviors of the original foes, though.

    There is also the Enemy of the Month contest at PureZC, which has had a lot of unique foes show up over the course of its lifetime. These have videos of the enemies in action and should still have quests available to download to try them out. (Some links may have expired, but generally; the authors of those scripts are still around.)

    There's also some scripts that aren't int PureZC's script database, but which are generally available. For example, the Moving Platforms and Hole/Lava scripts by Mero/Tamamo are available at PureZC, but many people have had trouble getting them to work.

    I know ZoriaRPG has a fixed version floating around somewhere (I think Tamamo does too, but I'm not sure); but there are others which are similar and easier to implement and not in the database. (The alternates were a Moving Platform script by Moosh and a Hole/Lava script by MoscowModder that was a modification of an existing script which he'd forgotten he'd posted when I mentioned it a while back.)

    There are also some that let you make a trading sequence, not in the database. This is one.

    I'm sure that there are more examples, but that's all I could come up with for now.

  10. #40
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Thanks! That's very helpful.
    By the way, do you know how I can get in touch with Mero and aaa2? They are apparently banned on Pure...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social