Graal v6.1 for Mac released

[Meph]

Super excited to see the ball is rolling with this.

When can we expect to see Era iPhone released for this new client?
I know a lot of Era PC players that have been waiting for client access.

[Jakov_the_Jakovasaur]

Originally Posted by Stefan

Version 6.11 for Mac can be downloaded from http://www.graalonline.com/downloads/Graal6.dmg
A new Windows version will also follow in a few days.

Major improvements:
- Support for international text / UTF8
- Compatible with the latest versions for iOS, Android and Facebook
- Fixed several crashing bugs

hello!

whats the status on the new windows version?

there are some bugs with the mac version which really need to be fixed, but if thats going to take a while then it may also help if windows developers could debug them, a good suggestion i heard about was to make an equivalent windows client as an optional download on the login server

thank you!

[lTBSl]

When will a Tile Editor be released for Mac? Not GConstruct?? Has this been talked about?

[Jakov_the_Jakovasaur]

there is definitely a bug on the new mac client when it comes to reading player attr[] values which contain numbers like so: "1 0 0.1 etc", it also seems to be the case even when trying to concatenate it using @

this means that you cant use tokenize() on a space separated list of numbers within a player attr

[Rave_J]

I know when they talk about releasing the clients on iPhone and androids devices that they were going to work on more updated dev tools but it hasn't happen yet. But if we do will prob be online tools like web based.

[Jakov_the_Jakovasaur]

hello!

ive heard from a reliable source that the equivalent new windows client has been ready for some time but is no longer planned to be released, is this true?

then again with the bug for using tokenize on a player.attr value this is probably a good thing

[callimuc]

And the stupid openGL bug which won't save the set option within the F3 menu. It's been a long time now we've had to deal with it and I don't get why a small update fixing at least that problem can't be released

[Jakov_the_Jakovasaur]

just found that the bug with attr values starting with a number also applies to when doing:

PHP Code:

GuiShowImgCtrl.actor.attr[index] = "1_OtherRandomChars"; 


i dont know who there is that can fix it now, but it should be fixed

[Restraint]

Originally Posted by Jakov_the_Jakovasaur

just found that the bug with attr values starting with a number also applies to when doing:

PHP Code:

GuiShowImgCtrl.actor.attr[index] = "1_OtherRandomChars"; 


i dont know who there is that can fix it now, but it should be fixed

I reported this a long time ago, when I ran into this situation with an account of mine ("100Zero100") getting passed server-to-client seemingly as "100"

The problem involves datatyping.

Although Graal does not have explicit datatypes, it does have IMPLICIT datatypes, which can be grabbed or corrected by using @.

For example:

PHP Code:

temp.a = nil;
temp.b = "";
if (a == b) { // true
if (@a == @b) { // false 


The former is true because null int and null string are the same when they're just "blob" datatypes. The latter is false because null int and null string are not the same when their datatype is invoked!

To fix your problem, simply put an @ before the attr.

Example:

PHP Code:

function onCreated() {
 this.attr[5] = "100Zero100";
}
//#CLIENTSIDE
function onCreated() {
 sleep(1);
 this.chat = this.attr[5];
} 


Chat sets to: 100

PHP Code:

function onCreated() {
 this.attr[5] = "100Zero100";
}
//#CLIENTSIDE
function onCreated() {
 sleep(1);
 this.chat = @this.attr[5];
} 


Chat sets to: 100Zero100

Hope that helps to shed some light and resolve these types of bugs.

[Jakov_the_Jakovasaur]

Originally Posted by Restraint

I reported this a long time ago, when I ran into this situation with an account of mine ("100Zero100") getting passed server-to-client seemingly as "100"

The problem involves datatyping.

Although Graal does not have explicit datatypes, it does have IMPLICIT datatypes, which can be grabbed or corrected by using @.

For example:

PHP Code:

temp.a = nil;
temp.b = "";
if (a == b) { // true
if (@a == @b) { // false 


The former is true because null int and null string are the same when they're just "blob" datatypes. The latter is false because null int and null string are not the same when their datatype is invoked!

To fix your problem, simply put an @ before the attr.

Example:

PHP Code:

function onCreated() {
 this.attr[5] = "100Zero100";
}
//#CLIENTSIDE
function onCreated() {
 sleep(1);
 this.chat = this.attr[5];
} 


Chat sets to: 100

PHP Code:

function onCreated() {
 this.attr[5] = "100Zero100";
}
//#CLIENTSIDE
function onCreated() {
 sleep(1);
 this.chat = @this.attr[5];
} 


Chat sets to: 100Zero100

Hope that helps to shed some light and resolve these types of bugs.

hello!

the problem i mentioned previously involved writing to an attr rather than reading

as for the original problem i mentioned where it does involve reading an attr, usually using the concatenate method does fix it however even that fails in the latest mac client

[Restraint]

Originally Posted by Jakov_the_Jakovasaur

hello!

the problem i mentioned previously involved writing to an attr rather than reading

as for the original problem i mentioned where it does involve reading an attr, usually using the concatenate method does fix it however even that fails in the latest mac client

My apologies. I have run into this question so many times I had assumed it was this (relatively common) Graal bug and not something new and more sinister.

How can you tell if the problem is with writing or reading the attr? If the problem is with reading and even the concatenation method doesn't fix it, then it would appear the same as writing!

Have you troubleshot it in other ways? Such as..

blah.attr[5] = "1_words";

blah.attr[5].length() -- is this 1 or is it 7?
blah.attr[5] @ "" -- is this still 1?

And have you tried it with different delimiters than "_" with no luck?

I suppose the worst case scenario involves setting the data acrossed multiple .attr[]'s or balling the data into one attr via numbers, and that's your current workaround?

I don't have a Mac unfortunately, so I'm not able to test any of this to see.

[Jakov_the_Jakovasaur]

Originally Posted by Restraint

How can you tell if the problem is with writing or reading the attr? If the problem is with reading and even the concatenation method doesn't fix it, then it would appear the same as writing!

if i were to do:

GuiShowImgCtrl.actor.attr[1] = "timestamp_otherCharacters.png";

which is basically to set a hat image on a gui control, the hat is not displayed, even if i attempt to use the concatenation method when writing it

after doing echo(GuiShowImgCtrl.actor.attr[1]); it does output the correct filename, which is also a valid downloadable file which would for example download if used as an npc image, which leads me to believe that its a problem with the client itself in regards to interpreting the attr value

with that said, i have since noticed that the problem also applies to player.attr[i] and it is not exclusive to the mac client, whereas the original problem i mentioned with reading + tokenizing a player.attr[i] value such as "1 2 3" is exclusive to mac

[Jakov_the_Jakovasaur]

Originally Posted by Jakov_the_Jakovasaur

the problem described by fowlplay4 also seems to be happening for player.attr[] values with mac users, and likewise i do not use mac so cant confirm or debug it

i just noticed now there that there is actually not a bug reading such strings which begin with a number within player attributes for the new mac client, it simply appeared to be the case because during my attempts to debug a problem the real bug turned out to be that a string value was being treated as if it were NULL

example:

PHP Code:

function onCreated() 
  this.hash = new TStaticVar();

function something() {
  //set these attributes just for the sake of an example
  player.attr[5] = "1 3 0.05";
  player.attr[6] = "2 4 0.1";
  player.attr[7] = "0 0";

  //lets just pretend that this is defined as an array
  temp.save = this.hash.(@ player.account);

  temp.h = player.attr[5] @ player.attr[6] @ player.attr[7];

  echo(temp.h); //outputs: 1 3 0.052 4 0.10 0

  /*is never true because temp.save[6] starts as NULL
  and temp.h is treated as NULL when it actually isnt*/
  if (temp.h != temp.save[6]) {
    this.doSomethingElse(player);
    temp.save[6] = temp.h;
    this.hash.(@ player.account) = temp.save;
  }

  echo(temp.h == NULL); //outputs: 1

} 


this example should show that there is a bug with concatenating strings which consist of numbers in such a way, as temp.h is being treated as if it is NULL when it is not NULL

[Ceasar]

i don't have linux but i feel that there is no love for linux