OTTD Unlimited?

[richk67]

This is sort of a question for the senior devs on design practice within OTTD... but I thought I'd ask in the open as its a topic Im sure people would be interested in.

Sometimes I see posts on the lines of ... why is XXX limited? eg. sprites, number of vehicle designs, map size, cargo types, etc... and it got me wondering... OTTD is not limited inherently - we can recode all parameters as required (OK with varying degrees of effort).

So why does there seem to be an acceptance of the limitations in original TT and new limits decided by TTD?

Other than tradition and effort are there any impeding reasons for not structuring OTTD in a way that can be more easily expanded?

eg.

• structuring the map file so that the sprite is an int32 (heck, a int16 would be an advance)
  breaking free of the 256 vehicle designs limit, and having int16 designs (thus allowing loading of multiple vehicle sets at the same time)
  allowing int16 cargo types

etc..

Any thoughts?
As usual this is only intended as a question, not an attack, and if there are already plans afoot, it is in no way a criticism of them. Im just curious as to any underlying design decision...

[peter1138]

Ok, here goes...

1) I'm not entirely sure what the map (file?) has to do with sprites, but there are plans afoot to alter the sprite limit. It is already a 32 bit int, though...

2) I've looked at this before, and may progress it further. Could be interesting.

3) Currently we have 12 cargo types in a game, and a CargoID is 8 bits. That'll limit us to about 253 cargo types (there are some special values). I don't really think going to a 16 bit value is really necessary...

[richk67]

Ah, I thought the limitation on the sprite ID was that it is used in the map to define the objects (.m2) I think, and that only 14 bits were available for some reason - hence the 16384 sprite limit.

[XeryusTC]

weren't some of those limits (like the vehicle limit) because there are hard coded limits in TTD which affect TTDP, which then affect GRF makers and thus also affect OTTD?

[richk67]

weren't some of those limits (like the vehicle limit) because there are hard coded limits in TTD which affect TTDP, which then affect GRF makers and thus also affect OTTD?

My point is that we need not be bound by them - just because the older versions accepted it, does not mean OTTD should, IMO. Just because .GRF makers work within the limits of TTDP, does not IMO mean that our capabilities should be limited too. Perhaps we should define a higher vehicle limit and have TTDP have to find a way to catch up...

[DaleStan]

weren't some of those limits (like the vehicle limit) because there are hard coded limits in TTD which affect TTDP, which then affect GRF makers and thus also affect OTTD?

That's the vehicle *type* limit, and yes.

The sprites limited is 14 bits because the required information for coding a sprite is:
1) Two different sprite numbers
2) Four bits of special flags (One three-state flag, and two one-bit flags)

This format is used in NFO in places where literal sprite numbers are used, so widening the 14 bits requires ... But I'm repeating myself: http://www.tt-forums.net/viewtopic.php?p=517908#517908, and the discussion (ranting?) that follows.

Internally, the one-bit flags may be unnecessary, so a change to 15+2+15 (instead of 14+2+14+1+1) may be possible, but that still requires that GRM ... And I'm repeating myself again.

You can, of course, use TTDPatch's solution of creating several 14-bit wide sprite-spaces -- one per feature, but that's also a lot of work.

Just because .GRF makers work within the limits of TTDP, does not IMO mean that our capabilities should be limited too. Perhaps we should define a higher vehicle limit and have TTDP have to find a way to catch up...

We work within the limits of TTDPatch because those limits, and abilities, are well documented. The only documentation I've ever found for OpenTTD's NFO support is documentation I've created myself, which does not bode well for its accuracy.

Given the choice of two compilers: gcc and one that natively supports arbitrary-precision math, but only supports three-quarters of the C standard, which one would you use?
Now, why do you expect NFO coders to behave any differently?
Catch up first. Then extend. Doing things in the other order will rarely go well, and may well cause the language to fork.

[richk67]

My thoughts are more about the design ethos - and playing catch up to anything is bad design practice. If OTTD is to be as good as it *can* be, then a bit of planning for expansion rather than merely matching to TTDP is a good thing.

I agree that it is a worthy goal for OTTD to support all of TTDP's features, however, it should not be a limit. ie. in my view, TTDP functionality should *ultimately* be a subset of OTTD.
(yes, yes, i know it is more the other way at the moment, but OTTD is developing at a very rapid rate)

[Brianetta]

