[ABANDONED] AGS 3.3.1 Alpha 2 Turbo

Started by Gurok, Tue 11/03/2014 11:25:53

Previous topic - Next topic

monkey0506

Quote from: Crimson Wizard on Mon 05/05/2014 08:08:24
Quote from: Gurok on Mon 05/05/2014 07:23:59I saw your thread and branch about this feature and was wondering why there wasn't a pull request yet.

Maybe people will look at this first and tell if that's ok the way it's done? Just to be sure that it is made conveniently. Just suggesting.

Also, Gurok raised good point about directory structure.

Yes, this is the reason there's not a pull request yet. (Well that, and I have several intermediary commits that don't need to be part of the main repo's history. Once I get a build that everyone's generally happy with then I'll dump it all into a single "initial" commit and pull that in instead.) ;) Agreed about the points you raised, and yes, to prevent clogging this thread up let's continue discussion about it in this thread. A few items were brought up there that I will be working on.

Calin Leafshade

Quote from: monkey_05_06 on Mon 05/05/2014 17:24:47
Once I get a build that everyone's generally happy with then I'll dump it all into a single "initial" commit and pull that in instead.) ;)

Look up "rebasing"

Crimson Wizard

Quote from: monkey_05_06 on Mon 05/05/2014 17:24:47
Once I get a build that everyone's generally happy with then I'll dump it all into a single "initial" commit and pull that in instead.) ;)

Quote from: Crimson Wizard on Sun 16/02/2014 15:50:35
It is strongly suggested to not put all the changes you make into one commit without consideration. When reviewing the history of changes it is very important to understand what has changed and why. Also, sometimes when looking for a source of bug we may walk down the history of commits, looking for the one which introduced the error: in this case it really helps when every commit has only task- and thematically related changes.
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50001.msg636481384#msg636481384
;)

Gurok

#43
Hello all,

AGS 3.3.1 Alpha 2 is out. You can download it here:

Download 3.3.1 alpha 2 as a .zip archive



Changes from 3.3.1 Alpha 1:



Engine

