Railworks America

So I hear a lot about "Core Game" issues. Where are the files? I see RailSimulatorCore but it doesn't contain core steam or diesel files or a core simulation file. Anyone have an idea where these core files are?

oops please move to appropriate subject

Two different concepts with the name "Core".
1- "Core game" is the game program itself (railworks.exe and assorted libraries). DTG compiles it from the source code they own, which is the direct descendant of the original Kuju Rail Simulator.

All the files that you can create or modify (blueprints, models, textures, physics curves, lua scripts, routes, scenarios, etc.) are data files that the core game uses for making its calculations and rendering the 3D world on your screen. Outside of that you can't change core functions. For example, you can't change the gravity constant that the core game uses for calculating physics, and you can't change the formulas either.

2- Assets/Kuju/RailSimulatorCore is a folder containing data files that are not specific to either European or US content. Possibly named that way because they are mostly used by the core program and have little significance to content builders.

Chacal wrote:Two different concepts with the name "Core".
1- "Core game" is the game program itself (railworks.exe and assorted libraries). DTG compiles it from the source code they own, which is the direct descendant of the original Kuju Rail Simulator.

All the files that you can create or modify (blueprints, models, textures, physics curves, lua scripts, routes, scenarios, etc.) are data files that the core game uses for making its calculations and rendering the 3D world on your screen. Outside of that you can't change core functions. For example, you can't change the gravity constant that the core game uses for calculating physics, and you can't change the formulas either.

2- Assets/Kuju/RailSimulatorCore is a folder containing data files that are not specific to either European or US content. Possibly named that way because they are mostly used by the core program and have little significance to content builders.

That's exactly what I need to know Chacal. Thank you

AFAIK, the whole of Railworks' core is contained in gamemanager.dll in the plugins folder. Rendering, physics, artificial intelligence, it all comes from this .dll file.
Railworks.exe, Utilities.exe just wrap themselves around gamemanager.dll
There are a few support .dll files that handle the on screen menus, hardware like gamepad, RailDriver and other human interfaces, as well as interfaces to your computer's hardware like video card, sound card, etc.

The source code to gamemanager.dll is the Holy Grail of Railworks and its best kept secret. Hopefully DTG knows it inside out by heart.

_o_OOOO_oo-Kanawha wrote:The source code to gamemanager.dll is the Holy Grail of Railworks and its best kept secret. Hopefully DTG knows it inside out by heart.

So they should have fixed it by now lol

JohnS wrote:

_o_OOOO_oo-Kanawha wrote:The source code to gamemanager.dll is the Holy Grail of Railworks and its best kept secret. Hopefully DTG knows it inside out by heart.

So they should have fixed it by now lol

Fixed what?

Well everybody keeps saying " it's a core game issue" so I guess that's what I was getting at. It works though so I understand don't touch if it's not broke.

JohnS wrote:Well everybody keeps saying " it's a core game issue" so I guess that's what I was getting at. It works though so I understand don't touch if it's not broke.

Trains are mostly ruled by Newtonian physics, power, mass, acceleration, gravity, resistance, etc.

While concentrating on the difficult stuff, simple stuff is often overlooked or neglected or broken by accident. Like EQ reservoir pressure being right in a single locomotive and wrong when that locomotive is coupled to another. Probably some simple arithmetic error made in oversight while trying to implement something more complicated like realistic braking.

A 70 plus megabytes gamemanager.dll is the result of a compilation of 10000's lines of code. Take a look at the Open Rails source code and you'll get the idea. OR is modular so perhaps easier to manage.

If you are really clever and determined, you can program an Open Railworks alternative of gamemanager.dll or adapt the OR source code to work with Railworks assets.

We can only wait and hope for better in the next generation of Railworks on the UE4 platform. I doubt DTG will start from a blank sheet, probably lots of the present code will be ported over to the new game engine.

The part that gets me is the EQ reservoir thing is because the core game has it set to "Apply to Consist(eTrue)". If you look at the manual this option will add or propagate whatever has eTrue in that line option to the entire consist. That's why one engine fine but the more you add the number goes off the chart. I do know that the core game can actually be rewritten when loading with a Lua (out) file present. It will look to that file and fill in the blanks with the core game files. That has already been proven with the FEF and what I have done to the K4. I don't know enough about Lua except for trial and error but it is still all possible.

Operative words being" but it is still all possible." Instead of complaining about the 'core' we should be exploring how to manipulate the game. My bride who is a IT person often says give her enough time she can get any program to do anything. i rarely have a clue what she is talking about but I see the results all the time.

JohnS wrote:The part that gets me is the EQ reservoir thing is because the core game has it set to "Apply to Consist(eTrue)". If you look at the manual this option will add or propagate whatever has eTrue in that line option to the entire consist. That's why one engine fine but the more you add the number goes off the chart. I do know that the core game can actually be rewritten when loading with a Lua (out) file present. It will look to that file and fill in the blanks with the core game files. That has already been proven with the FEF and what I have done to the K4. I don't know enough about Lua except for trial and error but it is still all possible.

