Messages

[BUG:]

BUG: AGS compiles and runs fine with errors in the script such as naming a View that doesnt exist but later on (and seemingly at random) picks them up and then wont run the game until the code is fixed.
This late detection is rather unusual.

Was this an error in a room script? If so then it could just be that AGS doesn't rebuild all the rooms when you rename a view, so whenever you next try and save the room it will detect the error.

Also, I can't seem to open more than one room at once. I can't remember if this was normal or not. It would be good to be able to edit more than one room for corrospondance between interactions/coordinates/etc.

This has always been the case. You can open multiple room scripts but not rooms themselves.

SUGGESTION (Aesthetic): Switch Character.ChangeView(VIEW) to Character.SetView(VIEW) to stay consistant with objects.

These are different because a character *always* has to have a View, whereas an object does not necessary have a view assigned at all -- it's a fundamentally different mechanism from characters with Change, Lock and Unlock -- hence why the name is different.

Edit: Is there any reason why repetedly_execute in room scripts are named inconsistantly with the global script? It may sound ridiculous but I actually prefer the slightly longer name for aesthetics and clarity sake.

You can name it repeatedly_execute in the Room Events panel if you want... of course there is the wider issue of whether Rep EXec should be a room event or whether it should just be a specific named script function, but this is down to legacy reasons.

eMouseMiddleInv has been added to the beta, IsButtonDown(eMiddleMouse) has not but I will try to squeeze it in before the Final.

This should be fixed in 3.2 RC 2 -- please could you try it out on a backup copy of your game and see if it fixes the problem?

Strange, looks like your Tahoma font might be corrupt.

If you open Notepad, go to the Format menu, "Font", and then choose Tahoma, do you see a "Regular" option?

If not you could try downloading the Tahoma font from the internet and installing it, see if that fixes the problem.

Now here is the strange part, the 11th parameter was eliminated and I expected to get the same results as before - no errors with 10 parameters.  But to my surprise the same error persisted, this time supplying this text in the error message: 'BluBox::Init^10'.
I am also using previous AGS release (AGS Editor .NET (Build 3.1.2.82) v3.1.2 SP1, February 2009).

This was a bug in AGS 3.1.x but should already be fixed in the latest 3.2 RC 2. Could you try it out and confirm that this fixes the problem for you?

Here's an issue, but I don't know what is the right behavior here.
Closing "Music" folder by clicking on Expand/Collapse box on the project tree removes Audio Clip from the Audio page, if one was opened before, and opens what looks like general Music properties on Properties Table.
This ONLY happen if Audio tab is active. If any other tab is active (Room, Script, Dialog, etc) this does not happen.

This is actually the correct behaviour, but I can see how it could seem like a bug. The problem is that because the audio folders (like "Music") have properties themselves, there needs to be a way to edit them -- and this is how you do it.
Because there is a single Audio pane that changes its view as you select different audio items in the tree, this is the result you get.

The other option would be to make audio work like Views/Dialogs where each one opens a separate tab, but then you start drowning in open tabs, I might make it a preferences option in a future version.

Also, I have a suggestion to add a way (a button perhaps ) to toggle repeatitive audio playback on/off

Do you mean the in-editor audio preview? Having some sort of Loop option wouldn't be a bad idea, however this probably won't make it into 3.2 at this stage.

In your situation, would an alternate approach such as splitting the walk-behind area into two separate areas or anything else solve the problem?

Yes, they would. And they did.
There was most definitely an alternate way of doing it. I just thought I might've mentioned my situation.

Thanks ... so is anyone using IgnoreWalkbehinds in a way where there is no alternate method?

Ok, RC 2 is now up. This fixes various issues (including that one!), and although there are a couple more things I need to address it seemed like a good time to get the latest release out there.


Again, if anyone hasn't tried their game with 3.2 yet, please do so now, so that we can find any bugs before it becomes a final official release!

What did you add to the global header?

To clarify, what you should have done was open GlobalScript.ash and add:

import function unhandled_event(int,int);

doing that should solve your error.

I have tried using the compress sprites option, but it made no difference at all.

It's worth noting that the Compress Sprites option isn't picked up until the next time you edit some sprites, so if you just change it and save the game nothing will happen. This is something that will be changed in the next version of AGS so that you can see the difference immediately.

I was wondering... since you've enabled audio panning, then it would make sense to add a property to characters to have the audio linked in their views be panned relatively to their position to the viewport, could it be done ? (if it's not too late)

That's a good idea, thanks. It's too late for 3.2 now, but it's a good idea for a future version of AGS.

I'm experiencing (at random times) issues with open script(s) not having the "dirty" (changed) state of the file updated properly by compiling or even by saving the file directly. I know the files are in fact being saved as testing shows the changes are implemented, but when this happens I can only get the dirty state cleared for that file by selecting to close it, after which I am prompted whether I want to save the changes to the file. I've been telling it yes and there haven't appeared to be any major issues arising from it as I've said.

Well spotted, thanks -- I think this bug has been introduced as a result of a fix that I did in RC1.
The bug seems to happen if a script file is already open, then you go into an Events pane and add an event.

I'll get it fixed.

Sorry for the time to reply, I've been very busy lately.

Does the player character have its MovementLinkedToAnimation property enabled?

If not, try turning it on and see if you still get this problem.
It looks like a bug in AGS if that property is turned off, which I'll get fixed.

Thanks for reporting this issue.

I do see where this would be useful. However, considering the other things on my to-do list, it probably won't make an appearance in the near future.

I see what you mean, there could be an UnlockViewAligned too. But generally, it's assumed that all frames of a particular animation will be the same size which is why this is not currently provided.

In your situation, would an alternate approach such as splitting the walk-behind area into two separate areas or anything else solve the problem?

Yes, some sort of custom pivot point rather than always being the bottom-centre of the sprite would be good, it's something I've been meaning to do for ages.

For now you have the LockViewAligned and LockViewOffset functions to work around this.

Sounds like a reasonable request to me.

Why not make this sticky for a while before we move on?
(Hmmm. Making it sticky may actually make this even less noticeable. Let's see how it goes and unstick it if it's not a good idea.)

Yeah, I didn't sticky it because people usually don't see the sticky threads at all...

I actually ran into this problem today

My situation was that I had a walkbehind, then an object hiding it, then a character who could walk in front of it.

So if I set the baseline to 9999, the player would appear behind the object, which I wouldn't want.

So wait, you had an object in front of a walkbehind and you wanted the character to walk in front of both? Surely just normally set baselines would solve that, or am I missing something?

This is quite a specialized request, so I can't promise it'll feature in AGS any time soon.

Would anyone else use something like this?

That would work, except that 2.72 doesn't support Direct3D so it wouldn't help in this case.

You could try using a 3.0.x ACWIN.EXE in that manner, I can't remember if it was backwards compatible with 2.72 games or not.

Just bumping this thread to make sure everyone has a chance to see it -- I don't want to go ahead and remove these properties, only to have somebody complain that they never saw this announcement!