Topics

I've noticed that a few AGS games can have a startup program that runs AGS games kept in separate subdirectories.

How can this be acheived within AGS? Or is it in fact dependent on non-AGS programs?

Not worth individual posts, but I haven't found a worthwhile reason to mention them elsewhere.

(General, Win2k)
1) Many AGS games do not unload properly on exit - at least, not on my system. i.e. they remain as active tasks that don't do anything or respond to system messages.
It may be the legacy of earlier versions, or a common (but unnoticed) scripting error/conflict in the games, or just Windows up to its old tricks.
Someone needs to figure out why so that it can be addressed at whatever level the fault lies.

(AGS v2.56d)
2) Arithmetic has unconventional parsing:
a-b-c-d = a-(b-(c-d)))
a/b/c/d = a/(b/(c/d)))
It took me ages to debug an occurrence of the first case (if it had been the second, a DIV0! might have clued me in).

3) I'm still experimenting with types. It seems that some illegal (or misleading) code is accepted by the compiler even though it doesn't work.
So here is what I believe. Feel free to clear up any misconceptions:

I haven't done much with char or short, so I'll assume they have the same uses as int.

struct may only contain int and int array
array may only contain int

string can be passed (by reference), but not returned by functions.

neither struct nor array can be passed as parameters, returned by functions, or assigned directly. (Passing them by reference would be nice, though).

4) Can't block-comment #defines, and /*/ appears to be interpreted as /**/.

That's all for now.

I found this SWF presentation on technical drawing systems.
It covers the basics well enough to start using them (and also provides the correct names for each system).

Even though I'm far from needing this myself, and that list of yours must already be rather long, I thought I'd better mention this before I forget or some else has problems with it.

