New OpenBVE Build- Testers Please

MattD6R wrote:With your latest build the program crashes when I view the Route information window. This occurred when I tested it on NWM and also Cheltenham with the error logs of:

Code:

<?xml version="1.0" encoding="UTF-16"?>
-<WERReportMetadata>

-<OSVersionInformation>
<WindowsNTVersion>6.1</WindowsNTVersion>
<Build>7601 Service Pack 1</Build>
<Product>(0x3): Windows 7 Home Premium</Product>
<Edition>HomePremium</Edition>
<BuildString>7601.19045.amd64fre.win7sp1_gdr.151019-1254</BuildString>
<Revision>1130</Revision>
<Flavor>Multiprocessor Free</Flavor>
<Architecture>X64</Architecture>
<LCID>1033</LCID>
</OSVersionInformation>

-<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>OpenBve.exe</Parameter0>
<Parameter1>1.4.17.1412</Parameter1>
<Parameter2>566f5175</Parameter2>
<Parameter3>System.Windows.Forms</Parameter3>
<Parameter4>4.0.30319.34251</Parameter4>
<Parameter5>54daee67</Parameter5>
<Parameter6>afc</Parameter6>
<Parameter7>30</Parameter7>
<Parameter8>VZEVNFUPILSVC31Z3H5GTO45URXFKID3</Parameter8>
</ProblemSignatures>

-<DynamicSignatures>
<Parameter1>6.1.7601.2.1.0.768.3</Parameter1>
<Parameter2>3081</Parameter2>
<Parameter22>0a9e</Parameter22>
<Parameter23>0a9e372d3b4ad19135b953a78882e789</Parameter23>
<Parameter24>0a9e</Parameter24>
<Parameter25>0a9e372d3b4ad19135b953a78882e789</Parameter25>
</DynamicSignatures>