Bug Fixes

  • Fixed occasional pathfinding failure on straight lines with complex walkable areas (reported here)
  • Printing [ no longer consumes all of the backslashes before it (e.g. "\\[" should now print \[ as expected)



Scripting

Do...While loops

The Do...While loop construct is now supported. For example:
Code: ags
x = 1;
do
{
    x++;
    Display("%d", x);
} while(x < 1);

Unlike While, Do...While runs the loop iteration *before* evaluating the condition. The loop above will run once.

Dynamic Arrays in Structs

Dynamic arrays are now permitted inside structs. You can declare a struct like so:
Code: ags

struct DieRoll
{
    int BaseModifier;
    int DieCount;
    int Dice[ ];
    import function GetTotalValueOfRoll();
};

function PrepareDice()
{
    DieRoll a;

    a.DieCount = 3;
    a.Dice = new int[a.DieCount];
    a.Dice[0] = 6; // d6
    a.Dice[1] = 6; // d6
    a.Dice[2] = 8; // d8
    ...
}

And the dynamic array "Dice" can be initialised and used like any other dynamic array.

Managed User Structs

In AGS parlance, a managed struct is a struct that can be created dynamically. You must use pointers to refer to them (similar to built-in types like Region or Hotspot). You declare them with the keyword "managed" and construct new instances with "new", like so:
Code: ags

managed struct Point
{
    int X;
    int Y;
};

Point *GetPosition()
{
    Point *result;

    result = new Point;
    result.X = 30;
    result.Y = 40;

    return result;
}

Important: Managed structs are currently VERY limited in that they can't contain pointers (including dynamic arrays). It is hoped that this restriction will be lifted in the future.

#define Improvements

#define can now refer to other #define'd constants. Like VC++, #define symbol expansion only needs to make sense at the time of reference. Also like VC++, the order of previously defined constants isn't important, making stuff like this possible:
Code: ags

#define RED    GREEN
#define BLUE   456
#define GREEN  BLUE
Display("%d", RED); // Prints 456
#undef BLUE
#define BLUE  123
Display("%d", RED); // Prints 123

Note: To prevent circular references, a #define cannot refer to itself or anything previously used to expand the #define symbol.

Character.DestinationX and Character.DestinationY

Two new read-only properties that can be used to determine where a character is currently heading (via a Walk command). If the character is currently stationary, these values are the same as Character.x and Character.y, respectively.



Editor

Clickable for Objects

The Clickable property of objects is now exposed in the editor so that you can set it at design time. Previously, this value was embedded in the room file format but only toggleable via scripting.



This build also includes everything in AGS 3.3.0 Hotfix 3 (including the updated templates).
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

#44
Gurok, I just found a compiler bug: it does not restrict dynamic arrays in managed structs (although that's too a pointer).
Guess I forgot to check that particular case.


E: elaborating to users: it actually will work, but will cause memory leaks in program (which may result in various problems).

Gurok

Quote from: Crimson Wizard on Thu 31/07/2014 15:12:36
Gurok, I just found a compiler bug: it does not restrict dynamic arrays in managed structs (although that's too a pointer).
Guess I forgot to check that particular case.

Sorry! I quickly patched it locally and updated the link (a bit cowboy, I know). Should be better now. I will make a pull request for the extra compiler warning soon (tomorrow).
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Quote from: Gurok on Thu 31/07/2014 15:32:02
Sorry! I quickly patched it locally and updated the link (a bit cowboy, I know). Should be better now. I will make a pull request for the extra compiler warning soon (tomorrow).
You may simply send me a patch and I'll apply it right into main branch.

Sslaxx

This isn't exactly a major feature request, but allowing "... } do" at the end of a while loop (to provide syntactic symmetry with the "do while" loop) would be nice.
Stuart "Sslaxx" Moore.

Crimson Wizard

#48
Post deleted :tongue:, sry nevermind.

Alberth

But the "do" is a prefix for the statements ("do x = 1;" rather than "x = 1; do"), just like "while" a prefix is for the condition. (Technically the "while" is thus not at the end of the "do while" since the condition follows).

The only somewhat feasible alternative is probably "while ... do { ... }", like Pascal had. The parentheses around the condition after the "while" make the "do" unneeded in this case.

In all cases, the syntax would be different from what the zillion C/C++/Java programmers are used to, which seems to be a major source of inspiration for the AGS language. That makes it highly unlikely to happen.

Calin Leafshade

agreed. while() {} do; is not correct form basically everywhere.

deltamatrix

Wow great job!

One thing I'd like to ask for. I noticed ages ago that when you assign the function names for interactions (i.e: for Hotspots), you were limited to use only functions in the room script and not global script functions - this caused for me a lot of duplicated code across the room scripts.
BAD WOLF - TORCHWOOD - MR SAXON - THE BEES ARE DISAPPEARING - PANDORICA - RIVER SONG

Crimson Wizard

#52
Quote from: deltamatrix on Sun 10/08/2014 17:38:11
One thing I'd like to ask for. I noticed ages ago that when you assign the function names for interactions (i.e: for Hotspots), you were limited to use only functions in the room script and not global script functions - this caused for me a lot of duplicated code across the room scripts.
Not that I am principally against this suggestion, but there are numerous ways to reduce code duplication, such as intercepting mouse clicks on hotspot in global script, or calling other, "generic", functions from room event handlers.
It is even possible to not having a room script at all.
Perhaps if you'd give some example of duplicated code you have, we could find a solution for you.

deltamatrix

Thats very true. I envision good programming practice within AGS using jQuery-like event detection (lambda expressions/Closures 4 AGS?? :cheesy::cheesy::cheesy:)

The example was Look at Bush which calls a global function with random descriptions. This game was Hero6 which had a lot of forest screens each with bush hotspots. Therefore the duplication was in the repeated calling of the global function in each room.
BAD WOLF - TORCHWOOD - MR SAXON - THE BEES ARE DISAPPEARING - PANDORICA - RIVER SONG

Crimson Wizard

#54
Quote from: deltamatrix on Mon 11/08/2014 14:06:57
The example was Look at Bush which calls a global function with random descriptions. This game was Hero6 which had a lot of forest screens each with bush hotspots. Therefore the duplication was in the repeated calling of the global function in each room.

Code: ags

function on_mouse_click(MouseButton button)
{
    if (GetLocationType(mouse.x, mouse.y) == eLocationHotspot &&
        Game.GetLocationName(mouse.x, mouse.y) == "bush")
    {
        ProcessBushInteraction(mouse.Mode);
    }
}


:=

EDIT: You could use "unhandled_event" function, that would be more logical, but it won't work properly if interaction was triggered not by mouse.
Code: ags

function unhandled_event(int what, int type)
{
   if (what == 1 && type == 1) // look at hotspot
   {
       if (Game.GetLocationName(mouse.x, mouse.y) == "bush")
       {
           LookAtRandomBush();
       }
   }
}

Billbis

#55
Great works!
I'm a bit late, but I would like to make a couple of comments about the new CharacterDirection enum.
- It would be nice to have a build-in FaceDirection function. Sure, it is easy to code with some AGSscript, but the very first things I'm doing in every AGS project I start is recode it, because I found it so useful. I should probably be able to implement it myself, if only I knew how to compile a C++ program on Windows platform. :-D
- Would it make some sense to have a eDirectionNone in the enum? That way you can make some functions that use it as an optional parameter:
Code: ags
// header
import void Use(this Character*, CharacterDirection = eDirectionNone);

// script
void Use(this Character*, CharacterDirection Dir)
{
    int view;
    if (this == cEgo) {
        view = 10; //La view Utilise de Ego
    } else if (this == cRoger) {
        view = 15; //La view Utilise de Roger
    } else {
        return;
    }
    this.FaceDirection(Dir, eBlock);
    this.LockView(view);
    this.Animate(this.Loop, 5, eOnce, eBlock);
    this.UnlockView();
}

But maybe I'm missing something. It seems I can't set my optional parameters to null (compiling error), so a eDirectionNone would be (relatively) useful.

Crimson Wizard

Quote from: Billbis on Mon 11/08/2014 19:21:59
I should probably be able to implement it myself, if only I knew how to compile a C++ program on Windows platform.
If you may build it on Linux, for instance, you could do that too, because both versions share nearly same code.

Crimson Wizard

Any plans on checking out why AGS does not allow to put non-managed structs into structs?
I don't think it needs any breaking changes, it's just inserting nested data chunk; in engine memory it will be just the seamless array of data, just like any simple struct.
Probably compiler is not taught to track nested offsets.

Gurok

#58
I haven't thought about it, but I'll put it on my list of things to investigate.

Current priorities are:
-- Investigate destruction of stack struct variables that contain pointers to user objects (something seemed weird about the way they were cleaned up)
-- Modify the script format to support writing out parts of the symbol table for RTTI
-- Implement switch...case
-- Function pointers, type coercion for floats<->ints, etc (these are more things I'd like to put up for discussion before even attempting)

Quote from: Billbis on Mon 11/08/2014 19:21:59
eDirectionNone would be (relatively) useful.

I meant to comment on this a while ago. I think both this and the FaceDirection suggestion are worthy of inclusion in the standard library, but I don't know how others feel. I also implement this in most projects. I tend to call it "eDirectionUnknown" because you aren't facing none, you're just not specifying the direction faced. Right now, I think all the directions in the direction enumeration have a 1:1 mapping with loops. Not sure if we need to consider that when adding eDirectionNone.

Also, regarding the standard library of functions, there's one that seems peculiar to me:

Code: ags
GetRoomProperty(const string property);


No idea why this is a global function and not a static function on the room (like Room.GetTextProperty). Would anyone object to tidying that up?
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Quote from: Gurok on Fri 22/08/2014 18:06:51
I meant to comment on this a while ago. I think both this and the FaceDirection suggestion are worthy of inclusion in the standard library, but I don't know how others feel. I also implement this in most projects.
We already have optional direction argument to Character.ChangeRoom, so I don't see a reason not to.

Quote from: Gurok on Fri 22/08/2014 18:06:51
I tend to call it "eDirectionUnknown" because you aren't facing none, you're just not specifying the direction faced.
Hmm, I'd rather vote for "eDirectionNone" to comply with other similar constants (e.g. eKeyNone).
Its value should probably be "SCR_NO_VALUE".

Quote from: Gurok on Fri 22/08/2014 18:06:51
No idea why this is a global function and not a static function on the room (like Room.GetTextProperty). Would anyone object to tidying that up?
Its global because 100% of old AGS script API was global. OO-style was introduced around 2.7, and still not complete.
Just leave existing one under #ifndef STRICT for backwards compatibility (there are many examples around the header).

SMF spam blocked by CleanTalk