Adventure Game Studio Official

User reported issues for officially released versions of AGS

Feature Issue: Copying Mouse Coordinates with ";"

Pages: [1]

horusr

  • AGSer
  • Posts: 197
  • Just joining everything for no reason.
« on: 09 Jul 2017, 14:11 »
I don't know should I post this or it is right place to post and it is nothing big, but here we go:

In room editor, if we click middle mouse button and copy coordinates, it wil copy it like "120,120" but when we paste it, we need to make it something like "120;120" to make it work. Can you change copying it?

Gurok

  • Rottwheelers
  • AGSer
  • Posts: 1,720
  • When life hands you lemons, combine them with the mop
« Reply #1 on: 10 Jul 2017, 02:48 »
You can use these coordinates with methods like Object::SetPosition.

I don't see any good reason to change it. How would "120;120" make anything easier?

Crimson Wizard

  • AGSer
  • Posts: 8,311
« Reply #2 on: 10 Jul 2017, 05:51 »
Like Gurok said, there should be a good reason to do anything here, and even if changed, this should be an toggleable option, because right now coordinates are copied in a form suitable for passing parameters to script functions (SetPosition, Walk, Move, and so on).

Even if these parameters are parsed from some string using custom algorithm, is there a reason it cannot parse "," instead of ";"?