Dump Summary
------------
Dump File: WER93C8.tmp.mdmp : C:\Users\*******\AppData\Local\Temp\WER93C8.tmp.mdmp
Last Write Time: 15/12/2015 12:16:17 PM
Process Name: OpenBve.exe : C:\openbve\openbve_1.4.4.0\OpenBve.exe
Process Architecture: x86
Exception Code: 0xE0434352
Exception Information: 
Heap Information: Not Present
System Information
------------------
OS Version: 6.1.7601
CLR Version(s): 4.0.30319.34209
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
OpenBve.exe C:\openbve\openbve_1.4.4.0\OpenBve.exe 1.4.17.1412
ntdll.dll C:\Windows\SysWOW64\ntdll.dll 6.1.7601.19045
mscoree.dll C:\Windows\System32\mscoree.dll 4.0.40305.0
kernel32.dll C:\Windows\SysWOW64\kernel32.dll 6.1.7601.19045
KERNELBASE.dll C:\Windows\SysWOW64\KERNELBASE.dll 6.1.7601.19045
advapi32.dll C:\Windows\SysWOW64\advapi32.dll 6.1.7601.18939
msvcrt.dll C:\Windows\SysWOW64\msvcrt.dll 7.0.7601.17744
sechost.dll C:\Windows\SysWOW64\sechost.dll 6.1.7601.18869
rpcrt4.dll C:\Windows\SysWOW64\rpcrt4.dll 6.1.7601.19045
sspicli.dll C:\Windows\SysWOW64\sspicli.dll 6.1.7601.19045
CRYPTBASE.dll C:\Windows\SysWOW64\CRYPTBASE.dll 6.1.7601.19045
mscoreei.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll 4.0.30319.34209
shlwapi.dll C:\Windows\SysWOW64\shlwapi.dll 6.1.7601.17514
gdi32.dll C:\Windows\SysWOW64\gdi32.dll 6.1.7601.18898
user32.dll C:\Windows\SysWOW64\user32.dll 6.1.7601.19061
lpk.dll C:\Windows\SysWOW64\lpk.dll 6.1.7601.18985
usp10.dll C:\Windows\SysWOW64\usp10.dll 1.626.7601.19054
imm32.dll C:\Windows\System32\imm32.dll 6.1.7601.17514
msctf.dll C:\Windows\SysWOW64\msctf.dll 6.1.7601.18731
clr.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll 4.0.30319.34209
MSVCR120_CLR0400.dll C:\Windows\System32\MSVCR120_CLR0400.dll 12.0.51720.34280
mscorlib.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\d1265d6159ea876f9d63ea4c1361b587\mscorlib.ni.dll 4.0.30319.34209
ole32.dll C:\Windows\SysWOW64\ole32.dll 6.1.7601.18915
uxtheme.dll C:\Windows\System32\uxtheme.dll 6.1.7600.16385
clrjit.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll 4.0.30319.34209
oleaut32.dll C:\Windows\SysWOW64\oleaut32.dll 6.1.7601.18679
System.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System\d18e2115a3270f89663fce831547f534\System.ni.dll 4.0.30319.34238
System.Drawing.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Drawing\fe41e3eae34ac29f3c1f03a03d8aa1af\System.Drawing.ni.dll 4.0.30319.34270
System.Windows.Forms.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Windows.Forms\ac49b0362a9648df9d2f437d27ff54ff\System.Windows.Forms.ni.dll 4.0.30319.34251
cryptsp.dll C:\Windows\System32\cryptsp.dll 6.1.7601.18741
rsaenh.dll C:\Windows\System32\rsaenh.dll 6.1.7600.16385
RpcRtRemote.dll C:\Windows\System32\RpcRtRemote.dll 6.1.7601.17514
version.dll C:\Windows\System32\version.dll 6.1.7600.16385
nlssorting.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll 4.0.30319.34209
shell32.dll C:\Windows\SysWOW64\shell32.dll 6.1.7601.18952
profapi.dll C:\Windows\SysWOW64\profapi.dll 6.1.7600.16385
opengl32.dll C:\Windows\System32\opengl32.dll 6.1.7600.16385
glu32.dll C:\Windows\System32\glu32.dll 6.1.7600.16385
ddraw.dll C:\Windows\System32\ddraw.dll 6.1.7600.16385
dciman32.dll C:\Windows\System32\dciman32.dll 6.1.7601.18985
setupapi.dll C:\Windows\SysWOW64\setupapi.dll 6.1.7601.17514
cfgmgr32.dll C:\Windows\SysWOW64\cfgmgr32.dll 6.1.7601.17621
devobj.dll C:\Windows\SysWOW64\devobj.dll 6.1.7601.17621
dwmapi.dll C:\Windows\System32\dwmapi.dll 6.1.7601.18917
XINPUT1_3.DLL C:\Windows\System32\XINPUT1_3.DLL 9.18.944.0
comctl32.dll C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18837_none_ec86b8d6858ec0bc\comctl32.dll 5.82.7601.18837
comctl32.dll C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_41e855142bd5705d\comctl32.dll 6.10.7601.18837
GdiPlus.dll C:\Windows\winsxs\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.19061_none_72d6d48d86649709\GdiPlus.dll 6.1.7601.19061
System.Configuration.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Configuration\908075c4922acdf834c67ac802814c9d\System.Configuration.ni.dll 4.0.30319.34209
System.Core.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Core\c61bafa9d029e3f2bf83bd5af3f1f5ac\System.Core.ni.dll 4.0.30319.34209
System.Xml.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Xml\3d6ee4ffbd9a86ac1e7b01800b6fe9c7\System.Xml.ni.dll 4.0.30319.34234
clbcatq.dll C:\Windows\SysWOW64\clbcatq.dll 2001.12.8530.16385
WindowsCodecs.dll C:\Windows\System32\WindowsCodecs.dll 6.2.9200.17251
urlmon.dll C:\Windows\SysWOW64\urlmon.dll 11.0.9600.18124
api-ms-win-downlevel-ole32-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-ole32-l1-1-0.dll 6.2.9200.16492
api-ms-win-downlevel-shlwapi-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-shlwapi-l1-1-0.dll 6.2.9200.16492
api-ms-win-downlevel-advapi32-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-advapi32-l1-1-0.dll 6.2.9200.16492
api-ms-win-downlevel-user32-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-user32-l1-1-0.dll 6.2.9200.16492
api-ms-win-downlevel-version-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-version-l1-1-0.dll 6.2.9200.16492
api-ms-win-downlevel-normaliz-l1-1-0.dll C:\Windows\SysWOW64\api-ms-win-downlevel-normaliz-l1-1-0.dll 6.2.9200.16492
normaliz.dll C:\Windows\SysWOW64\normaliz.dll 6.1.7600.16385
iertutil.dll C:\Windows\SysWOW64\iertutil.dll 11.0.9600.18124
wininet.dll C:\Windows\SysWOW64\wininet.dll 11.0.9600.18124
userenv.dll C:\Windows\SysWOW64\userenv.dll 6.1.7601.17514
secur32.dll C:\Windows\System32\secur32.dll 6.1.7601.19045
api-ms-win-downlevel-advapi32-l2-1-0.dll C:\Windows\System32\api-ms-win-downlevel-advapi32-l2-1-0.dll 6.2.9200.16492
OpenAL32.dll C:\Windows\System32\OpenAL32.dll 6.14.357.24
winmm.dll C:\Windows\System32\winmm.dll 6.1.7601.17514
MMDevAPI.dll C:\Windows\System32\MMDevAPI.dll 6.1.7601.17514
propsys.dll C:\Windows\System32\propsys.dll 7.0.7601.17514
wdmaud.drv C:\Windows\System32\wdmaud.drv 6.1.7601.17514
ksuser.dll C:\Windows\System32\ksuser.dll 6.1.7600.16385
avrt.dll C:\Windows\System32\avrt.dll 6.1.7600.16385
AudioSes.dll C:\Windows\System32\AudioSes.dll 6.1.7601.18741
msacm32.drv C:\Windows\System32\msacm32.drv 6.1.7600.16385
msacm32.dll C:\Windows\System32\msacm32.dll 6.1.7600.16385
midimap.dll C:\Windows\System32\midimap.dll 6.1.7600.16385
dsound.dll C:\Windows\System32\dsound.dll 6.1.7600.16385
powrprof.dll C:\Windows\System32\powrprof.dll 6.1.7600.16385
wrap_oal.dll C:\Windows\System32\wrap_oal.dll 2.2.0.5
atiglpxx.dll C:\Windows\System32\atiglpxx.dll 8.14.1.6099
atioglxx.dll C:\Windows\System32\atioglxx.dll 6.14.10.9704
ws2_32.dll C:\Windows\SysWOW64\ws2_32.dll 6.1.7601.17514
nsi.dll C:\Windows\SysWOW64\nsi.dll 6.1.7600.16385
atigktxx.dll C:\Windows\System32\atigktxx.dll 8.14.1.6099
atiadlxy.dll C:\Windows\System32\atiadlxy.dll 6.14.10.1054
wintrust.dll C:\Windows\SysWOW64\wintrust.dll 6.1.7601.18839
crypt32.dll C:\Windows\SysWOW64\crypt32.dll 6.1.7601.18839
msasn1.dll C:\Windows\SysWOW64\msasn1.dll 6.1.7601.17514
AtsPluginProxy.dll C:\openbve\openbve_1.4.4.0\AtsPluginProxy.dll 0.0.0.0
UKMUt.dll C:\openbve\openbve Route and Train Content\Train\Cl323 3 car Refurb London Midland\UKMUt.dll 0.0.0.0
Accessibility.ni.dll C:\Windows\assembly\NativeImages_v4.0.30319_32\Accessibility\d9ef873b190c9df202c3f9f8a5d38c48\Accessibility.ni.dll 4.0.30319.34209
riched20.dll C:\Windows\System32\riched20.dll 5.31.23.1230
diasymreader.dll C:\Windows\Microsoft.NET\Framework\v4.0.30319\diasymreader.dll 12.0.51209.34209

