Latvian Republic 1920

[Gumboots]

New beta aint ready to rumble after all.

Just been doing some event testing, and territory variables do not work properly. It's bloody annoying. Looks like you can't use a check against one territory to do anything to another territory. IOW, the "apply to territories" option in the effects screen will only work if you apply the effect to the territory selected in the conditions screen. If you are checking something against Territory A in the conditions screen you cannot then apply any effect to Territory B in the effects screen, even though the editor will allow you to select that option and even though the event validation page will say there are no event errors. It simply will not apply the effect when you run the game live.

Which is not mentioned anywhere at all, and is stupid, and very limiting, and now means rethinking the whole shebang again.

[Gumboots]

Oh and get this for extra stupid. Say you set a territory to no visible border, remapping to a larger territory. Like Pskov in Russia or Klaipeda in Lithuania. So you don't have access to the larger territory, which means you also don't have access to the smaller territory. Can't build rails or anything there.

However, and this is where the mind-boggling levels of blithering stupid come in, if you have an event that checks for access to the smaller territory, it will fire as if you have access. Why? Presumably because on the territories page the smaller territory is listed as not have an access cost, and therefore being open, and the game does not check that it is not part of a larger territory that does have restricted access. Sure, it checks when you try to lay track or whatever, but it doesn't check if it's to do with event scripting. for event scripting it just goes "D'oh it says no restriction on the territories page" and fires the event as if everything was open for business.

Remind me again why I don't make RT3 scenarios. Let me see. Could it be because some (insert complete vocabulary of swearing here) didn't even think to check basic stuff like this before they released the game?

[RulerofRails]

If you are checking something against Territory A in the conditions screen you cannot then apply any effect to Territory B in the effects screen, even though the editor will allow you to select that option and even though the event validation page will say there are no event errors.

You should be able to. I did a quick re-check to have an event check for Meat hauled to Riga Port, but raising cost of track in Poland by 100x. Also transfer territory variables from one territory to another. Both successful. What are you trying to do? Or does this also involve "hidden" territories?

ETA: You are right that the "Comp. has access to terr." doesn't work for "hidden" territories. As long as you can transfer between territories as I managed above you should be able to work most things out. Good luck.

[Gumboots]

I'm trying to allow and disallow territory access. Take the Strugi haulage. The idea is if you fail that often enough you get booted from Russia. So Strugi haulage is counted using Strugi TV's in various ways. Once a certain Strugi variable hits a defined value, this should set a corresponding TV in Russia and that will then be checked to disallow access. It doesn't work.

Conditions are set to test against companies and territories, with the check against the on-screen player's company and the Strugi territory. Effects screen should apply a TV alteration to the Russia territory, but doesn't.

And no, the territories weren't hidden at the time. They were visible but had no access cost. I've now given up on that as it was becoming a major PITA. Fortunately I still had two game variables left, so I am going to use those and have removed the visible borders from the subsidiary territories.

The lack of visible borders shouldn't matter for Pskov, Strugi and Klaipeda. Territory sizes are adequate so just dropping stuff near the middle of town will be fine.

[RulerofRails]

Strange. That sequence of events works fine for me as you had them, even after I set Strugi and Pskov to "hidden".

[Gumboots]

Couldn't get it to work at all. Had to resort to another method. Which works. Just have to fix a few other bugs I introduced by trying to outsmart the editor, but I already have fixes for those (just ran through a high speed event test). Shoud be good to go soon.

Edit: Oh and "Apply to comp/player/territory" doesn't work either. Say I have a test against those three things in the conditions screen, then on the effects screen I want to apply a change to company cash and player cash and a territory variable. Won't do it. It'll do the cash changes but not the territory one. To get the effect on the territory I need a second event that is dedicated to that effect. That will work, but it's the only way that does work.

ETA: You are right that the "Comp. has access to terr." doesn't work for "hidden" territories. As long as you can transfer between territories as I managed above you should be able to work most things out. Good luck.

No. No can do. Does not work. Tried it every way I can think of, and does not work. Or at least, not for what I want to do.