I don't think that is true, re: eq pressures being added up through the use of <ApplyToConsist>. <ApplyToConsist> is being used to have the same control value being displayed in all locomotives in a consist, i.e. all windshield wipers on/off, all step lights, etc. Unless overridden by an engine script, like in most of the current 'advanced' locomotives.
I thought I was being clever by setting the <CabLights> switch to <ApplyToConsisit>eTrue, so I could darken the cabs of all SH ES44AC's at the flick of one switch. But alas, the CabLights are scripted, initialised to on and don't listen to <ApplyToConsist> anymore. You have to hop into every cab and flick the switch to darken it.
You gain one, you loose one, all because of the presumption by DTG that XBox players don't like dark locomotive cabs and there is no button on their controllers to control the cab light.

buzz456 wrote:Operative words being" but it is still all possible." Instead of complaining about the 'core' we should be exploring how to manipulate the game. My bride who is a IT person often says give her enough time she can get any program to do anything. i rarely have a clue what she is talking about but I see the results all the time.

I like to tinker with this digital stuff. The only slow down is the fact that the Lua files are now converted to out format. I can't manipulate them like Lua files. The whole thing would have to be rewritten. Now if somebody knows Lua and wants to make a joint effort I'm in. I went to school for IT many years ago. I still will do a lot of IT stuff to stay sharp but I'm way behind in the Technology now. Hats off to your wife. She sounds like an awesome women.

_o_OOOO_oo-Kanawha wrote:

JohnS wrote:The part that gets me is the EQ reservoir thing is because the core game has it set to "Apply to Consist(eTrue)". If you look at the manual this option will add or propagate whatever has eTrue in that line option to the entire consist. That's why one engine fine but the more you add the number goes off the chart. I do know that the core game can actually be rewritten when loading with a Lua (out) file present. It will look to that file and fill in the blanks with the core game files. That has already been proven with the FEF and what I have done to the K4. I don't know enough about Lua except for trial and error but it is still all possible.

I don't think that is true, re: eq pressures being added up through the use of <ApplyToConsist>. <ApplyToConsist> is being used to have the same control value being displayed in all locomotives in a consist, i.e. all windshield wipers on/off, all step lights, etc. Unless overridden by an engine script, like in most of the current 'advanced' locomotives.
I thought I was being clever by setting the <CabLights> switch to <ApplyToConsisit>eTrue, so I could darken the cabs of all SH ES44AC's at the flick of one switch. But alas, the CabLights are scripted, initialised to on and don't listen to <ApplyToConsist> anymore. You have to hop into every cab and flick the switch to darken it.
You gain one, you loose one, all because of the presumption by DTG that XBox players don't like dark locomotive cabs and there is no button on their controllers to control the cab light.

So with that said Engine only brake should be set to eTrue then? So like in real life when MU'd together all brakes in a locomotive consist should apply.

JohnS wrote:

_o_OOOO_oo-Kanawha wrote:

JohnS wrote:The part that gets me is the EQ reservoir thing is because the core game has it set to "Apply to Consist(eTrue)". If you look at the manual this option will add or propagate whatever has eTrue in that line option to the entire consist. That's why one engine fine but the more you add the number goes off the chart. I do know that the core game can actually be rewritten when loading with a Lua (out) file present. It will look to that file and fill in the blanks with the core game files. That has already been proven with the FEF and what I have done to the K4. I don't know enough about Lua except for trial and error but it is still all possible.

I don't think that is true, re: eq pressures being added up through the use of <ApplyToConsist>. <ApplyToConsist> is being used to have the same control value being displayed in all locomotives in a consist, i.e. all windshield wipers on/off, all step lights, etc. Unless overridden by an engine script, like in most of the current 'advanced' locomotives.
I thought I was being clever by setting the <CabLights> switch to <ApplyToConsisit>eTrue, so I could darken the cabs of all SH ES44AC's at the flick of one switch. But alas, the CabLights are scripted, initialised to on and don't listen to <ApplyToConsist> anymore. You have to hop into every cab and flick the switch to darken it.
You gain one, you loose one, all because of the presumption by DTG that XBox players don't like dark locomotive cabs and there is no button on their controllers to control the cab light.

So with that said Engine only brake should be set to eTrue then? So like in real life when MU'd together all brakes in a locomotive consist should apply.

I don't think that will work either. Here, the game engine takes care of that. I believe it propagates the leading locomotive's brake blueprint along the consist to all the other locomotives, or just adds the braking power of all locomotives together and uses that in the first (notice how slack runs in between the engines lashed up at the head of the train, while there should hardly be any delay between them when actuating the brakes).
You can set <ApplyToConsist> to true on the brake handles, and you'll notice that the brake handles in the lashed up locomotives now move along with the lead engine (or at least the one marked in red on the F4 HUD which you control). Experiment some, and find out what works and what is purely cosmetic.