The program crashes also when jumping between stations/ points of interest using the F3 camera and it appears to happen when near a preceding train on routes that use RunInterval. This happened when tested on Cheltenham. Apart from that the program seems stable though I have only done a short drive on those routes.

Aha, now I've found it

Updating the trains in parallel is causing problems when jumping between stations-
The train index is relative to the camera position, and if the train index changes at the wrong time (Whilst the frame is rendering) all hell breaks loose....

The route information window seems to be exacerbating the symptoms, as it's adding another thread to the workload.
I get the nasty suspicion that on lower powered systems and anything running very heavy .animated stuff this problem may materialize itself without the route information window.

Will post a build that hopefully fixes this properly later today- I'm trying to see whether I can block updates whilst the simulation is updating itself, as well as trying to see if anything else is broken in a similar manner...

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Hmm, I'll have to test joysticks with the Mac VM and see where I get.

The OpenTK docs do suggest that joystick support works better on there with SDL2, but I haven't tried anything at the minute.
I suspect that the default controls resetting is probably something to do with the Mac app package and associated permissions, but I can't obviously see why when I presume that the previous builds were working OK before El Capitan
This really needs the configuration location moving somewhere more sensible (Mac-like ) in the longer term.

Again, will test and get back to you.

Meanwhile:
http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1.4.18.1379.7z

