AGS 2.61 Final now released!

[Gilbert]

heh ssh you're right about the variables, I don't even know they exist (as I'd never used this feature), but yeah the correct size should still be set when you load that as a sprite.

I'm not sure but I think that may not be related to the resolution-not-initialized-yet problem, as I think these size variables were just set as some numbers you required and are not accessed normally until you really save a game.

[Scorpiorus]

As far as I understand it, both the game.screenshot_height / game.screenshot_width variables and the height and width parameters of the LoadSaveSlotScreenshot function specify the resolution of the sprite. Thus, on game being saved AGS copies & resizes the entire screen using values stored in game.screenshot_height / game.screenshot_width vars, then it saves a picture to a file. On LoadSaveSlotScreenshot function being called AGS reads the image from the saved file, creates a dynamic sprite, and copies the resized (using LoadSaveSlotScreenshot height/width vars) image into it.

I tried to play with LoadSaveSlotScreenshot function but was unable to replicate the problem.

[Ghost]

okay.

1) in general settings i enable "save screenshots in save games".
2) in game_start i use the game..screenshot width/height and set them to the size of my button (160x120)
3) i rescale the the loadesavescreenshot-thingy to 160x120, too.

i still get the right half of the screenshot cut off, in scrolling rooms and in rooms that are the same size as my game resolution.
I gave up.

since i seem to be the only one having the problem, and since i don't think my code is buggy... could it be my hardware is kinda "in the way"? maybe my graphics card? I use an ANTIQUE ATI Rage2.

[SSH]

Can you try removing your setting of screenshot width/height from the game_starrt fucntion, please? See if it works... Otherwise, I suggest you upload a game template so that CJ (or others) can have a look.

[deltamatrix]

Looks like you forgot to put repeatedly_execute_always in the script shortcut menu.

A option to create custom shortcuts for your functions would be nice in the future.

[Gregjazz]

Well actually the thing that I noticed the most to do with the "repeatedly_execute_always" thing was the lack of the "section start" and "section end" tags that have been lately added to the rest of the scripts. No biggie.

[Radiant]

* It appears that objects and characters ignore walk behind #15.

* Object 0 disappears when using MoveObject. Sorry, that wasn't a helpful one, now was it? It only sometimes happens

* When you delete an object, its baseline is still visible

* If I put an infinite loop in the on_event(ENTER_ROOM) part, the game hangs and can no longer be aborted with alt-f4

* When you use SetCharacterFrame, that character's actual picture is still modified if it is walking (That may be what you intended but it isn't clear from the help file).

* I would find a function MoveCharacterToXYWhileAnimatingInLoopZ really useful.

* A 'GetWalkbehindBase' function would be very nice. So would 'getwalkbehindat (x,y)'.

* In the sprite manager, a useful functionality would be to 1) increase sprite size by one transparent line of pixels, and 2) move everything in the sprite one pixel to the left/right (both usable for aligning sprites so that they join well together in a view)

* and finally, how about being able to select views by name from the character editor? Or sorting views by name rather than number on the view list.

* My compliments on the stability of AGS; last weekend I tried multi-importing several thousand BMP files all at once, and AGS never even choked.

* However, when multi-importing, the entire folder of sprites is somehow recached in memory and displayed after each individual image is loaded; this means that the process gets linearly slower if you import a lot (i.e. it goes 'load a sprite - display all sprites - load another sprite - display all sprites once more' etc)

[Pumaman]

Looks like you forgot to put repeatedly_execute_always in the script shortcut menu.

As it's a bit of a specialist function, I didn't add it to the Script menu.

Well actually the thing that I noticed the most to do with the "repeatedly_execute_always" thing was the lack of the "section start" and "section end" tags that have been lately added to the rest of the scripts. No biggie.

