If pakset was shown in red, then you have a different pakset on your client.
Possible but unlikely. Unless someone changed the server pak then back again in 5 mins... Originally: Client rev 3821, pak pak.german_0-102-3c_net (from Franks post above) Sever rev 3821, pak pak.german_0-102-3c_net
Crashed client (server too I think) (vector_tpl index out of bounds) -- Reconnect attempt: Client rev 3821, pak pak.german_0-102-3c_net (same as before) Sever rev 3825, pak pak.german_0-102-3c_net (server rev changed)
Pakset now shown in red. Join game button greyed out. -- Update client: Client rev 3825, pak pak.german_0-102-3c_net (copied pak directly from 3821 directory) Sever rev 3825, pak pak.german_0-102-3c_net
Caused my client, and I think the server to crash building a powerline under another player's bridge. When I went to reconnect, the server changed from r3821 to r3825. Some sort of auto relaunch running?
The game info window pakset showed in red with join game remaining greyed out. The find mismatch button was active but did nothing. Not implemented?
I updated my client to 3825, didn't touch my pak, and could then join. The game info revision line turning red to indicate a game revision mismatch would be better; It looked like a pakset mismatch rather than the game version...
Can't maintain sync with 3825 for more than a minute either...
Just had a nasty desync. I was connected when industry growth occurred. Locally a Beverage trade was created in Bad Laer connected to the existing Brewery. I spent a couple minutes looking at how to use it when I desynced. Upon rejoining the server, the beverage trade was gone; Instead there was a Home Market/Furniture Factory/Sawmill chain in Bad Laer...
r3787 CTDs on me constantly when scrolling the screen. r3786 is fine. I notice graphics corruption in the scrolling message area at the bottom of the screen. The corruption is player color bits of vehicles that are hidden by the message. Reverting this section of code fixes the problem.
The call to the translator is unnecessary here. The "Aufspanntransformator" name is already being p****ed to the translator for display in the info window title; The appropriate entry in the xx.tab file is simply missing...
Upon loading a game, any ships that are moving on the open sea start over at 0 speed. Actually, they 'jump' as though you had opened/closed the schedule for each ship. Ships in canals behave.
vehicle/simvehikel.cc:612 vehikel_t::set_convoi( grund_t const* const gr = welt->lookup(pos_next); if (!gr || !gr->get_weg(get_waytype())) { pos_next = r.position_bei(route_index + 1U); }
is corrupting pos_next. After this call, pos_next is set equal to the current position which confuses the first code block, causing the unnecessary route search. This would be fine if the convoi was saved with broken coordinates as set_convoi expects at this point. However, it still triggers with valid coordinates.
The problem is open sea tiles don't require a weg for ships to transverse them. Patch to fix attached.
I think we're suffering from a double misunderstanding! I intended for the public service to connect my powerlines to jonasbbs. However, he connected transformers where I was going to (I build the lines but not the transformers to save money) so I deleted my lines but didn't edit my request message. Wish we could leave persistent messages in game - the current feature only works for players currently online.
If connecting is the intent of your rule then please connect @(273,179) If I have to connect myself at @(~404,~130) things are going to get quite messy again!
I couldn't connect until now. But, one problem is transporting cars by themselves is not profitable - atleast not in the 1930s. Unless you're involved in the rest of the chain somewhere there's no reason to move cars.
PAK balances that work well in single player might need some tweaking for multi. Generally, PAKs seem to have raw materials at low profits (or even losses!), and the final link in the chain is where the real money is made (except with pak.german cars!). In multiplayer, someone could swoop in and 'steal' production from that last link, ignore the raw material, and make literally like a bandit.
I am not yet convinced that stealing power from a player is per default.
I'm not understanding this statement "per default."
The experience with pak.german network game1 shows that every player seems to want to connect power to their factories even if there is insufficient power to go around. i.e. By default electricity_promille is 330 so only 1/3 of factories can receive full power. Further since one power plant can supply many factories, I expect a public service transformer at the plant is required. Else the first player to place a transformer receives a power monopoly. Once public service is involved, players can make a huge mess of private powerlines everywhere; The reason real life has resulted in public power utility monopolies in each geographic area...
I was connected when this happened. I observed a player join and the game never resumed from the pause state. Manually attempting to unpause had no effect. I exited simutrans and got 'server busy' when trying to reconnect. I frequently observe pause/unpause/pause/... stutters after a player connects. If I'm doing anything related to convoi schedules when this happens, I desync very shortly later.
EDIT: Exact same thing just happened again. It reloaded the game as though someone joined, got stuck in paused, and now 'server busy'
I had originally intended to extend my powerline network stabilization patch to remove the 1 transformer per factory restriction; Patch started but not to testable state yet. After seeing the mess that became of powerlines in pak.german Network game 1, I don't think this is a good idea. Thoughts?
To clean up in game1, the public service player had to step in and create interconnecting points so the many runs of parallel lines could be removed. To remove this burden from the game admin, the powerline connecting logic could allow for a player to connect to another players lines, not just to the public service lines. This is similar to how roads work now - you can build beside another players road and manually connect if you want - no automatic merging. I realize this would require a rather extensive rewrite of the entire leitung cl**** - I would expect making leitung_t derive from weg_t like the rest of the waytypes. Comments?
Anyone places additional routes for the same thing. Example: I had a good working oil transport line. I transported all oil that was there. But than there came another player and builds a second line. And then I got no oil more.
The 'fair' goods distribution patch I just submitted will generally help with this situation. The other player will still steal some of 'your' goods but you won't be left completely dry. Unfortunately, in your specific oil instance, the patch won't help as the station arrangement is a shared public stop as source to 2 separate private stops as destination. This is beyond the scope of my patch. If you could create your own station at the source then it would be fine. Of course Oil Rigs are a problem with their built in public stop.
Side note: Your raising the ocean in front of the other players canal entrance and placing a sign there to sabotage him is *NOT* the solution. Poetic justice, you may have stopped his boat but the route finder still routes all oil to him so you still aren't getting any oil.
Also, signs popping up everywhere blocking the map is not good.
The same for p****enger transportation. I have working p****enger networks and then other overcrowd the cities and uses to slow vehicles and stop so my network.
I don't think the 'no_routing_over_overcrowded' setting is good for multiplayer games. All it takes is one player connected to a public service stop to provide insufficient transport to one of his private stops and eventually the public stop fills jamming everybody up. It's impossible for a player to connect often enough to monitor things. Even connecting once a day resulting in several game years (@20 bits/month) p****ing before a problem might be noticed.
As to slow vehicles: if the roads are public, this is something with which the players will just have to cope, as it is perfectly realistic for vehicles of all speeds to use roads. However, there is much to be said for modifying the "private road" sign such that it allows only the player who owns the road's vehicles to use it.
This sounds goods. Although perhaps a players' roads should be private by default. Also, building a private road over top of the public road should be disabled IMO; As should building traffic lights, or road signs of any kind on a public road. As seen in this game, havok ensues when signs/lights show up, or your vehicles are routed over another players' road and the player removes it!
5) Oddities - might not be related to network but simply multiplayer. - Goods distribution from factories is being limited by the players stop with the least capacity. eg. Player 1 has a truck stop capacity 64, Player 2 has a train station capacity 320 both connected to the same factory. Once both stops have ~64 goods waiting, the factories output store starts filling up instead of Player 2s partially full station.
Attached is a patch to fix this. Goods are now distributed from factories to their attached stations in proportion to the remaining free space at the station.
e.g. Truck stop capacity 64, Train station capacity 320. The first distribution of 10 goods goes to the truck stop putting it at 15% full, the next 10 go to the empty Train station putting it to 3%. The next four distributions all go to the train station to get it up to 15%, then the truck stop gets 10 more, continue...
This seems strange at first thought but in testing works well. In the steady state with vehicles picking up the goods the end result is the same as the original code produces; Except, the extra capacity of the train station is used. i.e. The original code would fill both stations alternating 10 to each until they both have 70, and then stop distributing with the excess piling up in the factories output store. Hence, the train station is effectively reduced to a 64 capacity.
Multiplayer has nothing to do with the problem, it simply provides the condition where multiple stations would end up at a factory. An unlikely situation in single player - at least how I play.
In looking into this problem, I also noticed that the distribution wasn't very fair. i.e. One station would always be selected first for the distribution. This means all a player has to do is ensure a vehicle is always loading (if he was lucky enough to have the golden station) and he can deny the other players' station *any* goods. Ever!
First glace at the code showed a last_lieferziel_start variable that was "to distribute to all target equally". However, this only applied to goods leaving to multiple destination factories from the same source attached station. I've extended this functionality to also handle equal distribution to all attached stations. Renamed the variable to index_offset to reflect its new dual usage. last_lieferziel_start was also being incremented in ::step - this can render it ineffective depending on the number in lieferziele. Now incremented in ::verteile_waren where it provides round robin service rather than semi random.
If vehicles are loading at multiple stations all connected to the same factory, each station/vehicle now receives a distribution in turn. No more players hogging all the output...
What this patch doesn't do:
1. Change the loading order of vehicles. i.e. If multiple vehicles are in the station all loading the same goods, they'll continue to load based upon internal ID.
2. Change the route finding of goods. If you have vehicles loading at the same station with goods destined for the same factory but separate destination stations, only one route will be picked and receive all the goods. An example, a public service stop connected to a coal mine with both a train platform and a truck loading bay. At a coal power plant there is a train station from player 1, and a truck bay for player 2. The route finder will pick either the truck route, or the train route and provide no goods to the other. Players in a multiplayer game would probably expect this setup to work. I would. The last discussion involving routing went rather bad so... 'nuff said.
5) Oddities - might not be related to network but simply multiplayer. - My trains are retaining their speed at signals. i.e. if they arrive at a red signal at 50km/h, when the signal turns green they start accelerating from 50 instead of 0. The others players trains in the game are not exhibiting this behaviour. Sometimes my trains behave too...
More specifically if a train arrives at a red signal and the track on the other side is reserved by an approaching train, the train pauses it's motion but doesn't set it's speed to 0. Once the signal clears, the train starts moving again at whatever speed it arrived at the signal.
I've traced the problem to the r3667 commit. One liner patch attached...
For desyncs, you really need to match the server executable revision. Any changes will likely give desyncs. Currently you can join with wrong version.
The game info said "Revision: 3738" so I grabbed 3738 from the nighties. I presume the game info is displaying the server version. I have no idea what version others were using or if they can cause me to desync.
Reloading map is needed upon joining. However, position (and player) should be able to be kept easily.
Any chance of the windows you have open surviving the load process? I expect not... A warning to finish your task before the load would be nice. In the middle of setting a schedule, someone joins, the vehicle gets stuck in route finding mode and won't let you into the schedule again. (server appears to have crashed shortly afterwards so I can't tell if the vehicle ever recovered)
A few network/multiplayer thoughts after a few hours on the server. Used Windows/SDL 102.3-3738 and 3744.
1) Desyncs - Lost sync twice on the new year transition. Game time is p****ing so slowly I couldn't wait for a third attempt. - Lost repeatably on clicking new line in the line management tool. Tried a few hours later and it's working now... - Lost a couple times when scrolling around. - Lost when some other player kept pause/unpause/pause/unpause... - Lost a couple times when just it was just sitting. - Can usually reconnect right away. A couple times the server IP remained pingable but simutrans couldn't find a server. And now most recently, simutrans says "server busy" ??.
2) Responsiveness - Generally ok. I'm pinging 150ms to the server afternoon, 300ms late evening (thanks peer1!). Adding train cars in the depot is the only thing that's really unbearable. It takes 3-10 clicks on the car before it actually adds to the convoi, the rest of the clicks are ignored.
3) Joining process - Not good. Game seems to hiccup for ~30secs as other players are joining. Once they join all your open windows close and you're forced back to the human player. Other players joining needs to be smoother for those already connected. I presume the forced window closing/human player are due to the forced load game when another player joins. Instead of the forced load, perhaps the server could pause the game, send it to the new player, and unpause once the new player is ready?
4) Renaming - Client's can't rename anything (signs, stops, lines, etc.) except locally, which is lost on rejoin. The ability to use signs for ingame communication would helpful.
5) Oddities - might not be related to network but simply multiplayer. - My trains are retaining their speed at signals. i.e. if they arrive at a red signal at 50km/h, when the signal turns green they start accelerating from 50 instead of 0. The others players trains in the game are not exhibiting this behaviour. Sometimes my trains behave too... - Goods distribution from factories is being limited by the players stop with the least capacity. eg. Player 1 has a truck stop capacity 64, Player 2 has a train station capacity 320 both connected to the same factory. Once both stops have ~64 goods waiting, the factories output store starts filling up instead of Player 2s partially full station.
Have you used fast forward? There is a known bug with power line revenue when using fast forward.
Actually, you don't need to use fast forward to end up with completely wrong powerline revenue. Anything that disturbs the simloops from 5.0 will do... The patch to fix is sitting in the standard Considered Patches section; Same fix should be suitable for Experimental.
Patch attached. Powerline payments should be based on energy delivered rather than power. My powerline stabilisation patch changed the base calculations from energy to power but neglected the impact on the payment .
Just a note. Originally was not about GUI extension requests. I wanted to know how people expect that GUI elements should behave. I would still like to hear about this more.
Scroll bars - I would expect all scroll bars to continue scrolling when I hold the mouse button down on a scroll button. Some currently do, some don't. - pageup/down should also repeat when holding mouse button down on the scroll bar. None do.
Combobox - I would expect them to be a read only list. You can currently edit the text in the combobox and have the edit reflect back to the item. e.g. In the depot line selection combobox, the text field lets you change the name of the line. Not expected behaviour.
Keyboard focus - Most elements when clicked on now steal the keyboard focus entirely. Expected for a text entry box. Not expected for simple buttons. I would expect normal game hotkeys to continue functioning after simply clicking a button without needing to hit ESC first. Also, if ESC is defined to close the window, then I expect it to close the window - everytime. i.e. Multiple control functions ****igned to the same key, a context sensitive keyboard in essence , is not expected.
I did this a long time ago to get it to work properly on my machine: I couldn't work out how to make it work without doing that. Note that only the SDL build on Windows is affected because of the use of conditional compilation.
I would guess you either don't have the include paths set right in your compiler environment or have installed SDL in the wrong place. #include <SDL/SDL.h> should work. Hardcoding #include "../SDL-1.2.13/include/SDL.h" just breaks things for everyone else.
The conditional compilation for all these target specific files is controlled in the makefile by config.default. i.e. Setting BACKEND=sdl results in simsys_s.cc being added to the source list.
To which #ifdefs do you refer that result in the entire file being skipped? simsys_s.cc is only supposed to be used if Simutrans is compiled with SDL, not GDI. In most cases on Windows, GDI is preferable, but some people prefer SDL. The file is supposed to be ignored in Windows unless the pre-compiler directive "SDL" is specified.
#ifdef SDL is encomp****ing the whole thing. SDL is defined inside a #ifndef WIN32 statement. This must not evaluate to true in my environment - MinGW, SDL. I also note WIN32 and _WIN32 both being used???
I'm afraid Nathaneal is correct - substations within cities is completely busted.
I supplied a town of 3000 with a demand of 25MW from one well stocked coal plant/one powernet. Build 1 substation, 25MW loaded. Build a second and load splits 11, 13. Delete the second and the first stays at 11. Build a 3rd and get 11,14. Delete the first - third stays at 14. And so on... The routine is obviously not recalculating for deletions.
Another case had 3 stations supplying 7, 7, 9. Built a forth station within city limits not connected to any grid, all 4 stations dropped to 0 power.
Also, building a station within city limits adjacent to a factory can only happen once. If you delete it and try to rebuild, it complains of only one station per factory.
25MW is rather excessive consumption for a town of 3000! Especially when most factories are only demanding 1-2 MW. My coal mine with a production of 286 demanded only 1 MW. Once supplied the production only went up to 536 - less than the normal 2x. The mine was well outside of any city. No point in trying any cases of factories with city with the above problems...
Something has also broke with powerline bridges between 7.3 and devel. Build a powerline bridge across a single square of ocean and the two powernets graphically join but retain their original IDs and hence remain functionally separate.
I've also found that if a player tries to build a powerline beside a public service power line, they merge. Two players can build side by side and remain separate. This also happens with Standard...
EDIT: The test game was left running while I composed this message. Imagine my surprise when I tabbed back to the game and found the 4 station case with one disconnected showing load of 8,8,8,0. Deleting stations is also now recalculating properly. Weird. I still stand by 'busted' though...
WTF was done to Experimentals simsys_s.cc... System libraries included by hard coded paths.... Ifdefs that result in the entire file skipping compilation.... WTF???
Restoring to the relevant code from Standard works just fine. Is there some reason for Experimentals butchery?
This is probably a silly idea, but could someone comment on its ramifications? Can a factory check the unused power on the networks it can access for power and request power from each based on either the amount in MW available or the proportion of available power on each?
Sure it can. I believe this is basically what jamespetts has done with his sharing code. The problem is the factory can only know the situation right now; Its decision on where to pull the power from might negatively affect other factories.
Example: Lumber Mill is connected to power grids A and B. Grid A has 5MW available for immediate use. Grid B has 10MW available for immediate use. Mill needs (for simplicity) 6MW. Can the Mill request 2MW from A and 4MW from B? Can the Mill request 5MW from A and 1MW from B?
Let's extend the example by adding a Mine with 4MW demand connected to grid A. The Mill gets processed first. 1) Mill - 5 from A, 1 from B. Mine - 0. Not very good, we have 15 MW total supply, only 10 MW total demand, yet are only fulfilling 6MW. 2) Mill - 2 from A, 4 from B. Mine - 3 from A. Better, but still only supplying 9 MW of our 10 MW total demand. What's needed is 3) Mill - 1 from A, 5 from B. Mine - 4 from A. Now the entire demand is being fulfilled. But how is the Mill supposed to know it can only take 1MW from A? This is where a higher level coordinating authority is required.
Could different modes be made available to the player in the factory info window ("Select power mode: * Proportional * Smallest first * Single supply (if adequate)") I think that whatever balancing is used, this has the potential to become a strategic decision for the player.
Again, sure it could. As a player do you really want to have to fart around with details like this? I don't think I would... not fun. In the multiplayer case, who gets to set the mode? In your original example if grid A and B are owned by different players, surely player A would choose the mode so A:5, B:1, while player B would prefer the A:2, B:4 case. Who arbitrates this conflict?
Turfit - thank you for your thoughts. I didn't have the time to redesign the power system from the ground up (the work that I did took an entire week-end ad it is), however, what I have done seems to work well enough. I have not noticed any inconsistencies in loading/saving.
Timewise - that I can relate to... I think with all the work going into multiplayer, it's probably worth looking into extending my original patch to handle it better. No promises for any timeline though. I'll try to compile an experimental build from your devel branch and throw it some corner test cases.
As for the multiple transformer station problem, I encountered 2 main problems when this was allowed.
1) An inconsistency between the performance from the initial construction and the performance after a save/reload of the game. The first transformer connected to a fab, when stepped will attempt to supply the entire load. Subsequently stepped transformers will only load if the earlier ones had insufficient supply. IIRC the transformers step newest to oldest after construction. However upon loading, they step based on their geographic location - NW to SE. Fixable by iterating along a sorted list rather than a simple linked list. Also would be fixed by default by addressing problem #2.
2) Non optimal use of the total available power across multiple powernets. By this I mean the first stepped transformer may supply too large a proportion of a fabs load leaving it's connected powernet short on power and a subsequently stepped transformers powernet with an unused surplus. Something has to coordinate >> This essentially becomes the cl****ical 'generation dispatch' problem in power systems engineering. Fixable by implementing a load dispatcher routine that determines how much power is supplied through each transformer. Such routines are cl****ically implemented using linear equation iterative solvers on an equation set representing the entire interconnected power system. The required information to ****emble the equation set is spread across multiple cl****es in the Simutrans code. I think a complete refactoring of the power supply code would be required to cleanly implement a dispatcher, hence why I took the simple route of restricting transformers to one per... I'm also concerned about the ability to create a solver that converges on a globally optimal steady (non-oscillatory) solution in a finite and very short amount of time (will need execution every step) given automatically created seed values for all cases of weird and crazy power system layouts that players might dream up. This seemed a lot of work for no real benefit as in the original thread nobody came up with a reason for multiple transformers. But now...
Multiplayer.
Not something I had even considered. I'm aware of the ongoing work to add multiplayer functionality, but still tend to think of this style of game as best a single player experience. I think this requires some discussion on how things should work in a multiplayer environment.
My thoughts on requirements: Powernets remain separate between players. Allowing one player to extend another’s network gets too complicated IMO. Partial payments, etc. Retain one transformer per factory per player limit. Players should be encouraged to merge their own networks. Prevents one player blocking access by surrounding the whole fab with transformers. Limits complexity in the dispatch routine. Senkes only delivery power to fabs - no power flow through a fab. i.e. power will not flow powernet1>senke1>fab>senke2>powernet2. Greatly limits complexity in the dispatch routine. Power flow tries to split evenly between players servicing the same fab but the dispatcher will adjust as necessary to ensure the maximum power is delivered globally. No UI controls - automatic. Players simply place transformers and lines.
I think the above is fine for a cooperative multiplayer session. For an adversarial competition, not so much. Several avenues of player sabotage available, but then the whole game is full of these in other areas too...
Experimental issues.
I haven't looked into the code too deeply or played with it much but.
Fabs located with city boundaries are automatically supplied with power if the city is? I would think it best to require an explicit connection with a transformer. If the issue is building a powerline through a congested city to the fab site, getting the powerline tunnel patch completed along with underground transformers would be a good solution.
Nerodens idea of having city supply and fab supply transformers is good. This prevents a city boundary enlargement that encomp****es a new transformer from changing the players powernet design.
I think a one transformer per player per city limit should also be enforced. Again limiting the calculations.
What is this 7.5 consumption reduction factor? Right now 1 unit of power can generate 1 extra unit of fab production. Is this now 1:7.5?
I see code added to the senkes to share the load. IMHO this is not the correct place to control the power flow. See #2 above... might help some until #2 or similar can be implemented.
If multiple transformers are to be allowed, #1 must be fixed before release. Loading a game and being met with different results that when you left it not acceptable...
power_load * PRODUCTION_DELTA_T / last_power_demand should use brackets, otherwise the result may be implementation dependend. (Or maybe not, I learned C at K&R times.)
Should be ok as is. *, / have the same precedence and l-to-r evalulation.
And there is another technical showstopper for applying your patch: please, use *tabs* not spaces. Your patch break the formating completely.
@#$(#, !@$*#%@, and then $%&^*$&!. Was using tabs, then changed development machines, and the use tab option turned off. Why is using spaces even an option let alone the default. $%^#%$#. [/rant]
I think the power system was in for an overhaul anyway. Though I am a little confused if patch 1 is still need, when factories produce every step. But I will test it and see how well it works with the killer games.
Patch 1 is not needed if patch 2, 3,or 4 is used. Patch 2 not needed if 3 or 4 used, 3 not needed if 4 used. They are standalone.
I would also make the iterator static functions of their cl****es. This is imho the nicer way compared to bloating up karte_t further.
I'll look into this. My C++ is rather rusty being ~15 years out of date... Any examples in the Simutrans code? I just followed what was being done with the other stepped cl****es.
.