The International Simutrans Forum


Recent Posts

Pages: [1] 2 3 4 ... 10
Thank you very much for this - reviewing the code, I see that this is a very substantial amount of work. I have now committed this, and a further commit removing redundant instances of CACHE_TRANSIT so that accidentally defining this does not cause incorrect behaviour.

These changes should appear in to-morrow's nightly build.
Slow to this but hope you’re settling in well - you’re now not that far from one of my cousins in North Carolina so you never know I might be over in Virginia at some point...
A longer bath of changes this time, covering a period from May 7 to Oct 12 2014.

The main things of note are:
There were changes relating to the pakselector in Standard that I only partly ported because Bernd Gabriel rewrote the selector for Extended back in 2013. Since I don't think there are any differences to the functionality requirements, this seems like an example of a change that (in my opinion) shouldn't have been made only in Extended (cf. Code Quality thread).

I have reverted an accidental overwrite of readme.txt (in the repository root) with a file relating to help texts. I have also now added an initial section relating to Simutrans Extended.

I have also added a commit applying the translation of komp->comp to the OTRP code.
Bug Reports / Re: slow midi initialisation
« Last post by kierongreen on Today at 04:48:07 PM »
Indeed - think of the different directories more as a sound effect / music separation than one to do with particular format. I still remember being amazed when computers became fast enough to just about playback MIDI in software (using 100% CPU and rather low quality sound libraries)...
Patches & Projects / Re: Transplanting OTRP feature for standard
« Last post by kierongreen on Today at 04:42:57 PM »
Has that branch been stabilised yet in terms of reliability, consistency and multiplayer?
Patches & Projects / Re: Priority signals
« Last post by prissi on Today at 03:28:02 PM »
If one touches the signal system, I am getting warm to Leartins idea. However, to avoid trains stopping in the middle of nowhere, one just to make sure the next trains has a reservation through the next signal as long as its length in tiles, and only drive forward then. If there is not enough space for the first to reserve, or rather trigger a reservation attempt of the train ahead. (and recursively so). The downside is that trains may stop for a split second at full speed waiting for a logn cascade (or slow down, if they need to trigger a cascade). Also this szstem woudl require more resources the more trains are running without sginals, and some signals would be still required at some point.
Patches & Projects / Re: Transplanting OTRP feature for standard
« Last post by prissi on Today at 03:19:11 PM »
My main dislike is that the oneway road is a massive thing just for streets, while I would rather like something like a more general wayobj. This would link the directions with clear visual signs at intersections, and would furthermore also be more incentive to realise multiple wayobj on one tile. Furthermore, such single wayobj would work on any way, including airstrips.
Patches & Projects / Transplanting OTRP feature for standard
« Last post by HyperSim on Today at 02:21:13 PM »
Hello, everyone.

This is derived from THLeaderH's One-way Two-lane Road Patch thread.,16659.0.html

One-way Two-lane Road Patch (OTRP) is a very interesting patch but it's too complicated to introduce in standard.
However, I think part of feature of that patch, building one-way road without any sign and "Halt Mode", is worth integrating.
So, I rearranged OTRP with standard overtaking rules.

You can get .diff file based on r8555 from this URL.
Here's my github repository.
Patches & Projects / Re: Priority signals
« Last post by gauthier on Today at 10:49:13 AM »
I"m sorry, I did not consider about playing from books indeed. You're right that the help text is not very clear and even confusing about presignals. I'm not sure that expecting them to work like a particular signal from reality was a good thing in the first place.
If I understood you well, the main concern here is the risk of confusion between a signal in the game and a signal in reality, isn't it ? Its hard to get a name that fully describes the behaviour of a signal, and imho it's not here for that. The recursion is still a key feature of the priority signal and I (or you) may take care of writing its documentation so the same confusion as presignals would be avoided.
Patches & Projects / Re: Priority signals
« Last post by Ters on Today at 09:42:56 AM »
There is a third way: Rather than knowing or experimenting, you do things by the book. I learned to play Simutrans from a tutorial PDF that at least used to be available on the Simutrans site. Then I built upon the knowledge I learned from that to do more complex stuff. I never really experimented, at least with signals.

The pre-signal is particularly nasty, because:
  • The name and looks (in pak64 at least) indicates to someone familiar with German signals that it is a distant signal (Vorsignal), but it works nothing like them. The priority signal is in fact much more like a distant signal, except for this recursion thing.
  • It does not behave like the documentation says it does.
The behavior of the choose signal and long-block signals, which were completely alien signal types to me and for which I had no preconception of how they operated, was fortunately adequately documented. However, this forum has seen a fair share of beginners who were utterly confused as to the workings of the choose signal. They have pretty much disappeared, which I think was because choose signals were changed to act like a normal signal if it hit another signal before it reached the current destination station.

For instance, if I put a new signal called "foobar signal" with complicated graphics, are you going to use it instead of normal signals and expecting them to magically work the same way ?
No, but I did not expect priority signals to work like normal signals either. In fact, I got it backwards! I expected priority signals to be one-off signals, like choose signals (and how I use pre-signals), but they are actually meant to be used like normal signals in the sense that you put several in a row.

Furthermore, a "foobar" signal with complicated graphics carries no preconceptions of how they work (unless, perhaps, one is familiar with the MIT model railroad). Something called a priority signal does. The name alone suggest priority at the upcoming junction, which is a feature asked from from time to time. That the train waiting a the priority signal would always get green before trains waiting at other signals guarding the same block. The description quickly dispelled that misconception, for me, but I never expected that the priority signal, or the pre-signals, were hogging signals. That is an attribute I would rather have expected from the signal call long-block signal. (Which actually doesn't hog, but it only gives green if it could have. I can only assume that the reason this doesn't cause more confusion, is because most players don't even think of trying it without guidance.)
Pages: [1] 2 3 4 ... 10