Rubidium wrote:

Ignoring settings in one case and not the other is not easily possible. Also, if you set a bind address you must have a reason to bind to that address, otherwise you would not have set it.

Even then, silently ignoring is a setting is bad. So is possibly binding to an address where they do not want it to be bound to, e.g. an expensive internet connection instead of the cheap connection.

That said, the error message is kinda short and uninformative. Though... I do not see there being a nice way to present the error messages coming from the operating system; if you have multiple addresses, there could be one that fails and one that succeeds. Then you won't be having a "server not started error", so one probably needs to pass on all error messages. However, then you first get a "could not create listening socket" (which can be understood by a small percentage of users) and then the "server could not be started error".

Furthermore the error messages coming from the operating system cannot be translated which would mean even fewer people have a clue what's going on.

Finally, there is no real cross platform way to know what IP addresses can be bound to and which can't be bound to. For example, your computer most likely won't have IP address 0.0.0.0 but you can bind to that IP address. Likewise for a number of other IP addresses that are not assigned directly by your OS. Since we can't easily tell which addresses are such addresses and which aren't, we can't say (for certain) that a specific address cannot be bound to. Not being able to bind to an address can have many other causes.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5660#comment12421

YaakovTooth wrote:

I do not know how I got in the configuration file appeared yaakov.local address - the address is for a dozen years is the only address my gate on FreeBSD and I, of course, there's never start OpenTTD.

I believe that it is possible to establish that the address listed in the section and allowed to belong to a different machine. In this case - it turns out that OpenTTD tried to open a socket with the address of the my gateway. Is it impossible to ignore in this case it is obvious indication of the non-working parameter and the user does not show error, but a warning? I am a programmer spent ten minutes to establish cause of the problem if there were any information, I would have done it for thirty seconds. One good thing that I learned about the debug mode. :)

In any case, guys, it would be better if a similar error even add information about the error. Yes, the message is that you can not create a server; in parentheses - that it did not work, so that users can search for the error on the Internet. Now it turns out that the report on any errors and can only solve the problem of people with skill, a simple user or reinstall the game completely, or will forget and go on.

I sincerely thank you and team for your time and detailed response, for all your work.

Furthermore the error messages coming from the operating system cannot be translated which would mean even fewer people have a clue what's going on.

You can mark these messages as "technical information".

Finally, there is no real cross platform way to know what IP addresses can be bound to and which can't be bound to. For example, your computer most likely won't have IP address 0.0.0.0 but you can bind to that IP address.

The problem is not that you can not open a socket to 0.0.0.0. The problem is that the configuration file specified address of another machine (yaakov.local), which resolves to 10.0.0.1. As soon as I remove this section or write the address of your machine alex.yaakov.lotsal, which resolves to 10.0.0.18 - the problem disappears, and it opens a socket on 0.0.0.0 (and really works on all interfaces). In this situation, once it is known that yaakov.local (10.0.0.1) - NOT the address of the machine.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5660#comment12424

Rubidium closed the ticket.

Reason for closing: Won't fix

Removing a seemingly incorrect configuration like this automatically is going to cause more problems with magically disappearing configurations, e.g. due to DNS issues, than the problems when force-binding and sharing configuration files.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5660