What I had to do was resort to using a leftover game variable. So one test-against-Strugi event checks Strugi TV value, then sets game variable to X. Test-against-Russia event then checks game variable, finds it is set to X, so then uses that as a trigger to change its own Russia TV, and therefore company access.

I couldn't get it to work in a less verbose fashion that that.

Although must say we are pushing the game far beyond anything the devs ever thought of. To be able to see the event debugging fully I would have to make and test four or five separate maps, with the events split between them, before amalgamating them into one for a finished unit. Which I haven't been doing, but probably should in future.

[RulerofRails]

Edit: Oh and "Apply to comp/player/territory" doesn't work either. Say I have a test against those three things in the conditions screen, then on the effects screen I want to apply a change to company cash and player cash and a territory variable. Won't do it. It'll do the cash changes but not the territory one. To get the effect on the territory I need a second event that is dedicated to that effect. That will work, but it's the only way that does work.

Are you using "Force test against..." conditions? That's what these are for.

However, "Apply to comp/player/terr." can only be used to apply the effects to the same territory that you are testing against. So no transfer is possible. You have a PM with a test map attached.

[Gumboots]

Yes, I'm using force test against. Still not having any joy. Ditto with the comp/territory/player thing. In that case I was trying to apply to the same territory as on the conditions page. Had to be, because if you select comp/territory/player you only get the option of the territory on the conditions page. The other territories aren't selectable in that case, which is fine because it is obviously referring back to the conditions page anyway (****** condition is true, etc).

[Gumboots]

Alrighty then. It works now. Figured out a way to make it behave. All events fire as they should, all territory effects are applied correctly, when wanted, and only to the territory they are supposed to be applied to. Ditto all company and player effects.

At least, as far as I can tell. I've played it right through, and run some extra high-speed-not-right-through tests to check event triggers. This one seems to be free of bugs. If someone finds a bug I have no doubt I will hear all about it.

Zip is attached.
.

.
Beta 2 removed. B3 available down the thread.

[Gumboots]

Hey I just whipped this up for a bit of a laugh after all that code testing. The real thing is at Bauska.
.

.

.

[Gumboots]

Tried testing something with pax traffic in Estonia. Started from a game save just after I set things up there, and checked pax numbers over the standard economic cycle with a pretty basic system running: all single track, steel bridges, all trains P8's on auto consist, with most running a simple A>B>C>D>C>B chain between the available Estonian cities (there's not really any scope for other systems in Estonia).

Then I started from the same save, but changed the system to: double track everywhere, still with steel bridges, but with the trains split between P8's running freight only, and Class 500's running express only with a high priority setting. The result, over about ten years of running, was no noticeable difference in the amount of pax delivered. On this section of this map, in terms of loads of pax delivered, the dead basic system was just as effective as the more specialised system and was also a lot cheaper to set up and run.

Not only that, but most of the express trains were making hardly any money. This is with a 70% boost to pax numbers in mainland Estonia and a 95% boost on Saaremaa. There still simply wasn't sufficient traffic to make pure express trains viable on most runs. As a guesstimate, pax numbers would probably have to be up around +120% over the whole of Estonia* before dedicated express trains became the better option. And, even if that were the case, the slower-but-cheaper-to-run P8's would probably be just as effective as the faster-but-more-expensive Class 500's in terms of annual profit, even if the 500's could deliver more loads.

*Edit: Ran some quick testing on this and my guesstimate seems to be pretty accurate. Boosted pax production by an extra 50% for the whole of Estonia, so mainland Estonia was on 120% and Saaremaa was on 145%. This was with hotels and post offices in every Estonian city to help boost express (incl. mail) traffic. At that setting, dedicated express trains were making sense. Not over the top lucrative, but worth having. Freight trains were still doing well too. I think I might change the events to drop the extra 25% for Saaremaa, and just give Estonia as a whole a boost. Ditto for the extra hotel/restaurant/tavern revenue boost on Saarema. Ditch that, and just boost them (less) for the whole of Estonia.

Given that this is primarily a freight hauling game and the Estonian pax thing is a side issue for extra entertainment, I think I'll also drop the pax boost over most of the map. Off the top of my head: around 50% for the map as a whole (down from the current 70%), with Estonia getting an extra 75% pax production and +50% hotel/restaurant/tavern revenue.

