AGS 3.5.0 - Patch 2

Started by Crimson Wizard, Mon 24/02/2020 21:45:17

Previous topic - Next topic

Crimson Wizard

#20
Quote from: Cassiebsg on Sat 18/04/2020 09:10:57
I was importing sprites last night and made a mistake with the 1st one. I forgot to change the transparent color from "top left" to "leave as is". No problem I thought, I'll just re-import the sprite... only the setting on the sprite did not got the new imported setting, but kept the old one. I did this 3 times, before I realize there was now a nice dropdown menu that lets you change this. While this is a very cool feature, I think that re-importing a new sprite (I used the "Import new sprite(s) from files...") should get the new imported setting, and not keep the old one.

To double check, you were doing "Import new sprite", and not "reimport from source", thus creating a completely new sprite, but it retained old properties? Do you mean that you deleted old sprite first, and the new sprite got same number?

Quote from: Cassiebsg on Sat 18/04/2020 09:10:57
Changing 1 sprite is faster by using the dropdown than re-importing it, yes, but it would be a pain to have to manually have to change 100 sprites later in the development, when you noticed they had the wrong setting on import.

Do you imply it needs changing multiple sprite settings at once, or something different?

Cassiebsg

Oops, I meant "Replace sprite from file..."  , not "Import new sprite(s) from files..."

Sorry.

I just did a few tests, and can't reproduce it anymore. Now it seems to be working right.  (wtf) Maybe I did something wrong and selected a wrong setting somewhere.  (roll)
There are those who believe that life here began out there...

Crimson Wizard

#22
Quote from: Cassiebsg on Sat 18/04/2020 12:24:17
Oops, I meant "Replace sprite from file..."  , not "Import new sprite(s) from files..."

"Replace from source" (it really should read "update from source") should retain old properties. "Replace from file" must let you set new ones, as it implies creating a completely new sprite entry in place of old one.

EDIT: Okay, I now remembered, after testing, - when you do "Replace from file" it sets up initial values in the import window to be equal to values from previous import. Frankly, not sure why, as you may want to replace with completely different sprite... but then again, AGS sprite import logic is a bit flawed.
Maybe there was a user request to do so, but I forgot the details.

Monsieur OUXX

Has something changed with the encoding of translation files between 3.4.x and 3.5.0 patch 2? All my special characters in all my translations (French, Italian , Spanish...) are now displayed as several random characters. For example, è is now displayed as ï¿Ö even though I do have è in my font. Did we switch to full-blown Unicode or something?
 

Crimson Wizard

Quote from: Monsieur OUXX on Sat 18/04/2020 15:05:23
Has something changed with the encoding of translation files between 3.4.x and 3.5.0 patch 2? All my special characters in all my translations (French, Italian , Spanish...) are now displayed as several random characters. For example, è is now displayed as ï¿Ö even though I do have è in my font. Did we switch to full-blown Unicode or something?

I don't think anything changed in that regard. Please double check that TRS files are saved as ANSI, not UTF8 etc.

Crimson Wizard

Lord C, rongel and Lukey J, I finally managed to reproduce the problem you were having, or at least I think it has same root.

The crashes begin if you make the text in the object selection field too long. I don't know how did you do that, maybe this depends on monitor settings too (different resolution, font sizes, and so on), but what I did was creating a room object and giving it a very long name, something like "AAAAA_BBBBB_CCCCCCC_DDDDDDDD_FFFFFFFFF".

If the line is too long this control begins to wrap it, replacing words with "...", and eventually glitches begin to occur (selection not working, crashes, and so on).

rongel

Quote from: Crimson Wizard on Mon 20/04/2020 00:55:15
Lord C, rongel and Lukey J, I finally managed to reproduce the problem you were having, or at least I think it has same root.

I think you're right. I made a quick test too, created a new game, added an object, and gave it a name "oStreetlamp_Walkbehind" (same name that I had trouble with before). Everything seems to work, but when I close the program and start again, I get the error when trying to edit the room in editor. This time I tested to remove the .user file, and it works, until I close the program again.

Looks like the allowed number of letters is only around 21, "oStreetlamp_Walkbehin" works without error message. Weirdly "oStreetlamp_Walkbehinx" works too, but "oStreetlamp_WalkbehinX" with a capital X doesn't...
Dreams in the Witch House on Steam & GOG

Crimson Wizard

