Topics

Following is my idea on how the Editor interface could be improved accompanied by few mockup screenshots.
I don't like writing long explanations, let's just say those suggestions are based on my own experience working with AGS Editor and also looking and reading on how others work with it (something I mentioned here for instance: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=45623.msg624000#msg624000).

Oh, and important note. That is not in my plans to work on this right away. To be honest I'd wish someone else did this . I do not have much free time, I am not as proficient in C# as in C++, and there are people who know Editor source quite well already. That is - if they like the concept of course.


Let's look on new Project Explorer first:


It consists of three panels:
1. Project item type selection. Those are moved out from the project tree where were represented by root nodes, and now are represented by bitmap buttons.
The upper part has buttons that open new editor panes in the main workspace: General Settings, Colors, Sprites, Text Parser, Lip Sync, Global Variables.
The lower part has buttons that will change the project tree contents: GUI, Inventory items, Dialogs, Views, Characters, Mouse Cursors, Fonts, Audio, Scripts, Plugins, Rooms, Translations.
2. The Search/Filter. Input box is for entering a search line. Buttons have following meanings:
- clear input box;
- filter out on/off (when enabled the tree will hide all the non-matching elements);
- case (in)sensitivty on/off;
- match full name on/off;
- colour picker to mark out matching items.
3. The well known project tree. Now it shows only items of the type which is selected on head panel.


Let's move to the Room editor pane:

As you may notice I've changed the look of background-related buttons, they are:
- Change selected background;
- Import new background; there should not be such item in the combo-box now;
- Delete background;
- Export background.
The "Show this room's" combo-box is replaced with a set of bitmap buttons:
- Nothing (pure background);
- Edges;
- Characters;
- Objects;
- Hotspots;
- Walkable areas;
- Walk-behinds;
- Regions;


Finally a totally new Room Explorer pane. Since of 3.2.2 we have docking panels it will be easy to put it in the position you find appropriate.


As you should notice it's the same gui class as Project Explorer. The upper panel lets you select a content type. The buttons are the same as on Room editor pane with an exception for Edges (since they are not room elements on their own).
By selecting items in the tree you will open corresponding properties. There may be an option to either switch Room view to the element type when one is selected or not.


What do you think of this?

Are there any plans to improve the manual?

Personally I think it lacks distinct topics on using certain parts of editor. For example, there's no "Room Editor" or "Properties Pane" topics, these are described only in tutorials, which is not really good in my opinion. I remember that caused great confusion for me when I just started to use AGS (I couldn't figure out where to look for information).

Also, I noticed that beginners keep asking same questions about most basic behavior over time. It means that either some information is missing or explained not well enough.
What about searching through Technical board and gather FAQ? It may later be used to improve existing topics, remake FAQ section, or, perhaps, add new HOWTO section in the manual that would cover tips on implementing most desired non-basic game features.


BTW, online manual still describes AGS 2.72 in Tutorial section.

EDIT: maybe I should have posted this in Adventure Related talk board to bring more attention?

Something I noticed two months ago but forgot about.
Here's what is on SVN:
(acroom.h)

Code: cpp

#ifdef THIS_IS_THE_ENGINE
  if ((rstruc->wasversion < 17) | (rstruc->wasversion > ROOM_FILE_VERSION))
#else
  if ((rstruc->wasversion < 15) || (rstruc->wasversion > ROOM_FILE_VERSION))
#endif
  {
    fclose(opty);
    quit("Load_Room: Bad packed file. Either the file requires a newer or older version of\n"
      "this program or the file is corrupt.\n");
  }

Do you see a different operator here? Engine branch is using '|' (bitwise OR), Editor branch is using '||' (logical OR).
Is it a typo (hence a bug)? And which one is?

My guess is for '||', but... maybe there's some witty plan behind this.

I always wondered how does this record/replay stuff works, but not strong enough to actually check it out.
Now I see the recording functionality in the engine code and getting curious.

First of all, there are few commands registered internally, but they are not exposed to the editor. This functionality isn't mentioned in Manual - at all. I searched forums and found only few threads:
This circa 2003
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=10275

Yeah, recording the actions. Use Alt-R to start recording.
EDIT: press again to stop recording. Then you can play the recorded file via specifying it in the AGS setup menu.
The feature is unofficial though.