If there is actually a valid reason for this, a solution could be format string setting in editor preferences, which is "%d, %d" (or rather "{0}, {1}", since Editor is C# program) by default.
« Last Edit: 10 Jul 2017, 06:28 by Crimson Wizard »

horusr

  • AGSer
  • Posts: 197
  • Just joining everything for no reason.
« Reply #3 on: 10 Jul 2017, 13:20 »
Oh, right script works with ",".
But in preferences tabs, like hotspot's walk to coordinates, you need to write it with ";".
So maybe change that?

Gurok

  • Rottwheelers
  • AGSer
  • Posts: 1,720
  • When life hands you lemons, combine them with the mop
« Reply #4 on: 11 Jul 2017, 03:28 »
Perhaps this is really a localisation issue.
We should look into why the AGS properties panel is using ";" as a delimiter in some locales (presumably Turkish and maybe others). It might be possible to force the use of a "," instead.

fernewelten

  • AGSer
  • Posts: 37
« Reply #5 on: 20 May 2018, 22:42 »
The German locale uses ";", too, and I think the French (France) locale does, too.

The reason being that the Germans and French use a comma "," as the decimal delimiter. One million and a half is written as "1000000,5" over here. So in order to avoid ambiguity, our programs use ";" as the list delimiter. For instance, we denote page ranges for printing as "1; 5-9; 77-".

Probably the only thing in the AGS code that needs to be changed is telling the interface system that it needs to use the "C" or "Posix" locale (or similar) for all editable fields. I don't know what interface system the editor is based on, but I assume there is an easy way of configuring that. However, this might entail going through all the fields and deciding for each one whether they can/should be translated (menu items and such) or not (input fields). Translatable fields should use the local locale, whatever it may be.

Or otherwise, the code that copies the mouse coordinates might get an addition to convert the result into the local locale, whatever it may be. Again, I'm assuming that this will be simple to do once having found out how to. It'll be one call of an appropriate function with appropriate parameters.
« Last Edit: 20 May 2018, 22:45 by fernewelten »

Crimson Wizard

  • AGSer
  • Posts: 8,311
« Reply #6 on: 20 May 2018, 23:26 »
Probably the only thing in the AGS code that needs to be changed is telling the interface system that it needs to use the "C" or "Posix" locale (or similar) for all editable fields. I don't know what interface system the editor is based on, but I assume there is an easy way of configuring that. However, this might entail going through all the fields and deciding for each one whether they can/should be translated (menu items and such) or not (input fields). Translatable fields should use the local locale, whatever it may be.

Editor is built on .NET Framework, and afaik enforcing universal locale (InvariantCulture) for the whole application should be simple as one command. If that is what is desired?

My biggest concern is about serialization. What if editor also saves this ";" into Game xml? How would you detect that this is not an invalid data and the project file values require conversion?
EDIT: Oh, alright, game XML has "encoding" attribute in the header, hopefully that may help.
EDIT2: Also, if it's in room properties, such as Hotspot's WalkTo points, then it probably gets stored as two ints in the room file, which makes things simplier.
Anyway, this is something to be keep in mind.

I believe it should be possible to test this on any machine if you install one of the affected locales and set it as active.
« Last Edit: 21 May 2018, 00:29 by Crimson Wizard »

fernewelten

  • AGSer
  • Posts: 37
« Reply #7 on: 21 May 2018, 11:07 »
I'm using the AGS on a German Windows system an can confirm that coordinates are written with a ";". See here:
.

You can edit this field with a semicolon, and the individual values will be automatically copied to WalkToPoint.X  and WalkToPoint.Y. Do it with a comma instead, and the system will reject the entry.
« Last Edit: 21 May 2018, 11:08 by fernewelten »

Crimson Wizard

  • AGSer
  • Posts: 8,311
« Reply #8 on: 21 May 2018, 11:17 »
Yes, I know, I also have ";" there, having a russian locale.

Frankly I was not sure if this is related to locale at all, until Gurok mentioned it above. Prior to that I thought it's just the same for everyone.
« Last Edit: 21 May 2018, 11:18 by Crimson Wizard »

fernewelten

  • AGSer
  • Posts: 37
« Reply #9 on: 21 May 2018, 12:17 »
So, to sum up, the current situation is that we seem to have a "localized layer" sitting on top of the "code layer". The "localized layer" is where the user inputs their values, in local style, and where values are displayed in local style. One example being the field WalkToPoint of hotspots, as the evidence shows.

The system sees to it that localized inputs are converted to internal representation when moved to the "code layer", and that internal values are localized when output on the "localized layer". 

All the logic is done on the "code layer", where fields are processed exclusively in internal representation.

So this probably means that the clipboard should contain localized values, because the clipboard represents values that would otherwise be typed into a field on the "localized layer". For instance, if we paste a clipboard content into an Excel worksheet, they will probably expect localized entries just as if we typed it in there. (For an exception, see below at "special case").

If my assumptions are correct so far, then the proper solution would be adding a call to a "convert this to localized representation" function before moving values to the clipboard.

The internal representation, and serialization in particular, would not be affected at all by this change, since those are in the "code layer". The only thing that changes would be that we "show" the values "in local representation" when copying them to the clipboard, in the same way that we "show" them "in local representation" when we (or the system) copy them to display fields.

Whenever the user copies the clipboard into AGS fields, it will be into a field on the "localized layer". The system will convert the entry into internal representation on moving them to the "code layer".

Special case: A user that copies the clipboard directly to the coding window will have the localized representation copied although the internal representation is needed in that particular window. I think that this isn't currently much of a problem, however, since AGS code doesn't know the concept of lists, anyway: In C, you can have

Code: Adventure Game Studio
  1. int SpecialCoordinate[2] = {15, 20};
or
Code: Adventure Game Studio
  1. struct Coo {int x; int y} SpecialCoordinate = {15, 20};
but AGS doesn't know this (yet?).


Can we see it like that?
« Last Edit: 21 May 2018, 12:19 by fernewelten »

Crimson Wizard

  • AGSer
  • Posts: 8,311
« Reply #10 on: 21 May 2018, 12:30 »
Special case: A user that copies the clipboard directly to the coding window will have the localized representation copied although the internal representation is needed in that particular window. I think that this isn't currently much of a problem, however, since AGS code doesn't know the concept of lists, anyway: In C, you can have

Code: Adventure Game Studio
  1. int SpecialCoordinate[2] = {15, 20};
or
Code: Adventure Game Studio
  1. struct Coo {int x; int y} SpecialCoordinate = {15, 20};
but AGS doesn't know this (yet?).

This is a problem. AGS cannot initialize arrays like that, but it has functions that take X,Y coordinates, such as SetPosition, Walk, Move, and so on, and the ability to copy point coordinates from the room editor was created having those functions in mind also.
(I explained this in one of my previous comments above.)

Another example, in one of my games I was entering the copied coordinates into custom string properties as "x, y" for simplicity. If AGS were storing these coords in localized way, then I won't be able to use same mechanics if I worked in a team with a person who uses different locale.
« Last Edit: 21 May 2018, 12:42 by Crimson Wizard »

Pages: [1]

Issue Details

  • Reported
    09 Jul 2017, 14:11
  • Updated
    21 May 2018, 12:30
  • View Status
    Public
  • Type
    Feature
  • Status
    New
  • Priority
    Normal
  • Version
    Adventure Game Studio 3.4
  • Fixed in
    (none)
  • Assigned to
    (none)
  • Category
    Editor | Tools

Tags



Powered by: SMF Project Tools 0.5.4 © Niko Pahajoki 2007-2011