(Here endeth the edit.)

Also, pax generation appears to be divorced from the economic cycle, or only loosely tied to it. I had been thinking that perhaps the required number of pax loads could be tied to economic state, maybe ranging from 20 in a depression to 40 in a boom, but it looks like that wouldn't work anyway. AFAICT, boom or bust makes little difference to pax numbers in Estonia.
.

---

.
Another thing I noticed is that when running inline maintenance facilities with a large number of trains, it's useful to go overboard on the number of sheds and towers. By the time you have over 100 trains (I often end up around 150-160 on this map) your company should be rolling in cash and you will be trying to meet high haulage targets. If you only have the minimum number of sheds and towers, they become bottlenecks on heavily-trafficked lines. In effect they act like stations, with everyone stopping there. Doubling up on the usual quota of sheds and towers acts more or less like having dual stations in a large city: you split the traffic between them, so overall there is less congestion. Trains running in one direction will tend to hit their refill limits at a different point on the track to trains running in the other direction, so the result is they will use different sheds and towers if you give them the chance to do it.

[Gumboots]

I was just checking up on populations of towns and cities to see if any of the sliders needed better balancing.

Found this page: http://www.csb.gov.lv/en/statistikas-te ... 33017.html
which then led to this page: http://www.csb.gov.lv/en/statistikas-te ... 33080.html

And that page has a great graphic, showing populations for all major cities and towns in 1920 and 1930 in a simple idiot-proof format. I love it when they give me idiot-proof formats.

Edit: Hey this will be handy for map builders: http://populstat.info/ Gives historical population stats for every country in the world.

Just doing some quick comparisons, and one thing that does stand out is the increasing urbanisation over time. Estonia, Latvia and Lithuania all have current populations within about 10% of the pre-WW2 populations, but the number of people in major cities has gone through the roof compared to the 1930 figures.

[Gumboots]

Got the cities on the map charted up with populations for 1930, rounded off to the nearest 100, for all cities for which I could find that information. My assumption is that the ones I can't find information on (about 20 of them) probably weren't big enough for the authorities to bother with back then. For RT3 purposes they can be given the same sizes as the smallest ones I do have figures for.

Anyway, this is the result...
.

.
The current slider values were taken from the original map, for those cities which were on it. The extra cities I added just had values taken from what seemed roughly equivalent cities among the existing ones. Obviously, these slider values are often wildly at odds with the actual sizes of the cities in the 1920's and 1930's. Salacgriva, bottom of the list for population at only 900, has a slider value of 90%. Yet Rujiena, which at 4,600 was over 5 times the size, has a slider value of only 13%.

Riga is insanely large compared to any other city on the map. To give a true representation of population density Riga would need a slider set to 400%, while Liepaja would be on 60% and Salacgriva would only be on 1%. That simply isn't practical in RT3. Sliders do go to 400%, but a 1% city might as well not be on the map, so a bit of fudging is going to be necessary. So, how to fudge? Off the top of my head: one option would be to take the ratio between cities and use the square root of it. That way it still has a consistency related to actual population size, but the range gets knocked back to something more suitable for cruddy old game engines. That method would put Riga at 400%, Liepaja at 156%, and tiny old Salacgriva at a more useful 20%.

There's an additional trick which I think may be worth trying. Salaspils isn't even mentioned in the 1930 census results. Too small to bother with. These days it is on the outskirts of Riga, and even back in the 1930's it wouldn't have been far from Riga's edges. For game purposes they could be treated as all being Riga. Salaspils could be given a matching slider setting, but with a city recipe oriented more towards the demand side (ie: mainly residential and commercial buildings) and with Riga itself left as the more industrial of the pair. That way building density could be kept a bit saner at Riga (basically, 200% instead of 400%), which is important IMO since building space is so restricted there, but the scenario could be given a commodities draw and pax/mail output more closely matching the true situation.

[low_grade]

Well what happened from 1914 to 1920??? from 40% to 23% urban! cities destroyed by WWI? And not recovered through the 1930s. Statistics do tell a story, I love them!

