Messages

Okay... This will probably end up being little more than a footnote, but I'm sure it works now. I have clicked the d/load link, opened the zip file and run the game. The character does move.

I'll just try it again... Yes, it works.

No, it wasn't a feature as such. It was a monsterous error that slipped under my inefficient radar. I was trying to be clever...

[Fixed]
Serves me right for rushing, really.

Okay. It's as finished as I can manage for now:



I must admit, having slaved away on this for a good many moons, that this lends itself more to being a minigame than an adventure game in its own right. But then again, it's quite challenging (If that's the right word) so I hope you all enjoy it.

Download it here! (800KB)

Ah, don't worry 

"Great minds think alike." or something like that.

 

Bah, there goes my 'ingenious plan' for being unique... :-[Ã,  It obviously wasn't clever enough...

Nevertheless, mine will be out before the deadline.

Yep. That does it Thanks!

Okay, thanks for offering to have a look.

The purpose of the GUI in the cutscene is - for me - an easy way of providing a flashback of what happened. It is basically a small box, which has a picture background that is changed in the script to make a small 10 frame animation. Once it has finished, it is turned off by the script and the intro carries on its merry way. So, when I don't skip the scene, the GUI comes on and off as expected.

It just seemed to me the simplest solution to the problem of putting in a small flashback... Didn't fancy much else besides (I can be single-minded sometimes  )

Got a nice intro for my game coming along... During it, a GUI pops up and has its background animated to do a flashback of sorts. But I recently made it skippable using the

Code: ags

StartCutscene(eSkipESCOnly);
...
EndCutscene();

tags. It froze when I tried to skip it.

To find the problem I broke the cut-scene into two and kept moving the 'break' further back through the scripted cut-scene until it wouldn't freeze when I skipped it.
It seems that the cutscene didn't like one line in the code where I popped up a GUI. The game froze (It appears) just before the GUI would pop-up. By ending the first half of the scene before it, and starting the second half immediatey after the GUI box comes up, I've got no freeze when it is skipped. It didn't have a problem when I turned off the GUI shortly after.

Is this a bug? Or are the GUIs not supposed to be used in this way?

I've made a sufficiently good stab at something along these lines toÃ, throw my hat into the ring here. All I can say is that (If it gets finished on time) it will be unique.

Not that that means it'll be good...

If you rearrange the equation Pi = Arctan(1) *4, you get tan(Pi/4)=1. (Which, obviously, is correct) So I doubt there's anything wrong with your approximation.

Hmm, I just thought that this was a problem with floating point numbers for all programming languages. Theres a similar problem in C as I recall.

Basically, the minute differences are caused by the conversion from base 2 to base 10 being not-quite-perfect. Or something like that.

I think... But that doesn't explain how the windows calculator gets it right.



One thing you could try is stealing 100 decimal places of pi from a website and somehow outwitting the compiler so that you can use that as your Pie instead. But I'm not sure that Visual Basic will be happy with that.

Alternatively, you could hard code in routines that stop the calculator from giving these wrong results. So if the commands entered amount to tan(Mississippi Mud Pie/two) than instead of working the answer out, an error message comes up. Likewise when a sine / cosine function that SHOULD return 1 / 0 is called for, the answer is simply 1 / 0. Or, for the  trigonometric results that are known, introduce some kind of rounding up/down function that'll make the answer 1 or nought or 0.5 (Sine(Pi/6)=0.5, does that one work for your calculator?)

[not]

I have a scrolling room and I can put the mouse at a part of the screen so that when my character walks towards it, the screen follows him, and stops when my mouse cursor is over a hotspot at the edge of the screen. The cursor changes its view fine (In my game it flashes) and a pop-up bar names the hotspot as is expected.
But this particular hotspot also has a function behind it, to be run when 'Mouse moves over hotspot'. This function is not run when the cursor happns to land on it when the room has scrolled to it. It works fine when you move the cursor youself, but in the case above, it does not.

Hope this helps.

[did]

Yes, I get the gist of what you're saying here.

What I had done before is save my game in the original AGS directory on my drive (Say "C:\AGS\gamename"). When I unzipped the new version I did unzip it to a fresh folder (I named it "C:\AGS27") and then copied the 'gamename' subfolder into the AGS27 folder. So, it would appear that the original bit that ran the compiled game was for version 2.62, but the game file itslef had been compiled with 2.7. Okay. I get it now.

I got around this by doing a straight swap: Replaced the acwin.exe for 2.62 in the game directory with that for 2.7 it compiled without hitch and ran without delay.

Cheers!

Before I was tinkering on a game I was writing with AGS 2.62. However, with AGS 2.7 being provisionally released, I upgraded to it. Having copied over the game files into the folder with the new version (The upshot being "I backed it up before it went wrong") I open the game file in AGS 2.7. I recompiled everthing as I had done in the past when upgrading and after I fiddled with the new stuff I ('Test Game') ran my game in the works.

At first it SEEMED to compile fine. But then, I got an error message:
"Internal error 102 replacing icon - the ACWIN.EXE file was not compatible with this version of the editor. Your game file will have the default icon."

I didn't know why this was (It worked fine with AGS 2.62), but persisted anyway. Then this one popped up.
"This game requires a newer version of AGS (2.70). It cannot be run."

I was perplexed. Finally, I received this message:
"Invalid file format. The file may be corrupt, or from a different
version of AGS.
This engine can only run games made with AGS v2.5 or later."
And then I got worried. :o
Obviously, the conversion process (resaving the old game and recompiling in presumably the 2.7 format) should not make my game corrupt, or in need of a newer AGS thingumybob.

Incidentally, the second 2 errors also occur if I save my game, leave the AGS editor and then manually run my game.

Or is there something I'm likely to have done that I shouldn't have?
Any ideas?

That's brilliant!  I've tried it and it works. Thankyou!

Hi,

Before my room fades in I have the following code

Code: ags

Ã,  // script for room: Player enters screen (before fadein)
int which;
which=0;
SetBackgroundFrame(0);Ã,  
if (GetGlobalInt(6)==1) {
Ã,  EnableRegion(1);
Ã,  SetBackgroundFrame(1);
Ã,  while (which<8) {
Ã,  Ã,  EnableHotspot(which);
Ã,  Ã,  which++;
Ã,  }
}
else {
Ã,  DisableRegion(1);
Ã,  while (which<8) {
Ã,  Ã,  DisableHotspot(which);
Ã,  Ã,  which++;
Ã,  }Ã,  
}
}

So: The plan is that if something has happened (Which would change GlobalInt 6 to 1), the background frame is something, and loads of hotspots are enabled. If not, then they are disabled and the background set to something else. And the programmer in me spots the chance to use a loop to save writing out 8 lines of code for each case. Simple.
But when the room is loaded, the game comes to an abrupt standstill before it fades in and I have the following message:

An error has occured. Please contact the game author for support, as this
is likely to be a scripting error and not a bug in AGS.
(ACI version 2.62.772)

(Room 7 script line 42)
Error: DisableHotspot: invalid hotspot specified

I'm guessing this is because I can't use the variable "which" in enabling / disabling the hotspots meaning I would need 8 lines for my hotspots in each outcome. Is this the case?