News:

Want to praise Simutrans?
Your feedback is important for us ;D.

bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1

Started by jamespetts, January 26, 2014, 01:35:08 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Sarlock

Thanks TurfIt.  This parallels much my own experience: When I first connect it's very laggy until it settles down after a bit.  The same occurs when I am already online and another player joins the game.  It also happens at month-end boundaries as well - for the first few minutes after a new month it's very unresponsive.  I'm most likely to get disconnects during these times if I am doing any construction/building.  I try to save my building to the 3: and 5: hour marks, the connection seems the most responsive and I am least likely to get booted.

If I am just idling, I can stay connected for hours.  It's the building process that kicks me off frequently.
Current projects: Pak128 Trees, blender graphics

jamespetts

Hmm - I was in the process of splitting the topic when I realised that there were some posts that simultaneously dealt with both game play and the client/server timing issue.

I am very grateful to TurfIt for looking into this - it is very much appreciated. I am not sure why the server goes to sleep sometimes - perhaps it has something to do with running on a virtual server which is also running a web server that hosts the downloads?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

I've had several more instances of lines having some or all stops disappearing. It's becoming quite tiresome I'm afraid. My profitability was £2M/yr in 1757, now averaging barely 20% of that because of key stops being deleted from lines' schedules.

In many cases a line with 2 stops and 30 waypoints, just the first "100% load" stop is deleted, so the ships sail about empty (costing a fortune). Its always entry 1. in the list in that case. It happened to all of my most profitable lines. ::'(

I wonder, if entry 1. got deleted enough, it would presumably result in empty line-schedules??

What really puzzles me is how the other high-earning players arent having the same trouble?

Sarlock

Interesting.  I haven't run in to this issue, all of my lines are still operating flawlessly.  I had my road vehicles wiped a couple of times, as discussed earlier, but thusfar (fingers crossed) my shipping lines have remained intact.

If it happened to me I might very well quit playing as I have almost 900 ships in motion and over 200 shipping lines.  :o  (trying to re-establish everything while fighting frequent server disconnects would probably be close to impossible)
Current projects: Pak128 Trees, blender graphics

AP

The trouble is it's not easy to spot, because the ships keep sailing merrily.

The only clue is stations with "no service". There is a filter for that in lists (called "no connections") which I am now keeping a very close eye on indeed. Of course, it won't pick up if a stop is deleted but another service also calls there...

Server is down right now, I still have a fair few services to fix. If it recurs I may, as you say, give up. I've tried putting a "sacrificial" waypoint as entry 1. in each of my lines' schedules, may help?

ӔO

what works for me is all convoys set to a line, rather than lineless schedules.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

AP

Quote from: ӔO on February 15, 2014, 11:11:42 PM
what works for me is all convoys set to a line, rather than lineless schedules.
I do that always. It's impossible to manage all the vehicles otherwise. Hence the vulernability to this *issue*

AP

Just thinking ahead, many canals are in use by multiple players, in line with reality. If the canal owner player decides they want to remove a canal (e.g. to build a railway on the alignment), that will affect other players lines, and deprive them of revenue. I believe in reality since canals were "common carriers" they were not allowed to simply "close".

It would seem bad if a player comes back to game to find all his ships are reporting errors because vital infrastructure has been deleted...

asaphxiix

a nice solution could be that if you use another player's canal and you want to be protected from sudden closure, you'd sign a contract with them :)

but I think this is not practical until we can transfer funds manually, if only to pay compensation for a breach of contract :)

AP

Most canals and railways had "in perpetuity" clauses built into the enabling acts of parliament. Canals were called the "eternal navigations".

asaphxiix

yeah, and then, it's not that easy IRL to destroy a canal and restore the ground as it were, is it. I do think there's a long term plan to enable "abandoning" infrastructure rather than removing/restoring it.

jamespetts

That is an interesting idea, but I have no idea how this can practically be incorporated into the game without causing more problems than it solves.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

AP, why did you attach canals at Dartinghall and Dartington with my canals that don't work with sea fairing ships?

That peninsula does not even require a canal that bisects it, since going through there does not result in a shortcut for ships.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

AP

I assumed your canal was built with ship canal! Narrowboat canal is more expensive to maintain than ship canal in this version so nobody is using it. You should upgrade to save the maintenance.

I built the other half because it looked like it would be slightly shorter. Oh well.

ӔO

the barge canal is overly expensive, but the narrow boat is half the cost to maintain over ship canal.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:


jamespetts

Server now upgraded to 11.19, which should, in time, reduce the number of private cars to a more sensible level and overcome a number of the other bugs reported recently.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

My attempt to rejoin with the new version caused a fatal error in simutrans,;the map loads and i can interact with it, but the clock does not start ticking, then it crashes.

jamespetts

Might I suggest trying with the 64-bit version? I think that the memory requirements are a bit too much for the 32-bit version at present owing to the large number of private cars. That number will diminish with time with this new version, and might well reduce the memory consumption.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

