Відео

Thank you! Trains are relatively straight forward. The tricky part is figuring out the signals and how to set them up. For the most part the Block Signal is the one you will be using the most, to create individual blocks of track where trains can stop and wait. Our bridge blueprint is 5 foundations long, so we tend to run track pieces 10 foundations at a time and I generally try to have about 4 bridge pieces between each block signal. That seems to work fine for the trains we're using (4 cars). The Path Signal is only used with junctions. Bitz made a video about a year ago explaining the signals and how to use them - link: ua-cam.com/video/Be7m7hY51zg/v-deo.html

It's a team effort - thank you so much :)

I generally make use of Path.Combine() when dealing with paths, however for this series I deliberately chose to go old-school with most implementations, to show-case how things are done when nifty convenience libraries are not available. In my opinion becoming overly dependent on libraries to do simple things for us, causes developers to become trapped by the libraries they depend on, to a point where they can't continue their development process if a dependency library is suddenly not available. Show-casing how things can be implemented through manual means that are not dependent on a library, also provides the knowledge of how it's actually done by said library. This also has the effect of granting sufficient knowledge to implement similar methods in different languages that may not have a nifty library like System.IO's Path.Combine() available. Once the core knowledge is in place about how things are or can be implemented, library independent, then nitfy time saving libraries can replace the "back-to-basics" ways of implementing things. One key thing to note about Path.Combine() is that it's implementation differs depending which version of the .Net framework you use. In some versions, Path.Combine() only accepts 2 parameters at a time and in more recent versions the argument listing has been changed to accept a params array of path parts, making code written under newer versions of .Net incompatible with older versions, when making use of Path.Combine()

@@SharidanDK I absolutely agree about core coding knowledge. A brain is the first instrument for development. I just wanted to mention a problem which could be caused by a programmer's fault: if someone forgets to add "/" or adds an extra "/" (it will probably happen when somewhere exist values which would be concatenated in the future, i.e. "minecraftVersionsFolderPath=folder; minecraftVersionFileName=file", the string will concat with something like "folder1folder2/folder3//folder4filename". And to prevent that, the code should somehow handle this situation.

It has been a while since I did these streams, so I don't exactly recall which part(s) I go through the steps of launching a process in this project. The project source code is available on GitHub and you'll need to look in ServerHost.cs under CSharpLibs/Minecraft - line 504 to 518: github.com/Sharidan/MinecraftServerLauncher/blob/f57d22df05a6370724ae684430357ad0421c53dc/MinecraftServerLauncher/CSharpLibs/Minecraft/ServerHost.cs#L504 The Process and ProcessInfo classes in the System.Diagnostics namespace, allow you to launch any process / application, provided you specify the correct parameters and paths for everything. In this project, the assumption is that Java is installed and that you have downloaded the Jar for the specific Minecraft version you want to run. Since this project is a server launcher, the server Jar is assumed downloaded, but you can just as easily launch the game client - it's just a different Jar afterall. You could copy/paste the section of code I've mentioned, modify the parameters to match and stuff it into a regular button. The additional code in ServerHost.cs is there to capture and handle the output that comes from the executing Jar - what typically goes into the console. If there is no need for your project to process that console output, you can leave out that part of the code. The Process class on MSDN: docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=net-5.0

I didn't upload the sourcecode until a bit further into the project. If I recall correctly, the GitHub repo should be in the description in part 4 and onwards, though I would recommend that you follow along anyway, as these streams were intended to teach the code and expose the thinking behind the design of the code. Please also note, that the code in this project was written with the intent to teach code basics - not to show how it can be done the most efficient or compact way. Had I written this project without the need to teach, I would most likely have written it differently, more efficient and more compact, but the cost of doing that is that the code gets harder to read and understand. Feel free to see how I did it here, but keep in mind that there are other ways of achieving the same results.

I'm glad you found value in this, thank you! :)

@@SharidanDK All thanks goes to you really. I am watching your video second by second and doing what you are teaching us. Again, huge thank you for this really.

Glad you like them :) Just keep in mind, that while writing code, there are 1000 different ways to solve the same task or problem. What I showed in these videos is just my chosen approach, but also my thinking behind the choices I made.

Glad you find it useful :)

There is a link to the project's GitHub repository in the description. I usually update the repo right after every streaming session or the day after.