Suggestion: Allow user to set which screen angle the game uses for selecting diagonal loops.
Just allowing ratios, x/y in [1..5] would probably be sufficient for most cases (any higher wouldn't have much use for diagonals anyway).

As I understand it, the diagonal loops use screen angles near 45 degrees.
The problem is that the angle at which rooms and characters are typically viewed is very far from a plan view, often almost a side view.
Under this aspect, a 45 degree screen angle corresponds to slightly left/right of vertical world angle, and isn't really useful.

(I thought of a way to cheat in the correct loops for a given aspect ratio using existing features, but it made poor use of resources.)

[EDIT]
Because this post appears to cause confusion, and
because I'm sure people are assuming the original problem has been solved, and
because the answer would be so simple to anyone who knows it,
I'm putting this first:

If you move your mouse as far down and right as possible, it will give coordinates,
mouse.x=WIDTH-1, mouse.y=HEIGHT-1.

All I'm looking for are the global variables or functions that will return the values of WIDTH and HEIGHT.
Something like,
global.thing_width=WIDTH
or
GetThingWidth()=WIDTH

The following shows what doesn't work
[/EDIT: resume normal thread]

Ok, search fatigue impending, time to ask...

My game (ok, sandbox) is at 320x240, all 'letterbox' options are (compulsorily) checked. Good.

Room 1 is 320x200.
game.room_width/height = 320/200. Good.
system.screen_width/height = 320/200.
Eh? But it displays correctly letterboxed on a 320x240 screen.
Okay, maybe only the live area is reported; I can work with that.

Room 2 is 640x400
game.room_width/height = 640/400. Good.
system.screen_width/height = 320/200.
What? No, no, no. The background now fills the entire 320x240 screen, as it should. This kind of information is no use to me at all.

Now, it has occurred to me that somewhere in AGS' ancestral memory, there lurks a conviction that the sacred combination of 640x400 is really 320x200 in disguise.

I'm at a loss to see how I could have created this situation myself. The options just aren't there for forcing 320x200 into a 320x240 setup.

So, is there a way for me to fix this, either by trying some other import approach or using different globals?
I really don't like the idea that I may have to derive the resolution indirectly.

It all started when I noticed that, whenever a non-walkable end point was used, the point reached was always to the left. Not the nearest, or in some symmetrical relationship with the end-point's x, the left.
So I wrote a test program, and sure enough it always tends left and|or up (depending on angle).
In addition some points actually exchange relative positions, e.g. the walk-to of the left end-point is to the right of the walk-to of the right end-point.
The ratio of perimeter-points to found end-points was about 10:1 in my test, but it wasn't really suited to measuring that.

I was also getting the hang of scrolling rooms at the time. Now I haven't done a proper test for this, but it seems to be much slower at coping with the above situation.

I'm not saying that anything has to be done about it, these are just some quirks that tech folk might want to be aware of -- or possibly misconceptions that I can be corrected on.

Is there a function for this? And what about sprite dimensions? The alternatives seem a bit excessive.

On a related topic (since the above would solve this too), how does one find the depth ordering of overlapping objects/characters.

No. Not if you have any consideration for the game writers or other players.

The game title is a suffiently descriptive subject for this forum.

If you must tell everyone how clever you've been so far, there's this whole big message area to do it in.

A new event for on_event(int event,int data),
event=CHAR_STOP, data=CHARID.

It seems that scripters are routinely having to put

Code: ags

if(character[EGO].walking==0){ ...stuff... };

in repeatedly_execute(), which may well be more clutter than they really want in their main loop (bearing in mind that it's all unoptimized bytecode).

Also, I imagine that the engine already knows about this event, and needs only to share the information.

Note: The event of ceasing to walk is not the same as the state of not-walking, but I think this is generally what scripters are trying to emulate. At least that's what I've been thinking about lately (and trying decide how far to go with it).

On Win2k. After the (part 3) end credits music finished, when additional (spoken) audio started. No user action. Flash Player was active at this time.
---------------------------
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x00459B22 ; program pointer is +9901, ACI version 2.53.466, gtags (0,0)

AGS cannot continue, this exception was fatal.
---------------------------

2.21.167 - Carver Island 2
2.21.168 - Night of the Plumber, Monkey Plank.

It seems appropriate given that many of the games discussed and even listed here will not run without DOS or some emulator for there to be a forum here with appropriate information.

I downloaded DOSBox to run on Win2k and have yet to have any success with it.

But of all the computing quirks I have to study, I'm not going to invest much time trawling the net for the arbitrary datum that makes it go
-- or indeed, for the question I would need to ask of those who already know
-- or, examining all of those forums, rules, and subtexts before I am even permitted to ask.

The information could be as accessible from here as the games that require it (as revealed after downloading), if anyone were inclined to make it so.

... or whichever version(s) are actually required to run the following under Windows 2000:

Permanent Daylight (2.15.130)
Larry Vales: Dead Girls are Easy (2.12.097)
Larry Vales: Traffic Division (2.07.069)

The insta-game manual (KillMe.html) says

Load aapalette.pcx (Location: Objects Folder) into AGS as a Background.

Done.

Go to the palette editor and unlock all the colours. The colours at the bottom of the palette editor are the colours from aapalette.pcx.

I can load over the unlocked slots without any problem.

But all I can determine from the IDE tutorial is that, yes, the first 17 colours are locked, and the remainder are not, just as they appear to be. I have yet to find anything that  changes this.

Resuming quote...

Now Lock all the colours again except the colours on the bottom and on the top (Only the black squares in between).

I can only hope that this will be clearer when I get to it.

Basically, I'm just trying to assemble a minimally complete environment from which to try things, and insta-game looks like the place to start.

But in case the score isn't enough info, actual situation follows.

Spoiler

3 of 4 mission tasks completed. I have 12 items, the last of which is the Psych book.

[close]

I think I've done everything with everything, but I'm certainly out of plausible ideas.

I've had trouble with at least one interaction giving an incoherent game state (a clean restart fixed it), so it's hard to know whether I'm missing something or the game's gone off the rails again.

I've restarted the program and a new game, but still get stuck at the same point.

I'm at the stage at which

Spoiler

Pori says that I have the tools that I need and can go to the cave, and have joined the stick and crystal

[close]

. I have (I think) done everything with everything, including every hotspot that the game acknowledges, and nothing new has become available.

[possible]

And by older, I mean compiled with any version prior to the one currently on site.

Is there an archive of earlier ACWIN.EXEs from which it is possible to "obtain the ACWIN.EXE of the same, or as similar as possible, version" (as the Knowledge Base suggests)?

On a related topic, since I'm toying with the idea of trying it out --
What's the expected lifespan of a game made in AGS (before a new version declares it to be an invalid file format)? Or is this strictly a DOS-to-WIN problem?