[Gumboots]

Ah! If you mean Latvia itself I can answer that. There was a big program of land redistribution, taking it off the traditional large estates (mostly owned by Germans anyway) and giving it out to small family farm enterprises to get the country self-sufficient in food and the people employed. So urbanisation dropped initially after WW1, before rising again later (presumably when people found out that farming was hard work and there was easy money in the cities).

If you want a quick rundown on it, check out this page: https://www.lu.lv/adz/arhivs/50/agriculture/

If you're really pushed for time, just do the second paragraph.

One interesting point there is that in the 1920's Latvia imported large quantities of grain. They didn't get their own grain production rolling until the 1930's. Apparently the climate has a lot to do with it. Cows and pigs are more snow-proof and rain-proof than grain crops.

Come to think of it, this could be an addition to the scenario if I can figure out a way of finangling it in.

[Gumboots]

Anyway I had an idea to deal with Riga's gigantic size compared to everything else on the map. The port of Riga is not exactly the same as the city of Riga. Basically the docks themselves are a tad further downstream than the city centre, which is quite normal for cities that have ports attached. The island of Kundzinsala is an industrial area that deals with all sorts of maritime stuff. That's around the bend from Riga city, about halfway to the Daugava river's mouth at the Gulf. There are residential areas around it, in what's called the Northern District. This is an ideal way of dealing with the size of Riga in RT3.

I tried setting the Riga slider to 400%, but the results weren't that great. However, moving the scenario's Riga a bit further upstream, to its real life location, and setting the slider at 300% gives a pretty good result. The catch is that a/ that's still not enough to give a true representation of the size of the thing compared to other cities and b/ there aint no way of getting an RT3 port attached to it. So, adding a second RT3 city for the port itself, with the same slider settings as the current Riga in the beta, grunts total size of the combination up in the right range, and allows a port to be attached to the coast.

There was a main export terminal during the 1920's and 1930's, and they very helpfully gave it an idiot-proof name: Exportosta. You don't even need to speak Latvian to figure out what a place called Exportosta will be doing. It's a no-brainer, and won't be confused with Riga per se, so is ideal for in-game use. The real Exportosta is about halfway between Kundzinsala and Riga city centre, but for game purposes I'm fine with fudging that a bit so we can have a useful and historically relevant name attached to an RT3 port on the coast.
.

.
The white outline there is the game's city regions, that show up in blue against the yellow surrounding region in the editor, for Riga city and Exportosta combined. These are the limits for seeding for any city, but it seems to be coded so they start from the middle and work their way out, much like real cities do. The Exportosta region provides the same amount of available coast for ports as the old Riga did, so a second port will be able to seed sometimes, and the building distribution suits a major city with port attached downstream. It looks and feels about right.

The amount of recoding required is negligible. The haulage goals use the port territory (not region) anyway and the few connection events that require Riga per se were easy to change. It's ready for a trial run, but I'm going to apply a few more tweaks first.
.

---

.
Edit: Ran the slider values through a spreadsheet to see what turned up for new values consistent with actual population. Fudged the lower end of the scale, since anything below 15% for a slider setting only seeds one little house at the start of the game. 15-19% seeds two little houses, which is about the minimum I think is worthwhile, so I called 15% the lower limit and just rounded all the tiny ones up to that.
.

.
The numbers came out as shown in the shot, and funnily enough it's very close to Beta 2 for overall population on the map. The total difference is only a few percent, but of course the way it's arranged is going to be quite different in places. I've had a quick scan over it and think it will work, so will get onto testing it later in the week.

[Gumboots]

Just ran some quick seeding checks for scenario start. Generally seems to work well. Tweaked Riga/Exportosta a bit, to 285% and 180% instead of 300% and 165%. Also realised that massively boosting Riga's density slider meant it was necessary to wind back the individual industry sliders there. The other side of that is the towns which have their density sliders wound back may need increases on some industry sliders.

With density sliders, some towns which lose a fair chunk of territory to water may also need their density sliders boosted a bit, so they generate results which match similar-sized towns that are on clear terrain. I've already tweaked a couple of these. It should be easy enough to nail it all down pretty quickly.

