[Community Resource / Request] Phone Numbers!

[GioSerpo]

ok, i think i have an idea for the SMS, you have phoneinfo, which has the number and a phone book, then you make a smsifo table, which would be a seperate table, but in the same resource, that woul hold readSMS and unreadSMS. would that work? also, i got the betterweather resource implemented, but i had to export a function that wasnt already exported (i think it wasnt exported on purpose, but idk why not). that works. as for my own SMS, i couldnt quite get it working. ill get the latest version tho and try the idea about seperate tables in the same resource, ill get back to you on that. it will be about 2 hours tho, because im about to put some videos on my new MP4 player.

[XetaQuake]

Or we just use .xml

[Gamesnert]

Or we just use .xml

Am already using for skin.

About the skin: I've been working on it. Green light! Or well... It works. I guess, doesn't give anymore errors and the GUI loads, so it should atleast be positive.

But to go back on topic: I can do it in XML. I'll try it.

[Michael_Sund]

Or we just use .xml

Am already using for skin.

About the skin: I've been working on it. Green light! Or well... It works. I guess, doesn't give anymore errors and the GUI loads, so it should atleast be positive.

But to go back on topic: I can do it in XML. I'll try it.

LOL why didn't you think about this earlier?

[Scarface]

Make a GUI window for something like "Yellow Pages" which will show all the players numbers.

[Gamesnert]

Or we just use .xml

Am already using for skin.

About the skin: I've been working on it. Green light! Or well... It works. I guess, doesn't give anymore errors and the GUI loads, so it should atleast be positive.

But to go back on topic: I can do it in XML. I'll try it.

LOL why didn't you think about this earlier?

Because... I'm still not making any progress due to a few difficulties... I'll continue tomorrow.

[churchill]

Make a GUI window for something like "Yellow Pages" which will show all the players numbers.

Some people won't want to be randomly called in game some will want to be ex-directory

I'd rather it have the option to add people to a contacts list, than display EVERYONE'S numbers.

[churchill]

there is a BIG problem: SQL doesn't support the huge length of 15 SMS' with 160(actually, 168) chars and my guess is that we need to go to MySQL. Which is alot harder for the customer...

Oh noo thats bad

A alternative: smaller SMS? So there is a limit of chars or so.

Is this Limit only for one table or in the whole database?

Well, the IRL limit is 160. It also has that same 160 limit. But that's too big... =/

Hmm, something's not right if that's the limit...if I'm understanding the sql table you created you're storing all the users SMSs in one column?

I think GioSerpo is right when he suggests a two table approach.

phoneOwner table

username (Primary Key)

phonenumber

SMS table (a new row for each SMS entry)

username (Foreign Key)

SMSMessage (main body of SMS message)

ReadStatus (for holding a true/false)

to me, that's a better structure to hold the data as it's a more normalised approach, is more flexible and more scalable than the original structure?

[churchill]

also, i got the betterweather resource implemented, but i had to export a function that wasnt already exported (i think it wasnt exported on purpose, but idk why not).

Oh? tell me! I can probably explain why it wasn't exported originally etc

[50p]

Make a GUI window for something like "Yellow Pages" which will show all the players numbers.

Some people won't want to be randomly called in game some will want to be ex-directory

I'd rather it have the option to add people to a contacts list, than display EVERYONE'S numbers.

You could add a checkbox or radio, so if the box is checked you mark this number to be allowed to be seen in "Yello Pages"

[Gamesnert]

Well, the IRL limit is 160. It also has that same 160 limit. But that's too big... =/

Hmm, something's not right if that's the limit...if I'm understanding the sql table you created you're storing all the users SMSs in one column?

I think GioSerpo is right when he suggests a two table approach.

phoneOwner table

username (Primary Key)

phonenumber

SMS table (a new row for each SMS entry)

username (Foreign Key)

SMSMessage (main body of SMS message)

ReadStatus (for holding a true/false)

to me, that's a better structure to hold the data as it's a more normalised approach, is more flexible and more scalable than the original structure?

Ok first, 160 is the limit for IRL SMS's, not the SQL!

I don't even know the SQL limits...

