AGS 3.5.0 - RC 5 (new upcoming version)

Started by Crimson Wizard, Tue 30/04/2019 20:38:49

Previous topic - Next topic

eri0o

#180
It was never in the manual, the templates on the manual are the ones that have been there for historical reasons. Do you have a link to a README or other type of manual you can point to be added there? This 9verb text needs to be replaced for the tumbleweed template and a text describing it. Maybe it's interesting to add screenshots for each too.

The templates in AGS comes from here. :)

Edit: I think I found tumbleweed docs, but I need help to get this in a single markdown page to be placed in the manual.

abstauber

I'm also not too happy with the .rst file format. The only reason I used sphinx and .rst was that I could compile a chm file. Yet I still don't know, what the incomplete community version of the manual is :P

eri0o

#182
Sorry, I mixed up rtf and rst, I can take a look on this tonight.

Edit: @abstauber, I added in the ags-manual/wiki/Tumbleweed.md, I just need to fix some small details before linking it in the new template entry on the manual. I added a brief mention of your name and the template license at the top, please tell me what you think about it. Notice you can also edit it on GitHub.

abstauber

I think, it's amazing  :-D Did you convert it all by hand? And this should also be provided within the template file?
Nontheless this is way better than the .rst files. So I'd say - as long as I can edit the new Tumbleweed.md , there's no need to maintain seperate manual files in my repo.

eri0o

#184
I used Pandoc for doing the conversion, and manually fixed the links. I think maintaining it in it's repo too is good, even if you do it in this Markdown format. Please check if I accidentally removed anything.

The wiki should be editable by you when you click the edit button while logged on GitHub.  :)

bx83

I finally have a proper example of my non-scaling walkable area problem.

Below is the images of walkable area 1 - this was after the error started to happen, but before I had a chance to edit (accidentally or intentionally) the walkable area:




This is after I repaint the walkable area as id 2, and change the front scaling to 100 (from 110):




Finally I decided to change the scaling to 100/40. This area still works up until posting



Here's a zip of the room+code:
https://redrom.ltd/img/room35.zip

Crimson Wizard

#186
@bx83, I do not know what to make out of this case, because when I import this room into a new game and repaint area 1 the scaling works correctly - from full size to 50% size.

I think it may help more if you could send either a room where broken area is not touched at all (as in not even repainted), or a compiled exe where area does not work.

E: I can see on the first screenshots that area 1 actually does some scaling, perhaps not exactly what is intended though. But character is definitely smaller (maybe like 20% smaller) when he walks far away.
In theory this mistake could've been created if you put extra pixel for area 1 somewhere higher up in the room (because then it will think that min scaling should be at lower Y value). But idk if that's the case as I dont see any stranded pixels on a screenshot or in the room.

bx83

Maybe area 1 is scaled from the actual top of the area (y=O) and the actual bottom (y=768) instead of the top and bottom *of the area painted*? (y=500 to 768 approx)

I'll wait til it happens again and then submit the unchanged room.

Crimson Wizard

Quote from: bx83 on Mon 23/09/2019 20:09:49
Maybe area 1 is scaled from the actual top of the area (y=O) and the actual bottom (y=768) instead of the top and bottom *of the area painted*? (y=500 to 768 approx)

This could make sense also. Maybe AGS does a mistake when looking for the mask's stretch at some point, or saves wrong values.

eri0o

There's a key which I don't remember now to show Walkable areas in the game itself, I think using it when it happens in the game could be helpful.

bx83

The Frame counter on Views will not go above 100:


Crimson Wizard

#191
Quote from: bx83 on Sat 28/09/2019 08:54:55
The Frame counter on Views will not go above 100:

It works for me... created 107 frames and frame field goes to 107.

EDIT: Alright, I see what's wrong, it does not go above 100 when animating for some reason.

BTW, there's a "run next loop" checkbox that allows you to split loops in smaller ones and force to run in sequence.

bx83

When animating, yes. Is this a feature or a bug?

Crimson Wizard

Quote from: bx83 on Sun 29/09/2019 07:31:16
When animating, yes. Is this a feature or a bug?

Looks like a bug, yes.

Crimson Wizard

#194
Update: AGS 3.5.0 - RC 1

First release candidate. There are few known issues, but they are not critical imho and hopefully will be fixed soon.