The main change in Beta 3 is going to be increased terrain height. I thought it was a bit boring and didn't really give the right feel, so tested with various overall height increases. +30% turns out to be good. Sounds like a lot, but isn't in the context of this map. It's still extremely buildable, with no sweat whatever. In some ways it is easier because the increased emphasis on the terrain shows you where to go. I tested it on +40% and was able to connect everything on the map, quickly and with reasonable grades, and usually with several different options for getting there. The only reason I wound it back to +30% was looks. 40% was just a bit much to feel right, while 30% is nice. I may end up giving it a tiny bit of route smoothing here and there, but it doesn't really need any AFAICT. The only places it really needs smoothing are some of the isolated peaks, which you'll never build on but which look a little odd, so those will get a touch-up.

So all of the above means it should play much like Beta 2, with the obvious exception that there will be greater population and industry concentrations in a few key cities (Riga, Liepaja, and Tartu being the main ones) and that the terrain will have a better feel to it. I have also thought about events. Russia is pretty well sorted, so no changes there. There's not much that can be done with Poland as it's only a tiny snippet, so that wont change. I'll still be tweaking the Estonian pax stuff for balance, but I had an idea about Lithuania.

The existing 30% reduction in load/unload times at Lithuanian stations, once you connect Panevezys to Mazeikiai and Klaipeda, is frankly not very interesting. Lithuania is where most of the significant grades are, so I think I'll re-jig that event to allow purchasing a pulling power boost. +30% pulling power in exchange for +10% loco purchase cost feels about right. To compensate for this, so it doesn't go over the top, the silent event at the scenario start (which boosts pulling power by 20%) will be removed. This will give more interest to Lithuania with no adverse effects.

[Gumboots]

Made a few tweaks. This slider settings stuff is interesting to mess with. At high building densities for the city itself, it doesn't seem to matter much how low you set a particular industry as long as it's more than 0. Settings of anywhere from 1% to 10% or so seem to produce much the same results in the new Riga, with 3 each of various industries being generated at times, with only 1 or 2 being generated at other times. I think the solution will be to simply set some more industries to 0 in Riga itself, and let them be picked up by Exportosta or maybe Salaspils. So I might leave the Dairy Processor and Brewery active in Riga, and only have the Tool & Die active in Exportosta. Could also reduce initial density in Riga a bit and boost Exportosta to compensate. Just a matter of loading a couple of dozen seeds to see what happens.

Fixed a bug with the ports at Klaipeda too. Although Klaipeda was set to use its own unique port recipe, when it seeded a second port it would always use the Riga recipe for it. No idea why it did this, but it did. If it seeded a third port, which it did fairly often due to the coast there matching the economic grid perfectly, the third port would be back to having the correct Klaipeda recipe. I've turned the port slider way down so it doesn't spit out three ports so often, so hopefully that part will behave.