About your addition to Gio's suggestion, it kind of makes sence, but are you sure it'll all fit? What if the TOTAL space is a problem? But well I'll try. It'll probably give less trouble than my current XML cr@p...

But well, homework first, MTA second...

[churchill]

I know, I meant that 160 * 15 seems like a small amount of data to be causing problems!

it's more likely that it's a problem with column data length...2400 is quite a bit of text for one column to handle (though I had originally assumed that BLOBs were quite large), as opposed to 15 rows with each holding a column containing 160 characters.

just had a quick look, and got found the current implementation of BLOB in SQL Lite, has a max length of 2147483647, so 160*15 should be fine.

So maybe it's a problem with the MTA command that reads/writes that data, rather than SQL itself? in this case, maybe the change of DB structure to a 2 table approach will be more successful?

[XetaQuake]

Hey all.

When i see right, the limit is at 128 Bytes

Here you can find all limits: http://publib.boulder.ibm.com/infocente ... 001029.htm

But yea i think .xml is a good alternative, or not?

[Gamesnert]

Hey all.

When i see right, the limit is at 128 Bytes

Here you can find all limits: http://publib.boulder.ibm.com/infocente ... 001029.htm

But yea i think .xml is a good alternative, or not?

Table 9. String Limits Description Limit

Maximum length of CHAR (in bytes) 254

Maximum length of VARCHAR (in bytes) 32 672

Maximum length of LONG VARCHAR (in bytes) 32 700

Maximum length of CLOB (in bytes) 2 147 483 647

Maximum length of GRAPHIC (in characters) 127

Maximum length of VARGRAPHIC (in characters) 16 336

Maximum length of LONG VARGRAPHIC (in characters) 16 350

Maximum length of DBCLOB (in characters) 1 073 741 823

Maximum length of BLOB (in bytes) 2 147 483 647

Maximum length of character constant 32 672

Maximum length of graphic constant 16 336

Maximum length of concatenated character string 2 147 483 647

Maximum length of concatenated graphic string 1 073 741 823

Maximum length of concatenated binary string 2 147 483 647

Maximum number of hex constant digits 16 336

Maximum size of a catalog comment (in bytes) 254

Largest instance of a structured type column object at run time (in gigabytes) 1

[churchill]

and in any case, that's the DB2 SQL Implementation, not SQL Lite

[GioSerpo]

Churchill, it was the toggleWeatherReport function, i had to export it cause the exports you had were all returning nil. and my guess on why you didnt export it it cause it is the main thing for the whole resource, lol... anyway, i cant get the SMS to save, even with the two table approach. sorry it took so long for the reply, but i had to change fomats of a few of the vids i had. sry...

EDIT: While this is on my mind... i found a sort of bug. like if someone types /pda (or in my case, pushes Z) ore than once, it will open the PDA however many times they typed it, and only one instance can be closed... im goin to work on fixing that, right now, lol

[XetaQuake]

EDIT: While this is on my mind... i found a sort of bug. like if someone types /pda (or in my case, pushes Z) ore than once, it will open the PDA however many times they typed it, and only one instance can be closed... im goin to work on fixing that, right now, lol

Yea i know, thats the reason why i comment out the line to open the PDA with Z

I was too lazy to fix it, it was just a Prototyp...there was the possibility that we not uses the GUI.

But now, yea, i think its needful to fix it

[Gamesnert]

EDIT: While this is on my mind... i found a sort of bug. like if someone types /pda (or in my case, pushes Z) ore than once, it will open the PDA however many times they typed it, and only one instance can be closed... im goin to work on fixing that, right now, lol

Yea i know, thats the reason why i comment out the line to open the PDA with Z

I was too lazy to fix it, it was just a Prototyp...there was the possibility that we not uses the GUI.

But now, yea, i think its needful to fix it

Well, the SQL issue is a little bigger issue... How we gonna try and solve it? Since Gio already stated 2 tables doesn't work and converting it to XML is ALOT of work...

[XetaQuake]

Since Gio already stated 2 tables doesn't work and converting it to XML is ALOT of work...

But i think XML are the only possibility