I agree that OpenTTD shouldn't be bound only to follow TTDP's lead, but DaleStan has a very valid point when it comes to documentation. All the really interesting pages in the wiki have disclaimers at the top stating that they might be out of date.

There's not much in the way of design documentation, either. I get the feeling that documentation is preceded by C code, rather than the other way around. Trouble with that is, that if a coder neglects to write up his documentation afterwards, there may well never be any.

[sidew]

I like to see the remove of the height limit to 16 steps, maybe up to 256, so we 'll don't rework most heightmaps for balance the grayscale.

[belugas]

Just for the general interest of the discussion, limits are raised whenever it is possible. Not for competition over TTDPatch (Which I do really admire the ingeniousity of its devs) but rather because it CAN be done, or sometimes MUST be done.

Example : newhouses (which are nearly completed). TTDPatch allows up to 128 + 256 houses. We allow 512, because it was the best way for us to have AT LEAST the same amount of houses as TTDPatch: 256(map house id) + 1 bit = 512

Another one : newindustries (very very primitive stage but still...) . Due to its desnig in TTDPatch, it is limited to 39 industries. We do not have the same limit they faced. But having 256 possible industries is a bit overwhelming, so it has been set to 64, which is a nice number, imho.

May I remind that we do not have anymore a limit of 32 widgets per window?

And there is plenty more to tell... The point i want to bring is : let not define the limits of OTTD by comparaison with TTDPatch. If it can be done, why not. If it is usefull, why not. But do not play "Who has the biggest engine"... please

And don't forget, both programs have the same "ancestor". Thus the same fundamental design...

[athanasios]

And what about the limit of stations per city? I suppose it is only 15.
This is ridiculous with the current state of game - especially when using passengers destination patch. What will be the use of new industries if we cannot serve them? Will we have to continue to resort to long stations 20 or 30 tiles long to cover more?
I 've requested this for long and I wonder why it is not fixed yet.

[belugas]

And what about the limit of stations per city? I suppose it is only 15.

Changing the name of the stations might help you add more stations...

This is ridiculous with the current state of game - especially when using passengers destination patch.

Although this is a good patch, i wonder what it has to do with the current converstation... More stations? read the above.

I 've requested this for long and I wonder why it is not fixed yet.

Maybe because we are working on some other features?
Maybe because we have real lives and jobs?
Maybe because there is a ton of other stuff to do?
Maybe you could help us and provide a usefull solution to your problem?

Look at what Maedhros did : newhouses. Almost all of the code is his. Now that should be an inspiration...

[DaleStan]

I 've requested this for long and I wonder why it is not fixed yet.

I'm going to go with Belugas's fourth idea here. It's not done because you haven't done it yet.

[Quark]

And what about the limit of stations per city? I suppose it is only 15.

[t2t2]

And what about the limit of stations per city? I suppose it is only 15.

*** IMAGE ABOVE ***

Nice use of space bar in front of station name.

30 stations?

[mikeel]

hi
(i'm new on this form and maybe i'm asking something of stupid, please advise me if it's so)
what about the names limit? i create an italian scenario for OTTD (http://www.tt-forums.net/viewtopic.php?p=538735#538735) and discover that olso is possible to create more than 512 cities, there's a limit of 512 custom names (includin stations, cities, signs and companies names). is difficult to raise the limit to 1024 or more?

[Quark]

Network version string is just 15 bytes long — it's to small for something like «OpenTTD v0.5.0 rXXXXM [Subsidaries]»
64 bytes for version string and 64 bytes for password (instead of 20) will be good. How about 14 chars password in non-latin language?

[Rubidium]

Network version string is just 15 bytes long — it's to small for something like «OpenTTD v0.5.0 rXXXXM [Subsidaries]»
64 bytes for version string ....

Ofcourse 'OpenTTD ' is unneeded, 'v0.5.0' and 'rXXXXM' make absolutely no sense together as you're either using 0.5.0 or you are using some branch with a specific revision.

And yes, the version string might be short, but it has to be packed into the PACKET_UDP_SERVER_RESPONSE packet, which is nearly reaching the maximum size for a packet. And this packet is limited by the MTU of the network we are running on and you do not want to split it up into multiple packets as it increases the chance that the information does not come through dramatically.

[Quark]

How about to pack hash from version string instead?

[Rubidium]

How about to pack hash from version string instead?

Then how would you be able to tell the version the client needs to get to be able to play on that server?