User Tag List

Results 1 to 10 of 115

Thread: AngelScript: The Revenge

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #13
    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,765
    Level
    21
    vBActivity - Bars
    Lv. Percent
    69.76%
    Quote Originally Posted by Gleeok View Post
    They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.

    In AS no hack is required; you can pass arrays from anything to anything else if you want so long as it is type-checked. You can even get member variables declared in one script by another script. Heck, you can even have 100 global scripts communicate with each other and destroy/create each other. These are all built-in, and very simple to use script-side and c++ side. That is why I say we'll be saving years of dev time.

    But AS compatibility just dropped to no higher than 98% now.

    In the future just post the thing that is relevant so there's no confusion. I've never seen anyone do this, and it technically should be a compiler error, although it's a little late for that.
    (Emphasis, mine.)

    A little late for this now, too. I do warn that they need to refresh pointers, and that it can be dangerous (because you may be using the wrong data later), but even I need to do this, but I don;t need the data to persist between saves when I do. I do it because I store all of my global values in one array, and I use indices for pointers. I also use this a great deal for string pointers, to make them available between scripts, externally. That's another area where this is often applied.

    Sure, it won't matter for new scripts, but I'm still waiting for absolute clarity on if compiling old scripts via the ZScript parser will be maintained in your plan here. That alone will resolve most user issues, point blank. If they can still use all of their old stuff as-is, and they have the option to convert it to use new features, that would be ideal. I don't have a problem committing to support both languages, if you don;t have a problem allowing me to support both languages.

    Hell, I even added a way to get other-typed pointers to my fork. I need to be able to do that, to reference them externally. That's because there is no way to make a global typed array. Even DD admitted that with the stuff that we do, global special type arrays are pretty much needed for ZScript. Not to force pointers to persist, but to store them globally per-session, and to be able to store and reconstruct special-typed data. That is what type->GetPointer() does, as I had mentioned earlier.

    Now you know why that sort of thing is so useful to us. Some of my magic is simply impossible without it. That equally applies to everyone else. You should look at Moosh and Evan;s scripts at some point though, and see how common this is. Lejes also used it, as i recall, and I'm fairly certain that it is as common as dirt. Is it because it is a hack required to do something? Certainly. Is that actually bad? I think it;s arguable. You can pass arrays by reference in C/Cpp, which is the equivalent of this.

    I'm not sure precisely how AS does it, but clearly it has to allow passing arrays and strings by reference and using them in functions and elsewhere without worrying about scope issues like this.

    Take a look at when I documented this on the Wiki. You might want to read some of this stuff, at some point; you know? (That is my comment, at the end of the page, too.)

    I should further note that this is similarly used for psuedo-2D arrays, and for mass string handling, and en-queueing.

    Code:
    int string1[]="foo";
    int string2[]="bar";
    int string3[]="rats";
    int string4[]="meatballs";
    
    int strings={string1,string2,string3,string4};
    //Draw strings to the screen in a for loops using the 'strings' array, one at a time, adjusting their positions.
    That is how every quest that has scripted credits rolls, scrolling text, or otherwise handles this. make the strings, and store their pointers in an array, so that you can iterate them with drawstring using a for loop (using their pointers).

    Code:
    int subscreen[265];
    int positions[16];
    int items[16];
    
    //etc
    
    subscreen[0] = positions; 
    subscreen[1] = items;
    //etc
    
    //iterate subscreen[] and do all events from the iteration, because ZScript doesn't have real 2D or 3D arrays. Huzzah
    I am not joking when I say it is used EVERYWHERE, by EVERYONE. I know for a fact that Lejes and MoscowModder did both of the above things. This is how I was taught] to do it. Hell, does Tango.zh do it for scrolling strings? Probably not, but everyone else that does scrolling text, or wants to manipulate many strings does it.

    I was taught the '2D array' thing by MoscowModder, and people often (poorly) explain it as 'storing one array within another', which it does not do. I always clarify that you are merely storing the pointer. @Grayswandir also teaches it to everyone, as do I. It is a staple of ZScript. :p

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