Messages

Thanks for the detailed answered.

I think that monkey05_06 has modified Native.dll, because when I download his branch, it won't compile, it says it's missing a definition for "UpdateRegionCount". I works with neither Native.dll from AGS 3.4.0.6, nor the one in \Editor\References

Do you thikn I'm overlooking something?

These changes are located in the "multi_room_edit" branch. I would advise to use them as a reference, but there is one problem: there are things that are not (yet) compatible with neither 3.3 or 3.4 release, so blind copying won't always work.
https://github.com/adventuregamestudio/ags/commits/multi_room_edit

Dammit, I skipped that branch because I thought it was only targetted at multiple opened rooms, not the file format too

[Now a Wiki entry :]

Now a Wiki entry : http://www.adventuregamestudio.co.uk/wiki/Compiling_AGS

Dammit, I can't seem to get rid of that "http error 407". It worked for a while, and now AGS won't connect to the TFS anymore. I tried erasing my credentials in Windows' password vault, but to no effect.

Naive question here : What is the current technical difficulty for storing rooms as plain XML, at the moment, apart from "someone has to do it" ?
I mean, I know the code has to be compiled and stuff, and then it all gets binary stored into the CRM file.
But like, is there a genuine catch? For example: is it tricky because it's complex to insert a hook somewhere in the CRM compiling process, or anything like that?

If not, I could lay the base for that in the git repo. I've just pulled an "ouxx" branch.

[AND]

The entries made in Game.agf are sprite properties (Width, Height, Alpha Channel flag, etc), including path to the source file. This path is needed only when you use "Replace from the source file" context command, otherwise it may be ignored. So, for new sprite, you probably need to commit [Game.agf AND (acsprset.spr OR the sprite source file)].

I use that all the time.
I think I'll have two different repositories. One for the code (where I constantly do check-ins check-outs) and one for the sprites, that each developer is supposed to download locally before he starts working, but almost not modify. And they should download it to a given location that matches the sprite's source location.

[TUTORIAL]

TUTORIAL: One possible way of integrating AGS with a "modern" source control system
("modern" = not SourceSafe, which is discontinued)

This tutorial assumes that you have a notion of source control, and understand basic notions such as code check-in, code check-out.

