Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Crash after CloseNetwork

Author
Message
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 24th Mar 2013 14:15 Edited at: 24th Mar 2013 14:17
I've been investigating a bug in my WIP that appears to be the result of trying to close a network that you are hosting. Here's what I know.

My WIP is developed in Tier 2 using AppGameKit 1.088. The crash does not occur every time, maybe one in three times. I cannot tell any pattern to this such as the number of times you have to repeat the process (can happen on 1st, 2nd, 3rd time etc.) or the length of time between creating and closing the network, although perhaps shorter makes it more likely. From stepping through my code, it appears that the crash happens in the Sync() function. When the crash occurs in debug mode, I get the following error:


And I get the following in the debug console:


I've managed to reproduce the error in a simple Tier 1 example compiled with the latest beta (1.089). Here is the code:


Again, the bug does not occur every time. I have got as high as 20-30 iterations without a crash. However it has also happened on 1st and 2nd time. When it crashes, I get the following error:

After which, it "stops working and needs to close".

Anyhow it would be great if anyone could test this for me and see if they get the same error or if they can see if I'm obviously doing something wrong here. The only time I received this kind of error before in AppGameKit was when I tried to both use a broadcast listener in a client and host a network at the same time on the same machine. This I believe was caused by both trying to use the same port. Therefore I wonder if CloseNetwork is trying to use the same port as HostNetwork from a different process and this is causing the crash.

If other people are getting this error too, I'll head over to the issues board and post it there. Thanks!

Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 25th Mar 2013 09:32
Just to let you know, I've now added this as an issue on the issues board. You can follow it here.

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 25th Mar 2013 15:10
Based on the sample code you provided, you are repeatedly calling the HostNetwork command with the same network and app names on the same port.

I would think that that is a bad idea and am not surprised that it fails.

I suspect that you are only supposed to call that command once, to set up the hosting.

I'm guessing that each call sets up some sort of information and then, when you close the app, the AppGameKit engine is trying to close the network connection made, it doesn't know which one to process.

Do you have the same problem if you only make the call once?

(I am going to post this in the google issue as well.)

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 27th Mar 2013 16:17
I'm just guessing, but I have a function sever, and a lot of this code is done in the background on agk, so I think that's an issue. Very occasionally, closing a network causes errors, but for me it Def seemed to be linked to how quickly it was tried after the connection was made, perhaps because the background function being run didn't complete quickly enough etc. For me the solution was as simple as having a minimum delay before it tried to close after opening, problem gone.

Might not be related to yours though.
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 27th Mar 2013 19:12
Quote: "For me the solution was as simple as having a minimum delay before it tried to close after opening, problem gone."

Thanks for the response. Could you tell me what minimum time you set?

Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 27th Mar 2013 20:09
Yes and no. The code I have calls a function to deal with networks within a loop, so the delay is based around a number of cycles before checking again, but realistically it won't be more than about a second I wouldn't think. As I said it could be an unrelated problem, but it sounds the same. My assumption was, background code is performing functions to do all the real work, which depending on the device may or may not include initialising the network adaptor etc, or delays caused by other system functions.

I don't use tier 2 though, I never noticed that initially so it could well be completely separate thing.
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 27th Mar 2013 22:03
sync do something with network each loop and
between open and close i get no error.
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 28th Mar 2013 09:39
Quote: "realistically it won't be more than about a second I wouldn't think"

