Site Redesign & a New Release

This is v1.3 Alpha 9:
http://www.bvecornwall.co.uk/downloads/beta/TrackGen_alpha139.7z

Two important changes for this version:
1. TrackGen will now accept and convert any image format supported by C# on Windows natively. ( http://msdn.microsoft.com/en-us/library/system.drawing.imaging.imageformat%28v=vs.110%29.aspx )
2. Created files may now be found in the 'Output' subdirectory. Your selected textures will be copied as appropriate

Cheers

Chris Lees

http://www.bvecornwall.co.uk

As promised, Trackgen 1.4 is now the current stable release.
Changes:
1. Fixes a crash if an input texture was missing (You are now notified and generation continues)
2. Fixes a crash if the output folder was missing on rail generation.
3. German translation is now there on the main labels. I've left the 'Choose a new texture' bits in English at the moment, as my German isn't good enough to translate these to something I'm happy with.

http://www.bvecornwall.co.uk/downloads/utilities/TrackGen_140.7z

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Several people have requested this, so this is a highly alpha version of TrackGen which allows for variable rail widths.
This works reasonably well for both narrow and broad gauges, however has several issues, which are going to require a little more re-writing.

Issues at present:
* Texture issues when using large deviations inside the far end of the point. This is because TrackGen tiles the sleepers texture into the gap here. Fixing this will require slightly different sleepers textures and modification of the rail chairs.
* No validation of input values (Still)- This becomes an issue when using broad gauges, as you have to remember to add sufficient deviation.
* Point motor and platforms aren't currently moved for the new gauge.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

This is a rather improved version of TrackGen with variable gauges:
Changes:

1. Variable gauge option added. This works down to ~50cm in narrow gauge, and pretty much infinitely in broad gauge.
   
2. The way the frog infill works has been re-written. This means that using larger deviations between your tracks will now look much better!
   
3. Texture picking for platform fences fixed.
   

Notes & Current Limitations:

• The grass side isn’t built onto the two sides inside the frog- The code for this is next on the re-write list, as the texture size and mapping is pretty nasty.
  
• Remember to alter the proportions of your sleepers texture to the gauge you’re using.
  
• The check rails stay in the same relative position to the main rails, no matter the gauge. This is probably correct (Or at least visually reasonably accurate) for narrow gauges, I’d need more data on broad gauges to make a proper decision there
  
• No input validation- If the total deviation between your tracks is not great enough then some odd results will ensue.
  
• The dummy point motor isn’t currently moved, again it’s on the list of things to do…..
  
• The check rails stay in the same relative position to the main rails, no matter the gauge. This is probably correct (Or at least visually reasonably accurate) for narrow gauges, I’d need more data on broad gauges to make a proper decision there
  
• Platforms aren't currently moved for the new gauge.
  

http://www.bvecornwall.co.uk/downloads/beta/TrackGen_150_alpha2.zip


Cheers

Chris Lees

http://www.bvecornwall.co.uk

hi chris. tried to download trackgen but google say it is a maliciuos file, any ideas.cheers jckhinks (jack )

Short answer- Use a different browser.

Long answer- Some AVs have decided to pickup OS_ATS as a virus, and appear to have been for some time. Google has picked up on this and plastered on these warnings.
I'm attempting to get the false positives remedied, but this may take a little while.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Re OS_ATS,  I had similar problems when I released my 1st gen DMUs. It seems there are a couple of OS_ATS release variants that have been showing as false positives with various AV programs for a long time as Chris said, however, I managed to find a version which seems to be ok with the vast majority of AV software at present. My 1st gen DMUs all have this version now which should not register as a virus, so just copy said file from any of my DMUs if required for any other application.

I did try that, but the steam functions are broken somewhere :p
I also can't get the source for 1.3 to work at the moment (I built the version I'm using myself, it's a very slightly modified version); It compiles after a lot of work, but doesn't seem to be talking to OpenBVE.

I've succeeded in getting Commodo to remove OS_ATS, and I'm chasing various other AV vendors; It's definitely achiveable, and I'd rather get the false positive fixed.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

hi chris did what you suggested and downloaded trackgen using a different browser. off to try it.best regards jack

I'm using the beta 1.5.0 to construct some 1600 gauge trackwork (Irish standard gauge).
It's looking promising. It's useful to be able to work with other gauges. The textures will need editing in all probability for anythin other than 1435mm - which the supplied textures are designed for. Using a supplied texture as a template and working in photoshop layers, it was not too difficult to manipulate some photos I took from an overbridge last Thursday of some actual Irish track and produced sleepers and ballast.

Version 1.5 Alpha 6
Changes:
* Railtop texture is correctly written out for left rail.
* Texture picking for the railtop texture implemented.
* Platforms are now moved when an alternative gauge is selected.

Source code is also now on GitHub:
https://github.com/leezer3/TrackGen

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Chris, thanks for your work on TrackGen.

