Adventure Game Studio

NOTE: this version was previously known as 3.4.2, but we decided to rename it to 3.5.0 to indicate the significance of some changes.


This release is brought to you by:

- Alan v. Drake
- BigMC (fixes to building on some Linux systems)
- ChamberOfFear
- Crimson Wizard
- John Steele Scott (OpenGL support on Linux)
- Martin Sedlak (new pathfinding)
- Matthew Gambrell (better threaded audio support and bug fixes)
- morganw
- rofl0r
- scottchiefbaker (fixes to building on some Linux systems)
- sonneveld
- tzachs (new navigation bar for the Room Editor)



What is new in 3.5.0

Common features:
- Support for large files: compiled game, sprite set, room files now may exceed 2 GB.
- Deprecated relative assets resolutions: now sprites, rooms and fonts are considered to match game's resolution by default and not resized, unless running in backwards-compatibility mode.
- Allow room size to be smaller than the game's resolution.
- Removed fonts count limit.
- Raised imported sprites count limit to 90000 and removed total sprite count limit (this means you may have around 2 billions of dynamic sprites).
- Removed length limit on the Button and TextBox text.

Editor:
- Editor requires .NET Framework 4.5 to run. Dropped Windows XP support.
- Editor preferences are now stored using .NET configuration model, instead of the Windows registry.
- Added support for custom UI color themes.
- Game and room templates are now by default saved in AppData/Local/AGS folder. Editor finds them in both program folder and AppData.
- Added "Allow relative asset resolutions" option to "Backwards Compatibility" section. Disabled by default, it makes game treat all sprites and rooms resolution as real one.
- New revamped sprite import window.
- Sprites that were created using tiled import can now be properly reimported from source.
- Added context menu command to open sprite's source file location.
- Using Magick.NET library as a GIF loader. This should fix faulty GIF imports.
- New sprite export dialog that lets you configure some export preferences, including remapping sprite source paths.
- Sprites have "Real" resolution type by default. "Low" and "High resolution" are kept for backwards compatibility only. When importing older games resolution type will be promoted to "Real" whenever it matches the game.
- New navigation bar in the room editor, which allows to select any room object or region for editing, show/hide and lock room objects and regions in any combination.
   These settings are saved in the special roomXXX.crm.user files.
- Improved how Room zoom slider works, now supports downscale.
- Added "Export mask to file" tool button to the Room Editor.
- Added MaskResolution property to Rooms. It ranges from 1:1 to 1:4 and lets you define the precision of Hotspot, Regions and Walkable Areas relative to room background.
- Added "Default room mask resolution" to General Settings, which value will be applied
   to any room opened for editing in this game for the first time.
- Removed Locked property from the Room Object, objects are now locked by the navbar.
- Split GUI's Visibility property into PopupStyle and Visible properties.
- Added Clickable, Enabled and Visible properties to GUI Controls.
- "Import over font" command now supports importing WFN fonts too.
- Removed "Fonts designed for high resolution" option from General Settings. Instead added individual SizeMultiplier property to Fonts.
- Display audio clip length on the preview pane without starting playback.
- Added "Always"choice to "Popup message on compile" preference. Successful compilation popup will only be displayed if "Always" choice is selected.
- Added shortcut key combination (Shift + F5) for stopping a game's debug run.
- Don't display missing games in the "recent games" list.
- Build autocomplete table a little faster.
- Corrected .NET version query for the anonymous statistics report.
- Fixed sprite folders collapsing after assigning sprite to a View frame or an object.
- Fixed view loops displayed with offset if the view panel area was scrolled horizontally prior to their creation.
- Fixed Audio folders were displaying internal "AllItemsFlat" property on property grid.
- Fixed MIDI audio preview was resetting all instruments to default (piano) after pausing and resuming playback.
- Fixed MIDI audio preview had wrong control states set when pausing a playback.
- Fixed script compiler could leave extra padding inside the compiled scripts filled with random garbage if script strings contained escaped sequences like "\n" (this was not good for source control).
- Fixed crash when editor was updating file version in compiled EXE but failed and tried to report about that.