Ah in that case, it does sound like a different issue as the time between me creating and closing the network in my WIP would probably be more than this (you have to click the back button and I'm not that quick).

Quote: "sync do something with network each loop and between open and close i get no error."

Thanks for the feedback Markus. I'm away at the moment so I wont be able to test your code for a couple of days. However what I would say is that I discovered this problem not from the example Tier 1 code I posted but from by WIP which has many calls to Sync() between creating the host and closing the network. This is because when you click to create a network, it immediately goes ahead and creates it. Then the network is only closed if you click the back button. There is no way I can be clicking the back button in less than one cycle of the app's main loop. If you're right that that fixes the bug though, it opens the possibilities that:
1. The Tier 1 code crash is actually a different issue to the one I have in my WIP.
2. There was some kind of fix in v.1089 that prevents the crash so long as Sync is called. As my WIP is currently using the v.1088 libraries, it would not have benefited from this.
Anyhow thanks again, I'll experiment with this when I get back.

Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 28th Mar 2013 10:04 Edited at: 28th Mar 2013 10:08
came the c++ runtime error at each pc?
the error looks like i got at a third party addon for x-plane,
sometimes it works,sometimes i get this error at start.
maybe reinstall this c++ runtime and service packs after.

its better you write a 0 in the variable after close to prevent
future use and wrong debug output.
CloseNetwork(networkId)
networkId=0
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 29th Mar 2013 19:32
Quote: "sync do something with network each loop and between open and close i get no error."

I've now had a chance to test this and although I would say it is rarer, I can still produce the error.


Quote: "came the c++ runtime error at each pc?"

I've only been able to test it on my dev machine so that's why I wanted to check that other people were getting the same error.

Quote: "maybe reinstall this c++ runtime and service packs after."

Sorry reinstall which C++ runtime?

Quote: "its better you write a 0 in the variable after close to prevent future use and wrong debug output."

Thanks, I've added this to my WIP but I still get the same error.

Quote: "can you post some of how you are handling the network open/close in Tier 2? - from AppGameKit Issues Board"

I'll have a go, although this is from a fairly large project so it's not really practical to post everything. So to start with, when you click "Host Game", a new screen is created. In the screen's constructor is the following code:


As you can see, all I'm really doing is using the HostNetwork command.

Each screen has a runScreen() method that is called once per cycle. In the above screen's runScreen() method is the following code to handle the back button being pressed:


When I'm stepping through the code, it rarely seems to crash, perhaps suggesting that timings are involved. However when it has, once was on the Sync() command following the above code and the second time was on the CloseNetwork() command itself. If there is anything else I can show you to help diagnose this, please just let me know. I could try to share the whole project with you but it would be a non-trivial task wading through it!

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 29th Mar 2013 19:45
Try setting a flag the first time it's closed and then don't do it. There may be some latency in the GetPointerReleased() call.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 29th Mar 2013 20:35
For starters "hostId = agk::GetNetworkMyClientID(networkId);" is not the right command, since you are hosting and not clienting in the segment you showed. If you want to get the actual id for the host, use GetNetworkServerID(networkID).

And throw in agk::Sync() after your agk::CloseNetwork(networkId) command. It is possible that the network commands will be handled right away and it can't hurt.

Also throw in an 'if' before you close the network:
if (networkId != 0) agk::CloseNetwork(networkId);

And, be careful that you are always using either GetPointerReleased or GetPointerPressed. If you mix them, in different places, one may trigger when you don't want to.


Quote: "Each screen has a runScreen() method that is called once per cycle."

Is it possible that the different runScreen() methods are happening in an order other than what you expect?

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 30th Mar 2013 10:36
Quote: "For starters "hostId = agk::GetNetworkMyClientID(networkId);" is not the right command, since you are hosting and not clienting in the segment you showed. If you want to get the actual id for the host, use GetNetworkServerID(networkID)."

Actually GetNetworkMyClientID works fine for this because AppGameKit networks treat the host as a client. The difference with GetNetworkServerID is that this command will return the host's client id on every machine in the network, where as GetNetworkMyClientID will obviously only return the host's client id if it is called on the host itself.

Quote: "And throw in agk::Sync() after your agk::CloseNetwork(networkId) command. It is possible that the network commands will be handled right away and it can't hurt.

Also throw in an 'if' before you close the network:
if (networkId != 0) agk::CloseNetwork(networkId);"

Both good thoughts but I'm afraid I've implemented both and I still get the crash.

Quote: "Is it possible that the different runScreen() methods are happening in an order other than what you expect?"

I've stepped through the code and it doesn't appear so..

The strange thing is that I'm having real trouble producing the error whilst stepping through the code. It seems that this somehow affects the outcome. I start stepping through the code after the CloseNetwork command which mean that it isn't so much the gap between opening and closing the network as between closing the network and... something. If I place the break point after the Sync() command, it sometimes crashes before reaching the break point, indicating that the crash is happening somewhere in the CloseNetwork() or Sync() command. To be honest, I'm kind of out of ideas for the moment. I'll keep pondering it but any other suggestions would be great.

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Mar 2013 12:43
Have you tried my flag setting? If it's okay when stepping I think it's a time issue.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 30th Mar 2013 13:01
Quote: "Have you tried my flag setting?"

Sorry what exactly do you mean by this? Is it different to what AL and Markus were saying about setting the networkId to 0 after closing the network and then checking that networkId is non-zero before closing the network again?

Quote: "If it's okay when stepping I think it's a time issue."

If this is the case, I wonder what I can do about it. Does that mean it's an AppGameKit issue that TGC can fix?

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 30th Mar 2013 16:36
Since you are working in Tier 2, if you can come up with a simple example (like the Tier 1 one) that fairly reliably crashes, we can add that to the Google issue and I'll flag it as a confirmed issue (assuming I get the same results).

The AppGameKit guys need something that reliably demonstrates a problem before they can really work on it.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Mar 2013 17:11
What I mean is (pseudo-code):

Have a boolean variable something like CheckedClose
Initialise it to false

When you call GetPointerReleased() make it
if GetPointerReleased() and (not CheckedClose)

add CheckedClosed = true before doing anything else

That way you will not call your network close more than once. Don't assume that GetPointerReleased() will immediately return 0

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 30th Mar 2013 22:37
Quote: "Since you are working in Tier 2, if you can come up with a simple example (like the Tier 1 one) that fairly reliably crashes, we can add that to the Google issue and I'll flag it as a confirmed issue (assuming I get the same results)."

Sure, I've put this code together which crashes fairly often for me (usually on the first - third attempt). It is based off the Tier 2 v1088 template and has the following code.

template.h


template.cpp


If you could check this for me to see if you get the crash as well, that would be great. Thanks!

Quote: "Don't assume that GetPointerReleased() will immediately return 0"

That's interesting Jim; I had been assuming that. Can I ask if this is a known glitch? It's just that the AppGameKit documentation says the following
Quote: "GetPointerReleased returns 1 the instant the pointer is released and then returns 0"

which suggests that it should only return 1 on the cycle that the pointer is released.

It's definitely interesting to know and I'll consider that when writing my code, but I'm not sure that this is the cause of this issue. First off, AL's and Markus's suggestion should have a similar effect here (instead of using a boolean, the networkId variable is acting as a check to make sure that the network is not closed twice). Also I've stepped through the code and not noticed this problem.

Thanks for your continued help with this!

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 31st Mar 2013 00:12
Lucas - I don't know if I'm right. It's a hunch. In the past I've had to throw away a lot of mouse click events because users will keep clicking madly even if you've initiated a response to the first one.

I'm sure the documentation is correct, but a bit of protective programming never hurts.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 31st Mar 2013 05:53
Lucas, I'll try to test your code on Monday and post it all in the appropriate error places if I can reproduce the issue.

Thank you for putting the test code together.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Hodgey
14
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 31st Mar 2013 12:52
I tried the T2 test code on my mac a bunch of times and couldn't get it to crash. Might be a Windows thing.

Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 1st Apr 2013 00:09
Quote: "In the past I've had to throw away a lot of mouse click events because users will keep clicking madly even if you've initiated a response to the first one."

Good thought. The code can be as reliable as you like but you can't force the users to be equally sane!

Quote: "Lucas, I'll try to test your code on Monday and post it all in the appropriate error places if I can reproduce the issue."

Thanks!

Quote: "I tried the T2 test code on my mac a bunch of times and couldn't get it to crash. Might be a Windows thing."

That is interesting... Yes I guess it could be Windows only. I've not tried any other platforms.

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 1st Apr 2013 01:12
Quote: "Good thought. The code can be as reliable as you like but you can't force the users to be equally sane!"


Unfortunately, as programmers we live in a protected world. It's almost impossible to conceive what users will do, and I think we all tend to run the sensible tests we think are expected behaviour.

Because Windows is event-driven it's in my experience crucial to control expected behaviour by rejecting madness. Mostly this is mouse events. AppGameKit "appears" to be a simple polling linear system, but on Windows it's still responding to messages pumped from the main loop, and the arrival of these messages can be quite asynchronous. Hence, anything involving mouse-clicks or key presses should be guarded carefully - otherwise the thing you thought was being called once was actually being called several times, which can be nasty.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 2nd Apr 2013 16:37
I tested in both Mac and Windows with the following (starting from published vanilla templates on both platforms):
template.cpp -


At first, it appeared to work just fine, no crashes no matter how many times I clicked.

But when I tried in on the Mac, since it was started from Xcode it displayed output not seen in the app itself, it showed the following messages in the 'All Output' window each time the app opened the network connection:


There were no messages on the close network operation. It is entirely possible that my Mac Mini isn't properly configured to be a host as AppGameKit sees it.

But, being curious, I rebuilt the Windows version in Debug configuration and ran the debugger.

The first open and close produced nothing unusual. Then I sped up the time between the open and close click and got the message (the first line appears a lot while stuff is happening:


This would appear to indicate that something wasn't right and that a crash was possible.

But I still couldn't get either one to actually crash.

However, the original Tier 1 version would reliably crash with only a very few clicks. That one did the close immediately after the open.


When I changed the Tier 1 to be like the Tier 2, I couldn't get it to crash.


But, given the messages showing up in the debug logs, there does appear to be something strange. So, I will officially confirm a maybe bug.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 2nd Apr 2013 17:01
Wow thanks for all your work on this AL!

Quote: "The thread 'Win32 thread' (0x9bc) has exited with code 0 (0x0).
> Forcing a thread to terminate, this may cause a crash...The thread 'Win32 thread' (0x1748) has exited with code 0 (0x0)."

I've seen this error before under Windows, but it almost invariably crashes when I do see it.

Quote: "Failed to bind listening socket
Failed to set broadcast packet address: 1"

Not see this one before although I saw something quite similar when I was getting clashes between being both a host and having a broadcast listener running on the same PC. I'm running under Windows though so maybe Mac is different.

Quote: "But, being curious, I rebuilt the Windows version in Debug configuration and ran the debugger."

Ah yes, I should have specified, all my Tier 2 code is being compiled and run under debug, including my current WIP where I first came across the problem.

Quote: "When I changed the Tier 1 to be like the Tier 2, I couldn't get it to crash."

Just tried it out and I can't get it to crash either, although like you say, the original Tier 1 code does still crashes for me.

Quote: "So, I will officially confirm a maybe bug."

Thanks! Even if it isn't a bug, at least TGC may be able to explain to us what is going on so I can fix it in my current project.

JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Apr 2013 17:26
Failing to bind socket is usally caused by another process having the socket bound to that port. A crashing program can leave the socket bound. This usually requires a computer reset.

Occasionally debuggers can cause network errors. I would try in Release mode.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 2nd Apr 2013 18:33
No debugger in use on the Mac, but I've never tried the network stuff on it before.

The Release version of the Windows Tier 2 did not crash, even after 150 fast clicks. But, it might have been having that same error in the background, no way to tell.

This is why it is in the google list and on the TGC AppGameKit CT page as a 'maybe bug'.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Apr 2013 19:31
Sometimes, in my experience, the debuggers will raise internal exceptions because they've hooked everything. Any serious error will surely raise a fatal exception in release mode?

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 2nd Apr 2013 20:29
Probably. And I think the original issue was one of timing.

If the network delete was done right after the connection without at least one sync cycle, then it definitely barfs. I just tested a Tier 2 version of the open/close on press (both each time) and it pretty reliably barfed after 2 or 3 clicks.

But the version that opened or closed (depending on current state) with a sync cycle between click checks was pretty stable in both Tiers.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 2nd Apr 2013 23:16
I think I've tracked it down to the network thread being deleted before it has even been created, so when it eventually gets around to starting all sorts of bad things happen. I'll include the fix in beta 10
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 2nd Apr 2013 23:32
Apparently a comment I read somewhere else on the forum about apps having to deal with all kinds of unexpected user behaviors applies to AppGameKit itself too! Lol.

Any idea when beta 10 might appear Paul?
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 2nd Apr 2013 23:45
Quote: "The Release version of the Windows Tier 2 did not crash, even after 150 fast clicks. But, it might have been having that same error in the background, no way to tell."

Yes this is interesting. I tried compiling my WIP as release and I couldn't immediately produce the crash which seems odd. I'd say it was what Jim was saying about the debugger interfering with the network except that Paul seems to have found something.

Quote: "I'll include the fix in beta 10"

Thanks Paul! That's great news .

Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 3rd Apr 2013 00:39
Paul,

I've found something else out that may or may not be related, and may or may not be new - I'm not sure.

I was updating my own server code and have found an oddity of sorts. I run two AppGameKit apps, my server that basically never sleeps, and the main app which logs into it pretty much as soon as it starts. On windows, when the main app starts if the window is not in focus the network code apparently fails - no messages or anything it just doesn't log in, even after you click to take focus again. I've run it dozens of times without removing focus and it always worked, and always just didn't when the main apps window wasn't in focus.

May not be new, may be my code - but I've dropped it in as I've never noticed it before and I'm doing nothing new (only noticed it as I was moving the server to a second monitor).
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 3rd Apr 2013 01:17
How do you run the app without it having focus, can you give me a set of steps to replicate the issue?
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Apr 2013 01:35
I'm also puzzled by this. A newly-started program will always have focus, unless its window flags are abnormal.

-- Jim DO IT FASTER, EASIER AND BETTER WITH AppGameKit FOR PASCAL
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 3rd Apr 2013 01:59
Sorry, I wasn't clear. I run my windows app in a window, not full screen, so it has a title bar etc. So when it starts up you can click out of the window and and play with your desktop, which normally leaves the AppGameKit app running in the foreground. If you left or right click the title bar of the window though, the app freezes until you let go again, except for music/sound playing - this code seems to run on in the background. So, my guess was that the background network code also runs on ahead of the app and it was maybe missing something....but now I've restarted AppGameKit I'm not actually getting the same problem anymore.

Sorry guys, I restarted both programs earlier but I didn't think to restart AppGameKit itself (probably what I get for editing two programs at once really!!)
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 4th Apr 2013 21:34 Edited at: 4th Apr 2013 22:01
@Paul,

I'm still having issues Paul I'm afraid. The network issues I'm having are intermittent - I've tried recording my desktop but it never occurs when I am recording oddly. So, I decided to try the player app, and it seems fine. I can run the server on my PC, and the app either through AppGameKit or the compiled .exe and it connects sometimes but then sometimes not. Using the player on google play if I broadcast it, it still seems ok on my phone and tablet. I have noticed that occasionally the PC code is slow and very stuttery at startup (before my net code begins, drops from 60 to about 5 FPS, no notable background processes), and the recording software slows everything down quite a bit - has a change happened that is perhaps skipping the net code, hence why it works when the PC is slowed down due to recording? I'm out of idea's as to how to demonstrate without sending my entire project as there's quite a bit of net code??
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 4th Apr 2013 22:34
If it works when it gets slowed down due to recording, then you are definitely dealing with a timing issue, as we had thought before.

Try putting code in that forces a delay of a couple of seconds or so between possible clicks on whatever it is that your code does to disconnect/reconnect. I can't imagine any app that needs to have a connection opened and closed so quickly that a couple of seconds is going to make a difference.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 6th Apr 2013 01:02
There is a networking bug fix in 108 beta 10 related to quick disconnects after connecting, once that is released let me know if you still experience issues.
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 6th Apr 2013 10:25
Quote: "There is a networking bug fix in 108 beta 10 related to quick disconnects after connecting, once that is released let me know if you still experience issues."

Thanks! Will do. Looking forward to the update .

Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 6th Apr 2013 18:27
And the update (v10810) is now available in the 'My Products' page.

Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 6th Apr 2013 20:46 Edited at: 6th Apr 2013 20:47
I've just tested the Tier 1 example, the Tier 2 example, and my WIP under the new beta 10 libraries and I could not produce the crash in any of them, so I think this is fixed!

Thanks TGC!

Login to post a reply

Server time is: 2024-05-06 05:14:31
Your offset time is: 2024-05-06 05:14:31