Messages

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?

Yeah, I sort of did similar thing

It appears one cannot make a pull request to non-existing branch (i.e. to create a new one).
This leaves me one option - to just push my local rep to adventuregamestudio/ags/-new-branch-name-.

UPDATE: hey, that worked, it even shows the history correct (my branch forked from main in the past):
https://github.com/adventuregamestudio/ags/network

From what I've learned from the code, there's a distinction between main GUI object (class GUIMain) - the one you create in the editor by clicking "new gui" (you may think of it as a container), and child GUI objects (GUIButton, etc).
Child interface types are all derived from GUIObject base class and must have the GUIMain as their parent.
GUIMain does not have a base class.

I think it not very difficult to change this system by first either making GUIMain a child of GUIObject, or allowing GUIObject to have another GUIObject as a direct parent.

[JJS]

JJS, thank you! (Now I need to be careful not to screw something up there )

Regarding branches.
So far my work was mainly straightforward and used branching for the purpose of dividing history into stages rather than separating concurrent tasks.
This means that although there are 6 general branches right now, the last one (refact_Stage_4) is only needed, but it also "contains" all previous ones. (There are couple of side-branches too but they were used for temporary holding some code I later merged into main branch anyway).

More important question is, where do I pull it to? Should I create a separate repository inside organization, or a branch from ags/main?

//-----------
@monkey_05_06,
Earlier you spoke about implementing base utility classes. Perhaps it could be the next logical step. I need to explain one organizational issue though.
I do not know yet how the future work will be planned, but until now I tried to divide my work into stages, each for one general task; I also made sure everything builds and runs in most of times (and especially at the end of each stage).
1. Stage One: splitting the code into separate projects (two libraries - Common and Compiler - and one Engine application) with strict dependancy; then making shared library compile on its own without including any engine or editor-specific code.
2. Stage Two: splitting the code in Common and Compiler libraries into smaller units.
3. Stage Three: splitting engine code into smaller units.

I am currently at Stage 4, which is:
- tidying up;
- making sure all source files are in corresponding directories (Engine dir contains only engine files, Common dir only shared files etc);
- making sure that all the ports that work in JJS fork work on mine as well.
At the end of Stage 4 I am planning to merge all the differences from JJS branch.
This means that I'll have a code which was restructured, but executes at least 99% same way as the one in JJS branch.
I prefer to then leave that branch as a stable reserved source in case we screw up something in the future.

I think it is better to make new branch for any larger changes, like implementing new classes and similar stuff. What could it be named - Stage_5 or somehow more originally - I don't know. I am not sure that could be called refactoring if we put new utility classes (like STL) to use, since that will actually change the way program runs. Or, maybe it's just a not so important matter of preference and naming conventions.
What I intend to say, I guess you can branch from refact_Stage_4 right away and start writing classes or substituting C-style arrays and strings with std:: classes. When I finish Stage 4, I will just merge the changes to yours, or vice versa.

I don't have much experience with linux, but it looks like "treat warnings as errors" compilation option is on ("-Wfatal-errors" flag)?
Unfortunately AGS engine produces some type conversion warnings during compilation.

Brokeback Condo?

Hahaha
I had to watch fast forward about 30 minutes of some dumb movie, but finally saw the same picture!

I know this feeling.
Geez, it was back in April when I returned back to the forums after nearly year of absence and tried to figure out what's going on.

There is many ideas thrown around and it is hard to tell what is happening with AGS.

What is being planned?

Ideas are thrown in a large quantities, but over the time one should learn to simply ignore this fact. Sic! People keep getting new ideas infinitely, good and bad ones, and, unfortunately, love to tell them out loud.
They actually begin to matter only when a) actual work is being done and/or b) there's team and team coordinator(s).
In other words, do not try to understand or remember all those ideas posted around, but pay attention only to those that are actually being implemented, or, at least, if an actual implementor is defined who plans to start the work on feature in nearest future.
In other words, there's message, like: I (We) are going to make this (right away): ....
Otherwise, ignore it.

Now, what happening to AGS, you ask? Well, one thing is certain - it is being used to make games.

What is happening with the official version.

Good question! I would like to know the answer too. But with absence of "official" explanation we should, perhaps, simply take as fact that the official version does surely exist.

You may think that I am kidding and having fun on you, but I don't (that's it - I am totally serious) .


Other than that, here's what I know.
Official version did not have any changes for quite some time.
There are a lot of plans, as I said, but, as I said, you should mostly ignore them. I am serious. Unless being used as a reference for a real work, plan is nothing. Which is a pity, but still.
JSS and Tobihan are making a cross-platform version of AGS, that may be built and run on various platforms, other than Windows (Linux, MacOS, etc).
Some people are working separately to improve Editor as they see fit.
I know that Alan v. Drake made a version of engine that supports some advanced graphic filters (thus improving the graphics quality when game is playing in upscale screen resolution).
I, personally, am working on improving the AGS engine code to, hopefuly, make life of developers easier in the future.

