Transport Tycoon Forums

I still would like to make Simutrans also a little more friendlier to TTD users. I heard many complains about the menu systems but I am not sure, that it can be more simple than just point and click.

(It took me a long time to find out, that in OTTD one can also built by dragging, although only straight ones. Same was until I found out how to tell a train where to go.)

Thus apart from that I would like to hear things people in this forum would like to see in Simutrans. Maybe a difficulty switch, like easy and hard. (Easy would use 1.5 income for most goods and allow connection between random factories.)

By the way, if it is just the look, you can use the TTD-graphics and make a simutrans using 8Bit graphics. (Although I rather found this painful to the eyes.)

slopes that aren't size of a mountain in 128x128.
remove destinations fom everyhing except mail & passengers & food.

The reason I'm not playing Simutrans is mostly the looks. The higher resolution graphics are nice, but the problem isthat they're made by dozens of people without any agreed upon scale and colorings (or that's what it looks like) so that a town is just a big pile of ugliness.

So what I mean is, I like the look of the individual objects in Simutrans, just not how they look together.

_________________
Abunai!
Creator of the Openttd Challenge Spinoff, Town Demand patch

The features I like about TTDPatch that weren't in Simutrans last I checked:
- Presignals and PBS
- Most of the newgrf system (mainly the variational/random graphics)
- A well-documented newgrf system (Will retract upon pointer to a decent pak format definition.)
- Drag-and-drop rail [removal]
- Build-on-slopes (a hard-to-use version of this was in the versions I played; but in TTDPatch the foundations are built automatically.)
- Small memory footprint (I couldn't reasonably run the 128 set on my P4, 256MB RAM machine.)
- backwards compatibility (Anything valid in any previous version of TTDPatch is valid in the latest version, with a few highy publicized exceptions.)

prissi, will using TTD graphics really work? For one thing, height levels are completely different. (Only 8 px for TTD)

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

Trains that selects a free station slot (but that I already asked some days ago with TTD route finder)

_________________
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...

Thanks a lot for the feedback. I wil try a short summarizing.


Things that work/already exists:

- PBS are implemented in Simutrans since 86.xx, they are called Presignals.

- Since 86.xx the memory footprint is much smaller, even for the 128 (which I do not like).

- The *.pak-files are not dokumented, but the dat-file to create new paks are. There is a program to work with pak-File, but we do not want to spread it, because many graphics have permission only for use in Simutrans. The Wiki is a rather good source of dat-documentation: http://www.hajo.simutrans.com/pmwiki/pmwiki.php/MobEn/MakeObj.

- Backward compatibility is fully there. You can load a very old savegame, if the same objects are used. Of course, if you deleted some cars from the data folder, it may crash.

- In the german 64 pak all buildings and many vehicles are rendered by a single person. Thus all the scales are the same.



Things that may come:

- You built rails in simutrans but clicking on begin and end. If you did not like the result, press 'z' to UNDO. The artificial slopes are still somewhat buggy and thus not yet supported.

- Allow all possible destination for goods will be a setting

- In priciple TTD graphics should work. However, since the main tile size is 64x64 rather than 32x32, there might be some adjustments neccessary. Also the transparency/night/company colors need conversion.

- I also think the height are too high in Simutrans, but without new graphics this may be difficult to change. From a programming point of view, the change seems rather simple.



Things that probably will not come:

- Random platform selection.

Hmm, TTD graphics in Simutrans....

/me ponders...

_________________
Richard Eldred. Administrator of Planet TT-Forums!.
Former NewGRF Coder and Sprite Artist

14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!

Lurkin' like a boss.

IMO it's mainly the interface and that you've lines where vehicles run on, in staed of vehicles with orders. It just works somewhat different than TT, and I'm used to TT...

_________________
Contributor to the The 2cc Set and Dutch Trainset. Inventor of the Metro concept. Retired Graphics Artist.

Download TT | Latest TTDPatch | OpenTTD | OpenTTDCoop | BaNaNaS: OpenTTD content system | 2048² OTTD scenario of the Netherlands
GRF Codec | GRF Crawler | GRF Maker | Usefull graphics & tools sites | NML Documentation Wiki | NFO Documentation Wiki
All my graphics are licensed under GPL. "Always remember you're unique, just like everyone else."

X-Tome-Length: 1


Divided by a common language, I see.
PBS and presignals are two completely different things.
PBS permits multiple trains in the same block, provided their paths do not intersect.
Presignals prevent a train from entering a block unless it can also exit the block.
Which does Simutrans have?


But examples are not what I'm after. Examples are a great help to many people, but I prefer technical documentation, like the TTDPatch wiki, or newgrf.txt. Think man page. Something that says "@INPUT[n] is {required|optional}, and causes these effects." Repeat for n from 0 to numInputs-1. Next/prev buttons would also be a very nice thing.
Examples do little to convince me that everything possible is listed.


TTDPatch's backward compatibility applies to its GRF (Simutrans:pak) format too.


Again, this is last-I-checked, but the pathfinding left something to be desired. The main issue I remember is that N/S and E/W tracking would usually end up with an unnecessary jog on the end side.

 ______
       \_/

I thought that was in the works and maybe even an experimental feature last time I played. Am I just misremembering?

Also, I like being able to remove the connection between two squares without having to demolish one of them.

At least partly because it's the one I learned first, prefer TTD's track system, (6 peices of track per tile, instead of 4 connections per tile) but I know that's not going to change.


The vehicles-with-orders thing is perfectly dooable.

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

PBS vs. Presignals
Simutrans implements at the moment presignals, i.e. the next next block on the route must be free. In principle, since the route traveling is fixed, PBs would be easy. However, it may generate even more deadlocks.

How many tiles PBS on TTD look ahead? It must be a restricted range, otherwise not trains will move, because all could deadlock each other.

Documentation:
If you look into the comment examples section, there you can find exactly what you want, like allowed types and ranges. This documentation is half a year old (because the wiki is broken at the moment), but since Simutrans is backward compatible also on pak-files, you can still use it. (There is an internal version number in the simutrans paks.)

The plattform slection is in the moment not under construction, as far as I know. Perhaps Hendrik looked into it.

PBS looks ahead (and reserves) to the next signal, or the next station in the trains orders, whichever comes first.

Pathfinding in TTD is completely different than in Simutrans. In TTD, pathfinding is done on a switch-by-switch basis. It searches forward until it has seen $SMALLNUM (64?) tiles, or $SMALLERNUM (7?) junction tiles, and then chooses:
- The first option that gets it to its destination station, or, failing that
- The option that gets it closest to its destination (I think the distance algorithm is (Δx+Δy)/2.)

Paths may pass green signals and red one-way signals, but not red two-way signals.

_________________
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

Just some minor corrections...

From a53 on always to the next signal or end-of-line, even in stations.

Correct.

Actually, the shortest route that takes it to its destination.

Yep. Although there is some randomizing involved too, I can't quite figure out how that works. Maybe it's only important for trains without orders.

This only applies to the first signal. Also, if the first signal that gets it closest is a red two-way signal, the train will go towards the closest green two-way signal instead, without regard for where that route goes.

_________________
Josef Drexler

TTDPatch main | alpha/beta | nightly | manual | FAQ | tracker
No private messages please, you'll only get the answering machine there. Send email instead.

Personally I really like the towns in Simutrans. The variations in the look of the houses and the kind of houses are fantastic. And the information when you click on a house is plain fun. In real towns there is a huge variation in houses so that is great in my oppinion. It is also nice that the Simutrans graphics is different than TTD. But let me say that I like TTD very much too, I have played it a lot. But it is a different game, with a different feel. To me a different feel because of a different game is great.