Messages

I haven't played ArmA 2 for a while, and I was never any good at it, but I do enjoy it (even though I spend most of my time getting shot to pieces and shaking my fist at the screen).

Definitely re-downloading A2 + OA and joining the group!

Do you use any mods? I've never played with ACE/ACRE, so I've got no idea how to set them up or use them.

By default, I think it probably does. There's also a DirectDraw graphics driver that you can switch to in the game setup.

Liked the video - I look forward to seeing more!

It'd be great fun to see you play through one of my games - I'd recommend Plan M.

I've actually got my (semi-transparent, 'ice blue') GBA sat in a box next to me. It gets as much play as any other handheld I own, which is something of a testament to its longevity!

Mario Kart Super Circuit and the previously mentioned Golden Sun are probably the best titles I own. It also has the brilliant Ecks Vs. Sever and a decent port of Doom!

Aha - yep, just scrolled back up to my code snippets and saw the problem (I didn't test any of it before posting, sorry).

In room_RepExec, you'll need to reset the timer after the set of if statements, e.g.:

Code: AGS

function repeatedly_execute(){
    if(IsTimerExpired(1)){
        if(tutorialState==0){
            Display("Reminder");
        }else if(tutorialState==1){
            Display("A different reminder");
        }else if(tutorialState==2){
            Display("Hopefully you get the idea now");
        }
        SetTimer(1, 400); // Set the timer back to 10 seconds
    }
}

This makes sure that the reminder timer is reset every time a reminder is given.

And yes, room_RepExec is quite probably the correct function name - just use whatever you're given when you add a 'repeatedly execute' event through the room's properties panel

Are you doing anything at all in repeatedly_execute (either in the room script or the global script) or repeatedly_execute_always?

When GUIs are set to hide while interface is disabled, they disappear for a huge number of things, including Say and Wait commands. The cyclic nature of the 'flickering' sounds an awful lot like something is causing the GUI to hide itself, rather than a graphics error. The fact that changing it to 'display normally' fixes the disappearing issue only makes me more sure that its a problem with something blocking.

There must be something somewhere which is running continuously, and occasionally executing a blocking command.

Oh, I forgot to add, but I'm sure you can work it out - to make the verbs only appear as they are introduced, simply disable all the verb GUI controls in game_start(), and then re-enable them one-by-one as the tutorial progresses.

Don't forget to make sure they're all turned on if the player skips the tutorial, though!

The alternative method is to have a 'give item' option that exits the dialog, stores the character you're talking to (global Character*), and shows a separate inventory window (which may look identical to the normal one, if you want it to be consistent/undetectable).

When you click an item in this GUI, it sets the active inventory and a global 'talkAbout' boolean, and runs a function to interact with the stored character. The 'on use inventory' function for the character then needs to check for the 'talkAbout' boolean (so it knows whether or not you're trying to use the item on them outside of a dialog) and react appropriately (hiding the inventory GUI). This interaction will be your standard inventory use structure (if player.activeinventory==iInterestingItem then...).
After whatever the interaction involves, set 'talkAbout' back to false and resume the dialog where you left off.

Code: AGS

// In the dialog script, when you click the '[Show Item]' option
option 6:
Ego: Let me show you something...
    gcInventory_TalkAbout.visible = true;
    storedChar = cfriendlyMan;
stop

Code: AGS

// Global script

function gcInventory_TalkAbout_Items_OnClick(){ // Clicked an inventory item in the custom GUI
    gInventory_TalkAbout.visible=false;
    talkAbout = true;
    storedChar.RunInteraction(eModeUseInv);
}

function friendlyMan_UseInv(){
    if(talkAbout){
        if(player.ActiveInventory == iInterestingObject){
            player.Say("Look at this!");
            friendlyMan.Say("My my, that is interesting!");
        }
        
        talkAbout = false;
        dFriendlyTalk.Start(); // Resume the dialog at this point - if there is more than one, you'll have to store which one was active, as with storedChar
    }else{
        // Player is trying to actually use an item on this guy
    }
}

function gcInventory_TalkAbout_Cancel_OnClick(){ // Allow player to cancel the show action, and go straight back to the dialog
    gInventory_TalkAbout.visible=false;
    player.Say("Actually, never mind.");
    dFriendlyTalk.Start();
}

[Optional expert difficulty:]

I did something almost exactly like what you describe at the start of Astroloco (check out the demo here to see it in action at the start of Act 1).

I'd do it like this:

Code: AGS

// Room script
int tutorialState = 0;

function room_AfterFadeIn(){
    if(tutorialState == 0){ // Tutorial hasn't been started yet, so start it
        Display("Hey! You should interact with that hotspot in some meaningful way!");
        tutorialState = 1;
        SetTimer(1, 400); // 10 second timer, GO!
    }
}

function repeatedly_execute(){
    if(IsTimerExpired(1)){
        if(tutorialState==0){
            Display("Reminder");
        }else if(tutorialState==1){
            Display("A different reminder");
        }else if(tutorialState==2){
            Display("Hopefully you get the idea now");
        }
    }
}

function hMeaningfulThing_Look(){
    Display("Awesome! You win at adventure games!");

    if(tutorialState==1){
        Display("Now you should totally do that other cool thing that you can do!");
        tutorialState = 2;
        SetTimer(1, 400); // 10 second timer, GO AGAIN!
    }
}

Fill in more event handlers as you need to, to complete the tutorial. To end the tutorial (at the end, or on room_leave, for example), just stop the timer ( SetTimer(1, 0); ) and set tutorialState to its final number. To reset it, set tutorialState back to 0.

Optional expert difficulty:
You can make the tutorial more readable by replacing the 'raw' numbers of the tutorialState variable with an enumerator at the top of the script like this:

Code: AGS

enum TutorialStates{
eLookAtThing,
eOpenOtherThing,
eTalkToNPC,
...
}; 

Now, instead of 'if(tutorialState==1)', you can use 'if(tutorialState==TutorialStates.eLookAtThing)'. It's longer, but you can use auto-complete, and it makes reading it back later a hell of a lot easier.

At least the Find & Replace tool works, so it shouldn't be too much work to rename them

SetMultitaskingMode(1);

Another really simple solution: make the GUI the same size as the game screen, and add transparent borders to the background image you're using. Now you can use the regular OnClick event for the GUI to close it.

The only recommended extra work would be to add some simple checks to only close the GUI if the mouse is outside the 'active' rectangle where the visible GUI lives (super easy stuff - if((mouse.x<20 || mouse.x>620) && (mouse.y<20 || mouse.y>420), for example). It'll still work without the extra checks, but in my experience it means there's a tendency for the player to accidentally close the GUI by mis-clicking.

Any updates on when any video from the event will surface?

Ah, that's a relief.

I've always put the asterisk after the type, but I've seen a few forum posts (and I'm pretty sure there are even a few instances in the AGS manual) where people have done it the other way around. Wanted to make sure I wasn't doing something wrong!

Can someone please explain the difference between these two variable declarations?

Code: AGS

Character *myCharacter = cEgo;
// and
AudioChannel* myChannel = aSound1.Play();

What is the effect of the asterisk being before the variable name as opposed to after the type, and vice versa?

Regarding making enemies run away convincingly (without hard-coded co-ordinates), there are two methods that I can see:

• Programmatically search for a point in the rooms walkable areas which is far away from the player. You could do this by testing points in a circle (of radius maxFleeDistance) around the player object. If nothing is found, try making the circle smaller, and repeat.
• In each room with enemies, have a pre-built array of points which are good 'running away' spots. Have the enemy check through the array when they want to run, and pick one of the points either at random, or which is far away from the player (and requires that they don't run past him, although you could code in the super-cool ability for enemies to knock down the player as they flee). You'd probably also want to add some jitter to the point when it is used, so they don't always run to exactly the same spot.

Now I feel bad for derailing the topic

Bacon.

The reason they've not pulled it from the site is twofold, as far as I see it:

Firstly, if they pulled it they'd only be creating bad feelings against themselves. Sure, the software wasn't meant to be free (well, officially it wasn't; see below), but you know how entitled people feel these days. It was available, so it should remain so, as a positive PR exercise. Now people will be thinking 'good on Adobe for not shitting their pants over this' instead of 'wow, they really screwed that one up and now they're just trying to pretend it didn't happen'.

Secondly, companies like Adobe and Microsoft wouldn't make anywhere near as much money without piracy. The only reason their software is so broadly popular outside of the business environment is because of how easily it was/is copied. Aside from corporate/educational licensing, they make their money because people voluntarily lock themselves into using the software. They learn it inside-out, and don't want to change over to use anything new because they'd have to learn a new system. We've all been there - I actually grabbed Premiere 2.0 from the site when it was first announced for precisely this reason.

The site licensing is merely the icing on the cake, because not only does it bring in the big bucks, it ensures that a proportion of people will be using their products over a long period - perhaps even an entire working lifetime. You get a (probably illegal) copy of the Adobe suite at home because it's what you're learning at school and it's easy to get a 'free' copy. You are taught how to use the Adobe suite at college/university because 'it's what professionals use', and when you go into work you use Adobe software because 'that's what everyone knows how to use'. It's a beautiful system, really.

Why do you think Adobe/Microsoft/Autodesk do such great student licensing deals? It's in their interest to flog their software, dirt cheap, under an 'educational' license - it practically guarantees that the user will keep using the software for years to come, and it reinforces the status quo. The only reason they don't give it away for free is because they know that many people will still pay if the price is low enough (or the schools will cough up on the students behalf).

Sorry to go off on a rant, and I'm not for a minute suggesting that the Adobe suite isn't great software - just pointing out that it's almost certainly worked out in their favour for this to have happened, and that's why they've not removed the downloads.

Myth confirmed: The full game will have achievements!

20 of the time-sucking little bastards, in fact. For those of you who need more challenge to your adventuring.





They're not stored anywhere, by the way, since I didn't want to start fiddling around with writing files. The challenge is to see how many you can get in one playthrough. If we manage to get onto Steam, we can hook into their API for persistence.