Script API:
- Introduced new managed struct Point describing (x,y) coordinates.
- Implemented Dictionary and Set script classes supporting storage and lookup of strings and key/value pairs in sorted or unsorted way.
- Implemented Viewport and Camera script classes which control how room is displayed on screen.
- Implemented Screen struct with a number of static functions and properties, which notably features a reference to the primary Viewport. Deprecated System's ScreenWidth, ScreenHeight, ViewportWidth and ViewportHeight in favor of Screen's properties.
- Added Room.Camera property that references primary room camera.
- All functions that find room objects under screen coordinates are now being clipped by the viewport (fail if there's no room viewport at these coordinates).
   This refers to: GetLocationName, GetLocationType, IsInteractionAvailable, Room.ProcessClick, GetWalkableAreaAt and all of the GetAtScreenXY functions (and corresponding deprecated functions).
- Added Character.GetAtRoomXY, Hotspot.GetAtRoomXY, Object.GetAtRoomXY, Region.GetAtScreenXY, replaced GetWalkableAreaAt with GetWalkableAreaAtScreen and added GetWalkableAreaAtRoom.
- Replaced Alignment enum with a new one which has eight values from TopLeft to BottomRight.
- Renamed old Alignment enum to HorizontalAlignment, intended for parameters that are only allowed to be Left, Center or Right.
- Added new script class TextWindowGUI, which extends GUI class and is meant to access text-window specific properties: TextColor and TextPadding.
- Added new properties to GUI class: AsTextWindow (readonly), BackgroundColor, BorderColor, PopupStyle (readonly), PopupYPos.
- Added Button.TextAlignment and Label.TextAlignment.
- Added missing properties for ListBox: SelectedBackColor, SelectedTextColor, TextAlignment, TextColor.
- Replaced ListBox.HideBorder and HideArrows with ShowBorder and ShowArrows.
- Added TextBox.ShowBorder.
- Added Game.PlayVoiceClip() for playing non-blocking voice.
- Added SkipCutscene() and eSkipScriptOnly cutscene mode.
- Deprecated DrawingSurface.UseHighResCoordinates. Also, assigning it will be ignored if game's "Allow relative asset resolutions" option is disabled.

Engine:
- New pathfinder based on the A* jump point search.
- Implemented new savegame format. Much cleaner than the old one, and easier to extend, it should also reduce the size of the save files.
   The engine is still capable of loading older saves, temporarily.
- Implemented support for sprite batch transformations.
- Implemented custom room viewport and camera.
- Removed 200 chars limit for DoOnceOnly token length.
- Reimplemented threaded audio, should now work correctly on all platforms.
- Improved performance of hardware-accelerated renderers by not preparing a stage bitmap for plugins unless any plugin hooked for the particular drawing events.
- Reimplemented FRead and FWrite plugin API functions, should now work in 64-bit mode too.
- Made fps display more stable and timing correct when framerate is maxed out for test purposes.
- Completely removed old and unsupported record/replay functionality.
- Replaced number of fatal errors reported for incorrectly called script functions with a warning to the warnings.log instead. This is done either when arguments may be fixed automatically, or script command simply cannot be executed under current circumstances.
- Expanded some of the error messages providing more information to end-user and developers.
- Fixed engine could not locate game data if relative path was passed in command line.
- Fixed potential bug which could cause DoOnceOnly tokens to be read incorrectly from a savedgame.
- Fixed DynamicSprite.SaveToFile() not appending ".bmp" if no extension was specified.
- Fixed IsMusicVoxAvailable() not working correctly in old games which use 'music.vox'.
- Fixed a bug in mp3/ogg decoder where it assumed creating an audiostream succeeded without actually testing one.
- Added Scavenger's palgorithms plugin to the list of builtins, for ports that use ones.

Linux:
- Support for OpenGL renderer.
- Use same FreeType library sources as Windows version, which suppose to fix TTF font glitches.
- Re-enabled threaded audio setting.
- Improved CPU yield function, this supposedly may reduce CPU usage.

Windows:
- Windows version of AGS is now built with MSVS 2015 and higher.


KNOWN ISSUES:

- Reported by Snarky: need to find out which components need to be added to use AGS 3.5.0 on fresh Windows installation.
- Some weird sprite scaling bug in the room editor described in the posts below. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...
- Custom Viewport and Camera properties are not remembered in savegame. Temporary workaround is to save these in variables and restore custom camera in eEventRestoreGame event.
And of course the ones noted at github issue tracker: https://github.com/adventuregamestudio/ags/issues?q=is%3Aissue+is%3Aopen+label%3Abug



On color themes

After launching the Editor, go to File - Preferences. In the "Editor Appearance" group box you will find "Color Theme" setting. If you haven't installed any themes yet the selection list will be empty. Press "Import Color Theme" and select appropriate JSON file, containing theme configuration.
Sample color theme: Dark UI Theme (https://github.com/adventuregamestudio/ags/files/1613027/VisualStudioDark.zip).

There is no specification on theme creation yet, but I hope there will be one at some point. For now you may copy and modify existing one. Themes are in JSON format, which you may edit in most simple text editors. If the theme is broken, the editor will report an error and reset to Default theme on startup.
ChamberOfFear also suggested creating a repository for the themes to let people upload their own and improve existing ones, which we may do in a future.



On new navigation bar in the room editor

This was made by tzachs back in 2014, but got into the editor only now. The feature is working, but may need polishing.

Screenshots (warning - big size):

Spoiler

(http://i.imgur.com/dSAbGb3.png)
(http://i.imgur.com/Fk4YLkw.png)
(http://i.imgur.com/CPkUOwA.png)

[close]

Quoting tzachs (from his old thread) -

- Room Layers

This feature allows you to view (and edit) walkable areas/walk-behinds/hotspots/regions/characters/objects/edges in the same time (as opposed to only seeing one of them at a time, like we've seen before).
Well, not entirely though: walkable areas/walk-behinds/hotspots/regions still can't be seen together (as they use masks and is part of the natives dll so I skipped it for now) but they can be seen along objects, characters, and edges.

- Visibility

Each layer can be made visible/hidden by the push of a button. In addition, for the objects/characters/edges layers each item in the layer can also be made visible/hidden by the push of a button. This will only affect the editor, not the actual game.

- Locking

Each layer can be locked/unlocked by the push of a button. In addition, for each layer, each item in the layer can also be locked/unlocked by the push of a button.
A locked item cannot be moved until it is unlocked, useful to prevent mistakes when designing the room. This will only affect the editor, not the actual game.



On new room viewport and camera commands

This release changes the way AGS handles room viewport. Originally room view was covering whole screen and always drawn 1:1. 3.5.0 separates old viewport into viewport and camera, also changing the meaning of viewport term.

In 3.5.0:
Viewport is a place on screen where room is drawn, defined in game coordinates (e.g. 0,0 - 320x200).
Camera is a place in room which is being drawn, defined in room coordinates

The part of the room "seen" by camera is being copied to the viewport on screen, scaled up or down if necessary.
For example, if you set camera's size twice as small than the viewport, then room will appear zoomed in x2. If you set camera's size twice as big than the viewport, room will appear zoomed out x2.
NOTE: you cannot set camera size larger than the room's background.

To access viewport and camera use new properties: Screen.Viewport and Room.Camera.
Screen.AutoSizeViewportOnLoad boolean value turns automatic viewport adjustment on room load. It is ON by default which corresponds to normal room view you are used to.

Since the relation between screen and room is now more complicated new functions were added to help convert between screen and room coordinates: Screen.ScreenToRoomPoint(), Viewport.ScreenToRoomPoint() and Viewport.RoomToScreenPoint(). These functions return an object of Point type containing (x,y) coordinates.
Screen.ScreenToRoomPoint() returns null if there is no Viewport on screen under these coordinates. This is because if there will be multiple viewports supported in the future then engine simply won't know which to choose having none under these coords.
Both Viewport.ScreenToRoomPoint() and Viewport.RoomToScreenPoint() have 'clipViewport' parameter which tells whether they should return null if the coordinates lie outside of the visible part of the room.


Old viewport functions are now deprecated, they may still be enabled if you set "Script compatibility level" to v3.4.1 or lower.
Here's correspondence between old and new functions:

Old command	New commad(s)
SetViewport(x, y);	Room.Camera.SetAt(x, y);
ReleaseViewport();	Room.Camera.AutoTracking = true;
GetViewportX();	Room.Camera.X;
GetViewportY();	Room.Camera.Y;

As you may see, what was known as "viewport" earlier is now called "camera", and "new viewport" is something that was never supported before.


On savegame format

AGS 3.5.0 introduces new savegame format. This had to be done for several reasons, mostly internal ones, because existing format was too difficult to maintain and expand.
From the user's perspective, the notable change is that save file will be somewhat smaller, because redundant data is no longer written there (I did some tests in the past, and iirc depending on circumstances the size reduction was about 20-40%, but this awaits confirmation).

The new format is completely non-compatible with the old one. This means that if you run some existing game with the new engine, and save a game, that save can't be loaded by previous engine.
On the other hand, new engine can still load old saves. Old saves support is temporarily and may be removed in future.
Keep these two points in mind if you plan on upgrading existing game to AGS 3.5.0.

Ohh... can't wait to try this version, so many goodies I have long longer for! (nod)

Great work everyone and big big thanks!

I can't wait until I come home to try this! Awesome release! :O

Nicely done!

So... does it at least run? Still waiting for confirmation (lol).
I have a suspicion that we will need to make some adjustments to make it run on Windows XP, or even maybe make a separate build for Windows XP. Did not try myself yet.

I can confirm it runs (on win7 64bit) and reads the dark theme just fine. (nod)

Hey CW! It worked great here!

Steps for Linux using Play On Linux (I use Ubuntu 16.04):
- Create a new Play On Linux drive, I used wine x86 3.1 .
- On Play On Linux, go to the virtual drive, and under Install Components, install Microsoft Core Fonts.
- After, still under Install Components, install dotnet40
- I created a folder in Program Files called Adventure Game Studio 3.4.2
- Copy the downloaded AGS files and extract the content in the Adventure Game Studio 3.4.2 folder.
- I placed the VisualStudioDark.json theme there too.
- On Play On Linux interface, click create shortcut from this virtual drive, select AGSEditor.exe, I named the shortcut AGS342.
- done! Just run the previously created shortcut! 8-)

I added a spoiler tag in the image below because it's big.

Spoiler

342 default theme
(https://i.imgur.com/X3QUy6M.png)

with dark theme
(https://i.imgur.com/lw3mG1F.png)

[close]

(my Wine is emulating Windows XP environment!)

I'm testing it with my current game, installed the dark theme and running it on Win 10 64bit.
So far so good!

Uhm... was trying this, but I got an issue, not sure if it's just me.

I started a new project using the BASS template, change res, color depth, proper alpha blending, imported some sprites, created a few views, created 2 new characters, added them to room 1, change the BG in room 1... thus I now have 3 characters in room yet. Yet in the editor I can only see the original character. 8-0
And yes the characters are on the screen and I added a walkable area. If I run F5 I can move my new character and see the other two.

Edit: Okay, I closed the editor and opened it again. Now the characters are shown in the editor. Using the "rebuild all files" doesn't solve it either. Seems like only restarting the editor does. :~(

Quote from: Cassiebsg on Sat 24/02/2018 21:49:44
Edit: Okay, I closed the editor and opened it again. Now the characters are shown in the editor. Using the "rebuild all files" doesn't solve it either. Seems like only restarting the editor does. :~(

"Rebuild all files" compiles the game and does not affect what you see in the editor, so it's natural that it does not fix anything.

To clarify: in the editor you do not see the characters that you have added to the room until you restart the editor? What about closing and reopening room tab?

To clarify: Closing and opening the room tab doesn't help. so far only restarting the editor has solved the problem.
Maybe some others could try this just to see if it's just me or a bug?

My test on it:

Open Room X
Change Character to Room X
Character is not seen on Room X, but you can pick it from the list of characters in Properties for that room
Closing and opening the room tab doesn't show the character

Opening another room and then going back to Room X will now show the character (don't need to restart the editor)

Funny, I can't choose the character from list either (using the dark theme, if that makes a difference).
But can confirm that opening a new room and then returning will fix the character showing. (nod)

Quote from: Cassiebsg on Sun 25/02/2018 01:09:22
Funny, I can't choose the character from list either (using the dark theme, if that makes a difference).
But can confirm that opening a new room and then returning will fix the character showing. (nod)

Do you mean the list in the upper bar? Does it get shown there after changing rooms?

I mean the bar where it shows Room > Characters > cName
If I add a new character to the room and open the room, the character will neither be seen nor be available in that drop down list (is there another place to see which characters are in the room?). opening a new room and then returning will show the character in the room and in the list. Removing the character from the room (or moving it to another room) will remove it from the editor show but still show it on the drop down list. Again these are fixed with opening another room and returning.

(http://www.tom-simpson.com/agschar.png)

cMarket moved to Room 1. I can select them from Properties on the right (and their dotted line box is shown on the background) but I can't see them or select them from the Edit this room's > Room > Characters bit that I can once I reload the room

Quote from: Crimson Wizard on Wed 21/02/2018 13:52:21
Editor:
- Editor uses (and requires) .NET 4.0 and C# 6.0.

Does this means that in the new version we'll be scripting in C#? Nice.

Quote from: Lord Vetinari on Thu 01/03/2018 09:09:18
Does this means that in the new version we'll be scripting in C#? Nice.

Sorry to disappoint but that's not what that means. It's probably a little open to interpretation since Crimson Wizard mentioned C# version which isn't relevant to the end user. Anyway, the Editor is made in C# .NET, and we recently upgraded the .NET version, so now users need to make sure they have the corresponding .NET version, that's all.

I just installed AGS on a fresh Win10 machine, and had to go through an extra step of tracking down and installing .NET 2.0 (which is actually part of the 3.5 package) first. That's the bit that should no longer be needed, since newer versions of Windows cone with newer versions of .NET.

Quote from: Snarky on Thu 01/03/2018 10:56:25
I just installed AGS on a fresh Win10 machine, and had to go through an extra step of tracking down and installing .NET 2.0 (which is actually part of the 3.5 package) first. That's the bit that should no longer be needed, since newer versions of Windows cone with newer versions of .NET.

Which version of AGS did you install?
This new version should not be requiring .NET 2.0 anymore, at least not supposed to.
.NET 2.0 is included in 3.5, I think, but it is not included into the higher versions of .NET (4.0+).

Quote from: ChamberOfFear on Thu 01/03/2018 10:11:44

Quote from: Lord Vetinari on Thu 01/03/2018 09:09:18
Does this means that in the new version we'll be scripting in C#? Nice.

Sorry to disappoint but that's not what that means. It's probably a little open to interpretation since Crimson Wizard mentioned C# version which isn't relevant to the end user. Anyway, the Editor is made in C# .NET, and we recently upgraded the .NET version, so now users need to make sure they have the corresponding .NET version, that's all.

I will rephrase this line in the changes.txt to make it clear we are talking about .NET requirements.

As for scripting in C#, there was a plugin for that once.

Sorry if unclear, I was expanding on ChamberOfFear's answer to explain the reason for/benefit of the update.

I was installing AGS v3.4.1 (latest stable). Doing so required me to install .Net 2.0 first. However, 2.0 isn't actually available as a standalone any more: you have to install 3.5, which includes 2.0. The whole process is therefore a bit confusing. I assume that with 3.4.2 I would just have been able to install AGS without any other steps.

Quote from: Snarky on Thu 01/03/2018 14:36:33
Sorry if unclear, I was expanding on ChamberOfFear's answer to explain the reason for/benefit of the update.

Oh, okay, I thought there was some problem with this version.

Hey guys! ;-D

First of all, congrats for those new cool features! The Dark UI theme and the ability to lock room's layers and individual items brings lots of comfort! Great job! :smiley:

Quick question: as this new alpha focus mainly on the editor and save games, is a game made with this AGS 3.4.2 - Alpha 1 would still be compatible with AGS 3.4.1 - Patch 1 (the latest stable version)?

If not, would you think it's reasonable to start working with this alpha (I guess games made with this version will work on the forthcoming stable AGS 3.4.2)?

I worked with a lot of beta versions previously (from the Custom Resolution build based on 3.3.0 / 3.3.1 to 3.4.1 - Beta 7) and never had any problems or crashes with those versions.

Thanks a lot - and again, congrats for your fantastic job! ;-D

Hmm, somehow I missed this last post in March.

Quote from: declerfayt on Thu 01/03/2018 17:27:47
Quick question: as this new alpha focus mainly on the editor and save games, is a game made with this AGS 3.4.2 - Alpha 1 would still be compatible with AGS 3.4.1 - Patch 1 (the latest stable version)?

If you mean, whether it is possible to move back from 3.4.2 to 3.4.1, then probably yes, for now, because there were not any changes to game format. But there is no guarantee that this will remain so.

Quote from: declerfayt on Thu 01/03/2018 17:27:47
If not, would you think it's reasonable to start working with this alpha (I guess games made with this version will work on the forthcoming stable AGS 3.4.2)?

I guess that this release may be pretty stable. Actually I just removed "unstable" word from the title, because it may confuse people to think that it is crashing, etc. It's WIP, but should be relatively safe. Then again, even the releases that we call "stable" do have mistakes sometimes.
Also, in theory there are always ways to move your project back to previous version of AGS.

I'm building my MAGS on this version, and I just noticed the manual isn't included in the zip... (roll) At first I thought I had accidentally deleted it, but then saw it's not included in the zip... no big deal, I'll just open it from a previous version... just wondered why it wasn't included (morganw suggested it might be cause it's an "unstable/WIP" version...). Just thought I would mentioned it.

Quote from: Cassiebsg on Mon 14/05/2018 13:30:32just wondered why it wasn't included

The most logical reason is that I forgot to copy the file there.

Great job CW as always. Is there a limit of number of module scripts you can create ? Sorry if it was removed before. I couldn't follow it on the previous versions.

Quote from: proximity on Wed 16/05/2018 20:03:12
Is there a limit of number of module scripts you can create ? Sorry if it was removed before. I couldn't follow it on the previous versions.

It was removed, back in 3.4.0 I think.

I'm too close to launch to update to this WIP version. But hypothetically speaking, if I later decide to upgrade, saves created in 3.4.1 should be compatible (assuming I don't do anything that breaks saves)? That's amazing.

Quote from: Dave Gilbert on Wed 16/05/2018 22:08:38But hypothetically speaking, if I later decide to upgrade, saves created in 3.4.1 should be compatible (assuming I don't do anything that breaks saves)?

3.4.1 --> 3.4.2 saves are compatible, because we are keeping legacy save format for some time, in case someone upgrades the actual game or moves to the new version of engine port.
3.4.2 --> 3.4.1 saves are NOT compatible.

Yep. That's what I'm talking about. Sweet. Thanks!

I still did not have a chance to look into the reported bug about characters not displayed in the room editor until you reload the room.

Here's the update though.

AGS 3.4.2 - Alpha 2

Zip archive: http://www.mediafire.com/file/r988x5g4rxg5259/AGS-3.4.2-alpha2.zip

Updated with all changes from AGS 3.4.1 - Patch 2. Also brings some new stuff:

Editor
- Editor preferences are now stored using .NET configuration model, instead of the Windows registry.
- Added "Export mask to file" tool button to the Room Editor.
- Added "Always"choice to "Popup message on compile" preference. Successful compilation popup will only be displayed if "Always" choice is selected.
- Fixed sprite folders collapsing after assigning sprite to a View frame or an object.
- Fixed view loops displayed with offset if the view panel area was scrolled horizontally prior to their creation.
- Fixed TextWindow GUI's elements could be deleted or moved in the editor with key controls.

Engine
- New pathfinder based on the A* jump point search. (by Martin Sedlak)
- Expanded some of the error messages providing more information to end-user and developers.

Quote from: Crimson Wizard on Sun 20/05/2018 17:55:01
- Fixed sprite folders collapsing after assigning sprite to a View frame or an object.

Woohoo! ;-D

Quote- New pathfinder based on the A* jump point search. (by Martin Sedlak)

Interesting! Does it behave any differently, or is it just a matter of performance?

Quote from: Snarky on Sun 20/05/2018 18:49:37

Quote- New pathfinder based on the A* jump point search. (by Martin Sedlak)

Interesting! Does it behave any differently, or is it just a matter of performance?

Perfomance mostly, it is way faster, but requires few extra MB of memory to build a nodes grid. Probably latter could be optimized on per game basis by implementing some options.

It also fixes certain bugs AGS had with complex walkable areas with lots of curves, but that's may also be because the list of of checkpoints was increased.

Do I need anything additional installed for this alpha?

I have .NET Framework 4.0 installed. (and 3.5 / 2.0)

Get this error on opening AGSEditor:

(http://tom-simpson.com/agserror.png)

Alpha 1 opens fine.

1 file was missing, reuploaded.

Thanks!

The clickable areas on the new-fangled object/character/everything selector bother me. They're too small to navigate quickly.
I get that it's based on the Windows Explorer address bar, but that is arguably a secondary navigation bar (and I've never found it the mouse navigation intuitive).
Could we have the name and the arrow be one clickable area that shows a menu? The name currently makes it possible to navigate back up the hierarchy, but I don't think that's needed. i.e. There's no specific view associated with having "Room" selected on its own.
I don't know, what do other people think?

Quote from: Gurok on Mon 21/05/2018 03:23:37
Could we have the name and the arrow be one clickable area that shows a menu? The name currently makes it possible to navigate back up the hierarchy, but I don't think that's needed. i.e. There's no specific view associated with having "Room" selected on its own.
I don't know, what do other people think?

Yes, I wanted to suggest this too.

Quote from: Crimson Wizard on Sun 20/05/2018 17:55:01
- New pathfinder based on the A* jump point search. (by Martin Sedlak)

I test it now. New pathfinding is cool. It's similar to way system now. Performance is better too. It's a great update. Thanks a lot guys.

Uhm... I'll try it on my MAGS game (yes, I'll make a backup of the current state in alpha 1) :)

Some good stuff in here, thanks all involved!
Looking forward to try that pathfinder on this maze.

Quote from: Cassiebsg on Mon 21/05/2018 14:46:11
Looking forward to try that pathfinder on this maze.

Testing pathfinder is encouraged! So far it was tested by few people only in limited number of games.

Quote from: Crimson Wizard on Mon 21/05/2018 14:55:49

Quote from: Cassiebsg on Mon 21/05/2018 14:46:11
Looking forward to try that pathfinder on this maze.

Testing pathfinder is encouraged! So far it was tested by few people only in limited number of games.

Testing as well but is it worth (if feasible) having an editor setting to switch between old and new in case something unexpected pops up later?

Quote from: Privateer Puddin' on Mon 21/05/2018 15:08:29
Testing as well but is it worth (if feasible) having an editor setting to switch between old and new in case something unexpected pops up later?

Hmm... no. :/
It would be possible to restore the old one from the git history if something goes wrong. Then figure out how to make a switch in the engine.

Uhm, pathfinder seems to be doing fine

But I just discovered that when you put a new object in a room it turns all objects visible. :~( I also started a blank project and added a BG and a couple sprites, then added them as objects. does the same. This is a very big bother, as I have a few big sprites that cover everything...
Also it's rather annoying that when you create a new object in a room it doesn't automaticly jump to it's settings/properties, so you can name it and adjust it... you need to actively find it in the list of objects and click on it.

EDIT: And seems like changing the Name of the object does the same thing. :~(

EDIT2: Doesn't help to lock the state of the objects either.

Quote from: Crimson Wizard on Mon 21/05/2018 15:12:24

Quote from: Privateer Puddin' on Mon 21/05/2018 15:08:29
Testing as well but is it worth (if feasible) having an editor setting to switch between old and new in case something unexpected pops up later?

Hmm... no. :/
It would be possible to restore the old one from the git history if something goes wrong. Then figure out how to make a switch in the engine.

I've found that switching between the engine builds can leave characters in a different position after walking, with the old pathfinder moving the character further (which was then causing a bounds check to fail). I probably need to re-test without the smooth scrolling module, but the difference in player.x was enough to cause me an issue.

My "Explore Project" has accidentaly moved out from the right panel, now every time I open AGS editor the pane is placed in the middle, and I need to manually move itback to it's place on the right pane.

Any way to force it to remember where I want it to be? Seems like me just moving it into the correct place and then closing the editor doesn't save settings like it should. :-\

I think one of the panels is flagged as a main one, and if that is in a strange position it can make the others go wrong. The settings are now independent of editor version, and get upgraded to the next version (so what you set in 3.4.2 doesn't affect anything older). You can find the user.config file by running this at a command prompt:

dir /b /s %USERPROFILE%\AppData\Local\AGS\*user.config

Just delete it to reset the settings, although if you can send me a copy I'll double check what the settings are doing.

Quote from: morganw on Fri 01/06/2018 19:59:18The settings are now independent of editor version, and get upgraded to the next version (so what you set in 3.4.2 doesn't affect anything older). You can find the user.config file by running this at a command prompt:

Code (dos) Select Expand

dir /b /s %USERPROFILE%\AppData\Local\AGS\*user.config

Just delete it to reset the settings, although if you can send me a copy I'll double check what the settings are doing.

Is panel layout also saved to that config file?

Uhm... :-\

well, deleting the file did nothing to alter the problem. The project window is still opening in the "middle", and the room/scripts I open next will be open in the same pane... (in the middle)... so, still not a solution (and now I learned I have a new stupid named folder on my c drive... :( )

EDIT:
Oh, wait. I just noticed there's a "layout->save" option under Window... I'll try that.

EDIT2: That seems to have done it. (nod) Unless the fact that I reloaded the dark theme at the same time did it... (roll)

Quote from: Crimson Wizard on Fri 01/06/2018 20:06:25

Quote from: morganw on Fri 01/06/2018 19:59:18The settings are now independent of editor version, and get upgraded to the next version (so what you set in 3.4.2 doesn't affect anything older). You can find the user.config file by running this at a command prompt:

Code (dos) Select Expand

dir /b /s %USERPROFILE%\AppData\Local\AGS\*user.config

Just delete it to reset the settings, although if you can send me a copy I'll double check what the settings are doing.

Is panel layout also saved to that config file?

...I may have confused it with the overall window positioning, so possibly not.

The actual layour file is probably still %USERPROFILE%\AppData\Local\AGS\Layout.xml

Quote from: Crimson Wizard on Sun 13/05/2018 20:18:56
Hmm, somehow I missed this last post in March.

Quote from: declerfayt on Thu 01/03/2018 17:27:47
Quick question: as this new alpha focus mainly on the editor and save games, is a game made with this AGS 3.4.2 - Alpha 1 would still be compatible with AGS 3.4.1 - Patch 1 (the latest stable version)?

If you mean, whether it is possible to move back from 3.4.2 to 3.4.1, then probably yes, for now, because there were not any changes to game format. But there is no guarantee that this will remain so.

Quote from: declerfayt on Thu 01/03/2018 17:27:47
If not, would you think it's reasonable to start working with this alpha (I guess games made with this version will work on the forthcoming stable AGS 3.4.2)?

I guess that this release may be pretty stable. Actually I just removed "unstable" word from the title, because it may confuse people to think that it is crashing, etc. It's WIP, but should be relatively safe. Then again, even the releases that we call "stable" do have mistakes sometimes.
Also, in theory there are always ways to move your project back to previous version of AGS.

Thanks a lot for your response CW (and again great work!). With the new patch you just released, I think I'm gonna switch to the new WIP version next week :)

Quote from: declerfayt on Fri 01/06/2018 21:32:15
Thanks a lot for your response CW (and again great work!). With the new patch you just released, I think I'm gonna switch to the new WIP version next week :)

There were a number of inconveniences in new editor interface found since, so idk if that's a good idea until we fix them.

Quote from: Crimson Wizard on Sat 02/06/2018 12:32:52
There were a number of inconveniences in new editor interface found since, so idk if that's a good idea until we fix them.

Thanks CW ! Maybe I'll wait a bit - tbh, the new interface is pretty cool to manage the parralax effet and the different layers of object, but it's not super urgent, I can wait for a few weeks :) Thanks for your advice :)

Quote from: morganw on Wed 30/05/2018 21:36:43
I've found that switching between the engine builds can leave characters in a different position after walking, with the old pathfinder moving the character further (which was then causing a bounds check to fail). I probably need to re-test without the smooth scrolling module, but the difference in player.x was enough to cause me an issue.

This can happen if you click on a non-walkable area, the new pathfinder tries to get you as close as possible (unlike the old one).
Also the new pathfinder is pixel-perfect, old pathfinder did something like 3x3 pixel downsampling (or actually jumping over 3 pixels - I don't remember exactly),
so even one pixel gap is no longer walkable.
However, I think these features are actually useful and desired - even if it means adjusting game code when switching to the new engine, I hope it's still worth it :)
The new algorithm also does bidirectional path filtering when extracting waypoints, so the final paths should look a bit more natural (especially the last few segments),
old code did something similar but only in forward direction, probably not a big deal and barely noticeable.

The only drawback of the new pathfinder is increased memory usage (traded memory for performance), namely 8 times more than old pathfinder (read 8 bytes per walkable pixel),
so for example if your largest background is 3k times 1k pixels, the old pathfinder used 3 megabytes where the new uses 24.
This is still ok even on todays mobiles unless you use really huge backgrounds, but it's always good to understand the implications.
On the other hand, large (hires) areas is where the new algorithm really shines in terms of performance compared to the old one.

One potential solution would be to use lowres walkable bitmap, saving 4 times the memory by 2x downsampling in each direction, but I've no idea how much work it'd represent
in the editor and pathfinder glue code.
Maybe the best solution would be to switch to navmeshes instead, but this would add new challenges of its own and it would be a substantial amount of work, completely breaking backward compatibility...

Quote from: Martin Sedlak on Fri 08/06/2018 22:09:14

Quote from: morganw on Wed 30/05/2018 21:36:43
I've found that switching between the engine builds can leave characters in a different position after walking, with the old pathfinder moving the character further (which was then causing a bounds check to fail). I probably need to re-test without the smooth scrolling module, but the difference in player.x was enough to cause me an issue.

<...>
However, I think these features are actually useful and desired - even if it means adjusting game code when switching to the new engine, I hope it's still worth it :)

The issue here is that sometimes people are upgrading their nearly completed games to the new version of AGS, and they do not want to be surprised by extra work added when they do. So it is fair to warn them about these possible complications.

Also, something that I forgot to consider when reviewing your pull request, if pathfinder acts differently (even if better), there is a slight but real theoretical possibility that some old game breaks, if it were relying on exact places where character walks. We had similar problems in the past (not with pathfinder), when game creators were too much relying on particular quirks of the engine, and when engine got fixed or improved that broke these games. We have couple of places in the engine where less correct behavior had to be simulated under condition that the old game is being run.

Since we decided to split AGS into "backwards compatible" and "future" versions recently, we are currently considering (https://github.com/adventuregamestudio/ags/issues/448#issuecomment-394000925) what to do with pathfinder in "compatible" branch: whether to keep your new pathfinder, revert to old one, or have both with a way to switch between them in config.
This is not very critical, in my opinion, since we don't know if there is such game that would be broken by new pathfinder in practice (making it impossible to walkthrough), but has to be decided at some point.

Hi, sorry if this was answered - i was away for a while :)

Is there any plan to implement CW's excellent "typewriter" text animation (ala jrpgs) in a future version of the engine?
Because i am sure it would get a lot of use.

Quote from: Crimson Wizard on Fri 08/06/2018 22:31:23
Since we decided to split AGS into "backwards compatible" and "future" versions recently, we are currently considering (https://github.com/adventuregamestudio/ags/issues/448#issuecomment-394000925) what to do with pathfinder in "compatible" branch: whether to keep your new pathfinder, revert to old one, or have both with a way to switch between them in config.
This is not very critical, in my opinion, since we don't know if there is such game that would be broken by new pathfinder in practice (making it impossible to walkthrough), but has to be decided at some point.

I see, I never thought that the new engine may be used to run old games. For WIP games close to release it's probably never a good idea to switch to new engine anyway,
no matter what has changed.
Of course if a script relies on a certain behaviour of the pathfinder then it can break existing games.
Also since old pathfinder allowed you to walk over 1px/2px gaps in some cases, such games (with incorrect walkable areas) may break as well.
It's impossible to make the new pathfinder behave like the old one simply because it may choose more or less different paths, so if full backward compatibility is a concern,
the only option is to either revert or make the two coexist, because you can never get rid of the old pathfinder in that case.

Quote from: KyriakosCH on Sun 10/06/2018 10:58:02
Is there any plan to implement CW's excellent "typewriter" text animation (ala jrpgs) in a future version of the engine?
Because i am sure it would get a lot of use.

Personally I was against it, because I always believed the engine should provide basic building blocks and get extended with script modules.
There is too many ways text typing could be customized, too much to add it all to the engine, IMO, so sooner or later you would need a script module anyway.
Perhaps it would be a better option to extend script event system and ease customizing text output in the script. Like allow easier scripting speech speech style, something that we were discussing in the past.

Ok, thanks 8-)

A box where I could type which function my game would use for speech, so Dialog, Voice Script and Translations would know :O

Quote from: eri0o on Sun 10/06/2018 14:11:05
A box where I could type which function my game would use for speech, so Dialog, Voice Script and Translations would know :O

Roughly something like that, yes.

Is there a chance to remove or up the font limit that's currently 30 fonts, it's something that I'd personally really need, cause we're trying to integrate a bunch of translations into a project atm.

Quote from: Dualnames on Tue 12/06/2018 20:03:31
Is there a chance to remove or up the font limit that's currently 30 fonts, it's something that I'd personally really need, cause we're trying to integrate a bunch of translations into a project atm.

Should be trivial, that's strange, no idea why it was not removed yet.

Not sure if removing the limit it is doable, but please please up it up?
Also can AGS change the text Alignment of a label/button/ui control via code, or no (this is a minor thing, not really that important).

Quote from: Dualnames on Tue 12/06/2018 22:18:53
Also can AGS change the text Alignment of a label/button/ui control via code, or no (this is a minor thing, not really that important).

Hmm, does not look like it can right now. It's a matter of adding script property and adding variable to save format.

Would it be possible to update the 9 verb template? The one shipped is a tad outdated. Also I would love to see the Tumbleweed template included as well.

http://shatten.sonores.de/wp-content/uploads/2018/06/9-verb-MI-style_163.zip
http://shatten.sonores.de/wp-content/uploads/2018/06/tumbleweed_1.0.zip

I'm updating the existing ones at the moment, the suggestion was to include yours as a submodule.
https://github.com/adventuregamestudio/ags-template-source/issues/2 (https://github.com/adventuregamestudio/ags-template-source/issues/2)

I honestly haven't worked with submodules yet, but from what I've read it seems like a good solution. Of course I'd have to start with using tags, releases and such :)

Quote from: abstauber on Thu 21/06/2018 21:30:09
I honestly haven't worked with submodules yet, but from what I've read it seems like a good solution. Of course I'd have to start with using tags, releases and such :)

We could refer to particular commit too, but tags are more user-friendly.

That would be super cool to have a stand-alone game compiler (something that was talked about back in 2011-12), so that we could build all templates from script (like in Python script), but alas...

Quote from: Dualnames on Tue 12/06/2018 22:18:53
Not sure if removing the limit it is doable, but please please up it up?
Also can AGS change the text Alignment of a label/button/ui control via code, or no (this is a minor thing, not really that important).

Sorry to ask again, any luck on prioritizing or working on this, or any progress?

Quote from: Dualnames on Sat 07/07/2018 10:10:26

Quote from: Dualnames on Tue 12/06/2018 22:18:53
Not sure if removing the limit it is doable, but please please up it up?
Also can AGS change the text Alignment of a label/button/ui control via code, or no (this is a minor thing, not really that important).

Sorry to ask again, any luck on prioritizing or working on this, or any progress?

I was distracted by number of bugs in the 3.4.1, for which plan to release a patch on this weekend (or first days of the next week latest).
After that I will merge 3.4.1 to 3.4.2 again, and finally begin resolving issues in 3.4.2.

Since font limit sounds trivial (need to check again though), that could the first thing.
Other stuff in my personal plans:
1. bugs with the new editor UI which make it hard to work with;
2. properties that cannot be set at runtime.

Here's a test build with unlimited fonts:
https://www.dropbox.com/s/odfqfs0di9ax48d/ags-3.4.2-wip--unlimited-fonts.zip?dl=0

You may copy it over 3.4.2 release.
Warning: it raises project version number, so you won't be able to open same project with previous version after you save.

First test works, I can up the limit! Now onto testing a tad more!

I'm trying to load the project that is using the Speech Plugin https://skydrive.live.com/redir.aspx?cid=a031d4a2c1add700&resid=A031D4A2C1ADD700!111&parid=A031D4A2C1ADD700!110&authkey=!AJ9otK4Z8fEy_9I

And it's giving me an error, when I start the AGSEditor exe, since now I put the dll on the editor's directory.
https://ibb.co/mgUEp8

Quote from: Dualnames on Mon 09/07/2018 14:21:51
I'm trying to load the project that is using the Speech Plugin https://skydrive.live.com/redir.aspx?cid=a031d4a2c1add700&resid=A031D4A2C1ADD700!111&parid=A031D4A2C1ADD700!110&authkey=!AJ9otK4Z8fEy_9I

And it's giving me an error, when I start the AGSEditor exe, since now I put the dll on the editor's directory.
https://ibb.co/mgUEp8

Is this related to this particular version, or any AGS?

This happens to this version, other versions of ags prior to 3.4.2 seemed to have no issues.

The error appears when the editor loads, not when I'm trying to load a project, the speech plugin seems to be denied.

The error message seem to refer to difference in .NET Framework versions. This wip version now uses .NET Framework 4.0, previous ones used 2.0.

So would installing 4.0 fix this?

I have 4.6 installed

I wonder if it needs a specific thing out of framework 4.0

Try checking if the file is blocked, see this: https://stackoverflow.com/questions/18016315/an-attempt-was-made-to-load-an-assembly-from-a-network-location-which-would-have

It is, fixed that thankfully, but now getting this

https://ibb.co/eSoACT

Quote from: Dualnames on Mon 09/07/2018 15:52:43
It is, fixed that thankfully, but now getting this

https://ibb.co/eSoACT

I do not know why plugin is counted "mixed assembly", maybe it was referencing AGS.Native.dll? Just a guess.
Plugin's author started coming on forum again recently (http://www.adventuregamestudio.co.uk/forums/index.php?topic=45622.msg636588275#msg636588275), perhaps it's a good chance to ask him to look into this too. Maybe plugin has to be upgraded.

Right, getting a version of the plugin compiled with dotnet 4.0 is probably the best solution.
However, working with the old version might also be possible by setting "useLegacyV2RuntimeActivationPolicy" in the editor's config file (see here: https://stackoverflow.com/questions/6425707/mixed-mode-assembly-is-built-against-version-v2-0-50727-of-the-runtime).
It seems that the editor's config file is not part of the release zip though (I think it should be), but I think (not sure) you can just create an "AGSEditor.exe.config" file and it will be picked up.
So you can try creating that file and putting this inside and see if it works:


<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true"><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>


Alright making the AGSEditor.exe.config file with the content that tzachs suggested fixes the issue. It also requires irrKlang.NET2.0.dll but now it works just fine!

Quote from: Dualnames on Mon 09/07/2018 16:54:01It also requires irrKlang.NET2.0.dll but now it works just fine!

What does, plugin or AGS Editor?
irrKlang is the audio playing library, I think. irrKlang.NET2.0.dll was used by AGS before, now it supposed to use irrKlang.NET4.dll.

The plugin needs the 2.0.dll

Alright this seems to be working!

I'm done with 3.4.1 for good, hopefully, and now thinking about fixing UI problems reported here.
To sum up what was mentioned:

1. Character not appearing in room bug, reported by Cassiebsg and Privateer Puddin':

Quote from: Privateer Puddin' on Sun 25/02/2018 00:07:54
Open Room X
Change Character to Room X
Character is not seen on Room X, but you can pick it from the list of characters in Properties for that room
Closing and opening the room tab doesn't show the character

Opening another room and then going back to Room X will now show the character (don't need to restart the editor)

Quote from: Cassiebsg on Sun 25/02/2018 01:27:34
I mean the bar where it shows Room > Characters > cName
If I add a new character to the room and open the room, the character will neither be seen nor be available in that drop down list (is there another place to see which characters are in the room?). opening a new room and then returning will show the character in the room and in the list. Removing the character from the room (or moving it to another room) will remove it from the editor show but still show it on the drop down list. Again these are fixed with opening another room and returning.

2. Usability issue, reported by Gurok:

Quote from: Gurok on Mon 21/05/2018 03:23:37
The clickable areas on the new-fangled object/character/everything selector bother me. They're too small to navigate quickly.
I get that it's based on the Windows Explorer address bar, but that is arguably a secondary navigation bar (and I've never found it the mouse navigation intuitive).
Could we have the name and the arrow be one clickable area that shows a menu? The name currently makes it possible to navigate back up the hierarchy, but I don't think that's needed. i.e. There's no specific view associated with having "Room" selected on its own.

3. Another problem(s), reported by Cassiebsg:

Quote from: Cassiebsg on Tue 22/05/2018 11:46:38
I just discovered that when you put a new object in a room it turns all objects visible. :~( I also started a blank project and added a BG and a couple sprites, then added them as objects. does the same. This is a very big bother, as I have a few big sprites that cover everything...
Also it's rather annoying that when you create a new object in a room it doesn't automaticly jump to it's settings/properties, so you can name it and adjust it... you need to actively find it in the list of objects and click on it.

EDIT: And seems like changing the Name of the object does the same thing. :~(

EDIT2: Doesn't help to lock the state of the objects either.

Also there was this feature request from eri0o, although that may be a larger task:

Quote from: eri0o on Sun 10/06/2018 14:11:05
A box where I could type which function my game would use for speech, so Dialog, Voice Script and Translations would know :O

But we've discussed very similar thing with Scavenger recently on Discord, and I suddenly realized that implementing this at least for Dialogs may be not that complicated.

But UI fixes go first.

PS. Also, maybe we should rename this version to 3.5.0, because of changes to editor's GUI.

So, I was looking into problems 1) and 3) from above, and it appears that I'd need to modify some of the tzach's code to make this work correctly.


Technical things aside, my two big questions are:

1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

2) If it should be saved, should this information be saved as a part of the game project, or as a separate "editing state" config? What I mean, game project stores object properties related to the game in Game.agf, but there is another file called Game.agf.user that saves what is called "workspace state" which has some service info about last usage of editor which is not required to build the game itself (I guess we could also move few options, such as "Build Targets" there.
Anyway, the point of having Visible/Locked-in-the-editor setup in a separate config is to specify these properties as non related to the game itself, and if for example game is worked on by multiple users they may have separate design-time configs which are not shared between them when you sync the project.


NOTE: before this new navigation bar was introduced Room Objects already had Locked property that was saved in the room data and kept with the game.

I'd say that, if the interface is good and you aren't in the middle of a long-winded task that locks other editor components, you wouldn't expect the state to be saved and restored.

Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

Yes. Locked in particular (otherwise it's nigh-useless).

Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
2) If it should be saved, should this information be saved as a part of the game project, or as a separate "editing state" config? What I mean, game project stores object properties related to the game in Game.agf, but there is another file called Game.agf.user that saves what is called "workspace state" which has some service info about last usage of editor which is not required to build the game itself (I guess we could also move few options, such as "Build Targets" there.
Anyway, the point of having Visible/Locked-in-the-editor setup in a separate config is to specify these properties as non related to the game itself, and if for example game is worked on by multiple users they may have separate design-time configs which are not shared between them when you sync the project.

Given your explanation, probably the editing state (Game.agf.user). This doesn't seem that important, though; either would be fine.

Quote from: Snarky on Tue 17/07/2018 11:54:04

Quote from: Crimson Wizard on Tue 17/07/2018 10:02:36
1) Should the Visible/Locked states be saved in between editor sessions (and room's closing/reopening)? I guess answer is yes...

Yes. Locked in particular (otherwise it's nigh-useless).

Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing. If opening up the room data is on the to-do list anyway, and storing settings may restrict any future changes (you'll either have to validate them or drop them all), storing more data just seems to add more restrictions in the long run.

Quote from: morganw on Tue 17/07/2018 10:36:46
I'd say that, if the interface is good and you aren't in the middle of a long-winded task that locks other editor components, you wouldn't expect the state to be saved and restored.

Quote from: morganw on Tue 17/07/2018 12:52:27
Personally I would say, saving the state is just a workaround for not being able to open more than one room for editing.

It seems we have very contradictory views on what user expects from the editor... Nearly every contemporary editor I've seen saves layer visibility in the document - game editors and image editors alike, and I had an impression users usually want to see the scene in the same state they had it when closed editor last time.

Being able to edit several rooms at once does not change much in this regard, because you may close and and reopen editing panes, and restart Editor eventually too.

Does your opinion originate from concern about difficulty of implementation, or you actually do not think having state restored is needed, or even expect these settings to be reset every time you launch the Editor because that complies to your personal work habits?

In the example given above by Cassiebsg she has large objects covering whole room, and she wants them to be invisible in the editor to be able to work with the rest of the room. Without these settings saved every time she opens an editing session she would have to adjust their visibility over and over again.
Same will happen if you want to lock things. Usually people would lock objects that are already in place and should not be touched anymore or edited by mistake.

To slightly adjust my original question: do users expect these settings to be saved in between editing sessions, like in: reopening editor next day?

Quote from: morganw on Tue 17/07/2018 12:52:27
If opening up the room data is on the to-do list anyway, and storing settings may restrict any future changes (you'll either have to validate them or drop them all), storing more data just seems to add more restrictions in the long run.

I have no idea when opening room data or having multiple rooms at once will be done. If we are to make this state saved only as a temporary solution until these times, they may be saved in a "workstate config", as mentioned above, and later simply discarded. I believe they won't cause much trouble in such case. (I fear more trouble will be caused by implementing this serialization, because you need to sync it with existing rooms...)

Yes, I expect the logic thing is for the editor to remember what I wish locked/unlocked and visible/not visible, even after closing and reopening the editor. (nod)
Having to set it up again every single time is really a pain. 8-0

I think saving it in the user profile is probably best. (nod)

Quote from: Crimson Wizard on Tue 17/07/2018 13:15:27
Does your opinion originate from concern about difficulty of implementation, or you actually do not think having state restored is needed, or even expect these settings to be reset every time you launch the Editor because that complies to your personal work habits?

I guess that I'm saying, having to store the state is something you would need when applying the changes you need is taking too long or is overly complicated. With the example of hiding multiple objects in a room, I'd rather make it easier to multi select objects and apply any setting, rather than leave awkward controls in place and store the settings to avoid frustration.

Quote from: morganw on Tue 17/07/2018 14:29:17
I guess that I'm saying, having to store the state is something you would need when applying the changes you need is taking too long or is overly complicated. With the example of hiding multiple objects in a room, I'd rather make it easier to multi select objects and apply any setting, rather than leave awkward controls in place and store the settings to avoid frustration.

But aren't these are different problems that require different solutions? I did not mean the state saving as a solution to not able to select multiple objects.
When people are working on a game, they may open same room many times. Even if there are not multiple objects that need to be turned off but only one, or if there is a convenient way to multiselect, even then they'd probably rather keep that convenient state saved than change it same way over and over.

morganw, I don't see setting these settings as something you do just for a single room editing session, but rather:

Locked - This is something I would set once I have positioned an object precisely, to ensure that I don't accidentally move it while editing other things in the room. Once this setting is set, I never want it to be unset again (unless I explicitly turn it off). If I come back to the room in two months (to add another object, for example), I expect it to still be locked.

Visible - This is something I would set for objects that wouldn't normally be visible in the room and that cover up important parts of the background (for example, an object that shows an animation of an explosion). If I turn it off, I want it to remain off (unless I explicitly make it visible again), because to do almost any other editing to the room I would otherwise have to turn it off again every time.

Basically, the reasons I flipped these settings in the first place still apply the next time I come back to the room editor, and it would be annoying to have to set them again every time.

Quote from: Crimson Wizard on Tue 17/07/2018 14:50:02
But aren't these are different problems that require different solutions? I did not mean the state saving as a solution to not able to select multiple objects.
When people are working on a game, they may open same room many times. Even if there are not multiple objects that need to be turned off but only one, or if there is a convenient way to multiselect, even then they'd probably rather keep that convenient state saved than change it same way over and over.

Yes, I think there are probably three separate issues here. I only mention my point of view for storing state, as in my opinion , the workflow issues that make the persistent state desirable are related to only being able to edit one room at a time (so state cannot persist in the tab) and the existing controls are not particular streamlined (changing the settings is too involved a process). If it is easy to implement and doesn't restrict future changes or rolling back to previous versions, then it wouldn't be an issue.

Quote from: Snarky on Tue 17/07/2018 14:52:45
Basically, the reasons I flipped these settings in the first place still apply the next time I come back to the room editor, and it would be annoying to have to set them again every time.

Yes, but to make the settings persist through Editor upgrades this isn't just simple a serialize/deserialize. It would probably have to be linked to the project upgrade process and I don't know if that even considers per project user preferences rather than just project data. Having had to rewrite the whole preference system for the Editor just so I could add an option to suppress a message box, I wouldn't want these new settings to be trivially added and create a similar problem down the line.

Quote from: morganw on Tue 17/07/2018 16:50:26
Yes, but to make the settings persist through Editor upgrades this isn't just simple a serialize/deserialize. It would probably have to be linked to the project upgrade process and I don't know if that even considers per project user preferences rather than just project data. Having had to rewrite the whole preference system for the Editor just so I could add an option to suppress a message box, I wouldn't want these new settings to be trivially added and create a similar problem down the line.

The Game.agf.user is loaded through same serialization mechanism as the main game data in Game.agf, that allows using reflection (with help from attributes) to serialize classes.
This mechanism considers possibility of new, deprecated, renamed properties, and the change in the value range (this is also why I was suggesting using it for general preferences earlier). If something is lacking or suboptimal there, it may be improved.
EDIT: entry point is LoadUserDataFile() in AGSEditor.cs. The serializer is class SerializeUtils in AGS.Types.dll.

On the other hand, for rooms we may consider creating separate similar config files, one per room. It's just that since that may clutter project folder, they are better saved in "Rooms" subfolder already, so not sure.



PS. I honestly did not want to discuss implementation details in this "release" thread. I posted here to know user's opinion. Code problems may be discussed in related forum section, or even on github.

If there is already a mechanism to do it, then it isn't an issue. I just didn't want to get locked into the existing controls indefinitely; as a user the workflow is more of a problem to me than restoring the end result.

Quote from: morganw on Tue 17/07/2018 19:07:38
If there is already a mechanism to do it, then it isn't an issue. I just didn't want to get locked into the existing controls indefinitely;

No, of course not. This definitely should be saved in such way that makes it possible to even discard if control scheme changes cardinally.

This is also the reason (among few others) I changed my mind on keeping these flags in game classes as I initially thought: while much simplier code-wise, that could become a problem if UI or set of design-time properties changes. So currently I am trying to reimplement tzach's solution into a kind of data table in the Room managers, which corresponds set of editor-only properties to game objects. TBH the current code structure is not perfect for this (receiving updates about object changes is bit clunky), but hopefully I will be able to find good way to sync them.
After that next step will be serialization...

As an "end user", I just want to add that resetting these flags after updating the Editor (new version, if that's what you mean) would not bother me. I doubt most of us don't upgrade the editor several times during the developing of a game for it to become a serious issue. Then again, I'm just doing small games that do not take that long to make, so not sure about devs that want to have the latest release for their big and long developing game (and eventually commercial release, when you might want the best working version).

Run into this weird bug, whereas doing

PDAList2.Font=14;

(Pdalist2 is a Listbox) doesn't work. I searched for the entire project (to see if I set .Font on anything), and even put that line on repeatedly_execute_always but it won't go through.
I'm using the "custom version", can't check the specific project on previous versions

Also not sure if this is how it's supposed to be but

When I do

if (Game.DoOnceOnly("open cutscenetwo")) {

//code A
}

The code A within the if condition gets to run every time because the if condition always returns true, however when I do

if (Game.DoOnceOnly("open_cutscenetwo")) {

Adding a _ seems to make it work properly!

Quote from: Dualnames on Wed 18/07/2018 09:11:42
Run into this weird bug, whereas doing

PDAList2.Font=14;

(Pdalist2 is a Listbox) doesn't work. I searched for the entire project (to see if I set .Font on anything), and even put that line on repeatedly_execute_always but it won't go through.
I'm using the "custom version", can't check the specific project on previous versions

By "doesn't work" you mean font looks do not change, or some error showing up?
What will happen if you do Display("%d", PDAList2.Font) afterwards?
Does this happen only with particular font or any, and does same font apply to ther things like buttons, speech etc?

Everything else seems to be working fine, I think it's the listbox specifically that I can't change its font in runtime. It's always font 7 (which is the one on the editor). I can't change the font of that listbox in runtime, and there's no other code that reverts it to its original (font 7)

Quote from: Dualnames on Wed 18/07/2018 16:11:16
Everything else seems to be working fine, I think it's the listbox specifically that I can't change its font in runtime. It's always font 7 (which is the one on the editor). I can't change the font of that listbox in runtime, and there's no other code that reverts it to its original (font 7)

Yes I can confirm that changing ListBox.Font does not work in 3.4.2 Alpha. Changing other GUI fonts seem to work.

This may be related to GUI refactoring too, it was done a while ago. I will investigate.

EDIT: lol, a classic case of naming function argument like class member leads to assigning local variable to itself:
https://github.com/adventuregamestudio/ags/blob/master/Common/gui/guilistbox.cpp#L197

@Dualnames, here is the updated version, with ListBox.Font fixed:
https://www.dropbox.com/s/w5838ngizahlblt/ags-3.4.2-wip2.zip?dl=0

Quote from: Dualnames on Wed 18/07/2018 15:43:17
When I do

if (Game.DoOnceOnly("open cutscenetwo")) {

//code A
}

The code A within the if condition gets to run every time because the if condition always returns true, however when I do

if (Game.DoOnceOnly("open_cutscenetwo")) {

Adding a _ seems to make it work properly!

I could not reproduce this, tried in 3.2.1, 3.4.1, 3.4.2. Could you double-check with the updated version?
Also, may be a long shot, but do you use a translation? (Not that it should be translated, but maybe some bug appeared)

I doubt all the translators translated it, but i can check maybe the token is invalid if it has spaces within the string?

The update fixes the listbox issue! Gonna check on the string as well, see whats up with it.

I've tried to rewrite Room Editor, hopefully fixing reported problems: one with Character's not appearing in the list, all objects becoming visible at once when a new one is added or renamed, and maybe few others.

https://www.dropbox.com/s/5aeh3oku9d35aeg/ags-3.4.2-wip3-roomed.zip?dl=0

This is work in progress, there may be new bugs, which I will be fixing.

Note, the state of these settings still is not saved in-between edit sessions, this is in TODO list.

I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

Quote from: Dualnames on Sat 21/07/2018 18:36:14
I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

No, I did not change anything because I could not reproduce this with the example you've posted earlier. Is there any chance I could get your game for a test?
If not, I may investigate the engine code and see if there is something suspicious.

I updated the test build another time, link is same:
https://www.dropbox.com/s/5aeh3oku9d35aeg/ags-3.4.2-wip3-roomed.zip?dl=0

Now fixed whole room layer getting reset when you add/rename an object.
Looks like all is working now, but please try out yourselves.

PS. I removed the behavior when Characters, Room Objects and Walkable areas are all were made visible by default. Was not sure if that's really what users asked for, but tzachs simply made it so. Now it's reverted back to old AGS behavior when only background is visible at startup.

When room editor state will be saved all the existing rooms will reopen in the way you left them, but new rooms will begin with only background.
Question: does this still need an option in preferences?

Quote from: Crimson Wizard on Sat 21/07/2018 19:14:30

Quote from: Dualnames on Sat 21/07/2018 18:36:14
I'm pretty sure that if (Game.DoOnceOnly("")) is having some sort of issues cause I used them mostly for stuff that happen when you first load a room, and then I'm being reported issues that are only able to be replicated if the lines within the relative condition are executed again. Is that something that has been fixed on the zip files you just posted?

No, I did not change anything because I could not reproduce this with the example you've posted earlier. Is there any chance I could get your game for a test?
If not, I may investigate the engine code and see if there is something suspicious.

Is there maybe something to do with translations interfering with gamedo once onlys?

I'm 200% there's an issue with GameDoOnceOnly,(I'm using 1327 or so unique tokens, maybe that is an issue), anyhow, I replaced 2 of them, and then 2 others started malfunctioning, so I've made a custom function that does exactly what GameDoOnceOnly does, I'll let you know if that faulters, if it does it's something else.

Quote from: Dualnames on Mon 23/07/2018 12:22:30
I'm 200% there's an issue with GameDoOnceOnly,(I'm using 1327 or so unique tokens, maybe that is an issue), anyhow, I replaced 2 of them, and then 2 others started malfunctioning, so I've made a custom function that does exactly what GameDoOnceOnly does, I'll let you know if that faulters, if it does it's something else.

Is there really no way for you to send me a game? Then I could run it under debugger. If there is some bug in AGS, it could be caused by multiple reasons combined.
If you are worried about your game security, I will just delete it from my pc afterwards (I also don't have spare time to play adventure games now :)).

Otherwise I'd have to have exact steps to reproduce this problems, which are not known at this time, it seems.
Right, I have promised to investigate the engine code, I will try doing that today.

Quote from: Crimson Wizard on Mon 23/07/2018 12:26:24
Right, I have promised to investigate the engine code, I will try doing that today.

Hmm, alright, I looked there, and don't see anything curious right away.

Couple of notes:
1) The length of the string is limited to 199.
2) Strings are case-sensitive ("DoOnlyOnce" is not equal to "doonlyonce").

It has no connection to translation, or anything else.

PS. By the way, even the manual gives an example with the space in the string:

Quote
if (Game.DoOnceOnly("open cupboard")) {
  GiveScore(5);
}

it's gonna take me a long time to upload, but I will if this reappears, for now I've replaced the function with a custom one.

I've made a custom function to replace Game.DoOnceOnly and all the related bugs disappeared!

Quote from: Dualnames on Wed 25/07/2018 06:01:24
I've made a custom function to replace Game.DoOnceOnly and all the related bugs disappeared!

I don't know if you expect me to reply something... Like I said, I cannot do anything without a test case that would let me reproduce this error.

E: May this be a result of restoring a saved game? Did this begin only after upgrading to 3.4.2?

Sorry, if I'm frustrating you, don't intend to do that. The game files are over 4gb, and my upload speed is at 40kbps. This only begun after upgrading to 3.4.2 yes, not the result of a saved game, what seemed to be the case, is that the game seemed to pick 2 instances (the first two of Game.DoOnceOnly) and those didn't work. I can send you the script files, but not the sprite files, if you want.

Quote from: Dualnames on Wed 25/07/2018 12:35:02This only begun after upgrading to 3.4.2 yes, not the result of a saved game, what seemed to be the case, is that the game seemed to pick 2 instances (the first two of Game.DoOnceOnly) and those didn't work. I can send you the script files, but not the sprite files, if you want.

Hmm, yes please, there is a chance the erroneous situation could be recreated from these.

E: Maybe silly question, but did you do "Rebuild all files" after upgrading to 3.4.2?

Yes, have done the rebuild all files

New update

AGS 3.4.2 - Alpha 3

Zip archive: http://www.mediafire.com/file/5ijbdfd6ydcikpu/AGS-3.4.2-alpha3.zip/file

Common features
- Removed font limit.

Editor
- Fixed navigation bar settings in the Room Editor get reset when objects are added/removed/renamed.
- Fixed characters do not get updated in the Room Editor when their StartingRoom property is changed.
- Improved how Room zoom slider works, now supports downscale.
- Build autocomplete table a little faster.
- Fixed rooms not being rebuilt when running game just created from a template.

Engine
- Fixed setting ListBox.Font did not work (regression).
- Prevent game from crashing if there was an attempt to draw text with a non-existing font.

KNOWN ISSUES: Room Editor's navigation bar settings still get reset when you close the room.

/me clicks download link and then runs and gives a big hug to CW!

Thanks for all the hard work. :-D

Quote from: Cassiebsg on Tue 31/07/2018 18:07:10
/me clicks download link and then runs and gives a big hug to CW!

Yeah, well, better try how that works first :P... I had to change quite a lot of things in code there.

Well. if it works or not is a little besides the point you still put up for the hard work. :)

The bad news is that... ermm... seems to be more broken than it was. :-[
I have opened an older project (Stable Pete) opened one of the rooms, turned on characters & objects.
I locked and hid one of the objects. I added a new object and the hidden object popped back up to being visible... :( But when looking at the list where to pick them, it still shows the object as being locked and hidden. ??? Changing the name of the object also makes the hidden object to become visible (but not the icon state it shows on the drop down menu).

Have not tested more.

I probably fixed it: http://www.mediafire.com/file/5ijbdfd6ydcikpu/AGS-3.4.2-alpha3.zip/file

Yes, looks like you did. :-D (nod)
Tested and seems to be working as expected. :-D Now it just needs to remember how we left things last time we edited the room. But currently a lot less annoying than versions 2 was. Thanks bunch! (nod)

Test build that saves/loads room editor config:
https://www.dropbox.com/s/pxtn3kffuhod7fv/ags-3.4.2-wip5--roomedsaved.zip?dl=0

Now it saves visible/locked data in extra files called "roomXXX.crm.user" (xml format).
These files are safe to delete, and even break, Editor should simply warn about not being able to restore room state, but continue working as usual.

Please test and see if there are any problems with this.

I will be opening pull request for review soon.

Will give it a test run tomorrow once I get home from work. (nod)

Thanks again, and hope I don't break it like I usually do. ;) :-[

AGS with PlayOnLinux works quite well, but it has a problem: if you click on Run (F5) the game doesn't start most of the time because Wine gives an error.
To be able to run it, compile it all and execute the setup and press on Save and Run.

Also, sometimes the function selector does not appear.

Quote from: Neo_One on Mon 13/08/2018 15:12:04
AGS with PlayOnLinux works quite well, but it has a problem: if you click on Run (F5) the game doesn't start most of the time because Wine gives an error.
To be able to run it, compile it all and execute the setup and press on Save and Run.

I've also seen this on WINE, and it seems the file is still being written when the engine tries to open it. I thought it didn't happen on AGS 3.4.2 builds though; which specific version are you seeing this with?

Quote from: Neo_One on Mon 13/08/2018 15:12:04
Also, sometimes the function selector does not appear.

There is also an issue the autocomplete on WINE, which I think is also related to having something in the clipboard. Is this what you mean by function selector?

Quote from: morganw on Mon 13/08/2018 17:49:16

Quote from: Neo_One on Mon 13/08/2018 15:12:04
AGS with PlayOnLinux works quite well, but it has a problem: if you click on Run (F5) the game doesn't start most of the time because Wine gives an error.
To be able to run it, compile it all and execute the setup and press on Save and Run.

I've also seen this on WINE, and it seems the file is still being written when the engine tries to open it. I thought it didn't happen on AGS 3.4.2 builds though; which specific version are you seeing this with?

Quote from: Neo_One on Mon 13/08/2018 15:12:04
Also, sometimes the function selector does not appear.

There is also an issue the autocomplete on WINE, which I think is also related to having something in the clipboard. Is this what you mean by function selector?

I am with the current stable (3.4.1). I don't know if it's the same with 3.4.2.
In the clipboard I don't have anything open, you could be that PlayOnLinux itself is the cause.

I wish I could make a native version of AGS for Linux to get rid of Windows, all the programs I use are open source and AGS is the only one that is not for Linux :_(

Quote from: Neo_One on Mon 13/08/2018 21:06:19
I am with the current stable (3.4.1). I don't know if it's the same with 3.4.2.
In the clipboard I don't have anything open, you could be that PlayOnLinux itself is the cause.

It would be interesting to see if you had the same issue running the game with 3.4.2. I've found that the Editor's autocomplete would crash on Gnome 3, but I've never been sure that I've got WINE setup correctly.

Quote from: Neo_One on Mon 13/08/2018 21:06:19
I wish I could make a native version of AGS for Linux to get rid of Windows, all the programs I use are open source and AGS is the only one that is not for Linux :_(

Yes, me too. The editor itself will actually run, but the majority of the functionality to edit a game are currently in a library that is not cross-platform.

Quote from: morganw on Mon 13/08/2018 21:29:18

Quote from: Neo_One on Mon 13/08/2018 21:06:19
I am with the current stable (3.4.1). I don't know if it's the same with 3.4.2.
In the clipboard I don't have anything open, you could be that PlayOnLinux itself is the cause.

It would be interesting to see if you had the same issue running the game with 3.4.2. I've found that the Editor's autocomplete would crash on Gnome 3, but I've never been sure that I've got WINE setup correctly.

Quote from: Neo_One on Mon 13/08/2018 21:06:19
I wish I could make a native version of AGS for Linux to get rid of Windows, all the programs I use are open source and AGS is the only one that is not for Linux :_(

Yes, me too. The editor itself will actually run, but the majority of the functionality to edit a game are currently in a library that is not cross-platform.

I tried it on Linux Mint, but PlayOnLinux failed a lot. I don't know how it will go with Debian (or another distro) and a desktop like XFCE or KDE.

I think that for the next versions of the engine they should work on multiplatform (Linux and Mac). That and pass to 64 bits the file where the sprites are stored to remove the restriction of the maximum 2GB. I suppose the core will have to be very fine-tuned, but it will be beneficial for the future.

Quote from: Neo_One on Tue 14/08/2018 15:27:09pass to 64 bits the file where the sprites are stored to remove the restriction of the maximum 2GB.

I began working on this.

Ok I decided to test the AGS 3.4.2. I am on Ubuntu 16.04, used Playonlinux.

The FIRST TIME I opened, I got an Error from Playonlinux/Wine, but I didn't pay attention to it. After clicking ok, the AGS Editor proceed to open normally. Now I can close and open it, and all works.

I created a project using it, I selected Default Template, and it created TWO projects with the name of my project, one called Default Game, and one called new_test_game, but both are the same project?

(https://i.imgur.com/MxmICTp.png)

Other than this I did some more testing and it appears to work. All I have to say is that I REAAAALLY like being able to see Walkable areas together with the characters. This is the greatest thing in here.

Other than this, in all ags versions I have, it doesn't build the Linux version on Wine. I thought this one would be different because you had removed the takeown thing, but somehow something else must be blocking (I don't know yet what though).

Oh yeah, I loaded and built my game successfully. I really like the new Room Editor, it's much much better, being able to hide things is great because I have lots of object that I only use when loading a room and then get rig of them.

Quote from: eri0o on Sun 19/08/2018 01:23:19
I created a project using it, I selected Default Template, and it created TWO projects with the name of my project, one called Default Game, and one called new_test_game, but both are the same project?

It was tricky to differentiate between the recent game entries, as the data was just a collections of string (so external to a change of project name). I'm not sure how making a new project would show two entries, but potentially it could have migrated one of them from an old entry, from an older Editor version.

The comparison between entries is pretty basic, for the moment:
https://github.com/adventuregamestudio/ags/blob/master/Editor/AGS.Editor/Entities/EditorPreferences.cs#L58-L61 (https://github.com/adventuregamestudio/ags/blob/master/Editor/AGS.Editor/Entities/EditorPreferences.cs#L58-L61)

If it deduplicated by path, the correct project name needs to come from somewhere.

Actually I had noticed this, but for some reason I had forgotten to mention it. :-[

It does it on windows too (Win7 anyway), in fact it not only duplicated the project names for a new game, but also for the ones that were already done. It only shows on the start window to pick a recent project, it doesn't actually duplicate the folder (unless it's duplicating it some other place other than where I save them...)

Believe it or not, but it looks like I made support for files over 2GB.

Tested with 4.5 GB of sprites.

Test build: https://www.dropbox.com/s/a2pbghz4zsrfvl8/ags-3.4.2-wip6--64bitfiles.zip?dl=0
Source branch: https://github.com/ivan-mogilko/ags-refactoring/tree/ags3--file64updates

WARNING: this version modifies data format of some files, and you won't be able to use saved sprite file with older editor even if it's smaller than 2GB, so don't open your real project yet without a backup.

Hey, when I modify the project, build, and exit, and click yes to save, it crashes PlayOnLinux. Weird thing is doing the same running PlayOnLinux on Debug DOESN'T crash it.

playonlinux log output (https://gist.github.com/ericoporto/e32e6af8d18c2cbb3770360de4965154)

Other than this I have no assets to test the limits of more than 2GB :-\ , so I only quickly tested for regressions...

Oh reading the log I get it why it doesn't work the Linux build, instead of just copying the files, AGS creates hardlinks - and fails. I would prefer it just copied the files over - or gave me an option somewhere to do this instead.

Quote from: eri0o on Sun 19/08/2018 21:46:35
Other than this I have no assets to test the limits of more than 2GB :-\ , so I only quickly tested for regressions...

There is more than just 64-bit file support in this test build, compared to latest officially released one there is also room design state serialization. Is there a way to know better what causes the crash? I do not understand the log, it posts a lot of warnings there.

Quote from: eri0o on Sun 19/08/2018 21:46:35
Oh reading the log I get it why it doesn't work the Linux build, instead of just copying the files, AGS creates hardlinks - and fails. I would prefer it just copied the files over - or gave me an option somewhere to do this instead.

Normally it should fallback to copying if hardlink fails. Again, is it possible to find out at which point in code it fails?

Perhaps this explains what I saw, when the file was still being written whilst the engine was trying to open it. It might be the attempt to create a hardlink is triggering a copy as a fallback, but it isn't a blocking operation.

I have a question: does anyone use this version already to make the real game?

Assuming I may change savegame format a little without assigning it a new version index, breaking saves in this WIP version, because I don't want to keep and support the previous incorrect variant, would that be a problem to anyone?

Hey CW, sorry, I really have no idea how to get more insightful logs from playonlinux and wine. I am sea visiting family this week, but once I get home I should probably also test on wine on Mac to see how it's working there too.

I don't know if it was clear, but on Linux the crash I got was after closing ags. Apparently nothing got corrupted, so things are fine, but if something changed on the closing of ags since previous version it would worth a look.

Also I am on 3.4.1 and will be for some time.

Following the previously made suggestions from the few people, this version is now called 3.5.0, and since we decided to drop WinXP support there is a strong reason for a distinct major version.

AGS 3.5.0 - Alpha 4

Zip archive: http://www.mediafire.com/file/9bqybwn6g46hcn7/AGS-3.5.0-alpha4.zip/file

Common features
- Support for large files: single game package, sprite file, room files now may exceed 2 GB.

Editor
- Editor requires .NET Framework 4.5 to run. Dropped Windows XP support.
- Fixed editor preferences were saved separately for editor installed in different folders. Now they are shared between all installations of same version of AGS regardless of the program path.
- Save room editor's design-time config (item Visible and Locked states). These settings are saved in the special roomXXX.crm.user files and loaded when you open room in the editor.
- Removed Locked property from the Room Object, objects are now locked by the navbar.

Engine
- SetMouseBounds() no longer crashes the game if it is called with arguments out of range, these parameters are corrected and a warning logged instead.
- Fixed 'warnings.log' could never be created (was broken somewhere in 3.4.1 probably).


IMPORTANT WARNING: because of added >2GB file support some of the data formats were updated. Most importantly rooms and sprite file will become incompatible with previous versions of the Editor.
Also savegame format changed slightly and I dropped support for the savegames made by 3.4.2, because that version was never actually finalized. That could be get back, but only if it's really-really necessary.

Please make backups of your games before opening them in this version, and tell if something does not load up after this update (except 3.4.2 savedgames).

Quote from: Crimson Wizard on Fri 17/08/2018 16:21:22

Quote from: Neo_One on Tue 14/08/2018 15:27:09pass to 64 bits the file where the sprites are stored to remove the restriction of the maximum 2GB.

I began working on this.

THANKS! :);-D;-D;-D;-D:-D:-D:-D:-D:-D:-D

I recently had trouble to run the existing editor plugin with the 3.5.0 release.
The reason seems to be that all the AGS .net assemblies were changed to strong names. This is a breaking change, as the plugin compiled with an existing assembly (e.g. the plugin references AGS.Types) with a weak name is not compatible with the new one compiled with a strong name (see the following link https://stackoverflow.com/questions/15092577/weak-assembly-changed-to-strong-assembly for more details).

Is there a particular reason the assemblies now use a strong name?

Quote from: SpeechCenter on Mon 10/09/2018 23:15:04
I recently had trouble to run the existing editor plugin with the 3.5.0 release.
The reason seems to be that all the AGS .net assemblies were changed to strong names. This is a breaking change, as the plugin compiled with an existing assembly (e.g. the plugin references AGS.Types) with a weak name is not compatible with the new one compiled with a strong name (see the following link https://stackoverflow.com/questions/15092577/weak-assembly-changed-to-strong-assembly for more details).

Is there a particular reason the assemblies now use a strong name?

I moved the discussion of the strongname and settings problem to the Editor development board, because it may take some time to resolve:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=56457.0

A small note, the latest Alpha 4 made in August has number of mistakes that may prevent building game correctly under certain circumstances: noteably building speech.vox or audio.vox (I was actually surprised no one reported these, but guess not much people actually test this version yet).
I was going to upload an update that fixes them, but decided to wait a few days more to see if the above issue with editor plugins will resolve.

Thanks a lot! :cheesy::cheesy::cheesy::cheesy:

AGS 3.5.0 - Alpha 5

Zip archive: http://www.mediafire.com/file/51bicep52px9ilp/AGS-3.5.0-alpha5.zip/file

Has all content from AGS 3.4.1.14 (Patch 4).

Common features
- Raised imported sprites count limit to 90000* and removed total sprite count limit (this means you may have around 2 billions of dynamic sprites).

Editor
- (needs more testing) Fixed that existing Editor plugins could not load up with the new Editor.
- Don't display missing games in the "recent games" list.
- Fixed crash when deleting a room object.
- Fixed audio.vox and speech.vox not building correctly.


KNOWN ISSUES: Editor crashes on exit. This may be same bug eri0o reported a short while ago. The crash takes place only after game is saved and window closing and seem to not make it loose any changes.

(*) Technically engine now can handle up to 2 billion of sprites, but there is certain problem that makes non-trivial to allow user to set very large custom index to sprite (for example, have sprites number 1,2,3,4 and then 1000000). For the time being I found compromise in increasing the limit of imported sprites to some reasonable number (still 3 times higher than before). FYI the details of this problem are explained here: https://github.com/adventuregamestudio/ags/pull/499
The total number of sprites (imported + dynamic sprites) are now limited only by number stored in 32-bit signed integer (over 2 billion).

Thanks for taking care of the plugin probllem so quickly. I'll test this next week, based on the other thread, I believe the devised solution would work.

Just got around to test it with the latest plugin and it works.

Thanks for testing!

Hello Everyone,

I'm new to AGS and I'm having an error while trying to use two or more backgrounds in the same room (AGS 3.5.0 alpha5).

1) Create a new game
2) Import two or more background in the same room
3) press f5
https://ibb.co/dapQde

4) background can be removed after the error but if the editor is restarted then....
5) press f5
https://ibb.co/dapQde
6) edit room
https://ibb.co/kX2Lde
7) press close
https://ibb.co/kd7gjK

Hello, Vikram Vicky. I can actually see same error, this means that multiple backgrounds are broken in 3.5.0 WIP version.

Since you are only starting making new game I recommend using latest stable version instead for now, which is AGS 3.4.1:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=56452.0

Thank you, Crimson Wizard.
Is there any way to convert text editor of AGS 3.4.1 dark because I can convert AGS 3.4.1 to dark except the text editor...
https://ibb.co/gk3qTe ( AGS 3.4.1 dark using windows color scheme)

The only solution I can think of is using AGS 3.5.0 for coding only and copying that code in AGS 3.4.1.
What do you think? Is there a better way because I need code completion etc etc etc...

Alright, I'll try to release the fixed version today.

Awesome!!!

This is a (supposedly) fixed editor, you only need to copy files over the 3.5.0:
https://www.dropbox.com/s/08meilogunyyasn/AGS-3.5.0-alpha5--fix.zip?dl=0

There will be proper release post later, in few days perhaps.

Thanks a lot, Crimson Wizard.
It's really the greatest welcome someone can get, multiple backgrounds are running smooth.
I was downloading your game when I saw your message.
Thanks again.

90k imported sprites and more than 2 GB files? Wow! That was my dream and I knew it that one day my dream would become reality. If I make a new game, I will definitely import more than 30k sprites. Thanks a lot, Crimson.

Is there an installer for 3.5.0 and is it stable enough to begin using for development, I'm approaching the limits of 3.4.1 2GB cap and I've been looking forward to moving over to this to continue development?

Quote from: cdavenport on Thu 18/10/2018 16:59:21
Is there an installer for 3.5.0 and is it stable enough to begin using for development, I'm approaching the limits of 3.4.1 2GB cap and I've been looking forward to moving over to this to continue development?

I haven't made an installer yet, there's only zip archive (linked in the first post), which contents should be enough to run the editor and build Windows version of the game. I may add Linux component and/or Android APK for download if there's demand.

Frankly I do not know how stable it is. I do not make any games with it myself, and have spare time to only test newest added functions, so at most times rely on people's feedback to know if there are any problems. Earlier there were some serious bugs when the room editor got updated, which I fixed, but I haven't heard anything specific from users in the last couple of months.

Most important thing is that this version is still in active development. IDK about other contributors, but I personally have at least two big features planned before final release. Because of that each new update will have a chance to break something. I am ready to fix errors as soon as they are noticed, but since some changes may potentially break game project (making it unusable) my STRONGEST ADVISE is to make a full backup of your game whenever you install a new update of this WIP version.

AGS 3.5.0 - Alpha 6

This is a big update to GUI properties, both in the editor and script.

WARNING: makes changes to the game source format, please make a backup of your important game project before using this update!


Zip archive: http://www.mediafire.com/file/31534tckncjped5/AGS-3.5.0-alpha6.zip/file

Has all content from AGS 3.4.1.15 (Patch 4).

Common features
- Removed length limit on the Button and TextBox text.

Editor
- Split GUI's Visibility property into PopupStyle and Visible properties.
   NOTE: so instead of selecting "Normal GUI, initially on" and "initally off" you now choose "Normal GUI" then set Visible to whatever you need.
- Added Clickable, Enabled and Visible properties to GUI Controls.
- Fixed writing room with multiple backgrounds (regression).

Script API
- Replaced Alignment enum with a new one which has eight values from TopLeft to BottomRight.
- Renamed old Alignment enum to HorizontalAlignment, intended for parameters that are only allowed to be Left, Center or Right.
   NOTE: Alignment and HorizontalAlignment values are fully compatible, in the sense that you may use either. HorizontalAlignment is made mostly in sake of convenient autocomplete and backwards compatibility.
- Added new script class TextWindowGUI, which extends GUI class and is meant to access text-window specific properties: TextColor and TextPadding.
   NOTE: you get TextWindowGUI* pointer using GUI.AsTextWindow property (this works similar to GUIControl.AsButton etc).
- Added new properties to GUI class: AsTextWindow (readonly), BackgroundColor, BorderColor, PopupStyle (readonly), PopupYPos.
- Added Button.TextAlignment and Label.TextAlignment.
- Added missing properties for ListBox: SelectedBackColor, SelectedTextColor, TextAlignment, TextColor.
- Replaced ListBox.HideBorder and HideArrows with ShowBorder and ShowArrows.
- Added TextBox.ShowBorder.

Engine:
- Removed restriction preventing GUIs to be larger than the game's screen.
- Replaced number of fatal errors reported for incorrectly called script functions with a warning to the warnings.log instead. This is done either when arguments may be fixed automatically, or script command simply cannot be executed under current circumstances.

Linux:
- Fixes Linux game launch script (fixes issues with itch.io client).



KNOWN ISSUES: Editor crashes on exit. This may be same bug eri0o reported a short while ago. The crash takes place only after game is saved and window closing and seem to not make it loose any changes.
Unfortunately, I forgot to investigate this issue, will try to do soon.

Quote from: Crimson Wizard on Fri 19/10/2018 21:34:06
IDK about other contributors, but I personally have at least two big features planned before final release

Personally, I only want to look at improving tiled sprite import (just the interface, as someone opened a ticket for it).
If you wanted to make a to-do list for release, it would be useful, to check for any overlap.

Quote from: morganw on Sun 21/10/2018 15:29:47
If you wanted to make a to-do list for release, it would be useful, to check for any overlap.

Right, we may use the "Milestone" tag in github issues, I've just created the "3.5.0" milestone that may be assigned to tickets.

Quote from: Crimson Wizard on Fri 19/10/2018 21:34:06

Quote from: cdavenport on Thu 18/10/2018 16:59:21
Is there an installer for 3.5.0 and is it stable enough to begin using for development, I'm approaching the limits of 3.4.1 2GB cap and I've been looking forward to moving over to this to continue development?

Most important thing is that this version is still in active development. IDK about other contributors, but I personally have at least two big features planned before final release. Because of that each new update will have a chance to break something. I am ready to fix errors as soon as they are noticed, but since some changes may potentially break game project (making it unusable) my STRONGEST ADVISE is to make a full backup of your game whenever you install a new update of this WIP version.

Thanks Crimson Wizard I can't think of any bigger feature for AGS to improve on besides allowing users to make bigger games but excited to see how it evolves and begin using it. :)

Quote from: Crimson Wizard on Sun 21/10/2018 16:07:29
Right, we may use the "Milestone" tag in github issues, I've just created the "3.5.0" milestone that may be assigned to tickets.

Okay, I've added mine. If anyone wants to see the list, it is here (https://github.com/adventuregamestudio/ags/milestone/3).

Hello AGS dev team.

First I want to say that you guys have been doing great work, and while I never took the time to really say it, I am very appreciative of the work you have been doing, especially the ones who kept the project going for years when no one was paying attention.

I have a question about this version, which represents the future of AGS. The editor now cannot be run without the latest .NET patch, and we have lost support for an entire OS to have this privilege. Unless these parts are rewritten for future ports, it means these ports would have to be compatible with .NET, having to use something like mono. Is this new direction in the roadmap for the future of AGS? As you know there is monoAGS (AGS.NET) which is completely reliant on Microsoft frameworks. Is this the future of AGS too?

Quote from: Jack on Mon 22/10/2018 12:36:50The editor now cannot be run without the latest .NET patch, and we have lost support for an entire OS to have this privilege. Unless these parts are rewritten for future ports, it means these ports would have to be compatible with .NET, having to use something like mono. Is this new direction in the roadmap for the future of AGS?

Are you speaking of editor ports (do they exist or are planned?). (Engine nor engine ports never required .NET, and still do not.)
I don't think there is anything new in this direction, developers were continiously talking about porting Editor to Mono years before, so I guess this is where we were aiming at, although the progress was slow.
But neither game source format nor compiled game data have links to .NET, so in theory it's possible to write a program without .NET that would work with exactly same game sources and compile exactly same games.

Quote from: Jack on Mon 22/10/2018 12:36:50
As you know there is monoAGS (AGS.NET) which is completely reliant on Microsoft frameworks. Is this the future of AGS too?

Hmm, I do not know how to answer this question, not sure what do you imply with it. MonoAGS is completely different program with no relevance to original AGS except for some gameplay concepts. I guess it will develop on its own in the way tzachs wants. Whether it will succeed old AGS and fully replace it depends mostly on what this community will want.

Could someone direct me to discussions regarding the new pathfinder? Who has tried it? Has anyone witnessed enhancements? If so, in which specific cases? I know I have small pathfinding issues in some specific rooms of my game and I'm curious if I might fall in the scenarios where there is improvement, or what I should change in my end to fix the issues.

Quote from: Monsieur OUXX on Mon 22/10/2018 13:59:40
Could someone direct me to discussions regarding the new pathfinder? Who has tried it? Has anyone witnessed enhancements? If so, in which specific cases? I know I have small pathfinding issues in some specific rooms of my game and I'm curious if I might fall in the scenarios where there is improvement, or what I should change in my end to fix the issues.

Here's a discussion, which includes test results: https://github.com/adventuregamestudio/ags/pull/438, and specifically here (https://github.com/adventuregamestudio/ags/pull/438#issuecomment-379552909) I did several tests with unusual walkable areas.

Note that I've found a serious bug recently: https://github.com/adventuregamestudio/ags/issues/523

Okay I've tried the editor - incredibly easy and fast, very useuful for viewing several layers at once, exceptional :)

However, I have a suggestion for 'export' function for hotspot/walkbehind/whatever/etc; it's 90% the way there.

I'm trying to convert hotspots/walkable area masks etc. to a new size screen.
My old background was 1024x768; my new background is 1366x768 (this is the 16:9 ratio screen of the old 1024 5:4 size).
The transparent map that the .bmp (or some other format) I'm saving in is not the screen size; instead, it's edges are defined by the limits of the walkbehind/whatever
So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).
When I open them in paint.net, and alter canvas size to be the dimensions of the screen, the eg. hotspot ends up being a different position on-screen (and different proportions).

I don't understand how the proportion problem could have happened; I only increased canvas size, not changed image size.

See my photos for proof:
the widescreen version with too-small hotspot (http://redrom.ltd/img/1366wide.gif)
the original size and hotspot (http://redrom.ltd/img/1024wide.gif)

A simple solution would be to print all hotspots/walkable area/etc. on to one image, that's the size of the screen it came from; and somehow, the correct proportions.

Note: I have only used .bmp images.

Quote from: bx83 on Thu 01/11/2018 09:49:28
My old background was 1024x768; my new background is 1366x768 (this is the 16:9 ratio screen of the old 1024 5:4 size).
The transparent map that the .bmp (or some other format) I'm saving in is not the screen size; instead, it's edges are defined by the limits of the walkbehind/whatever
So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).

The purpose of the export operation is to print the actual bitmap as it is stored in the room you export from. It is only wrong if the result does not match the room it is exported from. In other words, for the test you should be able to import the same mask back into the same room and keep the original looks.

Then, if I got it correctly, you are exporting masks from the rooms which had one resolution and then trying to import them into the new rooms that have different resolution (with also different aspect ratio). Is it so, or something else?
If that's the case, correcting proportions is not what the export operation should do, but rather import operation. Because at the time of export the program has no idea what are you going to do with these images (and should not -- that's not its concern to know that).

BTW, you keep saying "screen size", do you actually mean game resolution? I was pretty confused by this earlier.

Quote from: bx83 on Thu 01/11/2018 09:49:28
So all exported resources come out a different size, and also, a different proportion... :/ (position is for my purposes, not important).
When I open them in paint.net, and alter canvas size to be the dimensions of the screen, the eg. hotspot ends up being a different position on-screen (and different proportions).

I don't understand how the proportion problem could have happened; I only increased canvas size, not changed image size.

If you have imported the masks from the 1024x768 room into 1366x768 room without modifying the image size, then it is only logical that proportions do not match the proportions of the background picture. You'd probably need to change mask size, stretching the proportions. But, that really depends on how much your backgrounds have changed. If they are like 1:1 only with different proportions, then stretching original mask should work; maybe will require a bit of adjustment by hand to correct loose pixels.

Could you upload some room (*.crm file) you do export from for me to test it out? Actually - both rooms, a pair of old and new ones.

Crimson, I've been tampering 3.5.0 alpha 5 and I have a problem. How do we draw any line or fill the area in the room editor? Nothing seems to work.  I can draw a filled rectangle but it renders the rectangle too away from my click point.

Quote from: proximity on Sat 03/11/2018 17:35:31
Crimson, I've been tampering 3.5.0 alpha 5 and I have a problem. How do we draw any line or fill the area in the room editor? Nothing seems to work.  I can draw a filled rectangle but it renders the rectangle too away from my click point.

Nothing has changed in regards to the mask drawing. The room zooming/scrolling code has changed, but I've just tested this in a random game and painting works.
Could you give more details of what you do? What's your game resolution, room size, do you use room zoom? what kind of mask mode are you in and what is the area ID?

I've just tried it with patch 6 and the result is the same. There is a huge offset between clicking point and drawing point. Offset amount is like a half of the screen. Drawing tools are broken for walkable areas and regions and hotspots. Walk behinds work properly.

Test resolution : 1920*1080
Room resolution : 1920*1080
Tried with zoom : 100%
Broken modes : Walkable areas, regions. hotspots (ID 1,2,3)
Working modes : Walk behinds

Check this image. The blue line on the roof is mouse position and the other lines below are actual drawn lines. There is a huge gap between them.

https://ibb.co/ct02YL

Yes, this is technically because in hires games all masks except Walk behinds are 2 times smaller than the room size (has 2 times less resolution/precision).
Probably the coordinate conversion is broken at some point, I am looking into this now.

Understood. I can test it after fix if you need me.

Quote from: proximity on Sat 03/11/2018 19:39:43
Understood. I can test it after fix if you need me.

Please try following build (copy over latest 3.5.0 installation):
https://www.dropbox.com/s/zune9gln285sozt/AGSEditor-3.5.0.2--roompaintfix.zip?dl=0

There is also one strange issue I noticed, when the editor's scroll position is not 0, the rectangles you paint end up shifted by 1 pixel right/down. Not yet sure if this was also caused by recent changes in this version. This may also be related to coordinate rounding.

I pasted them to both patch 5 and patch 6. All drawing tools work now. Rectangle tool draws to 1 pixel right-down as you said. I think you should update these files on patch 6. Thanks for quick update :)

AGS 3.5.0 - Alpha 7

This is a very small bug-fixing update, mainly  to counter recently found problems with the room editor.

Zip archive: http://www.mediafire.com/file/b0sa0425evh77p2/AGS-3.5.0-alpha7.zip/file

Editor:
- Fixed same game appeared multiple times in the "Recent games" list if the game's title was changed (regression).
- Fixed room masks drawing in the high-resolution games (regression).
- Fixed drawing operations on the room masks were sometimes off by 1 pixel (regression).

Engine:
- Made engine fallback to defaults if config contains invalid game scaling setting.
- Fixed crash in the Software renderer which was occuring when any other renderers are tried prior to Software one but failed to initialize for any reason.



KNOWN ISSUES:
- Editor crashes on exit. The crash takes place only after game is saved and window closing and seem to not make it loose any changes.
- New pathfinder crashes when the destination lies outside of the room: https://github.com/adventuregamestudio/ags/issues/523

Hello Crimson. There are serious problems with the engine:

* The Room pane gets broken over time and you can't access it, and it's too slow, nearly uneditable.
* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).
* GetWalkableAreaAt script command doesn't work anymore. The engine knows the player is on a walkable area but doesn't execute the command.
* Character.Frame property also seems broken. Whatever the character frame is, the engine thinks it is always true.

Quote from: proximity on Mon 12/11/2018 22:53:53
* The Room pane gets broken over time and you can't access it,

Can you give any details?

Quote from: proximity on Mon 12/11/2018 22:53:53
and it's too slow, nearly uneditable.

Is this related to the zooming? (it's still may not be optimised for high-resolution games)

Quote from: proximity on Mon 12/11/2018 22:53:53
* GetWalkableAreaAt script command doesn't work anymore. The engine knows the player is on a walkable area but doesn't execute the command.

Only to make sure, are you passing screen coordinates or room coordinates in there?

Quote from: proximity on Mon 12/11/2018 22:53:53
* Character.Frame property also seems broken. Whatever the character frame is, the engine thinks it is always true.

Not sure what you mean here? Character.Frame is integer, so its always "true" (in boolean sense) if its above 0. How do you use it?

Okay. Here are details :

* The Room pane on the top of the window gets unselectable over some time. When you select it, nothing happens. Just a window frame that represents the Room window and its inside is blank, or not blank really, its inside is the screen of the last window you visited. It's like an error from Windows 98 era. Do you visualize what I described? If not, I can take a screenshot.

* It's not related to zooming because I tried it with 100% zoom. It's much slower than 3.4.1.

* GetWalkableAreaAt I just migrated my test project from 3.4.1 to 3.5.0 and it was working on 3.4.1. Coordinates are player.x and player.y. I think they are room coordinates?

* I can explain it with an easy example :
if (cChar.Frame == 35) {
cChar.ChangeView(X);
}

In this simple code, the engine doesn't wait to change the view till the frame number 35. Instead, It changes the view immediately. Whatever the the actual frame number is, the engine thinks It's 35 and executes the command. And believe me, I know what I'm doing :) I didn't test every single script command. There may be more broken scripts like Character.Frame and GetWalkableAreaAt.

Quote from: proximity on Tue 13/11/2018 12:43:10
* GetWalkableAreaAt I just migrated my test project from 3.4.1 to 3.5.0 and it was working on 3.4.1. Coordinates are player.x and player.y. I think they are room coordinates?

According to the manual, GetWalkableAreaAt requires screen coordinates, so in scrolling room it will require adjustment with GetViewportX()/Y().
I will test that myself soon though, I recall we had some problem with detecting walkable areas (although that could have been another version).

Quote from: proximity on Tue 13/11/2018 12:43:10
* I can explain it with an easy example :

Code (ags) Select Expand

if (cChar.Frame == 35) {
cChar.ChangeView(X);
}

In this simple code, the engine doesn't wait to change the view till the frame number 35. Instead, It changes the view immediately. Whatever the the actual frame number is, the engine thinks It's 35 and executes the command.

But that's technically impossible if only Character.Frame is not working, it's about how "==" operator is working then, because Character.Frame itself cannot know what number you are comparing to. Either things are completely messed up in the engine, or there is something else in the script that affects that.
Could you for example log the current frame value somewhere, like print on a GUI label and see how it changes?
EDIT: I did a very simple test, which looks like this:

function repeatedly_execute_always() {
  lblScore.Text = String.Format("Frame: %d", player.Frame);
  if (player.Frame == 6)
  {
    lblScore.Text = lblScore.Text.Append("+");
  }
}

This prints character's frame value on label, and adds "+" only if it's particular frame.

Of course, I will check the frames with label to see If they are right and share the results. May be other things cause this. Did you change something in the global script page? I don't have deep knowledge but I feel something is not right about scripting.

I checked the frames with GUI label and everything looks normal. Probably I messed something in repeatedly_execute. So forget about Char.Frame :smiley:

In theory there is only one big feature (http://www.adventuregamestudio.co.uk/forums/index.php?topic=56565.0) left for me to complete, so I will hopefully find more spare time soon and begin fixing all the reported problems.

Quote from: proximity on Mon 12/11/2018 22:53:53
Hello Crimson. There are serious problems with the engine:

* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).

I am trying to replicate this now, and it does not seem to happen to me.

Does this still happen to you? Can you tell more details about this, like -
- what is the size of the room;
- what is the actual size of character or object sprite;
- if you choose sprite, what is "Resolution" field sais in its properties?
- do you have any walkable areas with scaling in the room?

Quote from: Crimson Wizard on Mon 03/12/2018 17:53:27

Quote from: proximity on Mon 12/11/2018 22:53:53
Hello Crimson. There are serious problems with the engine:

* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).

I am trying to replicate this now, and it does not seem to happen to me.

Does this still happen to you? Can you tell more details about this, like -
- what is the size of the room;
- what is the actual size of character or object sprite;
- if you choose sprite, what is "Resolution" field sais in its properties?
- do you have any walkable areas with scaling in the room?

Sorry for the late response. The bug occured when I first create an object or a character in a room. After closing and reloading the project, the sprites look normal now. I tried small and big sprites. The room is a wide scrolling room, 13000*1080. Sprites are all "high" resolution on the properties. Walkable area scaling is 70% but the characters and objects don't stand on it.

Quote from: Crimson Wizard on Mon 03/12/2018 17:53:27

Quote from: proximity on Mon 12/11/2018 22:53:53
Hello Crimson. There are serious problems with the engine:

* Object or character images on the room seem bigger than original size, like two times bigger.(in the editor).

I am trying to replicate this now, and it does not seem to happen to me.

Does this still happen to you? Can you tell more details about this, like -
- what is the size of the room;
- what is the actual size of character or object sprite;
- if you choose sprite, what is "Resolution" field sais in its properties?
- do you have any walkable areas with scaling in the room?

This just happened to me too, yesterday I began working with my game in the new engine and this morning in one of the rooms the objects and Characters were showing two-or-more sizes bigger than they were created at, in the room editor pane. I took a screenshot but I don't have a different site to host it on yet so I can link it up here. It seemed to occur after I imported a bunch of sprites to create an object animation, and deleted some old ones, then running the game to test it. I think it occurred after I ran the game, and when I went back to the editor, somehow the sprites were showing in the editor enlarged like they do when you run the game and it scales them up. I checked other rooms, and the objects, ect. in those too were two to three times bigger in the editing pane as well. Then I exited, and restarted the engine and everything went back to normal for the time being.

May game's resolution is 640x360 and I've begun using the latest AGS 3.5.0 which I got from the first page in this thread.

UPDATE: It was working fine after restarting, but after I began fiddling around by moving Objects and Characters around on screen (changing X,Y, coordinates to position them here and there) and testing the game repeatedly, it happened again and now all the objects and characters are enlarged two to three times again in the editor pane making it impossible to work on.

UPDATE 12-11-2018: This bug happens consistently for me, after I import some sprites, assign them a view, and then place an object in a room using the sprites I just imported, when I return to the room editor most of the time everything is blown up in size against the background, as in previous posts. Saving the game and then restarting the engine fixes it until I have to do those steps again. It doesn't seem to happen every single time I do those steps, but quite often.

My room sizes are 640x360. The size of the object or sprite is always different, depending on what I import. Resolution of sprites is High (above 320x240). All of my rooms have Walkable areas with different scaling factors.

Hmm, so I was trying to reproduce this object scaling bug you were talking about, and so far the only time I was able to get anything similar was when I zoomed out room very far, then small objects were scaling down at first but after certain zoom threshold they became larger instead. Idk if it's the same situation as you had but hopefully there is something common there. I will investigate this now, as well as the slowdown problem.

UPD: I've fixed few errors I found so far, and will be preparing new update soon, it will contain some major stuff...

Quote from: Crimson Wizard on Mon 17/12/2018 17:09:57
Hmm, so I was trying to reproduce this object scaling bug you were talking about, and so far the only time I was able to get anything similar was when I zoomed out room very far, then small objects were scaling down at first but after certain zoom threshold they became larger instead. Idk if it's the same situation as you had but hopefully there is something common there. I will investigate this now, as well as the slowdown problem.

For me, the object scaling issue always occurs after importing new sprites and assigning them a view. Most of the time the sprites are large, and there's a large number of them (up to 100 at times). Whenever I do that, I have to close and restart to be able to continue to work. I log hours daily working on the engine and this is the only issue that's come up from me.

I am still looking into this scaling bug reported above, but there are two major features completed recently, and we needed to post a new update to let people test them.



AGS 3.5.0 - Alpha 8

This update include two new major features:

1) New revamped sprite import dialog. We would really like to have a feedback on this.
2) Custom room viewport & camera script commands that let you configure position and scaling of your room on game screen.


Zip archive: http://www.mediafire.com/file/6bak3fncw1dg3ef/AGS-3.5.0-alpha8.zip/file


Editor:
- Game and room templates are now by default saved in AppData/Local/AGS folder. Editor finds them in both program folder and AppData.
- New revamped sprite import window.
- Sprites that were created using tiled import can now be properly reimported from source.
- Allow room size to be smaller than the game's resolution.
- Fixed wrong game may be loaded from Recent Games list if one of them was deleted in the past.
- Fixed crash when creating room template after doing full game rebuild or just after creating new game.
- Fixed room editor working very slow after new zooming slider was introduced (should be about as fast as before now).
- Fixed room sprites did not draw scaled down with zoom < 100%.
- Fixed GUI or Room editors sometimes allowed to scroll beyond necessary limits.
- Fixed translations were not available for the test run if game was not fully rebuilt yet.
- Fixed Windows Explorer was sometimes locking the game files during compilation.
- (Probably) fixed crash on Editor shutdown.

ScriptAPI:
- Implemented Viewport and Camera script classes which control how room is displayed on screen.
- Added properties Game.AutoSizeViewportOnRoomLoad, Game.RoomViewport, Room.Camera.

Engine:
- Fixed new pathfinder was crashing if target location lies beyond room borders.
- Fixed old-style string functions like StrCopy could crash the game if user managed object's member is passed as an argument into them.
- Fixed 8-bit sprites could have broken colours if game is run using Direct3D or OpenGL.
- Fixed broken colours during fade-in and fade-out in 16-bit games.



KNOWN ISSUES:
- Some weird sprite scaling bug in the room editor, described in the posts above. According to user reports it may be fixed by restarting the editor.

---

How to use room viewport commands in script.

This requires proper documentation, but for a short explanation:

Viewport is a place on screen where room is drawn, defined in game coordinates (e.g. 0,0 - 320x200).
Camera is a place in room which is being drawn. Camera size may be determined in two ways:
a) explicitly setting Width and Height, which tells actual rectangle in the room;
b) setting ScaleX and ScaleY properties to automatically adjust displayed room relative to the viewport's size.
For example, if you set ScaleX/Y to 2.0, then room will appear zoomed in twice as large as the viewport's size. If you set ScaleX/Y to 0.5, it will appear twice as small (zoomed out).
NOTE: you cannot set camera size larger than the room's background.

To access viewport and camera use new properties: Game.RoomViewport and Room.Camera.
Game.AutoSizeViewportOnLoad boolean value turns automatic viewport adjustment on room load. It is ON by default which corresponds to normal room view you are used to.

Old viewport functions are now deprecated, they may still be enabled if you set "Script compatibility level" to v3.4.1 or lower.
Here's correspondence between old and new functions:

* SetViewport(x, y); ===> Room.Camera.X = x; Room.Camera.Y = y; Room.Camera.AutoTracking = false;
* ReleaseViewport(); ===> Room.Camera.AutoTracking = true;
* GetViewportX(); ===> Room.Camera.X;
* GetViewportY(); ===> Room.Camera.Y;

Basically, as you may see, what was known as "viewport" earlier is now called "camera", and "new viewport" is something that was never supported before.

Something I just realized, although the sprite limit was raised, room objects save the sprite index as 16-bit value which means you cannot assign anything above 32767 to them. This would need an extra fix.

I am testing on wine the new sprite import. It feels easier, and apparently works! I like I can by default import a ton of sprites at the same time! This is cool!!!

I like the new progress bar addition, I think previously AGS just stood there unresponsive, in a folder with too many sprites, this is nice.

On the tiled sprite import, one minor thing, it loads with a number in x,y position, I think the default should be 0,0 (imagining I have a single sheet png, with each images of the same size).

The is an option to copy a sprite to the clipboard on the sprite navigator, I don't know if that was there before, but when I click, it does nothing.

Feature requests for the sprite GUI!:

- I have Aseprite triggering as my external editor, and it opens lightning fast, but a way to view and zoom a imported sprite, in AGS, would be cool.
- sprite GUI, has all things available through the right click on white space, adding a small bar on top of the GUI, with the same functions, would easier. I prefer inside the tab instead of the main toolbar like the rest of AGS, but both would work - one favor low resolution monitor and the other bigger resolution monitors.
- totally new feature: import folder -> would import a folder with pngs, and if a folder with png is inside that folder, recreate the folder structure inside AGS. I think is unneeded as project normally evolve slowly but could enable really fast use of ready made graphics from graphic asset packages.

____

Script Compatibility seem kinda broken since BASS template doesn't work anymore.

Thank you for testing this, eri0o.

Quote from: eri0o on Sat 22/12/2018 14:22:12
I like the new progress bar addition, I think previously AGS just stood there unresponsive, in a folder with too many sprites, this is nice.

To be honest, it was more a debug tool that was left in. It turns out that majority time whilst the Editor was in hung state was spent modifying the GUI control in a loop, and nothing to do with the import actions at all. This should be fixed now, so you should see a massive performance increase as well as the progress bar.

Quote from: eri0o on Sat 22/12/2018 14:22:12
On the tiled sprite import, one minor thing, it loads with a number in x,y position, I think the default should be 0,0 (imagining I have a single sheet png, with each images of the same size).

I think you are right, and just leaving it on 0,0 makes more sense in practice. I'll change it.

Quote from: eri0o on Sat 22/12/2018 14:22:12
The is an option to copy a sprite to the clipboard on the sprite navigator, I don't know if that was there before, but when I click, it does nothing.

I don't think this was modified, but it doesn't seem to work for me either, so I'll have a look.

Quote from: eri0o on Sat 22/12/2018 14:22:12
Feature requests for the sprite GUI!:

- I have Aseprite triggering as my external editor, and it opens lightning fast, but a way to view and zoom a imported sprite, in AGS, would be cool.
- sprite GUI, has all things available through the right click on white space, adding a small bar on top of the GUI, with the same functions, would easier. I prefer inside the tab instead of the main toolbar like the rest of AGS, but both would work - one favor low resolution monitor and the other bigger resolution monitors.
- totally new feature: import folder -> would import a folder with pngs, and if a folder with png is inside that folder, recreate the folder structure inside AGS. I think is unneeded as project normally evolve slowly but could enable really fast use of ready made graphics from graphic asset packages.

Personally, I'm still aiming for just having sprites on the disk, and 'importing' is just defining the import options for each image. So I would hope that the final result would just be a 'project browser' instead of a 'sprite manager', and you could choose some action on any type of file or folder, or hand-off to any external program. I think the toolbar has a lot of issues anyway, in that things magically appear there depending on what you are editing (since they also include the paint controls), and it contains functions that aren't available in any other place (probably makes sense for choosing a paint brush, but not for mask import/export).

Quote from: eri0o on Sat 22/12/2018 14:22:12
Script Compatibility seem kinda broken since BASS template doesn't work anymore.

I tried the one in the archive and it seemed to work. If it was an error for 'ProcessClick' it could have been an older copy of the template that hadn't had the fixes made. I think the plan is to release the final version of 3.5 with the templates from here (https://github.com/adventuregamestudio/ags-template-source).

Quote from: eri0o on Sat 22/12/2018 14:22:12
Script Compatibility seem kinda broken since BASS template doesn't work anymore.

Script compatibility is controlled by two switches in the General Settings called "Script API version" and "Script compatibility level". What were they set to and what were the errors?

It complained of SetViewport something, but maybe, I had some code from the first iteration of the camera functions. I will try a clean project later.

Quote from: eri0o on Sat 22/12/2018 16:38:50
It complained of SetViewport something, but maybe, I had some code from the first iteration of the camera functions. I will try a clean project later.

SetViewport is a standard AGS function, which is now deprecated. I warned about this in my recent release post: http://www.adventuregamestudio.co.uk/forums/index.php?topic=55829.msg636599086#msg636599086

You may get it back by setting script compat level to 3.4.1.

PS. By the way, I have a thought about changing it slightly once more time in the next update (have Game.RoomViewport moved to something like Screen class).

As info that might be useful, I'm testing alpha 8 with my game. I have changed the first "GetViewportX()" the compiler finds for "Room.Camera.X" (which is located in the Tween module), and then I get this message:
"must have an instance of the struct to access a non-static member".

Quote from: ArsCreativa on Mon 24/12/2018 06:41:48
As info that might be useful, I'm testing alpha 8 with my game. I have changed the first "GetViewportX()" the compiler finds for "Room.Camera.X" (which is located in the Tween module), and then I get this message:
"must have an instance of the struct to access a non-static member".

This is true, AGS has a bug that it cannot correctly parse long sequence of "x.x.x" if the second x is a static attribute or function. This is irritating and I am planning to look into fixing this if possible. If not, maybe I even move camera and viewport and make them global variables as a last resort.

For the moment workarounds is:
Camera *c = Room.Camera; something = c.X;
It's possible to write new version of "GetViewportX":
int GetCameraX() { Camera *c = Room.Camera; return c.X; }



Also I am planning on adding few extra functions to camera and viewport which will speed up typing most common commands, like setting X&Y position at once.

moved camera questions here (http://www.adventuregamestudio.co.uk/forums/index.php?topic=56565.msg636599439#msg636599439)

@morganw , the new tiled import GUI is amazing, did the below characters import to view in less then 10 min (find sprite in open game art, import sprite, view, assign view to characters), before importing tiled was a real pain.

Spoiler

(https://i.imgur.com/Vi5EPJw.png)

(https://i.imgur.com/NT3hPWv.png)

[close]

AGS 3.5.0 - Alpha 9

WARNING: there was a major internal modification to the Rooms code. Although I did a lot of testing with existing games and created ones for the test to make sure that everything is working like before, still please make a full backup of your project before upgrading to this version and report if you notice anything wrong with how your rooms are saved and loaded in the editor and run within the game.

WARNING 2: There was a change to recently added Viewports & Cameras script API, with some of the properties REMOVED and some moved to other struct and/or renamed. Keep in mind that you might have to edit your scripts once again. I apologize for this inconvenience.


Zip archive: http://www.mediafire.com/file/xnwsm03opg0g10t/AGS-3.5.0-alpha9.zip/file


Changes since 3.5.0 alpha 8:


Editor:
- Improvements and fixes to the new sprite import dialog. Allowed to drag the tile selection in the up-left direction.
- Added context menu command to open sprite's source file location.
- New sprite export dialog that lets you configure some export preferences, including remapping sprite source paths.
- Display audio clip length on the preview pane without starting playback.
- Fixed room mask export was saving masks as 8-bit PNGs instead of indexed bitmaps (which made them impossible to import back to the room as-is).
- Fixed MIDI audio preview was resetting all instruments to default (piano) after pausing and resuming playback.
- Fixed MIDI audio preview had wrong control states set when pausing a playback.
- Fixed Debug build failed if no Compiled/Windows folder exists (regression).

Script API:
- REMOVED ScaleX and ScaleY properties from Camera.
- Introduced new managed struct Point describing (x,y) coordinates.
- Implemented new Screen struct featuring static Width and Height properties and ScreenToRoomPoint() function.
- Moved AutoSizeViewportOnRoomLoad and Viewport from Game to Screen struct.
- Deprecated System.ScreenWidth, ScreenHeight, ViewportWidth and ViewportHeight in favor of Screen.Width/Height and Viewport.
- Added new functions to Viewport struct: GetAtScreenXY(), SetPosition(), ScreenToRoomPoint(), RoomToScreenPoint().
- Added new functions to Camera struct: SetAt() and SetSize().

Engine:
- Fixed graphic artifacts looking like thin vertical lines around sprites when running OpenGL renderer (aka "texel leaking").
- Fixed a new crash issue with the legacy InventoryScreen() command (appeared in somewhere around 3.4.1).
- Fixed some compilers (e.g. gcc 6.0 on Linux) could instigate a crash in the on_event callback with no loaded room.
- Fixed screen-to-room conversion not updated if viewport's location was changed but size remained the same.
- Fixed software renderer working with 16-bit rooms (regression).
- Fixed Debug(2) and Debug(5) overlays not drawn correctly in custom room viewports (regression).
- Fixed overlays that were positioned relative to the room not displayed correctly (regression).
- Fixed software renderer crashes when switching between fullscreen and windowed modes (regression).



NOTES:

Screen.ScreenToRoomPoint returns null if there is no room Viewport under these coordinates. If there will be multiple viewports supported in the future engine simply won't know which to choose if there's none directly there.
Both Viewport.ScreenToRoomPoint and Viewport.RoomToScreenPoint have 'clipViewport' parameter which tells whether they should return null if the coordinates lie outside of the visible part of the room.



KNOWN ISSUES:

- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...

I may be missing the line/function but is there a way to change the color of a listbox (for the selected and the non selected) during run-time. If not, and sorry to ask, but you think it'd be too complicated to implement, it's okay if it is, I'll work around it, just wondering.

Quote from: Dualnames on Tue 15/01/2019 16:18:35
I may be missing the line/function but is there a way to change the color of a listbox (for the selected and the non selected) during run-time. If not, and sorry to ask, but you think it'd be too complicated to implement, it's okay if it is, I'll work around it, just wondering.

Following was implemented in 3.5.0:
ListBox.SelectedBackColor
ListBox.SelectedTextColor
ListBox.TextColor.

Full list of script additions is under "Script API" section in the first post.

PS. You must have either v3.5.0 or "Highest" set in the "Script API version" option of the General Settings.

Wonderful, will update to this once it's stable!

Hey, I'm not sure this goes here, so I'm wondering in general, I've implemented an autosave system, but in general, because the game autosaves every time u enter a room, it's causing a 5-10 dps drop and music stutters, is there a good way around this, like the savegame part?

EDIT:

Whenever i comment the autosave code, it fixes the stutter, but the 5 fps frame drop seems to be irrelevant to that.

First off, thanks for the continued work, CW!

I have a question: What is the state of compatibility of this version with the iOS port? I am currently using 3.4.0 which works fine and haven't switched to any of the higher versions because they aren't compatible. I think the 3.4.2 thread had an explicit mention about incompatibility but I didn't see anything in the first post here.

Quote from: cianty on Fri 18/01/2019 08:59:04
I have a question: What is the state of compatibility of this version with the iOS port? I am currently using 3.4.0 which works fine and haven't switched to any of the higher versions because they aren't compatible. I think the 3.4.2 thread had an explicit mention about incompatibility but I didn't see anything in the first post here.

Android and iOS were broken in early 3.4.1 release because of changes to OpenGL renderer (so they could not compile). Android was since fixed, but iOS is still not. It may be that fixing iOS is as easy as copying Android fix over, but I cannot tell because I cannot build iOS port myself.

Someone needs to set up iOS building for 3.4.1 and help us find this out.

UPD. The problem was related to Tint and Light level support using shaders when using hardware-accelerated OpenGL renderer. But there's still software mode that should probably work. In the worst case we may simply programmatically exclude the newer code in ha renderer on iOS.

Mobile ports are still big issue because there is no one with good knowledge of Android or iOS to help us fixing and maintaining them.


UPD: So, I've just had a small talk with Janet Gilbert and she reminded me that her own iOS port is different now because they were developing it further separately. This complicates things in a way, because we now have 2 iOS ports and no idea how different they are.

Thanks a lot for the reply, CW. I will then stick with 3.4.0 for now for my game.

Quote from: cianty on Sat 19/01/2019 15:07:46
Thanks a lot for the reply, CW. I will then stick with 3.4.0 for now for my game.

Can you tell, how do you build for iOS with 3.4.0? Do you build iOS project yourself or someone is helping you?

I'm getting an error when I'm trying to launch this build (AGS 3.5.0 alpha 9). It's says it can't load AGS.Native.dll (which is present in the folder):

(https://i.imgur.com/XJgDxl8.png)

Quote from: Snarky on Sun 27/01/2019 21:01:45
I'm getting an error when I'm trying to launch this build (AGS 3.5.0 alpha 9). It's says it can't load AGS.Native.dll (which is present in the folder):

Which system are you on?

I think this is not mentioned anywhere yet, but since 3.5.0 AGS editor requires different C++ redistributable, one for VS 2015: https://www.microsoft.com/en-in/download/details.aspx?id=48145
Also I've seen information that it's a part of KB2999226 update.
Please tell if that worked.

Windows 10 (x64) running in a VirtualBox VM.

I installed the VS2015 redistributable (thanks!), but still get the same error.

Hmm... ok, not sure about this.
Native.dll requires two runtime DLLs: vcruntime140.dll and api-ms-win-crt-runtime-l1-1-0.dll

My properties and other editor windows disappeared.
I there a way to get them to show up again, maybe a hotkey and the like

Quote from: dbuske on Wed 30/01/2019 17:49:05
My properties and other editor windows disappeared.
I there a way to get them to show up again, maybe a hotkey and the like

1) Look into the "Window" menu and make sure these windows are checked.
2) If that does not work, go to C:\Users\<Your username>\AppData\Local\AGS and delete Layout.xml (do this when Editor is closed!).

Thank you Sir

Quote from: Crimson Wizard on Sat 19/01/2019 16:03:14

Quote from: cianty on Sat 19/01/2019 15:07:46
Thanks a lot for the reply, CW. I will then stick with 3.4.0 for now for my game.

Can you tell, how do you build for iOS with 3.4.0? Do you build iOS project yourself or someone is helping you?

It is indeed my girl-friend who set up the port as she is experienced with iOS development. I haven't really followed what she has been doing in detail though. I think our iOS build is based on the original AGS iOS port but also with adjustments from Janet Gilbert's version. Each version separately did not work on its own. The last problem we had e.g. was WAVs not playing but I can't remember what her fix was.

We made some other adjustments as well... e.g. in the AGS game I detect whether there is a file called "touchmode" in the savegame folder. If there is, the game sets a global variable TOUCMODE which switches to "touch mode" (surprise!) with a number of adjustments for touch devices (like showing no cursor, some hotspots being bigger, some puzzles different, etc.). In our iOS wrapper we automatically generate that file if it doesn't exist. Now, I can work on the game without having to worry about building a specific version and I can even use the same savegame from different environments.

Afraid the fix did not work. No matter what version I installed the properties etc windows do not show up.
Apparently there is no layout.xml file on my system.
Any help is appreciated.

Could you do a printscreen of your AGS screen?

(https://i.imgur.com/mT9iHtZ.png)
Notice the properties etc are checked and no windows

Quote from: dbuske on Sat 02/02/2019 12:53:05
Apparently there is no layout.xml file on my system.

Are you sure? because it must reset to default in such case.
I'll point again: it should be in C:\Users\<Your username>\AppData\Local\AGS\Layout.xml
Usually you can get there by typing "%USERPROFILE%\AppData\Local\AGS" in the windows explorer path line.

I go to that address and it is not there.
I searched for layout.xml and nothing comes up.
File explorer wasn't showing the correct location for some reason.
When I put in your last address it came right up
I deleted layout.xml and I got the windows showing again.
Thank you very much.

Quote from: dbuske on Sat 02/02/2019 17:44:55
I go to that address and it is not there.
I searched for layout.xml and nothing comes up.

This is most strange.
Please tell which version of AGS are you using? Maybe we may make a test build that resets panes or tells where the layout file actually is.

Windows 10 was acting in its usually funky way
Seems to work differently each time.
Inconsistent
It was the latest alpha

Quote from: dbuske on Sat 02/02/2019 17:44:55
File explorer wasn't showing the correct location for some reason.
When I put in your last address it came right up
I deleted layout.xml and I got the windows showing again.
Thank you very much.

Oh that may be my mistake. The first address I gave was working for Windows 7, but Windows 10 probably has slightly different one.

So, if I understand correctly, the problem is solved now?

All fixed!

AGS 3.5.0 - Alpha 10

WARNING: there was a major internal modification to the Rooms code recently (since previous alpha 9). Please make a full backup of your project before upgrading to this version and report if you notice anything wrong with how your rooms are saved and loaded in the editor and run within the game.


Zip archive: http://www.mediafire.com/file/bgb7617w6lc869h/AGS-3.5.0-alpha10.zip/file


In summary, this is a small but cruicial bug-fixing release.


Changes since 3.5.0 alpha 9:

- Have merged all changes from AGS 3.4.3 (https://www.adventuregamestudio.co.uk/forums/index.php?topic=56887.0)

Editor:
- Use Magick.NET library as a GIF loader. This should fix faulty GIF imports.
- If sprite import failed with data error AGS will instead create a placeholder image.
- Better crash prevention when reloading existing sprites from source.
- Fixed crash in the sprite import window when dragging selection box outside of the image.
- Fixed errors when importing of old-format rooms, as well as using room templates (regression).
- "Import over font" command now supports importing WFN fonts too.



KNOWN ISSUES:

- Reported by Snarky: need to find out which components need to be added to use AGS 3.5.0 on fresh Windows installation.
- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...

Ok so soon here's another small update, but it has critical bug fixes from AGS 3.4.3 patch 1, and also an important ammendments to new Room Viewport & Camera API.

AGS 3.5.0 - Alpha 11


Zip archive: http://www.mediafire.com/file/l6rtpsjq94fo5m1/AGS-3.5.0-alpha11.zip/file


Changes since 3.5.0 alpha 10:

- Have merged critical bug fixes from AGS 3.4.3 Patch 1 (https://www.adventuregamestudio.co.uk/forums/index.php?topic=56887.0)

Editor:
- Fixed few mistakes when converting interaction scripts from very old games (regression)

Script API
- Moved new room camera and viewport API into API version v3.5.0.7 (was v3.5.0).
- All functions that find room objects under screen coordinates are now being clipped by the viewport (fail if there's no room viewport at these coordinates).
  This refers to: GetLocationName, GetLocationType, IsInteractionAvailable, Room.ProcessClick, GetWalkableAreaAt and all of the GetAtScreenXY functions (and corresponding deprecated functions).
- Added Character.GetAtRoomXY, Hotspot.GetAtRoomXY, Object.GetAtRoomXY, Region.GetAtScreenXY, replaced GetWalkableAreaAt with GetWalkableAreaAtScreen and added GetWalkableAreaAtRoom.

Please take a notice: if this new behavior breaks your game, either switch to using GetAtRoomXY functions, or switch down to Script API Level v3.5.0 in General Settings.



KNOWN ISSUES:

- Reported by Snarky: need to find out which components need to be added to use AGS 3.5.0 on fresh Windows installation.
- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...
And of course the ones noted at github issue tracker: https://github.com/adventuregamestudio/ags/issues?q=is%3Aissue+is%3Aopen+label%3Abug


EDIT: I had to reupload the package because of the small but serious bug. Download link is the same.

I'm worried by the clipping behaviour but I don't know if it's justified or not.

Quote from: Monsieur OUXX on Wed 27/02/2019 16:28:52
I'm worried by the clipping behaviour but I don't know if it's justified or not.

I was planning to post detailed explanation but did not find time yet.
This change may complicate certain actions a little bit, but also makes interaction between screen and room more logical (especially now when you may have custom viewport and camera sizes, room camera scaling, and maybe even rotation in the future).

IMHO there are following common situations where you would like to find an object using some coordinates.

1) You are processing player's input and need to find an object or location under or near mouse coordinates. In this case only what you see on screen (or rather inside room viewport) is important, and clipping won't bother you (it will even help you if your viewport is smaller than the game screen).

2) You want to find an object or location that may be located anywhere in the room, even outside the visible area, using screen coordinates (dummy example: you want to find nearest object and move them to the mouse coordinates).
This is where new ScreenToRoom function comes to use. Such function would be useful even in old AGS, but the coordinates conversion was very simple then (adding or subtracting result of GetViewportX/Y) so we did not have it built-in.
It works like this:

Object *FindNearestObject(int mousex, int mousey)
{
    Point *roompt = Screen.ScreenToRoomPoint(mousex, mousey);
    Object *obj = null;
    for (int i = 0; i < MAX_OBJECTS; i++)
    {
        // continue searching using room coordinates roompt.x and roompt.y
    }
    return obj;
}


In an extreme case, if you want to use screen coordinates that are (or may be) outside of the visible screen, you may explicitly "pass" the point through the main viewport:

Viewport *viewport = Screen.Viewport;
Point *roompt = viewport.ScreenToRoomPoint(-1000, -1000, false); // "false" here means "no clipping"
// this will find room coordinates that are at (-1000,-1000) screen coords if seen through main viewport


3) You want to find some object or location relative to another object or location (like player character). This is where all the new GetAtRoomXY functions come useful (and that's the reason they were added).
For example:

Hotspot *h = Hotspot.GetAtRoomXY(player.x - 20, player.y); // check if there's a hotspot 20 pixels away from player
int walk = GetWalkableAreaAtRoom((player.x, player.y); // find walkable area under player's feet



If you find any case that is not covered please report and we'll fix it.

Thanks! I didn't see that there was a "clipping=false" extra parameter in order to disable it. So it's perfect.

I was worried that people would have to rack their brains to tell the difference between a return value that means "there's nothing there in the room at the coordinates you asked -- outside of the viewport" and a return value that means "you asked for coordinates outside of the viewport but I'm teling you that there's nothing there at the force-clipped coordinates at the boundary of the viewport" -- thus causing human mistakes.

All is well.

Quote from: Monsieur OUXX on Thu 28/02/2019 08:01:00
I was worried that people would have to rack their brains to tell the difference between a return value that means "there's nothing there in the room at the coordinates you asked -- outside of the viewport" and a return value that means "you asked for coordinates outside of the viewport but I'm teling you that there's nothing there at the force-clipped coordinates at the boundary of the viewport" -- thus causing human mistakes.

If you need to distinguish "no viewport"/"no room object" you may first do "Viewport.GetAtScreenXY()" and that will return Viewport* or null.

I want to underline that unless you are explicitly changing room viewport you normally should not be bothered about all this, since by default viewport is covering whole screen, as before. So you need to solve additional issues either if you have custom viewport (then you should be prepared), or if you want to use screen coordinates outside of the visible screen area for some reason (which is not a common thing to do).

And yes, games compiled with older script API (or in older AGS) will work as before.

Just to let you know, AGS has never been this sexy. And this comes from a man who refused to go beyond "the last CJ build" for a decade. Good stuff there, especially the camera functionality should be fun to play around with!

I think we are approaching beta stage, but it's not just there yet, some planned cruicial functionality has still not been added. Maybe soon...

AGS 3.5.0 - Alpha 12

WARNING: some things were changed in room format again. Please make a full backup of your project before upgrading to this version and report if you notice anything wrong with how your rooms are saved and loaded in the editor and run within the game.


Zip archive: http://www.mediafire.com/file/8ktezbit4uuffab/AGS-3.5.0-alpha12-rebuild.zip/file


Changes since 3.5.0 alpha 11:

Common features:
- Deprecated relative assets resolutions: now sprites, rooms and fonts are considered to match game's resolution by default and not resized, unless running in backwards-compatibility mode.

Editor:
- Added "Allow relative asset resolutions" option to "Backwards Compatibility" section. Disabled by default, it makes game treat all sprites and rooms resolution as real one.
- Sprites have "Real" resolution type by default. "Low" and "High resolution" are kept for backwards compatibility only. When importing older games resolution type will be promoted to "Real" whenever it matches the game.
- Added MaskResolution property to Rooms. It ranges from 1:1 to 1:4 and lets you define the precision of Hotspot, Regions and Walkable Areas relative to room background.
   Warning: if you change this to lower precision (e.g. from 1:1 to 1:2) your mask may loose some pixels!
- Added "Default room mask resolution" to General Settings, which value will be applied to any room opened for editing in this game for the first time.
- Removed "Fonts designed for high resolution" option from General Settings. Instead added individual SizeMultiplier property to Fonts.
   NOTE: this is mostly useful for bitmap fonts. When using TTF you better just reimport them with higher point size.
- Fixed property pane displaying properties for room object when the character editor is active - if you changed character's StartingRoom outside of room editor.
- Fixed script compiler could leave extra padding inside the compiled scripts filled with random garbage if script strings contained escaped sequences like "\n" (this was not good for source control).
- Fixed crash when editor was updating file version in compiled EXE but failed and tried to report about that.

Script API
- Added Screen.RoomToScreenPoint, which returns the point on screen corresponding to the given room coordinates relative to the main viewport.
- Added SkipCutscene() and eSkipScriptOnly cutscene mode. This lets you skip cutscene by your own script rather than using automatic conditions.
- Deprecated DrawingSurface.UseHighResCoordinates. Also, assigning it will be ignored if game's "Allow relative asset resolutions" option is disabled.

Engine:
- Improved performance of hardware-accelerated renderers by not preparing a stage bitmap for plugins unless any plugin hooked for the particular drawing events.
- Reimplemented FRead and FWrite plugin API functions, should now work in 64-bit mode too.
- Completely removed old and unsupported record/replay functionality.
- Fixed potential bug which could cause DoOnceOnly tokens to be read incorrectly from a savedgame.
- Fixed DynamicSprite.SaveToFile() not appending ".bmp" if no extension was specified.
- Fixed IsMusicVoxAvailable() not working correctly in old games which use 'music.vox'.
- Added Scavenger's palgorithms plugin to the list of builtins, for ports that use ones.


KNOWN ISSUES:

- Reported by Snarky: need to find out which components need to be added to use AGS 3.5.0 on fresh Windows installation.
- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...
And of course the ones noted at github issue tracker: https://github.com/adventuregamestudio/ags/issues?q=is%3Aissue+is%3Aopen+label%3Abug

Quote from: Ghost on Fri 01/03/2019 09:59:57
Just to let you know, AGS has never been this sexy. And this comes from a man who refused to go beyond "the last CJ build" for a decade. Good stuff there, especially the camera functionality should be fun to play around with!

I think it is safe to tell now, I believe we are one step away from implementing multiple cameras, which may already be trivial except for defining where character speech should appear on screen, and maybe some other quirks which I could miss. This is not 100%, but I will definitely try to add this if time constraints won't prevent me.

Meanwhile, a small teaser of hard-coded cameras in a old test version :):

Spoiler

(https://i.imgur.com/Kum2M2b.gif)

[close]

Will there be some kind of update for the Text parser?

Quote from: Neo_One on Fri 05/04/2019 16:50:42
Will there be some kind of update for the Text parser?

What update do you have in mind? I did not have anything planned before.

I'm wondering why 'Exclude Room from Game' is no longer available....

As previously mentioned in the passed: Compiling a demo game from a full Game and only compiling Rooms that are not excluded and therefore reducing the Game exe when in Compiled folder.


I know that at one point this feature was 'buggy' as Chris reported...

Over to you Crimson.....

Quote from: Slasher on Fri 12/04/2019 08:26:44
I'm wondering why 'Exclude Room from Game' is no longer available....

Where would you normally find this option? I've not seen it before.

Quote from: morganw on Fri 12/04/2019 10:39:23

Quote from: Slasher on Fri 12/04/2019 08:26:44
I'm wondering why 'Exclude Room from Game' is no longer available....

Where would you normally find this option? I've not seen it before.

It exists in 3.2.1. Never paid attention to this so idk when it dissapeared. But if it was in latest SVN version it might be possible to find out using git blame.
I believe it may work though. Room scripts are not connected to anything else, so this may be simply about not compiling / not merging into game data.

So it didn't disappear in the versions in this thread?

Quote from: Crimson Wizard on Fri 12/04/2019 11:38:58
Room scripts are not connected to anything else, so this may be simply about not compiling / not merging into game data.

Surely it breaks anything referencing the room directly, like ResetRoom?

Quote from: morganw on Fri 12/04/2019 11:50:45

Quote from: Crimson Wizard on Fri 12/04/2019 11:38:58
Room scripts are not connected to anything else, so this may be simply about not compiling / not merging into game data.

Surely it breaks anything referencing the room directly, like ResetRoom?

I meant that they won't cause any linking errors, game will run anyway. This is just as with any missing resource, if rest of the game can run without it then you may limit testing to script that does not address the room.

PS. we may also add DoesRoomExist function to script to test for a room (strange there's no such thing), which could also help with having optional game content.

Maybe such a thing would be better handled in the preprocessor?

Thinking about it a little harder, I guess you would just define a macro for DEMO and manage it yourself. Trying to do it in the scripting would probably mean every function call has to have a check around it 'if (DoesRoomExist(room)) { my_room_function() }', which doesn't really make sense when the result is always the same.

Quote from: morganw on Fri 12/04/2019 13:29:41
Maybe such a thing would be better handled in the preprocessor?

Thinking about it a little harder, I guess you would just define a macro for DEMO and manage it yourself. Trying to do it in the scripting would probably mean every function call has to have a check around it 'if (DoesRoomExist(room)) { my_room_function() }', which doesn't really make sense when the result is always the same.

It's up to the user to put these checks or not, and this is situational. It will probably not make sense for rooms that are basic part of the game, but may be useful for optional parts like add-ons and similar.

It's also a simple diagnostic tool, because right now there's no way to know if room resource is present or not at runtime. Rooms, as well as some other things in AGS, are designed to be able to add them as separate files into game directory.

EDIT: A possible example: someone likes to make a custom "go-to room selector" for game testing purposes. Right now they would have to hard-code room numbers. With DoesRoomExist or similar method they would be able to scan room numbers in a loop. Maybe a better solution is to return an array of available room indexes and even some other info (but in case of files on disk such info is potentialy volatile).

About excluding a room, isn't the amount of storage occupied by a room like 10 sprites (5 frames plus masks) which is kind of insignificant versus the rest of the game, like a single music file will be the size of 20 rooms?

Quote from: eri0o on Fri 12/04/2019 17:03:15
About excluding a room, isn't the amount of storage occupied by a room like 10 sprites (5 frames plus masks) which is kind of insignificant versus the rest of the game, like a single music file will be the size of 20 rooms?

Depends, I guess. You may also omit full audio.vox if you like.
BTW that also may improve compilation time during testing period. Compiling room scripts take most of time afaik.

Still not "beta", yet did not want to delay update too much because there's a completely unplanned but interesting addition (see below).

I am currently trying to finalize multiple camera (https://www.adventuregamestudio.co.uk/forums/index.php?topic=57075.0) support. I gave myself around 1 week of time, and regardless of whether I make it or not we probably should officially announce 3.5.0 a beta as a next update, and then it will be testing + bug fixing + polishing existing features time.



AGS 3.5.0 - Alpha 13


Zip archive: http://www.mediafire.com/file/560eor7perwri0d/AGS-3.5.0-alpha13.zip/file
Linux build pack: https://www.dropbox.com/s/m0fpi4xa52vdp7v/AGS.3.5.0.9.Editor.Linux.Pack.zip?dl=0


Changes since 3.5.0 alpha 12:

Editor:
- Fixed Audio folders were displaying internal "AllItemsFlat" property on property grid.

Script API
- Implemented Dictionary and Set script classes supporting storage and lookup of strings and key/value pairs in sorted or unsorted way.
- Added Game.PlayVoiceClip() for playing non-blocking voice.

Engine:
- Removed 200 chars limit for DoOnceOnly token length.
- Reimplemented threaded audio, should now work correctly on all platforms.
- Made fps display more stable and timing correct when framerate is maxed out for test purposes.
- Fixed engine could not locate game data if relative path was passed in command line.
- Fixed GetLocationName returning trash instead of empty string when there's no viewport under the given coordinates.
- Temporarily removed Camera/Viewport from savedgames (there was a logic mistake in data format). I am planning to re-add them as soon as I implement multiple cameras (or after a short while if that takes too long).
- Fixed a bug in mp3/ogg decoder where it assumed creating an audiostream succeeded without actually testing one.

Linux:
- Support for OpenGL renderer.
- Use same FreeType library sources as Windows version, which suppose to fix TTF font glitches.
- Re-enabled threaded audio setting.


What is Dictionary and Set classes:

Dictionary class allows you to store string key/value pairs and look them up. Set class allows you to store unique strings that cannot repeat and check for their presence (or abscence).
Both classes support 4 modes, mode is constant and defined when you create a set or dictionary -
1) sorted, case-sensitive,
2) sorted, case-insensitive,
3) unsorted (undefined order), case-sensitive,
3) unsorted (undefined order), case-insensitive
Note that when we talk about case-sensitivity this only relates to keys. Values will always be same as you put them in.
Both classes can return their items in dynamic array (order of items in array will be same as in container).

Script example:

Spoiler

Code (ags) Select Expand


Dictionary *dic = Dictionary.Create(true, false); // create a sorted and case-insensitive dictionary
dic.Set("name", "Roger");
dic.Set("pos_x", "10");
dic.Set("pos_y", "20");

int pos_x = dic.Get("pos_x").AsInt;


[close]

KNOWN ISSUES:

- Reported by Snarky: need to find out which components need to be added to use AGS 3.5.0 on fresh Windows installation.
- Some weird sprite scaling bug in the room editor described in the posts above. According to user reports it may be fixed by restarting the editor. Unfortunately I was still unable to reproduce it on my own...
- Custom Viewport and Camera properties are not remembered in savegame. Temporary workaround is to save these in variables and restore custom camera in eEventRestoreGame event.
And of course the ones noted at github issue tracker: https://github.com/adventuregamestudio/ags/issues?q=is%3Aissue+is%3Aopen+label%3Abug



New multi-camera teaser:
;)

Spoiler

(https://i.imgur.com/w8ShCLx.gif)
(https://i.imgur.com/1bMv6sI.gif)

[close]

Released Beta version, so closing this thread (continue here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=57133.0)

For the reference, changes since last alpha 13 are:

- Support for multiple viewports and cameras.
- Moved Camera property to Game (because they ended up being in global game state rather than room's).
- Added Game.Camera, Game.Cameras and Game.CameraCount properties.
- Added Screen.Viewports, and Screen.ViewportCount properties.
- Added Camera.Create (static), Camera.Delete, Viewport.Create (static) and Viewport.Delete.
- Viewport's position is no longer limited by the visible screen (for example, you may move it half-offscreen if you like).
- Added Viewport.Visible and Viewport.ZOrder to help arranging multiple viewports on screen.