Hmmm, whats with a SMS table for only one player? is that possible? So the user "XYZ" haves a table with all writen SMS Or is that exactly that what Gio already tryed?

[churchill]

I still don't understand WHY a two table approach won't work. What happens when you try it? what error messages? What sort of problem is occuring etc.

Also, GioSerpo: Could you do a mock up of how you tried to use the BetterWeather system originally, so I can see what the problem is and fix it?

[Gamesnert]

I still don't understand WHY a two table approach won't work. What happens when you try it? what error messages? What sort of problem is occuring etc.

Also, GioSerpo: Could you do a mock up of how you tried to use the BetterWeather system originally, so I can see what the problem is and fix it?

I'll try and find out today. And the BetterWeather external commands just returned nil. Have you tried them before release?

EDIT:

***** NEWS FLASH *****

Guess what? Results are looking better! Not just random better, but really GOOD for once!

It really seems that putting everything in 1 query was the problem. The query seemed to be too long, and the database couldn't handle all those things after eachother. Fortunately, I fixed it, and light testing made it seem like it worked! I tested it on my own, with about 160 characters per message. All a's.

I really need to test this more, but so far it's looking awesomely good.

A release might come soon. Which includes:

-Fully working SMS. (atleast, I hope)

-Customizable skin by XML. (done, not yet tested)

-Character count in message window.

-Remove button to remove SMS messages.

(-Alot of commented crap including debugmessages and a small part of XML... ^^)

Let's hope I find the time to finish all this and more soon.

[Scarface]

I'll try and find out today. And the BetterWeather external commands just returned nil. Have you tried them before release?

EDIT:

***** NEWS FLASH *****

Guess what? Results are looking better! Not just random better, but really GOOD for once!

It really seems that putting everything in 1 query was the problem. The query seemed to be too long, and the database couldn't handle all those things after eachother. Fortunately, I fixed it, and light testing made it seem like it worked! I tested it on my own, with about 160 characters per message. All a's.

I really need to test this more, but so far it's looking awesomely good.

A release might come soon. Which includes:

-Fully working SMS. (atleast, I hope)

-Customizable skin by XML. (done, not yet tested)

-Character count in message window.

-Remove button to remove SMS messages.

(-Alot of commented crap including debugmessages and a small part of XML... ^^)

Let's hope I find the time to finish all this and more soon.

Thats ma boyy!!! Keep it up

[churchill]

It really seems that putting everything in 1 query was the problem. The query seemed to be too long, and the database couldn't handle all those things after eachother. Fortunately, I fixed it, and light testing made it seem like it worked! I tested it on my own, with about 160 characters per message. All a's.

that's what I was referring to when I said that it was more likely a problem with the MTA command rather than a db issue.

[Gamesnert]

It really seems that putting everything in 1 query was the problem. The query seemed to be too long, and the database couldn't handle all those things after eachother. Fortunately, I fixed it, and light testing made it seem like it worked! I tested it on my own, with about 160 characters per message. All a's.

that's what I was referring to when I said that it was more likely a problem with the MTA command rather than a db issue.

Wrong I think, after a quick google it seems to be an SQL problem.

If you are using string, you can not passed a string that has length more than 255 characters in VFP, it will return line too long error message. You have to separate it using "bla bla bla "+"bla bla bla"

Now the line was DEFINITELY over the 255, so there could be truth in this. Also I tried to see if it would take 2520 characters, which seemed to be too long?

Anyway, I'm having some difficulty. When the client shuts-down, it should send SMS data to the server.

However, a quick check revealed that it doesn't trigger! I noticed that onClientPlayerQuit doesn't work, that was something I could find on the wiki. But onClientResourceStop also doesn't seem to trigger... Is it possible to trigger something while quitting? I still need to test some things, but still I don't know... =/

[Ace_Gambit]

[..]

Both onClientPlayerQuit and onClientResourceStop are useless if you want to capture and synchronize data with the server for local players. When a client quits it doesn't say goodbye it is just gone...

What you are looking for is the server-side equivalent onPlayerQuit. However data should be stored beforehand because once the client disconnects it can not send it anymore.