1. Go to the CodePlex website. They host opensource projects for free. Create an account, create a project
2. when you create a project, select "Team foundation Server" (a.k.a. TFS) --> "Team Explorer". Note 1 : You could use any other system (git?) but you'll also need an MSSCCI provider that works (see below), and so far I only know how to find one that works with TFS. Note 2: You could install a TFS server yourself, but that's a lot overkill.
3. On the website, navigate to your newly created project, and click on the "connect" button, which gives you connection details. Notice the url (something like https://tfs.codeplex.com:443/tfs/TFS40 ) and the connection credentials (something like snd\YOURLOGIN_cp )

Now you have an online code repository. And you have the code Editor (AGS). But AGS does not offer the GUI options to use the features of the source control. You need something in-between. AGS can only display the source-control-related buttons and windows if they are "installed" on your computer, as a sort-of standalone program, which is called an "MSSCCI provider". You need to install an MSSCCI provider that is able to connect to your newly-created TFS server.

4. Go to https://visualstudiogallery.msdn.microsoft.com/06c8e056-7f77-4a5c-9b8b-49318c143df8 This is an MSSCCI provider that works for TFS (that's what you want because TFS is the kind of server you picked on CodePlex) and that works with 32-bits systems. I believe AGS can only recognize that but I'm not sure at all.
5. After the installation, open your AGS game. File-->Add to Source Control. You will be asked for the TFS server address (use info from step 3.) and then your credentials (use info from step 3. again)
6. From this point on, every time you modify a file (either by typing text into a script or adding a sprite through the GUI then saving) the Editor will ask you if you want to check out the file. Then at any time you can go to File-->See pending check-ins. That opens a custom window allowing you to see file histories, compare, etc. Finally, you can check in your changes.

Note: It work for a short while then I kept having error 407 in the Editor. If someone has an idea...

About the sprites: I'm not sure how what you're saying relates to the "put sound and sprite files in source control" option.

If you check the option for sound and sprites the Source Control integration will add the files Crimson Wizard mentioned on check-ins. That's what the feature does, it adds "acsprset.spr" and "sprindex.dat".

Yes, that I understand, but once I know that, I still know nothing. when I add sprites in a source-controlled AGS project, I've observed that it checks out/in game.agf. IIRC, "acsprset.spr" and "sprindex.dat" are just cache files? What is the immediate consequence of having checked-in an up-to-date game.agf, but leaving out those files?

You're probably better off using independent tools outstide the editor like Crimson Wizard and Khris has already mentioned. Using a fine tool like Git Extensions or TortoiseGit complimented with a good gitignore would give you capabilities identical to the AGS integration, minus the menu-dialogs.

Yes, but my goal would be to add an Editor plugin adding permissions to some actions (e.g. "add a sprite") and manage the check-in/check out in a manner that is as integrated as possible.

About the sprites: I'm not sure how what you're saying relates to the "put sound and sprite files in source control" option.

I'm going to try. However I can't find any tutorial explaining how to hook up any non-MS repository (non-SourceSafe, non-TFS) to MSSCCI. I'd like to start off with a local, lightweight SVN or git server. If anyone has a lead...

I had actually read this article's online version after doing a few Google searches.

2.1. Has anyone ever (ever!) installed Sourcesafe to use it with an AGS game?
2.2. Is it relevant to install SourceSafe nowadays, since it's not supported anymore? do you think TFS also implements MSSCI and would be detected by AGS?
2.3. I'd still be very interested in hearing the experience of someone who added sprites to source control.

You should probably check out Manual -> Other Features -> Source Control Integration

Dammit I had no idea such a section existed in the manual.

Tell me everything you know about source control in the latest AGS Editor ( 3.4.0.6).
I know what source control is.

But:
1. how do you put it in action in the AGS Editor? typically: provide a scenario where I can see the checking-in and the checking out? (I imagine we're talking script files here?)
2. How would you set the source control provider using the Editor Gui? (or outside the Editor Gui?)
3. What is the "put sound and sprite files in source control" option? How does it work? Please illustrate with a typical conflict.
4. In the Editor plugin API, I can see the objects below. Can you give a basic code snippet using any of these, for doing ... well, anything at all (your choice).

Code: ags

_editor.SourceControl
_editor.SourceControlProvider

At the moment I'm trying to figure out AGS source control, possibly to contribute or at least to explain it as extensively as I once explained fonts.

[Z]

I'm not sure but player.Z could be of some use here.

Quick answer: there are already modules that do multidimensional arrays.

We're working on a tool that automatically brings back the player to a given place in the game (that's easy) but with a full console that allows you to enable or disable inventory items and logical quest variables (e.g. HasSpokenToMerchant).
We also have a script language that you can store in external txt files that automates all that so that the player would never have to deal with the script himself/herself.
This, combined with a small wizard meant for the player ("in your saved game, have you spoken to the merhant? Yes/No"), would be a workaround to "recreating" lost game progress after applying a patch.

#2 is the biggest issue. And the one that gets us the most complaints. I'm surprised this hasn't been addressed yet.

There was a module where you'd change the graphical settings in-game and the game would "reboot" itself and immediately reload the autosave it did before quitting.

The tween module is a nice icing on the cake to make the pieces move smoothly.
Also, as you saw, snarky uses room Objects instead of a gui with Buttons.

What we both do is using an array to manipulate the tiles based on their index, hence avoiding the hassle of giant "if" blocks and having to name each tile by its individual name. That's the central part, that beginners usually have trouble understanding.

Hello,

Warning: I'm not sure that slasher's answer is related to your issue at all.

Here is my suggestion :

Note: If you're confident with programming, you can base your puzzle on rendering each tile individually onto one large Drawingsurface, using the graphical built-in functions. Imho, that would be reinventing the wheel.
I think this would be much easier:
1) Create as many GUIButtons as there will be tiles. The advantage of GUIButtons is that: a) you can set an image into them. b) you can intercepot the click onto them. Please note that this could be a pain if you had many tiles, but since you have only 9, this will be easily manageable.
2) For convenience, create a module where you will put all the logical code for your minigame (if you need some help, ask). In the header, create a struct that represents the minigame, containing as many static functions as there will be possible actions in your game (for example: import static void on_click_tile(int whichTile); that will be called when the player clicks on one of the tiles.
Example;

Code: ags

struct MyMiniGame
{
   import static void on_click_tile(int whichTile);
};

If you have no idea about modules, then put all the code on the main script, I personally hate doing that.
3) Inside your module's body, create another struct that you will use to represent the individual tiles. for example something like this:

Code: ags

struct TilesStruct
{
     GUIButton* button;
     int positionX; //the position in the GRID (x=0, y=0 means top-left. x=2,y=2 means bottom-right)
     int positionY;
}
TilesStruct tilesArray[9];

You can now access the data of any tiles. for example, tilesArray[0].button.X will tell you the X coordinate (in screen pixels, inside the Gui) of the very first tile (tile #0)
4) Still inside your module, add standard function game_start() . This function is automatically called by AGS when the game starts.
5) Inside that function, bind all the GUIButton of the Gui to your data structure:

Code: ags

tilesArray[0].button = MyButton0;
tilesArray[0].button = MyButton1;
...
tilesArray[8].button = MyButton8;

the advantage of this is that from now on,  you can now manipulate the buttons only by using their number (0 to 8) and doing abstract calculations on that, without needing to write hard-written code for each button (MyButton0, MyButton1...) which is always a pain in the back.
6) In the Editor, create the "click" event/function for each button, and inside, call the function that you created earlier to react to a button click.
Example:

Code: ags

//this function created automatically by AGS when you set a "any click on button" event in the Editor.
//there will be 9 functions like this
function MyButton0_OnClick()
{
    MyMiniGame.on_click_tile(0);
}

Now you have the skeletton. You still need to program the logic of the game (which tile can move in which direction, etc.)
I just gave a general explanations without detailing each step.
If you have any questions, don't hesitate. Ask!

Like CW said, don't hesitate to try copying the game files into a folder with the brand new executable of the engine. If it works, then it enables much more graphical options, with less bugs.

Dear Cassiebsg and Frikker, why not join this wonderful yet ambitious Indiana Jones-project?

+1