Quote from: rongel on Mon 20/04/2020 15:51:05
Looks like the allowed number of letters is only around 21, "oStreetlamp_Walkbehin" works without error message. Weirdly "oStreetlamp_Walkbehinx" works too, but "oStreetlamp_WalkbehinX" with a capital X doesn't...

This is because it is not related to number of characters, but the graphical width of the full text line in the GUI, in pixels.

Lord C

Quote from: Crimson Wizard on Mon 20/04/2020 00:55:15
Lord C, rongel and Lukey J, I finally managed to reproduce the problem you were having, or at least I think it has same root.

The crashes begin if you make the text in the object selection field too long. I don't know how did you do that, maybe this depends on monitor settings too (different resolution, font sizes, and so on), but what I did was creating a room object and giving it a very long name, something like "AAAAA_BBBBB_CCCCCCC_DDDDDDDD_FFFFFFFFF".

If the line is too long this control begins to wrap it, replacing words with "...", and eventually glitches begin to occur (selection not working, crashes, and so on).

Thanks for getting back to us!

But when I create a walk-behind area, I don't give it a name, it just has an ID.
Regardless, when I delete the RoomXXX.crm.user file after the error occurs, it seems to be fixed and I can edit the room again.

Crimson Wizard

Quote from: Lord C on Tue 28/04/2020 18:11:13
But when I create a walk-behind area, I don't give it a name, it just has an ID.

I don't know, it's the only way so far that I was able to reproduce similar error.
We are currently looking into this, and maybe when there's a fix you could try and tell if that was fixed for you too.

Lord C


Crimson Wizard

Lord C, rongel and Lukey J, sorry for long wait. There's a temp build prepared that you may download here: https://cirrus-ci.com/task/4504037129191424
(choose either installer or archive)

Please tell if this version fixes the room "user file" problem for you.

rongel

Thanks! I'm away for the weekend, but will test this next week.
Dreams in the Witch House on Steam & GOG

rongel

Tested the fix now, and yes, it seems to work! I could give long names (I tested using "oStreetlamp_Walkbehind") to objects without errors. When I tried opening the project with version 3.5.0.23, I got the warning, and couldn't edit the room. When I re-opened it with the temp build, it opened nicely without any problems.
Dreams in the Witch House on Steam & GOG

Crimson Wizard

Here's a latest patch update, if anyone would like to test/use: https://cirrus-ci.com/task/6527904739753984
(choose either installer or archive)

I think there might be at least one more fix later though.

Changes already in the patch:
Quote
Editor:
- In room editor adjusted the object selection bar's visual style, made dropdown buttons larger
   and easier to click on.
- Fixed room editor failing to initialize if currently selected object's name exceeded navigation
   bar's width.
- Fixed some panels were not upscaling sprite previews in low-resolution projects as intended.
- Fixed ViewFrame's default Sound value set as "-1 (unknown)" (should be "none").

Engine:
- RunAGSGame() will now automatically reset translation to Default before starting new game,
   to prevent situations when new game will be trying to init a translation from previous game.
- Character speech will be now displayed relative to the first found viewport the character is
   seen in, or the one which camera is closest to the character in the room.
- Fixed Viewport.Camera not handling set null pointer properly (should disable viewport now).
- Fixed Screen.RoomToScreenPoint()/ScreenToRoomPoint() functions were converting coordinates
   always through camera #0, instead of a camera actually linked to the primary viewport.
- Fixed Screen.AutoSizeViewportOnRoomLoad property was forcing always camera #0 to align itself
   to the new room, instead of a camera actually linked to the primary viewport.
- Fixed speech vertical position was not correctly calculated if the room camera is zoomed.

Windows:
- Again fixed game becoming minimized when quitting with error from the Direct3D fullscreen.

As you may notice these are mostly related to new room editor selector and cameras.

Monsieur OUXX

Thanks! The language fix removes a weight from my shoulders.
 

Crimson Wizard

Idk how I missed it (can swear I was testing this), but "Change ID" does not work correctly until you restart the editor and rebuild game once more. Will have to fix that too.

Lord C

Quote from: Crimson Wizard on Thu 28/05/2020 00:56:09
Lord C, rongel and Lukey J, sorry for long wait. There's a temp build prepared that you may download here: https://cirrus-ci.com/task/4504037129191424
(choose either installer or archive)

Please tell if this version fixes the room "user file" problem for you.

Thank you very much, it works fine now! I can draw walk-behind areas with the rectangle tool and no error messages appear. Thank you!

Crimson Wizard


SMF spam blocked by CleanTalk