{ Update } SmartFoxServer PRO 1.6.5 is out!
{ Update } SmartFoxServer PRO 1.6.5 is out!
Hello,
SmartFoxServer PRO 1.6.5 update is available.
The patch addresses various bugs discussed in this board and adds new features to the server configuration and framework. See all the details in the release notes below.
NOTE: Make sure to check the release notes as there is an important note on setting the IP Address, which was slightly changed.
Download Update 1.6.5
(and follow the accompanying instructions)
SmartFoxServer PRO 1.6.5 update is available.
The patch addresses various bugs discussed in this board and adds new features to the server configuration and framework. See all the details in the release notes below.
NOTE: Make sure to check the release notes as there is an important note on setting the IP Address, which was slightly changed.
Download Update 1.6.5
(and follow the accompanying instructions)
Last edited by Lapo on 04 Feb 2009, 11:01, edited 2 times in total.
» Changed the way in which the <ServerIp> works: specify the wanted IP address or use an asterisk (*) to bind all available IP addresses (default in previous 1.6.x versions)
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP
This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
» Fixed a bug in dispatching "userLost" event at Room Level for Java extensions: only rooms where the user was joined will receive a notification. Previously it was dispatched to all rooms.
» Added extra defensive exception check to avoid that custom Extension code generating an exception when handling the "userLost" event causes incomplete disconnections at Server level
» Fixed IPFilter so that it doesn't interfere with the BlueBox
» Add new BlueBox 1.0.5 update
» ExtensionHelper new feature: added a rebootServer() that allows extensions to restart the server from code
» New server side event called "serverReady" is fired to any extension as soon as the server engine is ready to accept connections. The event is necessary for proper NPC initialization. Since every NPC uses a connection to the loopback interface, the extension should know when the server engine is ready to accept those connections. The init() method of an extension is not the right place because it is executed before the socket engine starts.
» Fixed FINE level logging for server side setUserVariables() method
» Updated documentation, in particular chapter 6.10 (Buddy list 2.0)
» Added an NPC tutorial showing how to create bots that interact with real users in the avatarChat example.
» AS 2.0 and AS 3.0 Flash API: fixed a small bug with UserVariables updates when users are joined in multiple rooms. With a particular combination of rooms the client could receive a null object instead of the reference to the User who updated the variables.
[[===--- Previous updates (1.6.4) ---===]]
» New Actionscript Extensions caching system:
Prevents possible Java VM PermGen out of memory errors
Speeds up loading and compilation of Actionscript extension compilation by many orders of magnitude
Allows thousands of Room-Level AS extension to run with lower performance impact
» Changed the way in which the <ServerIp> works: specify the wanted IP address or use an asterisk (*) to bind all available IP addresses (default in previous 1.6.x versions)
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP
This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
» Zone.getAllUsersInZone -> fixed possible bug that causes the list to have null objects
[[===--- Previous updates (1.6.3) ---===]]
» New RedBox API for Actionscript 2.0 including examples, documentation and source code.
» Fixed AS3 API that would prevent myBuddyVariables to be populated if buddy list was empty
» UserVariables (multiroom), fixed an issue in AS3 API that would cause a #1009 error when using multi rooms
» UserVariables (multiroom), optimized server messages, no more duplicates (it was sending 1 message for each room. Now it just sends 1 message)
» Client API now fire warnings if a call is performed without having received the room list or without having joined at least one room.
» Added new joinAsSpectator flag in the client side createRoom() method, allows to auto-join a new game room as a spectator instead of player
» AS3 API, createRoom fixed attribute name exitCurret ==> exitCurrentRoom (as in Actionscript 2)
» UserVariables, new <UserVarsOptimization> config parameter allows to receive only real changes in user variables, avoiding variables that didn't change to be retransmitted
» New <BanMode> tag allows to specifiy if the auto-ban does it by name or ip (default = ip)
» New debugging tags: <DebugIncomingMessages> <DebugOutGoingMessages> allow to debug incoming/outgoing data
» Added logging data dump for debugging "user name already taken" errors.
» New server side commands for handling kicking and banning (Java and AS): kickUser(), banUser(), banOfflineUser(), removeBanishment(). Note for Python users: you can call directly the methods on the ExentsionHelper instance
» Added new tag: <MaxSocketIdleTime> for specifying the max idle time of a socket connection
» New server side "force login" option , allows a user to force the login and close it's previous connection.
» Fixed an issue with removeBuddyList when not using mutualRemove. (was removed mutually anyways)
» Fixed <SystemHandlerThreads> not allowing values other than default
» Fixed problem with BuddyList 2.0 viewtopic.php?p=9843#9843
» Beta NPC feature: allows the server side to create fake User objects connected to the localhost. The server will recognize them as real connected users.
» New addModerator() and removeModerator() methods to add/remove moderator users at runtime
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP
This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
» Fixed a bug in dispatching "userLost" event at Room Level for Java extensions: only rooms where the user was joined will receive a notification. Previously it was dispatched to all rooms.
» Added extra defensive exception check to avoid that custom Extension code generating an exception when handling the "userLost" event causes incomplete disconnections at Server level
» Fixed IPFilter so that it doesn't interfere with the BlueBox
» Add new BlueBox 1.0.5 update
» ExtensionHelper new feature: added a rebootServer() that allows extensions to restart the server from code
» New server side event called "serverReady" is fired to any extension as soon as the server engine is ready to accept connections. The event is necessary for proper NPC initialization. Since every NPC uses a connection to the loopback interface, the extension should know when the server engine is ready to accept those connections. The init() method of an extension is not the right place because it is executed before the socket engine starts.
» Fixed FINE level logging for server side setUserVariables() method
» Updated documentation, in particular chapter 6.10 (Buddy list 2.0)
» Added an NPC tutorial showing how to create bots that interact with real users in the avatarChat example.
» AS 2.0 and AS 3.0 Flash API: fixed a small bug with UserVariables updates when users are joined in multiple rooms. With a particular combination of rooms the client could receive a null object instead of the reference to the User who updated the variables.
[[===--- Previous updates (1.6.4) ---===]]
» New Actionscript Extensions caching system:
Prevents possible Java VM PermGen out of memory errors
Speeds up loading and compilation of Actionscript extension compilation by many orders of magnitude
Allows thousands of Room-Level AS extension to run with lower performance impact
» Changed the way in which the <ServerIp> works: specify the wanted IP address or use an asterisk (*) to bind all available IP addresses (default in previous 1.6.x versions)
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP
This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
» Zone.getAllUsersInZone -> fixed possible bug that causes the list to have null objects
[[===--- Previous updates (1.6.3) ---===]]
» New RedBox API for Actionscript 2.0 including examples, documentation and source code.
» Fixed AS3 API that would prevent myBuddyVariables to be populated if buddy list was empty
» UserVariables (multiroom), fixed an issue in AS3 API that would cause a #1009 error when using multi rooms
» UserVariables (multiroom), optimized server messages, no more duplicates (it was sending 1 message for each room. Now it just sends 1 message)
» Client API now fire warnings if a call is performed without having received the room list or without having joined at least one room.
» Added new joinAsSpectator flag in the client side createRoom() method, allows to auto-join a new game room as a spectator instead of player
» AS3 API, createRoom fixed attribute name exitCurret ==> exitCurrentRoom (as in Actionscript 2)
» UserVariables, new <UserVarsOptimization> config parameter allows to receive only real changes in user variables, avoiding variables that didn't change to be retransmitted
» New <BanMode> tag allows to specifiy if the auto-ban does it by name or ip (default = ip)
» New debugging tags: <DebugIncomingMessages> <DebugOutGoingMessages> allow to debug incoming/outgoing data
» Added logging data dump for debugging "user name already taken" errors.
» New server side commands for handling kicking and banning (Java and AS): kickUser(), banUser(), banOfflineUser(), removeBanishment(). Note for Python users: you can call directly the methods on the ExentsionHelper instance
» Added new tag: <MaxSocketIdleTime> for specifying the max idle time of a socket connection
» New server side "force login" option , allows a user to force the login and close it's previous connection.
» Fixed an issue with removeBuddyList when not using mutualRemove. (was removed mutually anyways)
» Fixed <SystemHandlerThreads> not allowing values other than default
» Fixed problem with BuddyList 2.0 viewtopic.php?p=9843#9843
» Beta NPC feature: allows the server side to create fake User objects connected to the localhost. The server will recognize them as real connected users.
» New addModerator() and removeModerator() methods to add/remove moderator users at runtime
- mistermind
- Posts: 131
- Joined: 15 Sep 2007, 01:33
- Contact:
Lapo wrote:» AS 2.0 and AS 3.0 Flash API: fixed a small bug with UserVariables updates when users are joined in multiple rooms. With a particular combination of rooms the client could receive a null object instead of the reference to the User who updated the variables.
Lol that felt so... personal lol
Finally a bug I'm proud of
SELECT * FROM users WHERE clue > 0
0 rows returned.
0 rows returned.
sstark wrote:note : you copy files from '/Server' and paste into '/Server/lib', not 'Server' like I did.
Yes, please check the instructions before proceeding.
[[===--- Server Side ---===]]
1. Stop the server if its running.
2. copy the content of the Server/ folder in your path-to-sfs-installation/Server/lib/ folder
3. when asked to replace files, answer yes
4. Start the server
-
- Posts: 3
- Joined: 26 Jan 2009, 20:07
1.6.5 upgrade sour?
we seem to be now having bunch of random weird errors/issues after upgrade
is that normal?
is there a live person i can talk over the phone?
this product costed 2000 euros - tats a lot of money - i would like proper support.
is that normal?
is there a live person i can talk over the phone?
this product costed 2000 euros - tats a lot of money - i would like proper support.
-
- Posts: 3
- Joined: 26 Jan 2009, 20:07
@ thomers1
yeah, we reverted back because EVERYTHING broke. including java making sql calls.
i think i would be looking for an alternative for the next multiuser project unless some serious fixes will come very soon.
i think i would be looking for an alternative for the next multiuser project unless some serious fixes will come very soon.
-
- Posts: 3
- Joined: 26 Jan 2009, 20:07
@ thomers1
- initial connection establishing takes 10-15 seconds (used to be next to instant)
- errors are inconsistent seems like everyhting is now broken
- java extension fails making sql queries (used to wor next to flawless)
if upgrading is incompatible with previous version - thats fine but that should be noted, i almost grew grey hair.
a product that costs money should NOT HAVE bugs in it or they should be addressed in a timely manner and come with support.
as you might have noticed no one had tried to even reply to my. i cant give specifics on a project - there are thousands of lines of code - cant really be published. i cant change technology at this point, all i can do is wrap things in try catch and prey.
- errors are inconsistent seems like everyhting is now broken
- java extension fails making sql queries (used to wor next to flawless)
if upgrading is incompatible with previous version - thats fine but that should be noted, i almost grew grey hair.
a product that costs money should NOT HAVE bugs in it or they should be addressed in a timely manner and come with support.
as you might have noticed no one had tried to even reply to my. i cant give specifics on a project - there are thousands of lines of code - cant really be published. i cant change technology at this point, all i can do is wrap things in try catch and prey.
thomers1:
I apologize for the inconvenience on the web-page. It's been updated.
aidemsined:
Upgrading shouldn't create any problems.
Contact us directly via email explaining the details of the problem, including the logs where these errors appear.
Also what version was the server before upgrading?
Thank you
I apologize for the inconvenience on the web-page. It's been updated.
aidemsined:
we seem to be now having bunch of random weird errors/issues after upgrade
is that normal?
is there a live person i can talk over the phone?
this product costed 2000 euros - tats a lot of money - i would like proper support.
Upgrading shouldn't create any problems.
Contact us directly via email explaining the details of the problem, including the logs where these errors appear.
Also what version was the server before upgrading?
Thank you
Hi Lapo.
I'm having an issue with the 'serverReady' event and creating an NPC.
In version 1.6.3 I used the scheduler to create an NPC 10 seconds after the extension started, to ensure the init() had completed and the server was ready to create the NPC. This worked great.
Now in 1.6.5, this does not work. I get
I thought that maybe creating an NPC was tied to the 'serverReady' event, so instead of using the scheduler, I wait for the internalEvent 'serverReady'. However, this event never seems to fire!! I have a trace in on the event call, and also a trace in on ALL internal events - I see 'loginRequest', 'newRoom' etc - everything EXCEPT 'serverReady'!!!
I even tried creating the NPC 30 seconds after the init(), with the same result outlined above.
I'm at a loss here - the config.xml file is set to <EnableNPC>true</EnableNPC>, I'm not creating the NPC in the init() function, and I TRY to wait for the 'serverReady' event, but it never fires!!
What go on??!!
Cheers,
G.
I'm having an issue with the 'serverReady' event and creating an NPC.
In version 1.6.3 I used the scheduler to create an NPC 10 seconds after the extension started, to ensure the init() had completed and the server was ready to create the NPC. This worked great.
Now in 1.6.5, this does not work. I get
Code: Select all
NPC creation failed, due to I/O error. Local socket connection failed.
I thought that maybe creating an NPC was tied to the 'serverReady' event, so instead of using the scheduler, I wait for the internalEvent 'serverReady'. However, this event never seems to fire!! I have a trace in on the event call, and also a trace in on ALL internal events - I see 'loginRequest', 'newRoom' etc - everything EXCEPT 'serverReady'!!!
I even tried creating the NPC 30 seconds after the init(), with the same result outlined above.
I'm at a loss here - the config.xml file is set to <EnableNPC>true</EnableNPC>, I'm not creating the NPC in the init() function, and I TRY to wait for the 'serverReady' event, but it never fires!!
What go on??!!
Cheers,
G.
It sounds like your upgrade didn't succeed.
By simply taking a regular SFS PRO 1.6.2 and upgrading it to 1.6.5 you can clearly see that the serverReady event is traced by the default RedBox examples.
Also we provide a Java NPC example that should work out of the box, once installed in the simpleChat Zone.
Please double check your installation and verify the provided example too
By simply taking a regular SFS PRO 1.6.2 and upgrading it to 1.6.5 you can clearly see that the serverReady event is traced by the default RedBox examples.
Also we provide a Java NPC example that should work out of the box, once installed in the simpleChat Zone.
Please double check your installation and verify the provided example too
Ganius wrote:Now in 1.6.5, this does not work. I getCode: Select all
NPC creation failed, due to I/O error. Local socket connection failed.
Hi Ganius,
We had a same problem when we updated our server with new patches. However, here is the tip to solve the problem. Change the server ip section in the config.xml with <ServerIP>*</ServerIP>. This will solve the problem.
pt_dev
From the first post and from the readme in the update:
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP. This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
::: IMPORTANT NOTE ::::::::::::::::::::::::
Specifying the IP address in the <ServerIp> will make the server listen exclusively on that IP. This means that the BlueBox will need to be pointed to that address in order to work correctly
For optimal performance of the BlueBox we recommend to use <ServerIp>*</ServerIp>
::: END NOTE ::::::::::::::::::::::::::::::
Return to “SmartFoxServer 1.x Discussions and Help”
Who is online
Users browsing this forum: No registered users and 35 guests