This reverts the trains update code to single-threaded. I managed to get a couple of crashes out of the previous build by jumping between stations 5+ times, and I can't get this build to do that.
Would appreciate those who're seeing this issue more frequently testing though, as I can't reproduce it well enough to be confident this is fixed.

If we confirm that's fixed, I'll see what I can do about a threaded fix

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Will, finally, test tomorrow for the textures. Now my specs, as promised:

Onboard GPU: Intel HD Graphics 4600
Gaming GPU: Nvidia GeForce GTX 860M

leezer3 wrote:Hmm, I'll have to test joysticks with the Mac VM and see where I get.

The OpenTK docs do suggest that joystick support works better on there with SDL2, but I haven't tried anything at the minute.
I suspect that the default controls resetting is probably something to do with the Mac app package and associated permissions, but I can't obviously see why when I presume that the previous builds were working OK before El Capitan
This really needs the configuration location moving somewhere more sensible (Mac-like ) in the longer term.

Again, will test and get back to you.

Thank you so much!!!! The entire museum appreciates your efforts.

Using you latest build I can't get it to crash when jumping stations.

There is a problem with the briefing tab on the route information window. Sometimes the briefing tab is displayed when used on a route that does not use this command. When I click on the briefing tab, the program crashes. It happened on Cheltenham. This happens when no other route is clicked from the recently used list. Also if I select a route using the recently used list that uses the briefing text command (my WIP) and then select a route that doesn't use it (Cheltenham) and then click start, it displays the briefing tab and also the briefing text of that route that uses the briefing command.

Also after I close the route information window and then reopen it, the window is displayed behind the program window.

Hi Chris,
I am one of the Loksim3D developers
It's nice to here that you are working on support of Loksim3D objects. I think this can have positive impact on both of the communities.

If you have any questions or if I can help you in any other way, feel free to contact me!

I didn't read the whole thread, but the questions I saw so far

These are the options regarding transparency:
 TransparencyTypeNone = 0,
 TransparencyTypeBlack = 1,
 TransparencyTypeTopLeftPx = 2,
 TransparencyTypeBmp = 3,
 TransparencyTypeAlphaChannelAll = 4,
 TransparencyTypeAlphaChannelOnlyInvisible = 5

The difference between 4 and 5 is that the texture of objects with transparency option "4" (TransparencyTypeAlphaChannelAll) can have any alpha values. Whereas when "5" (TransparencyTypeAlphaChannelOnlyInvisible) is used, only alpha values "visible" and "invisible" can be used. At the moment these two settings are handled exactly the same in Loksim, but "I have the feeling"  the someday I can introduce some optimizations for objects with TransparencyTypeAlphaChannelOnlyInvisible

Regarding "stock textures" and file structure in general:
There is no real distinction between stock textures and custom ones (at least for some years now). Every Loksim package should contain all files that are needed.
Files can reference any other files (e.g. textures) in the Loksim directory. Paths starting with "/" or "\" are relative to the Loksim3D directory. All other paths are relative to the file that contains the path.

I guess you already figured out that our .l3dpack packages are actually just .zip files, with special encoded Non-ASCII characters in the filenames when necessary.
The PackageManager that installs the packages is open source (github.com/Loksim3D/loksim3d-source). If the encoding of non-ASCII chars is interesting for you: github.com/Loksim3D/loksim3d-source/blob/master/PackageManager/L3dPackageInstaller/PackageFileNameUtils.cpp

Best Regards from Vienna,
Lukas

