Introversion

Hey, I was all excited about DEFCONing today, and after a long wait, I got my download up and running. The first thing I tried to do, was run the tutorial, but oh oh... "Tutorial Starting" message box lasted forever. "Rolling Demo" didn't work either. Tried to go into a normal game against the AI to learn what to do with the manual, but after clicking New Game, only the chatbox popped up (I checked this with Miah and told me he had the same issues). What's going on?

Another thing I noticed, after quitting the game, it still showed up in the Process List.

Does anybody else has this problem?
Thanks in Advance

UPDATE!
My computer specs:

ASUS P4P800 motherboard w/ Intel Pentium IV 3.0ghz - 1GB ram
MSI FX5700 128mb ram
Linksys WRT54G w/wired connection to my pc
running Windows XP Pro SP2

For the record, I CAN play online games that someone else hosts, but I can't start my own. I downloaded the demo in class today and had no problem in starting a game vs. the AI.

debug.log

Defcon 1.0 built Sep 25 2006
Parsing archive main.dat...DONE
Parsing archive sounds.dat...DONE
Client listening on port 5011
Parsing Coastline data (1776 islands) : 54ms
Parsing International data (2753 islands) : 24ms
Parsing City data (2745 cities) : 33ms
Authentication key set : 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
Connection established to MetaServer, listening on Port 5009
Requesting data from MetaServer : LatestVersion
Requesting data from MetaServer : MOTD
Received data from MetaServer : LatestVersion
Received data from MetaServer : MOTD
Requesting authentication of key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Received Authentication : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx : (keyID xxxxx) : Accepted
Authentication HashToken set to xxxxx9059
CLIENT : Disconnected
EclRemoveWindow failed on window LOBBY
Server started on port 5010
CLIENT : Attempting connection to Server at 0.6.0.4:5010...
Requesting data from MetaServer : UpdateURL
Started requesting public IP:port for socket 1036
MetaServer enabling UDP broadcast for LAN discovery...MetaServer : WAN registration enabled
SUCCESS
MetaServer : LAN registration enabled
Received data from MetaServer : UpdateURL
Socket 1036 identified as public IP 200.55.64.xxx:5010
CLIENT : Disconnected
SERVER : Shutting down...
SERVER : Shut down complete
Disconnected from MetaServer

It was working fine for me earlier, now I'm getting this problem. The only thing that's changed is I've installed drivers for my webcam (Creative Videoblaster 5). I doubt that would have caused it, but it's my next stop.

I'm encountering that problem too. I have Version 1.0 Steam, demo version (thanks to the metaserver snafu) and then full version, and I'm encountering the same inability to do the rolling demo or the tutorial and the popping up of the chatbox when clicking New Game. I'm behind a NAT and have five "network cards", three of which are emulated; port forwarding is on in-game and on the router, and Windows is configured to use the net card attached to the router as its default gateway. Uninstall and reinstall doesn't help, nor does deleting the Preferences file. I haven't tried it with the non-Steam version 1.0 yet but am downloading it as I type. I'm running Windows XP Professional MP Checked, SP2, on an Intel Core Duo, 1GB RAM, ATi Radeon X1900, if any of that matters.

Ive had this problem since install. I am also on a router and for some reason if i walk 4 feet to the PC in the living room this works perfectly..what is going on? i would really like to play the tutorials and the pc before i play against people :p Any help on this would be Greatly appriciated

it would really help my mind out alot if anyone could please at least give me their input to this.. or atleast any ideas to try. Thanks

I am currently debugging this issue, and I believe it is either a high-load issue on the metaserver (in which case, you may just need to wait it out) or it could be NAT problems. Can you guys please tell what brand and model number your router is? Moreover, tell whether or not you have one (for those who haven't specified)?

Can everyone post the contents of their debug.log files?

NeoThermic

I have this same problem at the university I am at, but not home, on the road, or disconnected entirely. Since it was at the campus, and once at the time the network was spotty, I had hoped it was a fluke; however, it never resolved.

This is an odd error, because firstly, when I changed platforms, the bug disappeared (however the WiFi receiver was also different in the area), and secondly, several games I downloaded demos to did not have any such conflict. It fact, the university's wireless is less secure than my house, as far as hosting servers on the network.

We are basically working on this exclusively this weekend and next week, if needed (though I'm not thinking it's needed...... or hope). I'll basically be stepping through the entire handshake routine tomorrow and going from there. I only have one network that does this, and even though I control a section of it, it's still not local.

Apologies, I had actually picked out this bug, but it was the day of the Gold Master. There was no reasonable means of stopping things, nor would it have been advisable

Gomen nasai, everybody. I don't think any other devs/testers (other than myself) had this bug.

Oh, and, as far as I'm reading the logging code, the debug.log probably won't help much, though if you feel compelled to do so, by all means, feel free.

- Miah

Miah Helpmann wrote:Gomen nasai, everybody. I don't think any other devs/testers (other than myself) had this bug.

I had this bug two days before gold (or there abouts), and the only solution I came up with that worked fine was to restart the computer. I was unable to change any settings which would make it work.

NeoThermic

NeoThermic wrote:...and the only solution I came up with that worked fine was to restart the computer.

This would sometimes works, and sometimes not. I am running a dual-boot machine, and when I got into Windows, it was fine, at least for starting Defcon immediatly after boot. Are for my other OS, however, I can *never* get it to work at the campus, but I can *always* make it work at home.

So, I'm fairly certain it's a networking issue.

- Miah

nameghino wrote:CLIENT : Attempting connection to Server at 0.6.0.4:5010...

I expected to see this. The only solution you have now is to reboot your computer, at which the lobby should work fine.

Miah: of course it's a networking issue, the computer always reports the wrong local IP when this failure happens

NeoThermic

Ok, I followed Mr. Thermic's advice, and bang, it worked!

Fan-flippin'-tastic.

NeoThermic wrote:Miah: of course it's a networking issue, the computer always reports the wrong local IP when this failure happens

This is true, but even after I reboot in a certain non-Windows system, it still doesn't work. This could be a fluke to the system in question, or a fluke to the network. In any case, in my condition, as in Nico's (the first poster; he contacted me personally via MSNM), this is 100% repetetive. So there's got to be multiple layers to some of this.

Also, according to Nico, Defcon doesn't fully quit for him. This is possibly related, given the situation.

Ugh, I should sleep... I haven't even eatten yet.

Miah Helpmann wrote:This is true, but even after I reboot in a certain non-Windows system, it still doesn't work. This could be a fluke to the system in question, or a fluke to the network. In any case, in my condition, as in Nico's (the first poster; he contacted me personally via MSNM), this is 100% repetetive. So there's got to be multiple layers to some of this.

My guess, and this is without being able to see the code; you should be more informed to check this, is that because there's no clean exit, defcon doesn't release the socket requests correctly. Since they still exist, the next time it tries to use the sockets, windows tells defcon to bugger off and defcon then manages to pluck out of thin air a random set of numbers (at a thought, could be an error number return code), and use it as an IP. Restarting would fix this if the system in question had no problems freeing the sockets, but if a router or the network deviced holds on to the sockets after a reset, the problem can re-occur.

If none of this is correct, please slap me for spouting crap at 4am

NeoThermic