64-bit client works, but is constantly stuttering while connected.

---

the stuttering can be reproduced locally by fast forwarding.
Typically does 11 to 12x, but dips down to 2x every 5 to 10 seconds.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

I suspect that the performance troubles (and memory use) are caused by the very large number of private cars. The numbers should slowly dwindle until a new, lower, sustainable level is reached as the new code in 11.19 gradually takes effect.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock

32 bit crashes for me too.  64 bit is working fine thusfar.

The stuttering/pausing makes it a bit difficult, but if it'll clear up after a while we can live with it.

Game is taking up 1.7GB in memory.

Could it also be related to the more complex pathfinding?
Current projects: Pak128 Trees, blender graphics

jamespetts

Quote from: Sarlock on February 21, 2014, 12:57:55 AM
Could it also be related to the more complex pathfinding?

Yes, that is also possible. The situation will need to be reviewed after about one game year to see what the position is then.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock

Current projects: Pak128 Trees, blender graphics

ӔO

My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

There is no means of tracking the number of private cars currently outstanding in a game. The current server load is 54.3% CPU and 43.4% RAM (out of 3Gb).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock

Hmmm, I am getting very frequent desynchs... I can connect but I will desynch usually within 60 seconds, sometimes right away after connecting... and especially if I try to do something like build.

I am getting the heavy stuttering on local play as well, runs at 12-13x but then freezes up for a few seconds every couple of minutes of game time, then bursts back to 12-13x again.

EDIT: It usually happens during the stutters - the clock freezes, then jerks ahead, freezes and then I desynch.
Current projects: Pak128 Trees, blender graphics

jamespetts

Hmm - I wonder whether this is the game not being able to cope with the increased routing depth. Are others also experiencing this? If this is so, I will have to put the old routing depth back (but, be warned, one problem that I encountered was that, when access rights were withdrawn from players whose ships docked at the ports of the other players who were withdrawing the rights, the ships would often end up being sent to the depot because the jump between one stop and the next became too much after the removed stop was taken out).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

ӔO

I fast forwarded a local copy to 1780 and the stuttering persists, but not as frequently. I feel that it is about half as frequent.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

wlindley

I have been unable as yet to connect without an instant desynch.  Quadcore i5 @ 2.6GHz, Linux 64-bit, on 18Mbps connection.  This map is seriously un-responsive when played locally.  =sigh=

Sarlock

Indeed, James, we've been facing that problem all along and have learned to live with it.  The best solution I can suggest is to have shipyards all over the place so that if this happens your ship isn't pushed too far off their scheduled route.

I tried a few more times to connect last night and couldn't stay connected for more than a few seconds (sometimes an instant desynch).  I managed to place two stations after about 10-15 connection attempts.  I think I also built a ship but wasn't able to get so far as put holds on it.

The clock is really jittery, shooting ahead, stopping, shooting ahead again.  I assume that is occurring on the server side as well which is causing the desynchs.  We'd need a mechanism to keep the clocks more in synch so that this doesn't happen.

EDIT: I think what's happening is that when you perform a function in the game and your client is waiting for confirmation of the action from the server and it enters one of its frequent multi-second pauses, the client signals a desynch because it hasn't received anything from the server.  At least, that's how it feels.  When I am lucky enough to not desynch immediately on connection, as soon as I perform any action it will likely desynch because it will hit one of the pauses and time out.
Current projects: Pak128 Trees, blender graphics

AP

Also, a
Quote from: Sarlock on February 21, 2014, 03:39:52 PM
Indeed, James, we've been facing that problem all along and have learned to live with it.  The best solution I can suggest is to have shipyards all over the place so that if this happens your ship isn't pushed too far off their scheduled route.

Also, lots of waypoints, so it has a chance of making it if a (formerly shared) stop is removed.

ӔO

^
If you keep your waypoints within 1200 tiles, it seems like there is less chance of the stop being deleted.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

AP

^
Is that 1200 total or 1200x and 1200y ?(i.e. how are diagonals dealt with?)



Quote from: jamespetts on February 21, 2014, 12:19:35 AM
Might I suggest trying with the 64-bit version? I think that the memory requirements are a bit too much for the 32-bit version at present owing to the large number of private cars. That number will diminish with time with this new version, and might well reduce the memory consumption.

Am on a 32bit operating system, so I believe that means this isn't possible.

Sarlock

I am keeping my waypoints 600-800 average.  It's more work putting your schedules together but then you run no risk of failures.  I don't think I've had any shipping routes fail in that regard.  The only problem I had was when one of my docks was accidentally blocked by someone else, but other than that keeping below 1000 distance for waypoints has worked well for me.

I will also put my waypoints closer to together in areas that have more complex pathfinding (ie: open ocean vs. around islands).
Current projects: Pak128 Trees, blender graphics