The sectionstart things are needed for scripts that are edited via the interaction editor. repeatedly_execute_always is never accessed via the interaction editor (it's always accessed manually), therefore there's no need for the tags.

* If I put an infinite loop in the on_event(ENTER_ROOM) part, the game hangs and can no longer be aborted with alt-f4

What kind of infinite loop? If you do
while (1) { }
then AGS should detect it and abort the game after a few seconds.

I'll look into your other comments.

[Radiant]

What kind of infinite loop? If you do
while (1) { }
then AGS should detect it and abort the game after a few seconds.

Yes, like that. If I do it in any other place, AGS aborts with some message about 150001 iterations. However if I do it in ENTER_ROOM, AGS hangs.
(I actually like this abort message a lot, since I have a tendency for using whiles as fors and then forgetting the i++ part)

[Pumaman]

* It appears that objects and characters ignore walk behind #15.
* When you delete an object, its baseline is still visible

Thanks for the report - I've verified these two as bugs and will get them fixed.

* If I put an infinite loop in the on_event(ENTER_ROOM) part, the game hangs and can no longer be aborted with alt-f4

I was just trying this out, but I was unable to replicate the problem. I put:

while (1) { }

into the ENTER_ROOM part of on_event, and it detected it and exited correctly. Can you be more specific?

[Scorpiorus]

I'm not definitely sure if the following problem is related to 2.61 but seems like it is: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=7616.msg185245#msg185245

A link to the snow/rain plugin whose test game has a similar problem with the current AGS version:
http://www.geocities.com/scorpiorus82

[Pumaman]

Arg you're right ... one of the changes in 2.61 beta 6 indirectly revealed a bug.

If you load a pre-2.55 game into v2.61, all the characters get their movemenet and animation speeds set to 0. A character with a move speed of 0 instantly warps to their destination.

I'll try and release a 2.62 beta 1 as soon as possible to fix this problem. In the meantime, there are two workarounds:

(a) Manually set the move and anim speeds of the characters back to how they should be after upgrading
(b) Get a copy of 2.60 SP1, load your old game into that, then upgrade it to 2.61.

Once again, let me clarify this problem only occurs if you load an old game, or a template, that was made with an AGS version of 2.54 or earlier.

Well spotted Scorpiorus, thanks for the info. Sorry for any inconvenience.

[Radiant]

Sorry to trouble you but here are more obscure bugs...

If you have a room with 'player character hidden' and you use FaceLocation (EGO, ...), the game hangs.

An option 'abort game on Warnings' would be very useful in locating those warnings (especially as currently, no line number is given, nor an object/character number if appropriate)

Does SetCharacterFrame() set a character's view so that it must be Released() too? (probably yes?)

If you attempt to save the game with the script editor open, an error message pops up. If you now close the script editor BEFORE removing this error, AGSedit crashes as it tries to taskswitch to the no longer existent script window.

If you test the game from the editor, and the game has an initial warning popup (i.e. midi device not found), both the game and the editor hang.

When you create a new sprite folder and don't give it a name, it may end up with a name from a folder that was deleted earlier.

If a string is too long in a local script, sometimes the editor gives error messages like "unrecognized symbol: \"  instead of "string too long". And sometimes the string is just truncated at a certain point. By the way I thought that strings were implemented as pointers, so how can they be too long?

When you delete an object from a room, the baselines of subsequent objects don't change numbers [e.g. if you delete object #3, object #5 becomes #4. However, the baseline of object #5 remains #5]

[Pumaman]

Does SetCharacterFrame() set a character's view so that it must be Released() too? (probably yes?)

As it says in the manual for SetCharacterFrame, "The frame will be locked to the one you specify until you call ReleaseCharacterView."

If a string is too long in a local script, sometimes the editor gives error messages like "unrecognized symbol: \"  instead of "string too long". And sometimes the string is just truncated at a certain point. By the way I thought that strings were implemented as pointers, so how can they be too long?

When you delete an object from a room, the baselines of subsequent objects don't change numbers [e.g. if you delete object #3, object #5 becomes #4. However, the baseline of object #5 remains #5]

These two are actually already fixed in my latest build.

Thanks for all the reports, I'll look into your other points.