TEMPLATE: Tumbleweed Verbs 1.4

[AndreasBlack]

Since you've said you need to resize the button on the save function, then i figured maybe it's possible by doing it that way?

[Crimson Wizard]

There's currently only one way existing when the object may display in a higher resolution: that is when the "Render sprites in screen resolution" is set in the game setup. This will make scaled object appear to have more resolution, that is - less pixelated.

I don't really know if you were referring to this or not. But this trick is theoretically doable. The problem with this is that the result will depend on the size of the game window that player chooses. Also this currently won't work with "Software" renderer, only "Direct3D" and "OpenGL".

[AndreasBlack]

There's currently only one way existing when the object may display in a higher resolution: that is when the "Render sprites in screen resolution" is set in the game setup. This will make scaled object appear to have more resolution, that is - less pixelated.

I don't really know if you were referring to this or not. But this trick is theoretically doable. The problem with this is that the result will depend on the size of the game window that player chooses.

Exactly! I use that setting when scaling the characters, i don't want them looking like the true "Lucasarts" scaling back in the day did. So what you mean is if the player plays in say a windowed mode if they'll save the game it might end up looking...Strange? Or what's the caveat here? Hmm..Well at least i'm trying.
Edit: Ahh, but couldn't i turn off software rendering option or ship the game without the setup file in the future? I mean let's be honest. Who uses that software rendering mode. Maybe i'm missing the point. When i've used software rendering mode my game looks aweful anyways!

[Crimson Wizard]

So what you mean is if the player plays in say a windowed mode if they'll save the game it might end up looking...Strange?

No, screenshots in savegame will always will be same. It's the objects that will look different depending on the display mode.

[eri0o]

@eri0o
I really just changed a single line, but on a Mac using Crossover. So maybe the fileencoding changed too and therefore git wasn't able to detect the changes anymore.

Uhm, I don't think the issue is crossover, but I will check if it's the line endings - I think AGS uses Windows Line Endings but I don't remember what git on macOS does with that by default - on Windows git default is to commit with Unix line endings and checkout with Windows line endings.

I had a few issues using git on macOS - not with AGS Editor, but with Xcode. I noticed that if the hard drive is using a case insensitive partition and I rename only the case of a file, Xcode may instead duplicate the file and then once you do git commit the entire branch can be completely insane, giving wrong deltas. I had to delete the git dir when that happened and start from a new branch. This can happen if you delete and create a file with the same name but with different case and squash the history, and doing so with Xcode opened too. I looked into it online and apparently what people do when they hit my case is to create a dev partition that is case sensitive and work with that.

[abstauber]

hmm... I wasn't able to keep the history intact no matter what - I might try a newer partition soon.
But for now I did a soft reset and applied the change with a windows machine.

[eri0o]

I think you can try comparing the results on each PC of running

Code: bash

git ls-files --eol *.as*

I hid the output of mine in the spoiler.

Spoiler

Code: ags

i/lf    w/crlf  attr/                  CustomDialogGui.asc
i/lf    w/crlf  attr/                  CustomDialogGui.ash
i/lf    w/crlf  attr/                  DoubleClick.asc
i/lf    w/crlf  attr/                  DoubleClick.ash
i/lf    w/crlf  attr/                  GlobalScript.asc
i/lf    w/crlf  attr/                  GlobalScript.ash
i/lf    w/crlf  attr/                  TemplateSettings.asc
i/lf    w/crlf  attr/                  TemplateSettings.ash
i/lf    w/crlf  attr/                  optiongui.asc
i/lf    w/crlf  attr/                  optiongui.ash
i/lf    w/crlf  attr/                  room1.asc
i/lf    w/crlf  attr/                  room2.asc
i/lf    w/crlf  attr/                  verbgui.asc
i/lf    w/crlf  attr/                  verbgui.ash

[close]

When I did it in your change it was instead as below (look in the verbgui.asc line)

Spoiler

Code: ags

i/lf    w/crlf  attr/                  CustomDialogGui.asc
i/lf    w/crlf  attr/                  CustomDialogGui.ash
i/lf    w/crlf  attr/                  DoubleClick.asc
i/lf    w/crlf  attr/                  DoubleClick.ash
i/lf    w/crlf  attr/                  GlobalScript.asc
i/lf    w/crlf  attr/                  GlobalScript.ash
i/lf    w/crlf  attr/                  TemplateSettings.asc
i/lf    w/crlf  attr/                  TemplateSettings.ash
i/lf    w/crlf  attr/                  optiongui.asc
i/lf    w/crlf  attr/                  optiongui.ash
i/lf    w/crlf  attr/                  room1.asc
i/lf    w/crlf  attr/                  room2.asc
i/crlf  w/crlf  attr/                  verbgui.asc
i/lf    w/crlf  attr/                  verbgui.ash

[close]

The i at the start is what is in the index (and in the remote), and the w means what is in the working tree. So your change was really a change of line ending in the repository.

You can try setting git config core.autocrlf true only in the specific directory of ags_tumbleweed to configure that project on macOS - I haven't tried that yet. I use GitHub Desktop on macOS, I don't remember if it magically does this when it thinks it's necessary, I need to check later. I think I can try hacking a simple .gitattributes file, just so this doesn't change.

[abstauber]

Many thanks for the investigation and the solution of this silly cross platform issue.
Being lazy I added autolf to my global config, so I don't run into this issue again with other projects:

Code: ags

git config --global core.autocrlf input

Thanks again 

[AndreasBlack]

It's me again 

How do you setup so the various characters can use Snarky's lipsync tool on the basic lines? "I can't open that" "I can't use that" etc. Atm i'm just saying them in the rooms cAbstauber.SaySync ("I can't open that!"); but it would be nice i suppose a-reno to be able to use the template as it's intended a-who.

But with the lipsync working along with the characters aswell! I've added &10 etc in the template to get the voices for the various characters to say their speeches, but since the lipsync tool has a different syntax then the standard AGS &10 so i can't simply just add SaySync&10. I tried "player.saySync" inside of the template, but it's not setup that way it seems.

I hope your AGS forum vacation isn't going on for too long this crisis needs to be solved fast abo 

[Khris]

The messages are set up in TemplateSettings.asc, starting at line 102. Did you change these, too?

[abstauber]

If I understand you correctly, you want to change player.Say to player.SaySync.

This happens in VerbGui.asc::Unhandled

In the latest revision it starts in line 1985 and in detail in 2014

Code: ags

    
// unhandled USE
    if (Verbs.UsedAction(eGA_Use)) {
      // use inv on inv
      if (type >= 5) player.Say(verbsData.unhandled_strings[eVerbGuiUnhandledUseInv]);
      // use
      else player.Say(verbsData.unhandled_strings[eVerbGuiUnhandledUse]);

Here you can change .Say to .SaySync. And remember to have lipsync module above VerbGui.asc.