Why Simutrans sucks

[ojii]

First of all, simutrans doesn't really suck, it is however not perfect either. So I thought I'd give my feedback on what for me are the most annoying things about simutrans. Please see this as constructive criticism to improve simutrans, and despite me only pointing out the bad things here, simutrans is still great.

So here it goes, the list:

Performance

This is my by far biggest problem with simutrans. Playing on a 512x512 map (pak128.japan) with my very powerful laptop (Intel i7 820M CPU, 4(+4) core@2.3GHz, 16 GB DDR3 RAM@1600MHz, Nvidia GeForce GTX 560M 1.5GB GDDR5) on Ubuntu (11.10, 64bit) I get 10 FPS at max, and the UI is still not responsive (eg moving around the map hardly works), if I increase the maxfps setting to 50, the game becomes completely unplayable and trying to move around the map is next to impossible. Now note that the same laptop and same OS can run 3D games such as Heroes of Newerth at almost maxed out settings in full HD with no problems, getting around 70 FPS. Discussing this a  bit on IRC resulted in everyone telling me to use Windows, which is not an option. In the meantime I play the game in a super small window which makes the performance almost okay. Note that it feels like the latest release, 110, decreased the performance even more.


Silly Schedules

Make any line with any vehicle in simutrans, add a second vehicle. If you leave this running for a while the second vehicle will be right after the first one, resulting in a highly unprofitable second vehicle and possibly overcrowded station. I know there's "minimum load", but that might make sense for goods, but not for passenger lines. In real life, there's no trains that wait till they're "n% full", they wait until a certain time and then depart. That time is usually chosen, so there's an equal (or another economically sane) interval between two vehicles. So rather than having load limits, why not make the vehicles try to keep an equal distance between each other? If one tries to implement this using signals (only possible for rail, not for road vehicles), the train will "leave" the station (as in stop loading) and then wait for the next free block, instead of letting people board until it can depart. This whole scheduling issue made me just not use road vehicles at all in simutrans and make weird unrealistic things with rail signals to get somewhat profitable lines.


Airports

Airports in simutrans have one big problem I see, and that's scalability. It's impossible to scale an airport beyond two runways without completely separating two runway/terminal systems, since planes will always land on the same runway (even if that one is in use and another free one is available) and start from the same (again, same logic as before). Using waypoints and oneway signs, it is possible to change this, but that involves crazy micromanagament and is hard to keep track of what runway is used how much. Rather, an airport should schedule departures and arrivals using the runways it has available, just like in real life. (I actually have an idea how to do this programatically, but will keep this out of this thread and maybe post it in another one if anyone even is interested in this). So again, I hardly use airports because of those issues.


Multiplayer