With the second port using the Riga recipe, I figured the way to fix it would be to make a new port recipe for Riga, using the last port on the list (#12), and then set the old Riga port recipe, renamed "Klaipeda port alt", to be the same as the original Klaipeda port. Klaipeda now seeds Klaipeda ports, and Riga still seeds Riga ports. This is good. Since Klaipeda always seeds the second one as "alt", there is scope for introducing a bit of variety there if there seems to be any benefit in it.

The new Lithuania event has been added. You still get the 30% reduction in load/unload times at Lithuanian stations. That's automatic once you satisfy the connection criteria. The new event that has been added after that gives you 4 choices:

1/ +30% pulling power, for +10% purchase price.
2/ +1 level reliability, for +10% purchase price.
3/ Both improvements, for +20% purchase price.
4/ None of the above. Price stays the same.

Estonia events have been revamped so that the pax production is down to 60% for Latvia, but is up to 120% for Estonia. The latter is now uniform across Estonia, with no extra cargo boost for Saaremaa. These events also now give an automatic 20% reduction in load/unload times for Estonia, and 10% reduction in load/unload times for Latvia. The pax production increase no longer applies to Lithuania, Poland or Russia. I think events are all done now.

Next big thing on the list is fixing bodgey rivers. I really do not like RT3's terrain modification tools. They are as rough as hessian underpants, and the lack of any undo button is an especially sadistic touch. Nice of them to add that on top of the almost uncontrollable tools. However, I had a crack at it last night on a test copy of the map, and after practicing (and swearing) a lot I think I can now get them all sorted in one night. That would be great, because then it would be at the stage of only needing minor slider tweaking, new terrain painting, and trees. Then I can call it done.

Oh yeah I figured something out about terrain painting. Trees are important to give the right feel to a place (must make Australian tree pack sometime...) and RT3 has a limited range, so you have to pick the best match for the region in question. That means terrain painting should come after trees, because it has to match the trees. I was thinking terrain painting first, add trees last, but on reflection that's not going to be the best way of doing it.

So, sort out trees first, then get a .bmp together that ticks all the other boxes and matches the trees as best it can (much photoshoppery coming up) and then do the final terrain touch-ups. From a bit of quick testing, it looks like using the splatter option for mixing textures will be best in forested areas. It gives a good effect, like deep shade/dappled shade/intermittent light patches.

[Gumboots]

Got the !*@&#^@ rivers done, or as done as they're getting for now. They flow downhill everywhere. No uphill-going rivers. In fact I'd go so far as to say it's ready for trees. Trees I can do. Trees are easy.

[Gumboots]

Ok, Beta 3. With downhill flowing rivers even. If you downloaded Beta 2 and haven't played it yet, I suggest not bothering. Just let me know what you think of this one. It should be pretty good.

Edit: Just though of a few details. Noticed that building seeding can glitch the river at Daugavpils, so will take a look at possibly using reserved cells there. I think for the next beta I'll also relocate the warehouse and steel mill to the southwest corner of the Daugavpils territory, to give a cleaner run out of town for going into Poland. Feel free to butcher it in the editor if you like.

There's a minor glitch on the second river to the east of Abrene. Easy to fix, so will be done in the next beta. Figures I'd have to miss one spot on all those rivers. I was going cross-eyed by the end of it.

Other than that it seems ok.

Eidt: Hey there's a bug in this one. Don't know how it crept in, but anyway: the Saaremaa connected! event should be testing for Riga connected to Kuressaare. Somehow it's testing for Riga connected to Riga. Anyway, if you edit the first city to city connection to read "86 connected to 47" it will work.

I've checked all the other connection events and they seem to be fine. It's only this one that acquired a bug.

Edit again: Got some more thoughts for Beta 4.

1/ Definitely needs to make inventive use of reserved cells in some places. Daugavpils and Jurmala in particular, but could be useful in a few other places too. I've never used reserved cells before, but it's obvious how they work so it will be easy to implement.

2/ Raising the terrain height apparently got rid of the narrow strip of water between Muhu and Saaremaa. Must have been a rounding error thang in the mesh. The water will be going back in.

3/ Will do some minor route smoothing. Not to change grades as such, but just to get rid of annoying little lumps that make the trains buck.

4/ City/industry seeding seems pretty good. Probably won't need much changing.

5/ Not completely happy with some regions. Will think about tweaking those.

6/ Still finding occasional minor river lumps. Given the eleventy billion miles of rivers in this thing it's not surprising. Will fix 'em as I find 'em.

7/ The above are all minor debugging, but I'm thinking of one actual change. The original idea of the Estonian pax thing was to provide some added interest while waiting for the main haulage goals. The bonus for 20 loads is nice, but very easy to get once you have most of Estonia connected, so is basically a set and forget operation regardless of economic state. To give it some spice I think I'll remove the 20 loads bonus, and instead have it pay out a $5k bonus for every load of pax hauled to an Estonian station.

That should make it less set and forget, because you'll have an incentive to optimise Estonia for pax under the current conditions. With the amount of pax in Estonia now it's not hard to haul 80-100 loads per year if you go for it with dedicated express trains and double tracked main lines. In fact I may knock the production boost for Estonia back to +100%, and to +50% for Latvia. The tally for the bonus can be done on the existing one line on the status page, which will can save a newspaper at the end of the year. So it would read: Passengers to Estonia: **** loads. EOY bonus: $******