However, I have a problem. I was trying to make a switch where the player's rail turns right and the diverging rail stays straight. It didn't work, I got an object with missing pieces. Here is a picture of it. If the diverging track's value is higher than the player's track's value there is no problem. What am I doing wrong?

This happens on both 1.4 and 1.5 alpha 6 versions.

Another funny thing was this:

For the first one, You need to work out how much the diverging track diverges from the player rail at the end (Even though it is straight) and input it into the boxx

I was going to keep it 0 so that the direction of travel would be towards the right.

phontanka wrote:Chris, thanks for your work on TrackGen.

However, I have a problem. I was trying to make a switch where the player's rail turns right and the diverging rail stays straight. It didn't work, I got an object with missing pieces. Here is a picture of it. If the diverging track's value is higher than the player's track's value there is no problem. What am I doing wrong?

This happens on both 1.4 and 1.5 alpha 6 versions.

You want Rail 0's divergance to be 2m, and the secondary rail's divergance to be -2m for that to work
If the player's track is curved, then the secondary track's divergance should never be zero.

Wandering back to page 1:
Direction of travel works a little differently with TrackGen, but simple enough- You just need to know what Rail 0 is doing.

For example-
A standard 25m right-hand switch.
* To travel along the left branch, set Radius/ divergence of Rail 0 to 0m, and divergence of secondary rail to 2m
* To travel along the right branch, set Radius/ divergence of Rail 0 to 2m and divergence of secondary rail to -2m
In essence, if Rail 0 is placed to the right of the secondary rail, you need to subtract the distance from which it is offset from the divergence of the secondary rail. This isn't particularly user friendly, and I will look into fixing this

Let me know if this makes your head hurt
It's on my (long) list of things to fix, but when I last thought about it seriously, it was a whole bunch of work to rewrite the function in question and I never got round to it.....
(Whilst I could just perform the above internally in the app, it's a horrible hack, as everything is converted internally to radii and then has all sorts of fun performed on it)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Oops, OK. I even read your post earlier. I forgot to subtract that distance. It works like a charm now. Thanks a lot!

Version 1.5 Alpha 7.
Changes:
* Sleepers/ ballast infill were messed up on left-handed switches.

That should be the second one fixed
I was comparing against values calculated for a right-handed switch when building the ballast infill on left-handed switches.

Let me know if you find anything else!

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I've downloaded Alpha 7. I have a hard time running it, it won't always load from Explorer by double clicking the file and it won't run at all from the Windows 8.1 start screen. When I succeeded running it, it didn't produce a csv file for me. Then I tried it on another computer with Windows 7, the program started and produced a CSV file. However, the problem with left switches I mentioned in my previous post still exists.

The version information in the Properties dialogue says it is version 1.5.3, not 1.5.7.



One more thing I noticed: when I create a switch, all the texture files are copied to the Output/Tracks folder except the WeichAntrieb.png, I had to copy this file manually. This is on versions 1.4, 1.5.6 and 1.5.7 (have not tested it on older versions).

Sorry, didn't apply the release configuration before pressing build....

Trying again with Alpha 8
This fixes WeichAntrieb.png not being moved for good measure.

I can't reproduce any issues starting either build from Explorer or the start screen though- Win8.1 x64
My first thought would be that you've stored it somewhere Windows doesn't like- 8.1 can be fussy if it decides an app isn't starting from somewhere it doesn't like.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

OK, problem with the left switches fixed and I have no problem starting Alpha 8.

One more thing I have noticed is that when I create a left switch where the direction of travel is the left the point motor is rotated to the left as well (see screenshot).

It's keying off the primary track, and getting the angle from there.

I've added it to the list of things to look at, but it's a longer term project. (It's the same principle as the divergance issue, and will probably require the whole function re-writing to figure out if one track is straight and calculate from that..)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Is there any way to create track objects over 25m in length to prevent gaps appearing as seen above?

Sorry if this has already been covered.

Adam

Ouch, that's pretty nasty, although I'm not sure that -200m radius curves are necessarily prototypical except in pointwork

Short answer is not at the minute- Using the ScaleAll command in the completed .csv object will get you what you want to some extent, and the gaps ought to be basically invisible above approx 350m radius.

Added to the list of things I need to seriously get to, but again it requires rewriting some of the fundamental transform functions....

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3 wrote:Ouch, that's pretty nasty, although I'm not sure that -200m radius curves are necessarily prototypical except in pointwork

Short answer is not at the minute- Using the ScaleAll command in the completed .csv object will get you what you want to some extent, and the gaps ought to be basically invisible above approx 350m radius.

Added to the list of things I need to seriously get to, but again it requires rewriting some of the fundamental transform functions....

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Excellent work so far though, really good.

I've tweeked the curve to be -500m, gaps are a lot less noticeable.