Again, absolutely horrific performance. Making new lines or building stuff is horribly laggy, regardless of server/client performance or internet connection. Again I was told to use Windows (I start to wonder whether simutrans should just abandon it's linux support).

Further, why does simutrans not save my last server (or ideally all servers) I've connected to? I've played in moblet's game #3 but since it wasn't in the server list I had to type the full URL + port every time. With random disconnects/crashes, that's really annoying.

Also I found it quite weird how one's supposed to communicate with other players. First of all, why is there no way to see who else is online? It tells me that "n clients are connected" but not who those "n clients" are. In the playerlist it should show an icon "online" or "offline". The chat system could really need some improvements. For example some way to reference points on the map (eg "@Cityname" or "@271,3511" turning into clickable bits of text to jump to that location) and maybe direct messaging to other players, rather than globally.


UI/UX/Misc

There's a couple of things that annoy me in the user interface and user experience. One I described here regarding the ability to make trainsets to be reused as templates for convoys.

Another annoying thing is that it's really hard to estimate how much a certain project (eg connecting city A and city B with a rail line) will cost,and thus it's hard to know if I can afford that line right now or whether beginning construction of it will bankrupt me. So ideally there would be some sort of 'planning/sandbox' mode in which you can build a line (including landscaping) without actually building it, but it will tell you the costs for the whole project. Now it would be very nice if one could hit a "build it" button after that, but that's not needed to make this feature useful.


Approachability of codebase

So since this is an OSS project, probably the first response I'll get to this is "it's open source, stop complaining and fix it". Well there's a problem with that, and that's the codebase and it's approachability. I'm a programmer, so obviously my first reaction was "ok let's see if I can fix any of those issues". So I headed over to http://simutrans.com/development.htm to see how I should get started. Well turns out that the full 3 sentences about how to actually contribute code, doesn't say anything and only links to a wiki page telling me how to compile it, and a subforum. No "these are the code styles you should use, this is how we want you to submit patches, ...".

Further as far as I can see, there is no bugtracker other than the forums, so I cannot find "low hanging fruit" to work on to get to know the project. Overall I do not get a sense from the project that it's even interested in getting new developers, which I would hope not to be the case.


I'm sure I could come up with more problems, but I'll leave it at this for now.

[Dwachs]

Great post!

As to performance: can you please upload this savegame? along with pak necessary to load it?

As to Multiplayer: when doing stuff in network games there is a lot of latency to be considered: time to sent to server, server has to schedule your command, that all clients execute it at the same in-game time, server sends back to your computer. if the server is physically located on another continent, then these latencies become quite noticeable.

As to Approachability of codebase: I do not get what is wrong. You can obtain the code, browse it online etc. The whole interaction community <-> developers happens in this forum here, the subforum you mentioned.

"low hanging fruit" ... why not start with one of your complaints? for instance this multiplayer chat/online/offline status/remember last server stuff sounds like "low-hanging". I would be more than happy to provide you some start-up help etc.

[jamespetts]

Interesting and useful post - constructive criticism is always worthwhile! May I ask - have you tried Experimental? There are features in Experimental that deal with your "silly schedules" issue quite effectively.

As to the accessibility of the codebase, Experimental uses Git (Github repository here). A list of projects on which assistance is sought, with a brief description of each, can be found here. I did think of using a bug tracker at some point, but the feedback that I had at the time suggested that it was easier to use the forums.

I'd very much like to get more people involved in coding for Experimental - do you have any suggestions as to how to make it easier to get involved (for example, suggestions as to particular bug tracker tools and how to manage them, e.g., who should be allowed access to them, etc.)?

Edit: As to performance, I strongly suspect that much of the issue is related to the inherent complexity of the simulation and cannot be made any better without removing highly valuable features.

[Severous]

I cant help one jot on coding/performance stuff as I play without any knowledge of code.

- smaller map?. Long narrow map might retain game scale feeling whilst reducing system requirements?
- I micro manage most my games but if i want regular vehicle spacing I use wait for max time setting. Overlooked it for ages.

[Carl]

Silly Schedules

Make any line with any vehicle in simutrans, add a second vehicle. If you leave this running for a while the second vehicle will be right after the first one, resulting in a highly unprofitable second vehicle and possibly overcrowded station. I know there's "minimum load", but that might make sense for goods, but not for passenger lines. In real life, there's no trains that wait till they're "n% full", they wait until a certain time and then depart. That time is usually chosen, so there's an equal (or another economically sane) interval between two vehicles. So rather than having load limits, why not make the vehicles try to keep an equal distance between each other? If one tries to implement this using signals (only possible for rail, not for road vehicles), the train will "leave" the station (as in stop loading) and then wait for the next free block, instead of letting people board until it can depart. This whole scheduling issue made me just not use road vehicles at all in simutrans and make weird unrealistic things with rail signals to get somewhat profitable lines.

While this is very, very irritating, it's also quite realistic. This happens all the time with road transport.

However, Experimental's "convoy spacing" feature allows one to avoid this problem to some extent. You can progam a line so that convoys only leave the starting station every X minutes, thus ensuring a gap between services. This works more or less like a dream.


I'm a little surprised to hear of your performance troubles. I have a much less impressive setup, and I only get problems with huge maps (3000x3000) with several thousand convoys. And when I'm dealing with maps that big, I expect a performance hit!

[VS]

Large viewport = atrocious performance. Size of map is nowhere as important, at least until late game.

[japa86]

I also have the same problem with performance: large window = poor fps. I also have Ubuntu.

[Ters]

It's been a while since I played Simutrans on Linux now, but I remember sluggish behavior initially. At some point things got better and I could finally play with a full screen window (a not so impressive 1152x864) at 20 fps. I don't think anything changed in Simutrans, but that it happened when I upgraded the graphics driver or something like that. It's possible that the driver or whatever was more optimized for issuing 3D rendering commands used in modern games rather than the old style rendering used in Simutrans. A much better performance on Windows makes me believe that it is not primarily Simutrans' fault. (The fact that I insist on compiling Simutrans as a 64 bit executable for my Linux machine, while my Windows executable is 32 bit, might also be a contributing factor.)

[prissi]

performance
The Linux performance is in now way different form windows. Some problem might be compiling as 64 bit binary, which makes simutrans (and a lot of other programs) slower.

Simutrans is not a first person shooter. On a straight tracks the smallest space a vehicle moves is two pixel in horizontal direction. Running simutrans with 15 frames per second is still smooth, compared to 3D games. Anything beyond 25 frames per second is overkill. (OpenTTD run with fixed 20 fps if memory saves me right.)

(A 3D adapter may only help to render simutrans 16 bit per pixel screen to wqhater resolution is on the screen However this depends entirely on SDL or allegro. Maybe try allegro, it usually gives more fps on windows than SDL.)

Actually I can play it easily on 1280*1024 with my onboard graphics in the virtual PC with Ubuntu 8.04. Also my old Athlon XP 1.6 GHz single threaded was not the limit. But as said before, do not exceed 25 fps, it is meaningless for a 2D isometric engine.

Multiplayer
performance is same on Windows and Linux. There is no OS specific times etc. in there. And Unlike games for multiplayer only, every simutrans client has to execute the same command locally. Thus to ensure the slowest client can cope with it, the default buffer is rather conservative.

Also a player is not connected to a slot, he can change the slot freely. So you cannot show, which player is actually connected on which slot, since even the server does not know about it. You could show which player executed commands in the five minutes or so. But feel free to dig through the code and change this.

Cost estimates
You can drag a rail connection and see the cost. Just do not built it.

Codebase
When you download the codebase, there is a folder documentation. It contains what you requested, especially code styles. (But this is like the in-game help - maybe I am too old school to look at stuff for te minutes before complaining.)

Silly schedules
This game is about transporting. If your convois bunch, the one of them is not full (otherwise it would not be faster.) Then minimum load with a short waiting time (like 1/4 day=1/128th month) would cure this.

Airports
Air transport is difficult to integrate into a transport simulator like simutrans (or OpenTTD). Air do not need any maintenance, has small size vehicles (so full load is not too difficult) and one does not even need a way to built. This is one of the main reasons the airports have not been improved. It would shift balance even more to airplanes. (In OpenTTD airplanes are by fair the most income generating mode of transport. An AI only doing air will never get bankrupt there.)

[Severous]

Cost estimates
You can drag a rail connection and see the cost. Just do not built it.
......
Airports
..... In OpenTTD airplanes are by fair the most income generating mode of transport. An AI only doing air will never get bankrupt there.)

