So, i'm just gonna post some screenshots of the situation instead of code, but first I'll describe it.

I've made a server ASL file and to bypass Quest's error when you have a continous 1 second timer running from the start, I have the timer enabled after an Administrator account logs in. This all works fine, so I added a wizard to prompt the Administrator for current date and time to base the persistent time off of. All this works fine, and I thought it was causing an error and not changing my Status Variables value untill I checked in my Numeric Variables Debug Window, to find that none of my variables even start off with their values as defined in the code. I've tried it with and without scope values, these values are never modified by the code. I realize I could bypass all this by giving some game object properties similar to these and just read from the game object rather than store in variables and read them.

Click to increase size.

Here's a screenshot of my code...


Here's the Questnet Numeric Variable Debug immediately after opening...


I'd rather not have to work around this using object properties, I can but, by all accounts this shouldn't happen I believe.

Bumpity Bump Bump, Any response anyone? Alex? I'll work around it starting in about an hour but uh, thought it might attract some attention.

P.S. I'm pretty deep into a new server, much leaner and more functional.

After I'm done seeding a few torrents I think I'm going to want to test it for any bugs.

Also another problem Alex, the built-in function $disconnectedby$ is really pretty useless. It have yet to have it successfully return any information no matter how a player disconnects.

Which version are you using? There was a bug fixed in Quest 3.52 which was that all numeric variables started with a value of zero. This would also have affected QuestNet Server 3.5, but QuestNet Server 3.52 shouldn't have this problem.

You can use the $disconnectedby$ function in the "disconnect" script in the "define game" block - where are you trying to use it?

Eh Quest update feature leads to a webpage saying it's up to date, but Questnet's update feature leads to a webpage saying there is an update available, when I click the download link, it takes me to the regular Quest download page.

Quest build is 3.5.233
Questnet build is 3.5.94

I downloaded the Quest install from the main download link a couple weeks ago, and the Questnet pro from the download link in my email from you with my login/pw information.

I think the problem here is that Questnet Pro hasn't been updated.

I had been using the $disconnectedby$ in the disconnect script in define game.

The latest QuestNet Server build is 3.5.97, and this is included in the quest352.exe download. Make sure you tick the option to install QuestNet Server or it won't be updated.

Ah, I see the problem - I haven't updated the build of Questnet Server Pro. I will send you an email.