lukash wrote:Hi Chris,
I am one of the Loksim3D developers
It's nice to here that you are working on support of Loksim3D objects. I think this can have positive impact on both of the communities.

If you have any questions or if I can help you in any other way, feel free to contact me!

I didn't read the whole thread, but the questions I saw so far

These are the options regarding transparency:
 TransparencyTypeNone = 0,
 TransparencyTypeBlack = 1,
 TransparencyTypeTopLeftPx = 2,
 TransparencyTypeBmp = 3,
 TransparencyTypeAlphaChannelAll = 4,
 TransparencyTypeAlphaChannelOnlyInvisible = 5

The difference between 4 and 5 is that the texture of objects with transparency option "4" (TransparencyTypeAlphaChannelAll) can have any alpha values. Whereas when "5" (TransparencyTypeAlphaChannelOnlyInvisible) is used, only alpha values "visible" and "invisible" can be used. At the moment these two settings are handled exactly the same in Loksim, but "I have the feeling"  the someday I can introduce some optimizations for objects with TransparencyTypeAlphaChannelOnlyInvisible

Regarding "stock textures" and file structure in general:
There is no real distinction between stock textures and custom ones (at least for some years now). Every Loksim package should contain all files that are needed.
Files can reference any other files (e.g. textures) in the Loksim directory. Paths starting with "/" or "\" are relative to the Loksim3D directory. All other paths are relative to the file that contains the path.

I guess you already figured out that our .l3dpack packages are actually just .zip files, with special encoded Non-ASCII characters in the filenames when necessary.
The PackageManager that installs the packages is open source (github.com/Loksim3D/loksim3d-source). If the encoding of non-ASCII chars is interesting for you: github.com/Loksim3D/loksim3d-source/blob/master/PackageManager/L3dPackageInstaller/PackageFileNameUtils.cpp

Best Regards from Vienna,
Lukas

'Stock' wasn't perhaps the best word in hindsight, but it seemed a reasonable assumption at the time

Thanks for the transparency values, that's most helpful.
I just need to figure out a decent way to combine a separate alpha channel into a bitmap at load-time. I'm sure it's possible, just need to think about the best way to do it.

Package management is on the list of things I'm going to properly revisit-
Your package format being just a renamed zip file is very similar to something I was playing with months ago, but the difference there was that I tried loading an information XML file/ image from the archive.
This didn't work badly, but in order to utilise the best compression solid format archives (RAR or 7z) are needed, and this then in turn means that you actually have to extract the entire file to get anywhere.

Non ASCII characters have been a problem in BVE for many years, and they're not one that's going to go away any time soon
OpenBVE currently just has a charset selection box for routefiles, and also does a little in the way of attempting to automatically select it.

I'll try and knock up a BVE to Loksim object convertor at some stage (Not sure when, Christmas is coming.....), as the two file formats are so similar.

Matt-
I know what's happening with the briefing- The path to the briefing file isn't being cleared between runs, and this is a relative path. Validation is only performed when the path is first parsed, which in hindsight is obviously a mistake!
Will fix later, along with the activating in the background issue.....


Cheers

Chris Lees

http://www.bvecornwall.co.uk

Wouldn't it be a possibility, to create a "two-layered" archive? The compressed package contents in one archive, and this archive together with the loose XML info file in a second, non-compressed archive serving as nothing more than a container? From my layman point of view this would mean you can access the XML file without unpacking the archive proper, or am I thinking to simple here?

Quork wrote:Wouldn't it be a possibility, to create a "two-layered" archive? The compressed package contents in one archive, and this archive together with the loose XML info file in a second, non-compressed archive serving as nothing more than a container? From my layman point of view this would mean you can access the XML file without unpacking the archive proper, or am I thinking to simple here?

Dunno

That seems an eminently reasonable approach, and those always have unexpected pitfalls.....

I also need to find a good multi-platform extraction solution, and for that matter will need to decide on a method to alter the exact paths used for content storage on each operating system.
These are semi-present at the minute, but basically unused by anyone.

Will let you know when I get this right.....


Cheers

Chris Lees

http://www.bvecornwall.co.uk