Cost estimating as you describe is very useful, not exact but good enough.

In TTD/Locomotion AI using Aircraft go bankrupt when the station catchment area contains no buildings so the cargos were no longer demanded. Demolish the buildings

[jamespetts]

Hmm - can't aircraft simply have a higher maintenance and capital cost? I suppose that the fixed monthly cost in Experimental can help here.

[isidoro]

Maybe a much larger time to load and unload airplanes would make them less attractive, specially for short distance travel, as in real life...

[Ashley]

Multiplayer

Again, absolutely horrific performance. Making new lines or building stuff is horribly laggy, regardless of server/client performance or internet connection. Again I was told to use Windows (I start to wonder whether simutrans should just abandon it's linux support).

Have you replicated this lag running a server locally on the same machine and connecting to it? Have you raised a bug report with your findings?

Further, why does simutrans not save my last server (or ideally all servers) I've connected to? I've played in moblet's game #3 but since it wasn't in the server list I had to type the full URL + port every time. With random disconnects/crashes, that's really annoying.

Moblet's server is running an older version which isn't using the new listings server yet. When I have time I'll switch it over. Changing the game so it stores user-entered server entries would be trivial and I'm surprised you haven't posted this in extension requests?

Also I found it quite weird how one's supposed to communicate with other players. First of all, why is there no way to see who else is online? It tells me that "n clients are connected" but not who those "n clients" are. In the playerlist it should show an icon "online" or "offline". The chat system could really need some improvements. For example some way to reference points on the map (eg "@Cityname" or "@271,3511" turning into clickable bits of text to jump to that location) and maybe direct messaging to other players, rather than globally.

Multiplayer is very new in Simutrans terms and definitely lacks polish. Currently the concept of a player isn't very well defined, it's simply someone who has connected to the server (and new connections default to the "human" player - which I by convention turn into a "spectator" instead on my servers) and has picked a free player slot. Since new connected clients are free to switch between player slots there isn't a very good clear distinction between clients and players.

I'd suggest fixing this by allowing a connecting client to specify a username which would uniquely identify your client. This could be displayed on a connected clients screen next to whichever player slot that client happened currently to be controlling. Similarly these client handles could be used in the chat window, e.g. if your handle was "ojii" and you were currently playing as player 3, a chat message could be:

ojii (Player 3): Hello!

Clickable map references by coordinate shouldn't be too hard to do, indeed it'd probably be best to automatically include one with the current viewport location of the player with every message. A simple parser could then look for text of the form pos:XXX,YYY and include a link.

Direct messaging to players is also a logical extension to the chat system. There are lots of little tweaks which could improve in-game chat, but these are mostly candy (and require manipulation of the UI, which I have barely touched so far in Simutrans).

Please do raise extension requests, you have half a chance of one getting implemented by a developer. Starting a rant about why Simutrans sucks is not a good way to go about getting someone to listen to you.

[stmaker]

Quite a review.. it help the developers to improve the game.

[jamespetts]

Timothy's ideas are very good ones. As to Isidoro's suggestion: this is already implemented (and customisable) in Experimental.

[ӔO]

Under windows, performance is excellent, no matter what the window size is until a program that uses video overlay is run. I'm guessing the poor performance under linux might have something to do with how the game displays the graphics.

I can run simutrans at 25 to 30fps with 1920x1080, with only a C2D 2.13Ghz, 3GB ram and AMD HD5770.
actually, I can't seem to get simutrans to stutter anymore, unless I run about 2600 convoys, which means CPU limited.

edit: actually, the 10fps might be because simuconf.tab is set to that. It's possible to change this to 25fps while playing by going to 'new game > settings > frames_per_second'


Scheduling
There's game called A-train by artdink, and it handles schedules in a drastically different manner. It allows for a full timetable/diagram for each train, but the destination of each train is determined by how the switches in the track are set. The merit is that you can schedule commuter, regional and express trains all on the same set of tracks without them getting stuck behind slower trains and you can also make realistic single tracks. The downside, is that it's very time consuming, it's easy to accidentally cause a jam by sending a train down the wrong set of tracks and it's not beginner friendly. Actually, coming off of simutrans, the scheduling was ridiculously difficult in comparison.

There is a demo for a-train 8 if you want to see what it's like to play. The videos on youtube don't quite show the complexity of setting up schedules, but they do show what it's capable of.

[ojii]

As to performance: can you please upload this savegame? along with pak necessary to load it?

As this happens with *any* game I start regardless of pakset, size or settings, I don't see how this is helpful.

As to Approachability of codebase: I do not get what is wrong. You can obtain the code, browse it online etc. The whole interaction community <-> developers happens in this forum here, the subforum you mentioned.

Well for one, it doesn't help that the code is mixed German and English. Also it doesn't help that half the things in there seem to be named "dings xyz" (thing xyz). But maybe I'm just spoiled by generally nicely readable code coming from the Python world...

Interesting and useful post - constructive criticism is always worthwhile! May I ask - have you tried Experimental? There are features in Experimental that deal with your "silly schedules" issue quite effectively.

I did, but to my understanding most Experimental features only kick in with Experimental enabled paksets, and I'm not a huge fan of the british pakset (no offense to the authors of it).

I'd very much like to get more people involved in coding for Experimental - do you have any suggestions as to how to make it easier to get involved (for example, suggestions as to particular bug tracker tools and how to manage them, e.g., who should be allowed access to them, etc.)?

Being the maintainer of a fairly largeish open source project myself, yes I do:

• Use a bug tracker and tag stuff as 'low hanging fruit' (the name is not important, but something that indicates that someone unfamiliar with the project/codebase could work on this)
• I found IRC to be amazing to get people involved, since the barrier is usually lower to ask a question there as opposed to the forums. This of course means that one has to be there all the time (although not necessarily actively) and it can tend to use up quite a lot of your precious time. I found it to be worth it over time though.
• Have somewhere easily accessible a little "howto" for newcomers to the codebase. Where are the important bits? What are things one should keep in mind? What are the coding style guides for the project? What is the preferred format of contributions (seems to be patch uploads to the forums here)?

That's what I can think of from the top of my head, should I come up with more I'll tell you.

While this is very, very irritating, it's also quite realistic. This happens all the time with road transport.

I beg to differ. At least here in Switzerland busses normally aren't all just after each other and then non for an hour. They're usually running at fairly regular intervals.

Large viewport = atrocious performance. Size of map is nowhere as important, at least until late game.

This might be an issue, as I'm using 1920x1080 screen resolution. But making the viewport smaller makes it just not nice to work with since the UI get's all messy.

A much better performance on Windows makes me believe that it is not primarily Simutrans' fault.

The days where 3D graphics on Linux are horrible are over. At least the non-open nvidia drivers are amazing. And benchmarks have proven that Ubuntu has equal or better 3D performance than Windows/Mac (in some cases), and at least the gap is not that big anymore. And as mentioned in OP, I can run other games (Nexuiz, Heroes of Newerth, ...) at very high settings in full HD with no issues. At some point I even compiled the linux kernel, compiled pypy and ran Heroes of Newerth at the same time just to see if it would work. I did not notice any FPS drop in that game. So although I hate to say it, this seems to be a problem in simutrans (or possibly the dependencies such as SDL).

(A 3D adapter may only help to render simutrans 16 bit per pixel screen to wqhater resolution is on the screen However this depends entirely on SDL or allegro. Maybe try allegro, it usually gives more fps on windows than SDL.)

I might try that. Thing is that with 10FPS the game looks like rubbish. And it's not a lot more playable for me to make it worth it. I might set it down to something like 25 though.

You can drag a rail connection and see the cost. Just do not built it.

What if there's tunnels/bridges in a section? What if there's many different section on the whole route?

This game is about transporting. If your convois bunch, the one of them is not full (otherwise it would not be faster.) Then minimum load with a short waiting time (like 1/4 day=1/128th month) would cure this.

It's about (somewhat realistically) simulating transporting. And I usually don't see all the train of one line grouped up just after each other and then a huge gap of nothing in real life...

Changing the game so it stores user-entered server entries would be trivial and I'm surprised you haven't posted this in extension requests?

I decided to put everything into this thread for now. But you're right, this should probably also be in extension requests.

I'd suggest fixing this by allowing a connecting client to specify a username which would uniquely identify your client. This could be displayed on a connected clients screen next to whichever player slot that client happened currently to be controlling. Similarly these client handles could be used in the chat window, e.g. if your handle was "ojii" and you were currently playing as player 3, a chat message could be:

ojii (Player 3): Hello!

Clickable map references by coordinate shouldn't be too hard to do, indeed it'd probably be best to automatically include one with the current viewport location of the player with every message. A simple parser could then look for text of the form pos:XXX,YYY and include a link.

That would be awesome!

[prissi]

Codebase accessibilty:
Simutrans started 13 years ago by a german guy who wants to teach himself some OOP programming and got out of hand later. It was 100% german and then more and more english crept in, even way before it become open source in 2008. The team is small, never more than 3 active people.

IRC is nice, if you have too much time. I code like 1-2h per evening. This forums costs enough time already. With lurking in IRC I could achieve nothing at all.

And what use is a bugtracker, if you are a team of 2-3 people? All bugs reported here are usually dealed with in less than a week. (And the sourceforge bugtracker would have lost its content already twice since 2008 ... )

There is a short introduction into the codebase is sticky thread in development http://forum.simutrans.com/index.php?topic=7460.0. There is no further magic. I mean this is open source, you would not expect people writing spec books in their evening to relax? But any question on the code is usually answered quickly in the forum.

Any extra stuff needs someone who maintain it, i.e. maintain the bugtracker and so on. It would also involve somebody telling people what to do next. This is the commercial way of doing software, but for such small hobby stuff like simutrans it is not the right way imho. (You might of course disagree.)

Apart from patches, what other methods are there to submit code changes? I have not yet encountered another method. Maybe I have some misunderstanding here.

Use a bug tracker and tag stuff as 'low hanging fruit' (the name is not important, but something that indicates that someone unfamiliar with the project/codebase could work on this)

Sorry, what do you mean by this? Do you mean there is a central managers who assigns tasks? There are many places, which irks somebody and then this guy works it out. Or make graphics or reports errors. There are so many ways to contribute, central management would be a job in its own - without a volunteer for it so far. So there is no central management, which could fulfil this request.

Honestly, you are whining a lot for aparently now not having discovered or read "trunk/documentation/coding_styles.txt" as I told before. (Does anyone look at least more than a second at stuff nowadays? There goes another half hour I could have spent coding ... )

Performance:
Simutrans just uses the bitbit operation. Depending on graphics adapter and driver this may or may not be accelerated. And during each frame all stuff on the map must be moved, all several thousands cars, pedestrians and convois on the map, with the smallest visible movement 2 pixels horizontal on straight ways. That is why frame rates beyond 25 frame per second are meaningless.

And 1920x1080 is indeed very large and will also lead windows to stutter when zoomed out. There is not much that can be done about this, since simutrans has too many different objects for portable OpenGL 2D implementation (that was tried with openTTD.) It may run faster, if the screen depth is set to 16 bit per pixel; it trys to do so on windows in fullscreen mode. Then it only has to transport half the data and do not need color translation.

You are free to look at it. It is only simgraphic16.cc and simsys*.cc, depending on your backend.

[VS]

ojii -> This is not an argument against you, just... someone is maybe slightly technically wrong on teh intarwebs You're correct that there is an intrinsic performance problem. BUT - you keep bringing up other programs wrt. performance, but here we're on: single thread, no 3d at all. That's comparing apples and oranges. This old horse can't do some tricks, and that's the primary fault, not intense computation done wrong.

edit: I'm dwelling on this, since this is exactly my problem, too :( No hard feelings or anything... Actually, I do agree with you

[Ters]

The days where 3D graphics on Linux are horrible are over. At least the non-open nvidia drivers are amazing. And benchmarks have proven that Ubuntu has equal or better 3D performance than Windows/Mac (in some cases), and at least the gap is not that big anymore. And as mentioned in OP, I can run other games (Nexuiz, Heroes of Newerth, ...) at very high settings in full HD with no issues. At some point I even compiled the linux kernel, compiled pypy and ran Heroes of Newerth at the same time just to see if it would work. I did not notice any FPS drop in that game. So although I hate to say it, this seems to be a problem in simutrans (or possibly the dependencies such as SDL).

Considering Simutrans runs a 1024x1024 map at 25 FPS in 1920x1080 with processing time to spare on my laptop with somewhat less power than your's, suggests that Simutrans has the speed. The Linux version of SDL might, as you write, be to blame, as can every other component from there on to the graphics card. Unfortunately, I can't check the performance on my Linux machine at the moment. However, both on Windows and Linux I run Simutrans without sound, which might have something to say.

And as others have pointed out, comparing Simutrans to 3D games is pointless, as they use completely different methods to put thing on screen (unless you use software rendering).

But looking into drawing efficiency on Linux might be a way of getting into the code. I think the graphics code was where I first started, as I needed to get it to work in 64 bit with the newest versions of GCC.

[Dwachs]

As this happens with *any* game I start regardless of pakset, size or settings, I don't see how this is helpful.

So you have bad performance even with say the starting map in pak64? You have bad performance with an completely new map (where your only action is creating the map) ?? You have bad performance even without zooming out??

@all: please continue here

http://forum.simutrans.com/index.php?topic=8465

to discuss and report performance problems. I would *love* to help out. I would *love* to get anything substantial reported to identify performance bottlenecks and improve on them.

mod note...
Yes, please, don't keep posting about performance problems here, do it over there. Thank you.

[jamespetts]

I did, but to my understanding most Experimental features only kick in with Experimental enabled paksets, and I'm not a huge fan of the british pakset (no offense to the authors of it).

Have you tried the new Experimental version of Pak.64?

Being the maintainer of a fairly largeish open source project myself, yes I do:

• Use a bug tracker and tag stuff as 'low hanging fruit' (the name is not important, but something that indicates that someone unfamiliar with the project/codebase could work on this)
• I found IRC to be amazing to get people involved, since the barrier is usually lower to ask a question there as opposed to the forums. This of course means that one has to be there all the time (although not necessarily actively) and it can tend to use up quite a lot of your precious time. I found it to be worth it over time though.
• Have somewhere easily accessible a little "howto" for newcomers to the codebase. Where are the important bits? What are things one should keep in mind? What are the coding style guides for the project? What is the preferred format of contributions (seems to be patch uploads to the forums here)?

That's what I can think of from the top of my head, should I come up with more I'll tell you.

Thank you very much. Can you recommend any good free bug trackers? (Incidentally, some of the projects in the forum list were actually marked as the equivalent of "low hanging fruit": did you look at that thread that I linked? Some people have suggested using the forums as a sort of informal bug tracker, which I think is what Prissi does - do you think that a full-fledged bug tracking system is better than, say, re-organising and stickying that thread?)

[Ashley]

IMO another website with another login wouldn't help us with such a small project, the forum can (and is) used as a bug tracker and I don't really see what switching to using trac (for example) would really gain us.

[prissi]

A bug tracker is something made by programmers for other programmers. A layman is usually overwhelmed by this (apart from needing another account just to report bugs.) And we get most of our bug reports from users.

A forums is also much better to ask about for details or circumstances and is more personal. We take care of each bug as soon as possible and you will get that feedback. I am not sure how many people get taht from bugtracker ...

[TheUniqueTiger]

@ Prissi,

I'll have a look in a different respect and let you know later. I'll give it a try with XNA to experiment something.

[jamespetts]

Hmm - the response that Prissi gives above is the response that I had last time that I suggested a bug tracker, which is why I did not press the idea then. Prissi's point seems to make sense. In light of that, would it help to sticky that thread to which I referred in the Experimental forum?

[meme]

I confirm the same problem on OS X version of Simutrans - GUI is responding slow..

[Ashley]

meme - If you're using OSX Lion can you try this version and see how it compares?

http://forum.simutrans.com/index.php?topic=8783.msg88714#msg88714

[meme]

I changed the default pak64 to 128 so i could compare - It is much faster! Thanks you
I'm just having some problems with vehicles - they are invisible when they turn on some side / with pack 128 which I tried /


Screen - On left native version with invisible vehicles and on right standard version ...


http://imageshack.us/f/850/snmekobrazovky20120310v.png/     <--- click

[Ashley]

Ugh, imageshack is so crappy.

This must be a bug in Simutrans, rather than anything I have done, since the drawing of graphics in the game is done exactly the same for the SDL or Quartz version.

I'll make a version when the next stable is released, for a direct comparison.