View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001770 | FSSCP | FS2NetD | public | 2008-09-20 02:04 | 2008-10-05 13:33 |
| Reporter | FUBAR-BDHR | Assigned To | taylor | ||
| Priority | normal | Severity | trivial | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.9 | ||||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001770: Couple of minor standalone / FS2netD login problems | ||||
| Description | Well I created a new account for my standalone servers but in doing so hit ran into a couple of glitches. Lumping them in this one report since they are so trivial and all probably related. First: If you go into the game and change the login settings for PXO via F2 but do not log into FS2netD with the new player the settings will save but the standalone will either not pick them up or not log in because the player hasn't been created under the account. Second: If PXO is off the standalone will still run and connect to FS2netD. Noticed this when I went in to change the login info. One of the servers had it turned off but ran without any errors. Third: A standalone will run and connect to FS2netD even if there are invalid multi.cfg and fs2open_pxo.cfg files present. This seems to be a new problem and I only noticed it when trying to do a regular login to FS2netD lobby to solve the first issue. | ||||
| Additional Information | This was with Kara's TeamChatBuild.7z build. | ||||
| Tags | No tags attached. | ||||
|
|
I'll take a look at 1, but I was under the impression that such a situation should be handled by the code whether it was standalone or not. It could just be a bug in some special handling of standalone stuff in the fs2netd client code though. If so then it should be pretty simple to track down. For 2, I'll give it a look, but I'm sure that it was working the last time I messed around with standalone. Not sure if it just got broken since then or whether my previous test cases simply weren't enough to catch the problem. For 3, fs2open_pxo.cfg is no longer used in newer builds, so it doesn't really matter whether it's invalid or not. Depending on what sort of "invalid" you've got for the multi.cfg however, the code will attempt to apply default values if needed. Define how it's invalid and I'll be able to tell you if the code is automatically fixing it or not. |
|
|
It still had my old PXO settings for standalone servers including the IP address and lobby 20 stuff. I caught it from the multi.log showing the wrong IP address trying to be connected to. Apparently some of the builds ignored these settings at least for regular play as I was able to login to the lobby previously with the same machine. Is the mulit.cfg file even necessary anymore? |
|
|
Most Xt builds did ignore the multi.cfg settings, so that may be what you are remembering. Once the code hit SVN that part was removed though, and all of the builds should use multi.cfg. And yes, multi.cfg is needed now. It actually wasn't before but it is with the new FS2NetD code. We couldn't use fs2open_pxo.cfg since a new format and new information was needed, and there was no point in comping up with yet another cfg file that basically just replicated everything in multi.cfg, so I just reused it. The file can be missing and the game will still work (it will use the defaults), but if it's there then it will be used. |
|
|
For 1, I have yet to recreate this issue. Can you give me some more details on exactly what you are doing, whether you have multiple servers running at the time, etc? For 2, I haven't been able to recreate this condition with multiple tests. I also noticed that you said "One of the servers had it turned off...", so does that mean that you were running two instances at the same time? The PXO setting is global, so I'm thinking that this just might be a problem with your test case or usage rather than a code bug. For 3, Haven't been able to recreate this one either. Were you using a mod with the standalone? The multi.cfg file used is mod specific, so my best guess is simply that you had two or more cfgs and the one standalone was using had correct values. |
|
|
For the first one all I did was create a new PXO account (BDHR-Standalone). I then proceeded to go into the command deck or whatever you call the menu area. I hit F2 and changed the PXO login and password to the new BDHR-Standalone one and applied the changes. When I exited an launched the standalone it would not connect. I went back into the game and this time into the lobby. When I entered the lobby it said pilot created. I exited the game and tried the standalone again and it would now connect. So it looked as if the login info wouldn't work until after the pilot created message. The second one was on one of 2 machines. Both run standalones on separate DSL lines but on the same LAN. One had PXO flag turned off but still showed up on FS2netD. I don't know how long that flag has been turned off but the standalone has been showing up on FS2netD all along even when the other machine wasn't running a standalone. I actually had an old multi.cfg file from the PXO days in the data folder. It did have the PXO settings including IP address. Has been in there since I put FS2 on that machine. I probably still have it on my old machine if you need to see the file. Not sure about the mod part. I don't think I was at this point. I did add the MediaVPs to one of the machines but I'm not sure when. |
|
2008-10-01 20:40
|
|
|
|
Pretty sure that is the multi.cfg I had in there. |
|
|
On the first, that's pretty much exactly what I did during my test and it worked fine. I checked the code just in case my test was the problem, but the code looks sound. It doesn't differentiate between standalone and the regular game when logging into the server so just as part of the basic login process it should have created the pilot regardless of how you ran the game. I'm making some changes to give some more verbose status reporting to standalone, so see if you can reproduce the results with a different pilot and we'll see whether it works and a new build is available with the changes (I'll let you know), and if not, what sorts of messages it's giving. So for the second you are running the standalones on two separate computers, correct? Are the two machines configured differently, running a different OS, or anything like that? On the machine that's messing up, use regedit to verify that PXO is actually disabled in the registry. It defaults to disabled, and there really isn't a way that it would enable itself without changing the setting on the options screen (F2), so there must be some reason that the PXO flag is getting set in-game, and that is only via the registry setting. For number three, that multi.cfg is basically what I was testing with and it refused to connect. If you can replicate it with a current build and without using a mod then let me know. Otherwise I think that I'm just going to chalk it up to a bad build or possibly just mod related. |
|
|
Can't check the other two right now but for the second one the machines are identical except for the vid card. I probably disabled PXO at some point to do some testing and just forgot to enable it. Just seemed weird that it was showing up on FS2netD with it turned off. I can try it again tomorrow. |
|
|
Please try and replicate these problems with this build: http://icculus.org/~taylor/fso/testing/multi_test.rar |
|
|
Looks like all three of these are working now. Tried the BDHR-Standalone account on a computer it was never used on before. With PXO off the server didn't show up on FS2netD. With it on it did. Invalid multi.cfg returned a connection failed message and didn't show up on FS2netD. This build even pulled up my old multi.cfg servername setting. Only one thing that might be a minor issue if anyone ever even encounters it. With PXO turned off the standalone didn't try to access the network at all. (I didn't get the standard FS2_Open wants to connect to the trusted zone firewall message) Why anyone would want a standalone on a LAN I don't know but it might not work. So I don't think it's an issue just thought I'd note it just in case anyone ever tries it. |
|
|
Ignore that part about the standalone not trying to connect to the LAN. It would accept connections not connect. It asking before was probably another symptom of it trying to connect to PXO with the flag off. Everything should be fine. |
|
|
Hate to actually mark this as "fixed" without knowing exactly what did it, but there isn't a "fixed, but no friggin idea what did it" option for resolution. :) Fixered. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-09-20 02:04 | FUBAR-BDHR | New Issue | |
| 2008-09-20 04:45 | taylor | Note Added: 0009696 | |
| 2008-09-20 04:45 | taylor | Status | new => assigned |
| 2008-09-20 04:45 | taylor | Assigned To | => taylor |
| 2008-09-20 05:03 | FUBAR-BDHR | Note Added: 0009697 | |
| 2008-09-20 05:05 | FUBAR-BDHR | Note Edited: 0009697 | |
| 2008-09-20 12:11 | taylor | Note Added: 0009699 | |
| 2008-10-01 00:00 | taylor | Note Added: 0009751 | |
| 2008-10-01 19:31 | FUBAR-BDHR | Note Added: 0009758 | |
| 2008-10-01 20:40 | FUBAR-BDHR | File Added: multi.cfg | |
| 2008-10-01 20:41 | FUBAR-BDHR | Note Added: 0009759 | |
| 2008-10-02 01:21 | taylor | Note Added: 0009762 | |
| 2008-10-02 01:27 | FUBAR-BDHR | Note Added: 0009763 | |
| 2008-10-04 12:39 | taylor | Note Added: 0009795 | |
| 2008-10-05 03:36 | FUBAR-BDHR | Note Added: 0009810 | |
| 2008-10-05 03:39 | FUBAR-BDHR | Note Edited: 0009810 | |
| 2008-10-05 04:07 | FUBAR-BDHR | Note Added: 0009813 | |
| 2008-10-05 13:33 | taylor | Status | assigned => resolved |
| 2008-10-05 13:33 | taylor | Fixed in Version | => 3.6.10 |
| 2008-10-05 13:33 | taylor | Resolution | open => fixed |
| 2008-10-05 13:33 | taylor | Note Added: 0009816 |