Wouldn't it be a possible workaround to pack OpenBVE together with 7zip and call that by arguments for extraction? Since it is GNU licensed and has many command line parameters (at least on Windows there even is a separate executable specifically for command line use), it shouldn't be any problem to use it as an external extraction/packaging module. This way you'd get a throughly tested, easy to handle archive solution without having to look into different file path formats at all. Would also mean you would have more time to take care of the OpenBVE-specific aspects. Maybe it would be possible to create a package management based on and similar to the LokSim3D one? That one is very comfortable, with two very nice functions. One is: Select one or several files (route file, object file, panel file) and all required files are found and packaged. So e.g. it reads in the route file, finds all objects and sounds and images (on OpenBVE also "includes") referenced (on OpenBVE would also need to parse all $rnd commands to all possible values in the file paths to really find everything), opens all objects, finds everything referenced in there as well, and so on, until there are no references to resolve any more. Everything that has been found is then packaged into a zip file (in OpenBVE, assuming the two-layered archive solution would work, it would probably be sensible to create several second layer archives, for each main folder; so at most "Train", "Railway/Object", "Railway/Route", "Railway/Signals" and "Railway/Sound"). The other comfy function is that you can also select an existing archive and have the package manager pack only those files, which aren't in or are newer than those in the existing archive; thus creating a very slim update package, which saves quite a lot of bandwith for users and servers.




And: Welcome to these boards, Lukas, glad you made it here

Sir Chris Lees
I did test your 1.4.18.1379
It is good for me with successful driving many railways and trains

Good day and night for you
Hijau

Rather busy time of year, hence nothing has been really happening for the last week or so

Some observations on your points Quork-

• Calling an external extraction tool is a reasonable solution, but in practice it may not be the most reliable solution outside of Windows.
  
• GPL- That's a nasty can of worms, and one I'd rather avoid if at all possible. It's intent is admirable, but IMHO that's all. (Discussion for another thread.....)
  
• Differences are another nasty can of worms. Additions are no big deal, but deletions and differing files are the bane of any package management system's life.
  

I've got a basic XML database & interface written, and I'm currently playing with extraction using SharpCompress:
https://github.com/adamhathcock/sharpcompress

At present, I think package management won't really be much more than a glorified interface to archive extraction with a little metadata and dependancy management.

There will be a new build in a few days which fixes another bug I've discovered in the original source, and which also adds an option for joysticks not to trigger EB braking
I don't know when (if) packages will be ready, so please don't ask on that front.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3 wrote:There will be a new build in a few days which fixes another bug I've discovered in the original source, and which also adds an option for joysticks not to trigger EB braking
I don't know when (if) packages will be ready, so please don't ask on that front.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Wonderful! Thanks so much for all of your efforts! The NY Transit Museum greatly appreciates your work to update openBVE! 

As you can see here, openBVE is featured as a main program at the museum: 
http://web.mta.info/mta/museum/pdf/Children_Family_Programs.pdf


By the way, did you happen to find a solution to the issues with Windows XP compatibility and joysticks on Macs?

Some progress on the Mac front, but not really working right at the minute-
Joysticks seem to work just fine within a GameWindow context, but nowhere else.

To get joysticks working, you can copy and paste an existing joystick control line into the controls.cfg file. Assigning controls doesn't work full-stop.

I think your previous overwriting problem was caused by copying the *whole* file- The way keyboard assignments are done is different in these builds, and using a file containing any old keyboard assignments will cause the whole configuration to be reset.
Probably ought to change it to upgrade, but doing it that way was easier at the time.....

Haven't yet tested XP.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

As promised, the next build is 1.4.24.804
Changes:

• A new option added to the in-game menu- 'Customize Controls' - This allows Linux users with SDL2 installed and Mac users to customize joystick controls successfully without editing the configuration file, by handling everything within the in-game engine.
  
• Checkbox added to the joysticks panel in the Options page- 'Do not allow EB on brake axis'
  