Yep - it's unofficial because it is still buggy and the playback can get out of sync after a while (it tended to work for about 5-10 minutes then mess up).
It was originally designed to allow live walkthroughs of games, but in its current state it's only really good for demonstrating bugs or recording short pieces of your gameplay.

Also later one, circa 2007:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32910

In fact, all that the replay feature does is record any user input (mouse moves, key presses) on each game frame. This works on the principal that the game logic is deterministic, so the only way to affect the game flow is if the user does something.
The replay feature does almost work, but there is a bug that can throw it out of sync in certain situations and I've never spent the time to track it down and fix it.

So. Basically this is in the engine for years now, but not working correctly.
Should it be fixed later? Is it needed to anyone?

EDIT: Heh, I was a bit wrong when I mentioned that "registered commands". There's only one command, and that's what it does:

Code: cpp

void scStartRecording (int keyToStop) {
    quit("!StartRecording: not et suppotreD");
}

not et suppotreD, sorry

When I try to post an issue, I am getting this all the time:

Please try again. If you come back to this error screen, report the error to an administrator.

[THE NOW OFFICIAL ENGINE ISSUE TRACKER:]

LATER EDIT: THE NOW OFFICIAL ENGINE ISSUE TRACKER:
http://www.adventuregamestudio.co.uk/yabb/index.php?project=3


Thanks for Khris for pushing me towards it (although he probably did not know about it )
Let's gather useful suggestions and problems that could be solved by adding features to the engine. Some were mentioned on forums already.

-------------------------
EDIT: I have to do this :
Let me elaborate why I started this thread. We all have some things in mind for sure. However, there are things being mentioned around forums, that could miss our attention. I suggest to gather them, if you find something interesting just give a link and some commentary.
-------------------------

My first contribution to this:
------------------------------------------------------------------
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=46344.0
Basically the guy wants his character's walking animation to have extra frames that play only once at start and never repeat (unless animation is reset).
I am thinking about "repeat from here" frame flag (or loop property). But there should also be a way to tell engine since it is walking anim, he should jump from one repeatable sequence to another if character turns into different direction without stopping.
Any thoughts on how to better design this? I mark "design" word, since it is question of one at the moment, rather than coding.

I know that mentioning real people, as well as discussing something behind their backs could be impolite, if not rude, but there's something that bothered me.

As many of you may know, there were cases when certain people keep posting their games here, claiming that these are real games, which, in fact, were looking too terrible to believe they are serious. Some thought these people are stupid, others - that they are trolls. I felt quite annoyed too, not that I was angered, I was rather scared (!), because I couldn't stop thinking there's something in modern education that makes people behave so weird.
I remembered my own teenage years, I myself did a lot of silly and stupid things, but there was one difference - I rarely displayed my works in public, and I would be ashamed if I had to show something so unfinished and low quality... wait a second...

And then it hit me.
What if this is not stupidity or exaggerated self-confidence, but rather a natural behavior of a new generation? I mean, they are born in the era of Internet. What if they post such games here not because they truly believe they are superb, but because they are just used to show everything they do on Web, even things that older generation would dare to show only to closest friends?
Does this makes any sense?

[EDIT from 13 feb 2013:For those who are new to this, the latest valid discussion starts here:http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912First posts in this topic are quite old, and arguments obsolete.//----------------------------------------------------------------------------------------------------------------]

EDIT from 13 feb 2013:
For those who are new to this, the latest valid discussion starts here:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912

First posts in this topic are quite old, and arguments obsolete.

//----------------------------------------------------------------------------------------------------------------




First of all, I am not going to post any theoretic plans here, dream team lists (sorry, Di Perla ), etc.
What I want to post is a specific proposal, which, if accepted, could get under way same day.

I seem to make new threads here often lately but I thought I really must make one to separate discussion about immediate release policy from the "refactoring" thread.
I'll try to be as brief as it is possible without making nonsense.

What is the practical situation?

There are three sequentially related development branches (I mean that every next contains all the changes from previous ones):
1. dev 3.2.2 on SVN.
This branch contains only changes to the Editor, mainly to GUI look and behavior (by tzachs); also few fixes and whatnot (by Calin and monkey_05_06).
The branch did not have any update since January 2012, that is half of year already.
The natural questions are:
a) What was the goal of that branch (features, fixes, updates, etc, supposed to be implemented there)?
b) Was the goal achieved? To what extent?
c1) If it wasn't achieved, what is actually left to do? Why is no one working on it?
c2) If it was achieved, why it wasn't released?
I read earlier several discussions on 3.2.2 and also things people are wanting/trying to implement, but none mentioned release date;
FYI (but I guess many of you know these better than me):
http://www.adventuregamestudio.co.uk/forums/index.php?topic=42066.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43383.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43955.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=43965.0
http://www.adventuregamestudio.co.uk/forums/index.php?topic=44230.0
Basically I see the common problem: everyone is like "when the 3.2.2 is released, then..." (something good happens); but no clue who is responsible for releasing it.