Installer (testing out): https://github.com/adventuregamestudio/ags/releases/download/v.3.5.0.17/AGS-3.5.0.17-RC1.exe
ZIP file: https://github.com/adventuregamestudio/ags/releases/download/v.3.5.0.17/AGS-3.5.0.17-RC1.zip
(zip file now includes Linux pack too)

Changes since Beta 7:

Editor:
- Disabled sending crash reports and anonymous statistics, because of the AGS server issues.

Script API:
- Added optional "frame" parameter to Character.Animate and Object.Animate, letting you begin animation from any frame in the loop.
NOTE: this may be counter-intuituve, but for compatibility reasons the reverse animation begins with frame-1: this is because passing default 0 will make reverse animation begin at the last frame, so we pretend it wraps the loop and steps one frame back.

Engine:
- Fixed potential crash that could happen when switching between fullscreen and windowed mode, or switching back into game window (only observed on Linux for some reason).


Also

Editor regressions and fixing new features:
- Made new Sprite Import dialog commence import by pressing Enter
- Fixed audio clips got ordered in game incorrectly after importing old project
- Fixed detection of installed Linux build pack
- Fixed "Assign sprites to view" command
- Fixed "Copy coordinates" context menu not shown in some of the room editor's modes
- Fixed false reports of game "not able to shut down properly"

Engine regressions and fixing new features:
- Fixed few recent regressions related to wrapping text lines
- Fixed potential crash which could occur when loading saves made in games with large amount of dynamic objects

Dualnames

I've set SetMultiTaskingMode to 1 or whatever the value is that means that the game's loops continue when alt-tabbed, however the game seems to not do that on fullscreen.

EDIT: And I've replied my own question "Note that mode 1 does not work with some graphics cards in full-screen mode, so you should only rely on it working when your game is run in windowed mode."

Question regarding
Quote
- Added optional "frame" parameter to Character.Animate and Object.Animate, letting you begin animation from any frame in the loop.
NOTE: this may be counter-intuituve, but for compatibility reasons the reverse animation begins with frame-1: this is because passing default 0 will make reverse animation begin at the last frame, so we pretend it wraps the loop and steps one frame back.

I'm doing this a lot in my code, where EGOTORCH VIEW has 8 frames i believe the frame 7 is the last one. That will continue to work, correct?
Code: AGS

cEgo.LockViewFrame(EGOTORCH, 2, 7);
cEgo.Animate(2, ANIMATION_SPEED, eOnce, eBlock, eBackwards);
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

Crimson Wizard

#196
Quote from: Dualnames on Thu 03/10/2019 19:08:30
Question regarding
Quote
- Added optional "frame" parameter to Character.Animate and Object.Animate, letting you begin animation from any frame in the loop.
NOTE: this may be counter-intuituve, but for compatibility reasons the reverse animation begins with frame-1: this is because passing default 0 will make reverse animation begin at the last frame, so we pretend it wraps the loop and steps one frame back.

I'm doing this a lot in my code, where EGOTORCH VIEW has 8 frames i believe the frame 7 is the last one. That will continue to work, correct?
Code: AGS

cEgo.LockViewFrame(EGOTORCH, 2, 7);
cEgo.Animate(2, ANIMATION_SPEED, eOnce, eBlock, eBackwards);


Yes, new parameter was implemented in such way that all the existing scripts are supposed to work as before. If they won't - that should be considered a bug.

I am not sure though, why do you do LockViewFrame before running Animate? I think Animate always uses its own frame (0, or max-1 for eBackwards), so one you set with LockViewFrame will be overiden immediately.

cat

Not really a bug but a bit annoying:

I'm editing the objects of a room. When I switch to another room to look up something the previous room is closed (okay, can't have more than one open) and the "Edit this room's" field is reset. This is quite annoying because I manually have to select that I want to edit room objects when switching back to the first room.

Crimson Wizard

Quote from: cat on Sat 05/10/2019 14:26:57
I'm editing the objects of a room. When I switch to another room to look up something the previous room is closed (okay, can't have more than one open) and the "Edit this room's" field is reset. This is quite annoying because I manually have to select that I want to edit room objects when switching back to the first room.

It's quite easy to save another field to room design data (*.crm.user file), but I met problems setting selected object when room is opened because editor logic is pretty messy there... will look again in a bit.

cat

I'm not sure if this should be saved per room or globally. I can see use cases for both.

SMF spam blocked by CleanTalk