The fix then was removing "\Core" from the "start in" line. No need to take the space out of "rFactor2 Dedicated.exe", that only leads to not being able to start it from the launcher anymore. Well, anyone is free to do, whatever they want to do. I just wanted to share my experiences. Why does the working dir have to be the rFactor2 installation folder and not Core for example? Quite simple, really. The Launcher is started from that root folder, which means its working dir is that one. It starts the respective applications by executing their .exe files residing in the Core folder, so these inherit the environment of the Launcher, which includes the working directory. Starting those programs directly, outside the Launcher, means one has changed dir (cd) into the Core folder, which in turn makes it the working directory, unless one explicity sets it differently. Removing "Core" from the "Start in" field of the shortcut properties is basically the same as running from the launcher. Anyway, I think I might make starting Core programs from outside the Launcher a new Wiki article then. That Wiki article about running multiple profiles is a work in progress. I will add some more info, especially on caveats, which were the reason for ISI to recommend using multiple installations. Of course I´d rather have ISI staff provide such information in an official documentation, but that is likely not at the top of their priority list, especially if there is still quite some change from one version to the next which might render such info obsolete. About the IP address as a parameter, it does not seem to have any effect. Just tried to use it to make the server bind to another IP, didn´t work. But it does not do any harm either, I guess, it is simply ignored as an unknown parameter. FWIW, +profile also seems to have no effect unless combined with +oneclick. Best regards, Marcus
Thanks Marcus, that first part of the quote is what was causing the problem in our case, the 2nd part the solution to it.
@Diablo, Just a question. In the way you describe to host multiple servers, how do you keep the apart? When the server window is running, I really can't tell which server is set up, with wich server profile? Obviously, using the same profile twice results in non-reachable servers, so I am kinda curious how you are doing this. I have to say, the new mod manager is a big improvement, and also the fact that finally the data.path file is working appropriatly, is a great improvement as well. I am still using seperate instances for the seperate servers, as I find thats working better for me. I do not have to be "cautious" with disk space, so a few gigs in disk size extra is no problem. I start the dedicated servers via the .exe file directly (as explained above with the removal of the /core from the Start in line), and it works very well. It's been stable so far, with no disconnections or hangups. I also did not experience the drop offs from the matchmaker service, or the disappering from the list in the multiplayer, so it seems all is working very well so far. Lets hope we will not run into any newly introduced issues.
Well, I do need to remember which is which basically. But I have different server names assigned to the different profiles. Since that server name is always shown in the status window, it is not too hard to distinguish one from the other. I just need to make sure, that I don´t change those names. As for server crashes or falling off the matchmaker, that happened to our servers just like everybody else´s, I guess. The matchmaker issue was fixed with build 146, but that fix might have introduced a bug which seemingly caused crashes to happen more often. Even before that build there was the occasional crash, maybe not as often. But maybe falling off the matchmaker just caused the servers to get restarted before they could crash, and that bug was there, somewhat hidden, all along, I don´t know. Cheers, Marcus
I see. I have made a wish for the profile name to be listed in the server window in build 49 or 60 I believe, so people like me (who support a large community with multiple servers running all kind of different combinations) can use 1 install as well. Uptill now, this is not implemented yet unfortunately. Which leaves me in the situation that I must use different installs, or instances, of the dedicted server to keep track of which server is running which combi. When you have multiple persons maintaining a server, you can't trust on remember which is which Server crashes have happend to me almost never before. Dropoffs where very limited as well. With build 146, it was horrible. Now, it seems fixed again. Lets hope it stays that way
That screenshot showed me something I did not except For my multi server setup I just use the full installer and install both core and a data to same directory. I do not install data inside core to void using path=".." on the command line. The reason we do this is that Windows no longer allows you to right to program files. As such the core location is read only the data directory will default to the a windows users read/write space. For a vast majority of people using the installer -- this is ideal. The data.path file key to this separation If you data.path does not point to the data location the simulation will not start as it is unaware of any assets. In this case the ambient sounds are not being detected. The default location of you installed core and data to same location is ".\" in the data.path. I personally did not change any of this from 146 to 156 but if the update blew away a data.path file that may be possible. Or another developer dabbled in this code that I am not aware of, however, I think the latter is unlikely.
Hi Jeremy, I can say that the Data.path file did change, it now says \Core after the rFactor2 install location... Unusual as I have been installing and setting up the mods / components the same way each time, now this time it adds an extra \Core in the path.. I decided to remove this path in the line to see what happens, the server starts but doesn't find any profile, nor mods etc installed. So the extra \Core is obviously now needed (no biggy).. On another note however, which is why some of us had issues early on.. If you shortcut the rFactor2 Dedicated.exe, the Start in: has your install path \rFactor2\Core. Diablo had mentioned to remove the \Core from the Start in: which now makes our shortcuts work.. Something has changed from 146 to 156. It's something people need to be aware of when short cutting their dedi.exe file, unless you guys can work out something..
I have run 3 instances next to each other, all up for around 48 hours now, without any drops. You sure it's not a local issue JB (not saying it is, just asking ) ? Servers have had joins, leaves, restarts, idle time and everything. I do have to say that I use seperate installs, and not seperate profiles, 1 install.
I think that´s because you changed that manually via the Launcher: FWIW, Jeremy, as far as I have seen, the data.path, by default, contains the absolute path to the Data location one chose during installation. I usually install both the "Core Destination Folder" and "Data and Settings Destination Folder" to the same directory and my data.path contains that same path in explicit form (d:\Program Files (x86)\rFactor2), not as ".\". I just did another test installation and chose to seperate both locations and its data.path contains the absolute path to the seprate Data location, as expected. By the way, I was able to reproduce the original error message now: I used a clean installation - wheter it uses one and the same directory for "Core Destination" and "Data Destination" or seperate directories doesn´t matter. Just to check I started the Dedicated server with Core\ as working directory, and as expected it output the error message "No mods installed". I installed a mod into the "Data Destination" (content of data.path) and tried again. Still the same error message. I uninstalled the mod again. Then I opened ModMgr.exe directly from within "Core\", so the working dir is the very same one for the application, but that does not seem to matter anymore anyway. I set The "Working Dir" (this is different from the working dir of the application!) in the lower right of the Mod Manager to <rFactor 2 root folder>\Core, which was the default behaviour of the previous Mod Manager version, when it was started with Core\ as working directory (double clicking the exe inside that one causes that). This way I installed the same mod again to the Core\ folder this time. It created the Installed and Manifests folders there. Now starting the dedicated server from within Core\ results in the error message of the OP. The funny thing is, that when I start the server from the Launcher, it greets me with the profile and Mod selection, even though there is no content to be found in the "Data Destination". Two things, I think about this. First, naming that option in the Mod Manager "Working Dir" was not the best choice, since it creates confusion, "Mod destination dir" or something like that would be a better naming choice in my opinion. Second, the dedicated server shows some strange/inconsistent behaviour. Installing mods to the correct location (data.path) but starting the dedicated server with the wrong working directory results in it not finding anything. Using the Launcher or running it with the correct working directory, which is "Core Destination Folder" chosen during installation, results in it finding the components and starting fine. Installing mods/components to Core\, a location that is not supposed to hold such data, results in the dedicated server running fine, when started from the Launcher, which is odd, because it should only use content installed where the data.path says it should be. Running the dedicated server directly with the wrong working dir and content in the wrong place as well, results in the error message in the OP. I think the dedicated server should strictly enforce the location pointed to by data.path to avoid having such problems in the future. Had it not worked prior to this update, like it did for all the users, who had this problem after installing build 156, they would have known something is wrong and would have fixed it a long time ago. I also don´t like that the Mod Manager now uses some arbritrary "Working Dir" setting, which stays the same across multiple installations, unless one is really careful and double checks it every time it is run. That´s out of sync with data.path and is an error waiting to happen. It should simply use what data.path says where Data belongs for that particular installation. Best regards, Marcus
Marco: We to install in separate named directories re: rf2servers#1 rf2servers#2 They all pull from one master directory: C:\Users\Administrator\Documents\rFactor2 I create 1-4 desktop icons for each dedicated, and rename: rf2servers#1 rf2servers#2 rf2servers#3 I do the same for the Modmanager: Modmanager #1 Modmanager #2 and so on. I then make sure when each server is launched, the infinity is set 1 dedicated per core. I know the above way takes a little more to update, but in the same way, you can have 1 or 2 mods installed per running exe and the tracks. I haven't heard from our folks any issues about drops. or performance issues this way. this way is also the way we have installed our servers from day one. Oh and I also create a link to each core shortcut to the desktop, and rename them accordingly. Dave
@Marcus, I disagree on the mod manager issue you mention. The way it is now, so with the selectable working path (which I do agree has a strange name), I can use 1 mod manager, maintain multiple installs. (please mind, multiple installs, not multiple profiles). For the average user (read client side), it doesnt matter anyway, as they most likely will never change it. They have 1 install, so the mod manager always points to the same location. This is a huge improvement IMO. I do however agree with the strict use of the DATA.PATH file. Not only the dedicated server, but all .exe's that use the data location should look at that file, to find the local path. 1 thing I do not like to have (spoken as a programmer), is using relative paths, which are defined in different places, or even overruled by hard-coded settings. I believe it is still possible to install all content in the CORE section, and start stuff from there, with the data.path file pointing to somewhere else. Would have to test that to be sure though. @Dave, As said above, use a single mod manager. There is no need anymore to have all the seperate mod managers linked to the desktop. Further, I have just about the same. However, I have not set any afinity to a single core, per server. As performance wise, the machine is no where near it's maximum, I did not find that needed for now. I also have prio's set to normal, also when loading a new track. Works fine for the hardware I use.
I don´t know exactly what you mean, by "pull" but I guess from the path, that all installations share the same Data Path? That´s basically quite similar to running multiple profiles, if not even the same, since they also share the UserData folder then.
Alright I can see your point there. But at least the "working dir" should default to the respective data.path setting of that particular installation then. I also think that should be an "advanced" option, since as you said, normal (client) users will have little use for that option anyway. So I propose, we should have a toggle for advanced options, if it is off, they are hidden to not tempt inexperienced users. Edit: FWIW, I would like complete profile separation even better. That way one would not need multiple installations in the first place. I find the latter solution harder to maintain and it creates redundancies.
We (that is, Jim Beam and I) always ran the ModMgr and Dedicated exes directly (either actually direct, or shortcuts with the same target and working ("Start In:") folders). To cover recent history: - In build 134, the server was dropping off the matchmaker sometimes very often, while continuing to display "Server updating successfully". - In build 146, the server would sometimes drop off the matchmaker, display a message indicating it had lost connection, then crash. - In build 146+ (test .exe from Jeremy), the server continued to sometimes drop off matchmaker, usually displaying a message saying so. When attempting to Exit to restart the "Shutting down server" message wouldn't go away; the process had to be killed manually. Usually it was only using 14MB of memory at that point, though sometimes 170ish. With this same test version I tried a completely clean install on another user account on the server box and ran it completely default with a single standard ISI mod installed (the F2s I think), with the only change being the port settings. This fell off the list as well. We knew a new build wasn't far off so waited to see what happened. Now Build 156: as above JB had issues running the server using the 'direct run' method which it seems was never the right way to go about things. So we've now got a fresh install, data.path points to the data folder from installation, running both the ModMgr and Dedicated exes via shortcuts that set the 'Start In:' folder to the main folder from installation (the one that contains 'Core' and 'Plugins' folders). Both the mod manager and the dedicated server install and run fine. But it's still dropping off the matchmaker list. So my question right now is: is anyone else getting this? If not it seems likely something we're doing... so just trying to work that out to start with
Marcus, As long as there is no identifier to see which instance is running, or which profile is running, other then the location mentioned in the top bar, I have no other option then using multiple instances.
I'm not 100% sure yet about this, but I've been starting our servers by using the launcher until a two days ago, when I tryed the "shortcut method" above explained to start the dedicateds. Since then, and already happen 2 times in 2 days, all of our servers dropped from matchmaker, and also hanged like you described when trying to close them, had to kill them with the task manager. ATM they are all started with the launcher, and no issues since then. PD: none of our 4 servers are configured to "freeze" (Pause While Zero Players="0").