• An animated object file containing no available states would crash the sim or cause unexpected results. (Issue from Michelle's code)
  
• Unwanted control repeats were being added whilst in the Pause menu.
  

http://www.bvecornwall.co.uk/downloads/beta/OpenBVE_1.4.24.804.7z
http://vps.bvecornwall.co.uk/OpenBVE/OpenBVE_1.4.24.804.7z

The in-game control configuration is a little basic at the minute, but I think it should suffice.
There are also no translations for most of what I've added, these are on the list of things to sort out at some stage

XP is still on the to-test list (Sorry...)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I could translate to German and Polish, and I could try French and Norwegian.

Quork wrote:I could translate to German and Polish, and I could try French and Norwegian.

My French is quite reasonable, although it's more conversational than UI.

Atrocious German, and not much else

Current languages are:

Code:

Spanish (Catalan)
Czech
German (Swiss)
German (German)
English (GB)
English (US)
Finnish
French
Hungarian
Italian
Japanese
Korean
Dutch
Polish
Portuguese (Brazilian)
Portuguese (Portugal)
Romanian
Ukranian
Chinese (China)
Chinese (Hong Kong)
Chinese (Taiwan)

I note that even in these, there's various non-translated strings.

There are some open-source crowd translation sites out there, but exactly how useful these would be for technical phrasing is something I don't know enough about.

It's definitely under consideration.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I guess some would beat me up for this, but IMHO no damage whatsoever would be done by dropping en-US and de-CH translations from the new version. British English and American English vary noticeably in spoken language, but I doubt there is any problem in understanding written BE. Swiss and "normal" German vary way more when spoken, but funny enough even way less in writing. While BE and AE orthography (and even grammar) does have some distinct differences, the difference between German and Swiss German boils down to the latter ones writing 'ss' where otherwise 'ß' would be written. Other than that, Germany, Austria and Switzerland actively work together to prohibit any divergence.

Wonderful! Thank you so much! I will try out on Mac tonight.

Hoping for a working XP version soon! We have a couple of computers at the museum that run XP and can't be updated. The more computers we can put the program on, the better.

I'll keep taking care of the Hungarian localisation, as always.

I have just re-installed Windows 7 64-bit and the program crashes at startup. Are there some fundamental dependencies that may be missing. It works ok on my laptop with the same OS.

The crash dump leaves three files in the appdata folder. Would there be clues in there to the problem?

Thanks.

Hello Chris.

Great job with the program, you are fixing many things that were broken in the last "official" OpenBVE version. As an add-on developer I cannot be happier, thank you! I use Ubuntu 15.10 as my main OS, so I will try my best to tell you about any bugs I find.

Also, I was the Catalan translator of the previous versions of OpenBVE, and you can count on me if you need to translate new strings. I could also work on the Spanish translation if necessary (I have native knowledge of the language).

Regards from Barcelona,

Marc

ecreek wrote:I have just re-installed Windows 7 64-bit and the program crashes at startup. Are there some fundamental dependencies that may be missing. It works ok on my laptop with the same OS.

The crash dump leaves three files in the appdata folder. Would there be clues in there to the problem?

Thanks.

Please upload them somewhere, and I'll take a look

The most interesting one should hopefully be a .mdump , but all three will tell me something.

No promises, but if we can find out what's crashing then that's half the battle.


The only thing I can suggest off the top of my head at the moment is to try disabling completely any antivirus you've got running for a test-
There are two people who've had Avast blocking this.
A clean install of Windows 7 should run work by default though- I've tested in a fresh Windows 7 x64 Hungarian VM with no additional software installed sucessfully, so this is just a little frustrating!

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris,
Here are the files -

[url=https://www.dropbox.com/s/yk6aehz3yvrhhpb/OpenBVE crash]https://www.dropbox.com/s/yk6aehz3yvrhhpb/OpenBVE%20crash%20dump.zip?dl=0[/url]

Thanks,
Michael

ecreek wrote:Chris,
Here are the files -

[url=https://www.dropbox.com/s/yk6aehz3yvrhhpb/OpenBVE crash]https://www.dropbox.com/s/yk6aehz3yvrhhpb/OpenBVE%20crash%20dump.zip?dl=0[/url]

Thanks,
Michael

You're missing OpenAL

https://sites.google.com/site/openbvesim/openAL%20Installer.zip?attredirects=0&d=1

(Not my OpenAL link, but still)

I'm sure that ought to be handled, or at the least a more graceful error message, will have to investigate with a machine without AL installed on it.

Cheers

Chris Lees

http://www.bvecornwall.co.uk