2. JJS's branch
As you may know pretty much well, JJS and tobihan port AGS engine to other platforms.
JJS is making what he calls "daily releases" for all platforms, except Linux version, I believe, which is supposed to be built by users from current source.
Is there any "grand" release planned to mark a checkpoint in this work is unknown to me. How long this work is supposed to take more is also unknown to me.

3. Refactoring branch
Currently made by me, but I really hope monkey_05_06 and perhaps someone else will join eventually.
My primary task was to clean the engine code up and split it to readable units. This is almost done. In fact, I am very close to a point when further "cleaning" becomes useless since it does not add enough to the whole picture to even spend time on it.
What comes next depends on open discussion and collaboration.


Recently I was told by tzachs that, quote:

Eventually we will want to merge those unofficial ports into the main trunk and release an official version (the sooner the better IMO), we wouldn't want to keep those branches alive, this could create chaos for the exact reasons you mentioned.

I actually disagree to this for following reasons:
1. JJS's branch contains ports for several platforms. These may have different issues that never existed in Windows version. I doubt anyone can tell when they all are well tested and fixed.
2. Current 3.2.2 version itself is still in BETA stage (at least that's what editor tells when I open it), and hence should be tested and maybe fixed on its own.
3. Having number of branches each for certain aim (e.g. basic functionality, editor, ports, etc) is not a problem so far as they all originate from same root and exchange code regularly. There's no reason to "kill" these.


What is the practical suggestion?

A. Take existing 3.2.2 code and officially (with notice on site homepage) release it as an open BETA (with warnings to have game backups etc). Mind this, you can do it right now.
If there are errors, fix 'em.
If there are suggestions to the Editor functionality that does not require core changes and big work, implement them.
Polish the whole thing and release as 3.2.2.
Make the branch for future Editor development from here. All the new editor features that do not require changes to engine are implemented and tested in this branch first. After that they are copied to other branches (see below).
If there's a suggestion that requires changing both editor and engine, then wait for engine changes coming from other branch, or make editor part as a "carcass" then wait for engine changes.

B. After 3.2.2 is released, merge everything made for Editor to JJS's branch. JJS's branch so far had literally no changes to Editor, so that won't be problem a single bit.
Ask JJS to define some kind of "checkpoint", a date for "big release", and help him (if possible) to reach a stable Windows version and stable or relatively stable versions of other ports.
No new features are to be added to the branch at this time.
When time comes relase public BETA first, then new official version, call it, I don't know, 3.3 for instance.
Make a branch for future ports development from here. All the porting, including maybe even Windows system-specific changes, should be made in this branch. Every time a stable stage is reached, this branch will share its code to others.

C. Meanwhile the refactoring branch will be worked on, gradually changing from simple code restructuring to starting implement new engine features.
It will get the Editor code from 3.2.2 branch first, then "Editor" branch. It will share stable, tested engine code with Editor branch if such necessity is met.
It will get the ported code from JJS branch first, then "Porting" branch, and similarly, give back stable core code so that porters could check it for portability issues and add some fixes, tweaks etc.

Finally there will be Main branch, created right after 3.2.2 release and branched from one, which should not be worked upon at all (except for, maybe, manual and packaging fixes).
As soon as any of the previous three branches reach stable stage, it will get a code from them. It does not really matter in which order. It may get, like 5 changes for Editor and none for Engine. Yet that program will be stable and ready to be released any moment if wanted.


That's it.

If someone thinks I have no right to suggest things this way, then find the one who does have the right, drag him here and make him read this and state his opinion .

Well, I made this as a small experiment. I wrote a separate output "system" as a possible substitute for existing functions.
It may be found in the "feature_dbgoutput" branch here:
https://github.com/adventuregamestudio/ags/tree/feature_dbgoutput
Check that out (in both meanings ) if you are interested. Actually I would like to hear some comments.

Idea was to have a simple subsystem meant for outputting text messages for debug or user notification purposes.
Output is being controlled by verbosity settings (at the moment they are hard-coded, but I supposed they should be read from config or command line).
Verbosity is defined as flags:

Code: cpp

        VERBOSE_DO_LOG          = 0x0001, // do log (otherwise do not, C.O.)

        // Debug reason is for random information about current game state,
        // like outputting object values, or telling that execution has
        // passed certain point in the function
        REASON_DEBUG            = 0x0002,
        // Notifications are made when the program is passing important
        // checkpoints, like initializing or shutting engine down, or
        // when program decides to make a workaround to solve some problem
        REASON_NOTIFICATION     = 0x0004,
        // Warnings are made when unexpected or generally strange behavior
        // is detected in program, which does not necessarily mean error,
        // but still may be a symptom of a bigger problem
        REASON_WARNING          = 0x0008,
        // Handled errors are ones that were 'fixed' by the program on run;
        // There's high chance that program will continue running as normal,
        // but message should be maid to bring user or dev's attention
        REASON_HANDLED_ERROR    = 0x0010,
        // Unhandled errors are errors that program was not able to fix;
        // Program *may* try to continue, but there's no guarantee it will
        // work as expected
        REASON_UNHANDLED_ERROR  = 0x0020,
        // Fatal errors make program abort immediately
        REASON_FATAL_ERROR      = 0x0040,

        // Convenience aliases
        REASON_FUNCTION_ENTER   = REASON_DEBUG,
        REASON_FUNCTION_EXIT    = REASON_DEBUG,

        REASON_NOT_DEBUG        = 0x007D,
        REASON_WARN_ERRORS      = 0x0079,
        // Just print out the damned message!
        REASON_WHATEVER         = 0x00FF

System registers a variable number of "output targets" - objects of classes, which implement IOutputTarget interface. These may be newly created classes or any other preexisting class that was extended to become IOutputTarget implementation. For example, in this branch I made AGSPlatformDriver its implementor.

There's a general verbosity setting that is used to tell what types of messages should be completely ignored during game run, and each output target has its own verbosity setting that is being checked after general setting.
Print is made by ALL output targets that pass verbosity check. That means you may have, for example, a file output for printing out only serious errors, and console or editor debugger output for printing both errors and some minor debug notifications. You may even have two file outputs - one for general logging (some 'debug.log'), and separate one (original 'warnings.log') for printing only serious errors, and so forth - any combination of these.

Basically you register them like this:

Code: cpp

    out::add_output_target(TARGET_FILE, new Engine::out::CRawFileOutputTarget("warning.log"),
        out::REASON_NOT_DEBUG, false);
    out::add_output_target(TARGET_SYSTEMDEBUGGER, AGSPlatformDriver::GetDriver(),
        out::REASON_WARN_ERRORS, true);
    out::add_output_target(TARGET_GAMECONSOLE, new Engine::out::CConsoleOutputTarget(),
        out::REASON_WHATEVER, false);
    out::add_output_target(TARGET_FILE_EXTRA_TEST, new Engine::out::CRawFileOutputTarget("ags_game_debug.log"),
        out::REASON_WHATEVER, false);

There's a common function for printing simple message with given "reason", as well as bunch of convenience helper functions for more user-friendliness.
The output is made simply like:

Code: cpp

    out::fprint("Debug system: testing!");

    out::debug          ("This is a debug message, p1 = %d, p2 = %f", 1, 2.0);
    out::debug          ("Function name", "This is a debug message, p1 = %d, p2 = %f", 1, 2.0);
    out::notify         ("This is a notification, p1 = %d, p2 = %f", 1, 2.0);
    out::notify         ("Function name", "This is a notification, p1 = %d, p2 = %f", 1, 2.0);
    out::warn           ("This is a warning, p1 = %d, p2 = %f", 1, 2.0);
    out::warn           ("Function name", "This is a warning, p1 = %d, p2 = %f", 1, 2.0);
    out::handled_err    ("This is a handled error, p1 = %d, p2 = %f", 1, 2.0);
    out::handled_err    ("Function name", "This is a handled error, p1 = %d, p2 = %f", 1, 2.0);
    out::unhandled_err  ("This is an unhandled error, p1 = %d, p2 = %f", 1, 2.0);
    out::unhandled_err  ("Function name", "This is an unhandled error, p1 = %d, p2 = %f", 1, 2.0);
    out::fatal_err      ("This is a fatal error, p1 = %d, p2 = %f", 1, 2.0);
    out::fatal_err      ("Function name", "This is a fatal error, p1 = %d, p2 = %f", 1, 2.0);
    out::fnin           ("Function name");
    out::fnout          ("Function name");

    out::fprint("Debug system: end testing!");

The code is not final, ofc. Main issue is unsafe usage of string buffers, and also limits made by using static array, but this would be fixed as soon as utility classes are implemented.
I also may have gone too far with namespaces . On other hand the whole thing could be converted to the class in a matter of an hour.
Currently functionality mimics original AGS logging (file and writing to game console; btw it's funny I don't remember ever seeing that.... :/ or maybe I forgot how it looks like).

What do you think?

I don't know if this is a forums problem or google maps one. But I cannot understand how to save my location on the map in my profile settings. I can zoom in, place the marker, then a panorama shows up with approximate address displayed. That's ok. I copy that address into input box in the top-left corner of the map window, and hit enter. Page updates and there's "Your profile has been updated successfully." message. But when I check the map, the marker is on the place it was before (showing my location somewhere in the inhabited woods or something ).

Can somebody please explain how this thing works?

[What is depicted on Pumaman's avatar?]

Now, that is silly! but... I want to know this for 4 years now (so long as I am on forums).
What is depicted on Pumaman's avatar?

[imgzoom]http://www.adventuregamestudio.co.uk/pumaman3.gif[/imgzoom]

Seriously....
Earlier I was struggling between two options: some superman-like guy flying, or scuba diver in the water.
Now I got a thought it could be a drawing of a man standing with his hands up but rotated by 90 degrees.

So, can someone enlighten me?

[1.]

Here are my thoughts on possible continuation of the hypothetical branch of AGS that would merge JJS's portable version and refactored one.
I wanted to wait till I clean my branch a bit before posting this, but that takes time and also monkey_05_06 told me he wants to work on that too; so it goes here.

Before anything else I want to state following:
1. Unfortunately I am not aware of development process in official AGS 3.2 branch. I only know that Tobihan merged it into JJS's rep some time ago, but that was only Editor code.
2. My own branch is based on JJS's one and has practically everything JJS and Tobihan made, except for maybe few recent commits. I planned to merge their code at every stable stage, but after last changes I made to my branch I am not sure I will be able to do so with the same ease, since code structure changed too much (on other hand, it is perhaps worth trying automatic merge to see what happens ).
Recently things became somewhat messy there because of rushed splitting large source file, but I am working on cleaning things up right now.
It does compile and seem to work as expected (i.e. without any changes to program execution). On Windows - that's it. Haven't tested on other platforms that are supported by JJS branch.
3. I asked JJS and Tobihan to tell their opinion about merging our branches; so far I got response from Tobihan who agreed to check and fix linux compilation for my branch.
I haven't got answer from JJS yet, and I would really like to hear from him.

Links:
Adventure Game Studio "organization" on github:
https://github.com/adventuregamestudio
contains JJS's branch:
https://github.com/adventuregamestudio/ags

My own branch:
https://github.com/ivan-mogilko/ags-refactoring


Following is not a "big plan", but rather thoughts on most immediate things needed.

Organizational
Obviously there should be a feature and bug tracker.
Using forum threads is not a good idea, since they tend to become messy and off-topic too fast.

JJS has one for his own branch: http://jjs.at/tracker/
Does the offical AGS branch have it?
What may we use?

Some place to discuss practical coding problems. I know this will sound snobish, but I am a pragmatic man and I realize that doing this on forums with public write-access will make it mostly off-topic chat eventually as well.

Code design documentation.

Administrative
Since there will be alot of ideas thrown in eventually, I believe we must determine the criteria which would allow us to split all such ideas and feature proposals into three categories:
- Ones that change engine/editor too much to be implemented into version 3.* and should be left aside until better times (AGS 4).
- Ones that could be implemented into 3.* without breaking backwards compatibility.
- Ones that could be implemented into 3.*, but are too exotic or not as useful to average game creator to be part of engine core, and thus should be rather made as plugins.

Code-wise
Code-style is to be determined. I do not think it should be thoughtlessly applied to existing code, since that will increase amount of work needed to merge changes from other branches, but as we rewrite parts of it we should use code-style.

Following are changes that I would really like to see made to AGS engine:
1. Separating platform-dependent and low-level code as much as possible (and reasonable) from engine core.
There should be no #ifdef WINDOWS_VERSION or #ifdef ALLEGRO_BIG_ENDIAN scattered all around the code as it is now.
I belive, there should be no raw FILE or BITMAP type references in the engine core as well. I hate to include allegro headers in almost every unit only because one of the function it needs to be known has BITMAP or RGB in parameter list.
Probably writing interfaces for some kind of "serializer" or abstract drawing system will improve things.
2. Substituting raw static and dynamic arrays with classes. That could be either STL or AGS own utility classes.
String class too, perhaps.



//--------------------
EDIT: Oh, right, how could I forgot...
Important thing is to decide whether to propose refactored branch as a merge candidate to official 3.2 or not.
Ofcourse it needs more testing, but with changes made only to code composition and not to program execution it does not make whole new version of AGS, like 4.0.
I would suggest to aim for version 3.3 or something like that, which would include refactored code + some of the most wanted additions to engine.

I have couple of questions regarding AGS engine portability.

1. If you are familiar with engine code you may know that it does not make use of container classes (aside from limited number of exceptions): it uses dynamic arrays at best (although in a quite unsafe way), and static arrays too (that explains object limits). I do not know what were CJ's considerations, but is there anything that would prevent us from using container classes like STL or boost in the engine code? Can there be any portability issues?

2. If I am not missing anything, plugins - in the way they are made now - can be used only under Windows. IIRC that was why JJS made some of the plugins built in engine.
Are there any ideas on how to change that? I am not asking of immediate implementation, maybe some thoughts for the future use?

... a shout made years ago reached my ears today.

AGS code, acroom.h:

Code: "acroom.h"

void ViewLoopNew::ReadFromFile(FILE *iii)
{
#ifdef ALLEGRO_BIG_ENDIAN

  STEVE PLEASE VALIDATE THAT THIS CODE IS OK

Well, of course it is not OK; I never met a compiler that would understand such instruction.
And whoever is Steve, he did not even bother...

I may be mistaken, but I think there was such an option in earlier versions of AGS: when you right-click on room background it allowed to copy current coordinates to clipboard in a format (like "X, Y") useful to be pasted, e.g., into Walk function. There's no context menu now, and I wonder was it removed intentionally?

AGS does not let declare a struct member function with name similar to global function. It shows "already defined" error.

Code example:

Code: ags

struct GameBoard
{
   import static function SetViewport(int x1, int y1, int x2, y2);
}

Few weeks ago I have drawn this for Background Blitz. Back then I was quite proud of my accomplishment, but when I look at this picture now I feel it lacks life somehow. Maybe lighting is bad, or shadows too soft, or something's missing... I need suggestions, because I want to develop this style of art.

For a few times already I've met a situation when I need to rename lots of instances of a variables in the code. Hence, I can tell that Find & Replace tool in AGS has certain inconveniences in how it works.

1) There's no "replace all" option.
2) It is possible to hit and hold enter key, when "replace" button is selected, and it will work, but for some reason script window is not updated during this process and you will only see changes after you release the key.

If there's a variable of any type declared in module header, like

Code: ags

int var;

and there is a structure declared in module body, which has a variable of the same name, like

Code: ags

struct A
{
   int var;
};

compiler will treat this as error and will give following message:
"'var' is already defined".

This won't happen if structure is declared in module header, though.

Example code:

Code: ags

struct MyStruct
{
  import static int func();
};

function SomeOtherFunc()
{
   int arr[100];
   int var = arr[MyStruct.func()];    // <--- line X
}

Compiler stops with error: " Error (line X): parse error after '[' ".


Possible workaround:

Code: ags

   int dummy = MyStruct.func();
   int var = arr[dummy];