MyOTTD

[CMircea]

Once I my new computer arrives (in 2 weeks) I could volunteer to host the servers, but I'm not too fond of keeping the computer up so much as the case isn't very well ventilated and I don't want to terminate the warranty to pack the wires nicely with a sleeving kit. Though I have an idea:

How about a service for testing the trunk? This could prove invaluable to developers, as you could require to update and compile the latest revision and then test it as you wish. As I'll have a Core Quad, I doubt it'll do much of a performance impact. The problem would be how to do it, as for GNU/Linux it is pretty straightforward, but I'm and I think I'll be using Windows.

[SpComb]

Once I my new computer arrives (in 2 weeks) I could volunteer to host the servers, but I'm not too fond of keeping the computer up so much as the case isn't very well ventilated and I don't want to terminate the warranty to pack the wires nicely with a sleeving kit.

Hosting the servers in a distributed fashion is something that's been part of the design from the start, so it's not impossible. However, it has some kind of service level requirements... the servers would need to be on 24/7, be relatively stable, have a static IP and adequate network connectivity.

I'll be getting access to a co-owned/shared eight-core xeon server in the near future, remains to be seen how many OpenTTD servers I can stuff on that

Though I have an idea: How about a service for testing the trunk? This could prove invaluable to developers, as you could require to update and compile the latest revision and then test it as you wish. As I'll have a Core Quad, I doubt it'll do much of a performance impact. The problem would be how to do it, as for GNU/Linux it is pretty straightforward, but I'm and I think I'll be using Windows.

I'm not quite sure what you mean with testing the trunk. Devs can run their own servers locally for testing, and I'm not sure the public testing servers need to be more frequently updated than what the nightlies are now.

[athanasios]

{

...as the case isn't very well ventilated and I don't want to terminate the warranty to pack the wires nicely with a sleeving kit.

And you bought from them? I would throw the PC on their heads.
At least 2 times I found out that parts were not assembled correctly...

RULE: Never buy a preassembled PC. Buy the parts separately and assemble them yourself.

regards
athanasios
}

[bob27]

Thanks SpComb for reconsidering the project. I really appreciate it and I'm sure others do to!

[Connum]

I don't own a root server to offer, but I'd be glad to help with the back-end, as far as it's coded with PHP.

[SpComb]

I don't own a root server to offer, but I'd be glad to help with the back-end, as far as it's coded with PHP.

(Un)forunately, the backend is written entirely in Python and C, so there's not really anything that can be done with PHP.

[jwa1992]

I can't create a server. It says: 'internal server error'

[SpComb]

I can't create a server. It says: 'internal server error'

All the allocated ports were in use... I've added some more for now.

[CMircea]

[quote="SpComb"Hosting the servers in a distributed fashion is something that's been part of the design from the start, so it's not impossible. However, it has some kind of service level requirements... the servers would need to be on 24/7, be relatively stable, have a static IP and adequate network connectivity.[/quote]

Those in bold are quite the problems, as it ain't a server. And I have dynamic IP, but isn't it possible to use dyndns to "correct" that?

[Connum]

dyndns shouldn't be a problem, my server had a dyndns before it blew!
but it should run 24/7 or it wouldn't make sense...

[Alberth]

How about a service for testing the trunk?

The idea is quite interesting, but how do you test a game?
Checking whether the source compiles is not much use, devs do that already.

Imho testing would mean running the executable, checking that the game behaves well.

Albert

[CMircea]

How about a service for testing the trunk?

The idea is quite interesting, but how do you test a game?
Checking whether the source compiles is not much use, devs do that already.

Imho testing would mean running the executable, checking that the game behaves well.

Albert

Yes, so you start a server and then join a company will all you would need to see how the game works.

[SpComb]

[...]I have dynamic IP, but isn't it possible to use dyndns to "correct" that?

Well, yes, it would be possible to run it on a not-officially-static IP (myottd.net is on what appears to be a long-term DHCP lease right now), but that assumes that the IP address only changes very rarely (it's been the same for six months here), not e.g. every day at midnight, as is common with DSL connections.

How about a service for testing the trunk?

The idea is quite interesting, but how do you test a game?
Checking whether the source compiles is not much use, devs do that already.

Imho testing would mean running the executable, checking that the game behaves well.

Albert

Yes, so you start a server and then join a company will all you would need to see how the game works.

I still don't really understand what void this would fill. As I said earlier, devs can run their own servers locally for testing multiplayer changes, and versions of the trunk are released every day for general play-testing-use to everyone (the nightlies).

[SpComb]

It's been roughly a year now since I first put MyOTTD online, and I guess the time has finally come to start putting it to rest.

I need to reboot the server that MyOTTD is running on, as I need to relocate the UPS that it's powered by. At the same time, I'm going to start killing off the MyOTTD servers.

Effective immediately, all servers have been marked as disabled, which means that they will no longer automatically start up again if the service is restarted. I've added a little button to Enable your server again (next to Stop/Restart) if you want it to stay running.

At some point in the fairly near future (i.e. sometime next week), I'll then restart MyOTTD. Users' servers will not come back online automatically, unless they've been explicitly enabled before that.

I predict that the vast majority of the servers will stay offline, as the current myottd.net is, to put it bluntly, buggy, outdated and slow.

I've had some ideas and done a bit of work in relation to a new version of MyOTTD that I found very interesting and promising, but unfortunately, I've had to conclude that I really don't have the time that would be required to develop and maintain the entire service on my own, now and in the future.

Unless things change, I'll probably shut down MyOTTD for good sometime sooner than later, depending on what kind of reaction I get.

EDIT 2008/11/09: I shut down the server on Wednesday/Thursday night (2008/11/04), and due to the lack of response it will presumeably remain offline until further notice. I've redirected the domain to this forums post.

[SpComb]

Holy thread necro! Welcome back to 2007/2008, roughly ten years ago...

So as a matter of historical curiosity I dug up the old myottd.net source code repos from 2007-2009: both the original mess that was actually running at myottd.net, and the fancy new re-architecting that I gave up on because it was just too much work for one person.

• https://github.com/SpComb/myottd original prototype/monolith that was running in "production" at myottd.net
• https://github.com/SpComb/myottd2 RIP the containerized (Linux vServer) microservice architecture dream that got stuck in development
• https://github.com/SpComb/netdaemon#use-case--scenario generic tech for managing service processes (running in containers)

Interesting seeing how times have changed now. With technologies like Docker now being mature and widely available, that kind of cloud SaaS service would be a whole lot easier to implement today than back in 2008, because I was basically trying to implement Docker: using (fuse) unionfs mounts to combine read/write user data with versioned OpenTTD and shared base GRF layers, some iptables NAT to expose the servers on the network, and writing some service daemon manager to control the openttd process running within that vserver via an unix socket while handling console streaming etc...

[Dave]

Wow, now there’s a name I haven’t seen for time!

[orudge]

SpComb! Nice to see you again.