[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?

3. If by merging you mean that the main branch switches to the refactored code: Not sure if this is beneficial at this stage. But I will also test the changes on the other platforms.
What we could do is creating a refactoring branch directly in https://github.com/adventuregamestudio if that helps.

My primary intent is to make this more open and easier to find so others could join in and collaborate eventually.
So, I would totally agree if there will be a separate branch in adventuregamestudio for now.

Existing platform specific methods should also be used, e.g. for delaying the execution there is a method in the platform class but still Sleep() is used in various places and has to be separately redefined for non-Windows platforms.

Well, my idea in general is to limit the amount of modules that "know" they are using something platform-specific. If a code uses a symbol without having to "worry" whether it is a Windows function or some defined alias with extra tweaking, it should be ok, I guess.

The only thing that saved AGS are the unofficial forks, that are revitalizing the project a lot. Where's the strong hierarchy there?

Pardon?
Timofonic, I seriously do not understand your point sometimes.
The "only" thing that "save" AGS are people who are making games with it. And they are doing that a lot, and for a long time.

Oh, right, sorry for off-topic

[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.

Come on, people....

By the way, there's an unknown project called Linux. It was the main reason of making Git, named after the creator of the project himself (that he likes to say "fsck you!" these days too). There's tons of other of bad examples of unknown projects here.

What monkey's point was (at least that's how I understand this), - the choice of the source control system won't automatically make project successful or unsuccessful, nor make a difference between life and death. Personally I would not care a little bit if I had to work with SVN (I did for several years before... and nothing bad happened).

JJS, Tobihan and Ivan are doing the most interesting work. Most of that work isn't in the official repository. Now JJS's fork becomes an inofficial repository of AGS in GitHub but it seems the SVN repository still coexists.

Seriously, so what? It is always nice to have a separate branch or repository with stable version. It is in other rep, under different source control system? I see no problem in that too.

The refactoring efforts are also a point of concern, primarily as they are extremely likely to cause a break in backwards compatibility. This is a major issue for those who understand AGS. The common regard is that a more stable 3.2.2 should be developed prior to integrating refactoring efforts, and the latter can be implemented in a later version (discussed as a potential AGS 4.0). This would allow the refactoring to break a few things here or there without having to worry about disenfranchising the 3.2.* branch of the program.

Hmm, that was in my primary concern to not break anything whether it is compatibility or anything .
I seriously believe that 3.2.* branch should be made cleaner by refactoring - this would allow it to remain up-to-date even further and with lesser effort. Or maybe it should be some AGS 3.3.

It seems you are doing a GREAT refactoring work, would you like to set up a development blog? So your effort would gain more visibility in the community.

Erm. My results there are quite raw at the moment. I did some mistakes and it ended up in a messy code structure. Right now I am checking Sonneveld's implementation to use his ideas and clear things up a bit.
But, yes, I finally splitted that ~30k line ac.cpp (and all other big files there).

I feel reluctant about any kind of "development blog" right now. My work won't affect 99% of AGS users, in other words those who do not work on code themselves.
My branch has yet to be tested under other platforms; and there are some fixes that need to be done prior to that (I mainly focused Windows). Tobias Hansen (aka Tobihan) is fixing Linux compilation right now.
I actually hope I will be able to give my work to JJS and thus make my code useful to community.

In the office where I work a sheet of paper is attached to the door of the programmers' room:

Theory is where you know everything but nothing works.
Practice is where everything works but nobody knows why.
Here we combine both theory and practice:
Nothing works and nobody knows why.

They can be loaded from disk on all platforms.

Well, this is one of the cases I am glad I was mistaken

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?

*Fun involves C++ programming. Might not actually be fun.

Hahaha, depends on how you look at that

From what I see in the AGS code right now, there's only one place where this macro is defined: AGSBlend plugin (by Steven Poulton ).

I believe you should add these declarations:

Code: "AGSBlend.cpp"

#define STRINGIFY(s) STRINGIFY_X(s)
#define STRINGIFY_X(s) #s

EDIT: or use C sprintf function to format string

Code: ""

char longstr[100];
sprintf(longstr, "Plugin needs engine version %d or newer.", MIN_ENGINE_VERSION);
engine->AbortGame(longstr);

WARNING: unsafe code, do not use that at home (hypothetically may cause overflow).

That looks beautiful, but is it possible to add "quick-find" input box to the Index page that would scroll list down to the first match found?