Over the Reich - Creation Thread

[Civinator]

I never participated in any multiplayer game. But if you allow, I will post the pdf file with your invitation for the gametest at civforum.de, where I did some reports about ToTPP and especially about some of the great features of this scenario. May be, there will be some civers there who will be interested in the tests of this scenario.

 

[JPetroski]

That would be great, civinator. BY all means please start a thread as they're definitely a target audience here.

 

[Prof. Garfield]

gatherPattern(2,20,cloud2,3,17,21,1) stormInfo[nil][3]={[5]=true,[6]=true,[7]=true,[13]=true,[24]=true,[30]=true,[33]=true,[35]=true,[36]=true,[37]=true,[40]=true,[44]=true,[48]=true,[58]=true,[62]=true,[70]=true,[72]=true,[74]=true,[104]=true,[112]=true,[150]=true,[152]=true,} t

Just to clarify my understanding further - will we basically be adding a polka dot pattern of some sort to the map of storm centers that clouds can form on? I ask because the examples above are fairly large storm systems but I suppose I should also create several clouds that start with perhaps 2-3 tiles, then 4-5, then 6-7 but are small and localized?

Suppose the above storm category and intensity are chosen, and suppose that the 'storm center' is at (50,50,1). Then clouds will be drawn around (50,50,1) in the same way that they were drawn around (17,21,1) when you took your 'snapshot'. So I think that the answer to your question is 'yes'.

It would indeed be useful to have small and localized storm categories, but perhaps it would be more useful to have more intensities for each category of storm, so that they can gradually grow and shrink.

 

[Prof. Garfield]

Just started reading the Readme. It is very important that we have a specific file path relative to the ToT Directory, since we have a lot of 'required' files, and TOTPP doesn't currently search for lua files in the 'active' directory. At the moment, the folder name is OTR3, so either the readme has to be changed, such that you tell people to name it OTR3, or you tell them to name it OTR and I change some stuff at the top of Events.lua. I can make the game look in a few places (I already accommodate a few different possibilities for what the Scenarios folder could be called) but we should instruct new players to put the scenario in a specific place (relative to the main TOT folder) so we can make sure it works for that.

Maybe later I can find a way to cut and paste everything into the Events.lua and not worry about finding the included files, but not while things might have to be changed during playtests.

EDIT: Might as well choose the same name for the 'Scenarios' folder as was used in Napoleon, if you didn't already.

 

[JPetroski]

Ok -- I can change it. We should probably have a text box at turn 1 load for both players telling them that too.

 

[Civinator]

That would be great, civinator. BY all means please start a thread as they're definitely a target audience here.

I will do a first post about the public playtest in the common ToTPP information thread, when you have decided, if you will do any changes to the Readmefile or if the file should stay as it is. May be later, if my free time allows it, I will start a separate thread about the scenario "Over the Reich". As it is difficult to do a report about a multiplayer game, as it is OtR and additionally this scenario is still in development, I started to write a story about your great single player Caesar scenario in my free time (besides still renovating my home). I´m very astonished, that this story at Civforum.de now has more than 4.500 views, so I´m still in 58 BC and have not crossed the Rhine.

 

[JPetroski]

I will do a first post about the public playtest in the common ToTPP information thread, when you have decided, if you will do any changes to the Readmefile or if the file should stay as it is.

I'm sure there will be minor changes before release but it is probably 98% complete/accurate and worth sharing early so people can wrap their heads about it.

May be later, if my free time allows it, I will start a separate thread about the scenario "Over the Reich". As it is difficult to do a report about a multiplayer game, as it is OtR and additionally this scenario is still in development, I started to write a story about your great single player Caesar scenario in my free time (besides still renovating my home). I´m very astonished, that this story at Civforum.de now has more than 4.500 views, so I´m still in 58 BC and have not crossed the Rhine.

I'm glad to see you have enjoyed the scenario!

I can start a thread there for Over the Reich eventually. That way I suppose I'll get notifications and can respond to concerns.

 

[JPetroski]

Suppose the above storm category and intensity are chosen, and suppose that the 'storm center' is at (50,50,1). Then clouds will be drawn around (50,50,1) in the same way that they were drawn around (17,21,1) when you took your 'snapshot'. So I think that the answer to your question is 'yes'.

It would indeed be useful to have small and localized storm categories, but perhaps it would be more useful to have more intensities for each category of storm, so that they can gradually grow and shrink.

Once it's functional I intend to spend the better part of a day playing around with the table. I figured if I started by giving you three categories with three intensities each, I would probably be able to figure out how to expand the table later.

EDIT: Might as well choose the same name for the 'Scenarios' folder as was used in Napoleon, if you didn't already.

I directly lifted (with permission) the installation instructions from Napoleon, so we should be good there.

 

[Prof. Garfield]

Here are the cloud events.

Note: Clouds need to be removed at (182, 58, 2), (242, 62, 2), (243, 63, 2) Cloud functionality won't work if the map has clouds on it before we run cloud generation (since there is no info on what to replace them with when they are removed). I have included a saved game where the clouds are removed, just in case.

At the moment, we can manually press 6 to move the clouds. You can use this to set up an initial weather system, and check that the weather is working as desired. At the moment, clouds will move 'after production', so that no one has a special advantage positioning units.

I've been having some trouble with strange bugs, which bring up an error because an entry in a table isn't there. I think I've solved this issue, but let me know if there are any errors. If there are, there is a good chance they'll be difficult to reproduce. (I suspect it was because I was pressing '6' very frequently and also had a routine to delete 'unneeded' table entries, and multiple instances of the function were trying to deal with the same table)

All the parameters to change the weather are in clouds.lua, not the Events.lua (except the fact that '6' is the key to update the weather). An explanation is included, though I'm not sure that it is helpull instead of confusing. I'm willing to write another explanation if you would find it helpful, so ask if you'd like it.

Basically, storms move east, usually at 6 squares per update (so 12 per turn), but sometimes faster, sometimes slower. Sometimes there is a north or south component to it. Storms have a 'size' between 0 and 1, and this size tends to grow over water and shrink over land (based on the location of the 'storm center', but it is possible to grow on land and shrink in water also). The 'intensity' is selected based on the size, and the number of intensities in the category. A storm that falls to size 0 disappears.

At the very top of clouds.lua, there is an option to allow or disallow clouds over water. I have allowed them at the moment so that the weather patterns are more observable. Other parameters can be found by searching for frontParameters.

Something else I remembered: do we want UBoats to be able to travel north around England? If so, we need a mechanism for that, since they won't be able to sneak in that 1 lane channel. Ideally, I'd like a solution that doesn't require taking them off the map for a few turns, since I don't really want to create that functionality (though I suppose if I did, we could also use it to move planes to the Italian Front also).

 

[JPetroski]

I'll dig into this probably tomorrow or definitely Friday, but it sounds pretty darn good!

I'm not super worried about the u-boats. The space along the north of the map is more for the royal navy.

 

[JPetroski]

Ok - I couldn't resist checking it out quickly before work. A few things:

1. This is more brilliant work and it's going to have a video soon!!! Damn you work and mortgage, damn you!

2. After seeing it in action, I kind of like them over water, even though there are issues with it. I can't do anything about the border and players will just have to deal with that (which I'm sure they can), but the player really needs to be able to see them moving in to plan their attacks. Also it just looks cool. The fact that they effectively create land bridges will require one of two options:

A: We simply institute a house rule that players can't use clouds to cross the channel;
B: I give you a list of coordinates that clouds can never appear on (basically a line through the channel and this is added to the code.

I think A would probably work though I'm not opposed to giving you a list of coordinates if you think it would be an easy plug and play to exclude certain specified coordinate tiles.

We don't need either solution for the high-alt day map as there are no land units on it.
Unfortunately I can't just make clouds "impassable terrain" on the night map because pretty much everything except for railtrack and urban are "impassable terrain" as it stands. Most units can pass impassable.

(This reminds me of another problem - freight trains can move through urban, which will often be covered by clouds, so I may need to go back through the map and make some more rail track connections. I hadn't done this before because it is less aesthetically pleasing but that was before we had the clouds to contend with. I might just do this on the night map as its the only map where this matters).

 

[JPetroski]

Also - I don't need the events, but can I have the clouds file for tomorrow please?

 

[Prof. Garfield]

2. After seeing it in action, I kind of like them over water, even though there are issues with it. I can't do anything about the border and players will just have to deal with that (which I'm sure they can), but the player really needs to be able to see them moving in to plan their attacks. Also it just looks cool. The fact that they effectively create land bridges will require one of two options:

A: We simply institute a house rule that players can't use clouds to cross the channel;
B: I give you a list of coordinates that clouds can never appear on (basically a line through the channel and this is added to the code.

I think A would probably work though I'm not opposed to giving you a list of coordinates if you think it would be an easy plug and play to exclude certain specified coordinate tiles.

I'll make a program that puts into a table all ocean squares that are adjacent to land (when there are no clouds). Then, when I have the cloud events again, I'll forbid clouds on those squares.

(This reminds me of another problem - freight trains can move through urban, which will often be covered by clouds, so I may need to go back through the map and make some more rail track connections. I hadn't done this before because it is less aesthetically pleasing but that was before we had the clouds to contend with. I might just do this on the night map as its the only map where this matters).

Easiest solution is to forbid clouds on night time urban. This would mean that urban targets will never get a defensive bonus for having clouds, but I would figure that, unlike a factory, if you could actually find the city, cloud cover wouldn't be very good protection from indiscriminate firebombing. On that topic, there might be a simple way to introduce night time navigation error. All we do is vary the defensive value of the urban targets.

After production, a function is run that determines how good at night navigation the active player is, (e.g. based on technology, and maybe something else we can think of). The better the player is at night navigation, the lower the defensive value of urban target units.

Also - I don't need the events, but can I have the clouds file for tomorrow please?

Sure, I will assume that you have the clouds file until further notice. I have the events, so I can do special targets (and do the reaction modification for clouds).

 

[JPetroski]

I'll make a program that puts into a table all ocean squares that are adjacent to land (when there are no clouds). Then, when I have the cloud events again, I'll forbid clouds on those squares.

That would save me a lot of time, thanks. It also would prevent people from using clouds to bridge the Rhine. I'm not super concerned about the flak unit moving over land but I am concerned about settlers moving across the channel and establishing a super-secret Allied air base, for example.

Easiest solution is to forbid clouds on night time urban. This would mean that urban targets will never get a defensive bonus for having clouds, but I would figure that, unlike a factory, if you could actually find the city, cloud cover wouldn't be very good protection from indiscriminate firebombing. On that topic, there might be a simple way to introduce night time navigation error. All we do is vary the defensive value of the urban targets.

After production, a function is run that determines how good at night navigation the active player is, (e.g. based on technology, and maybe something else we can think of). The better the player is at night navigation, the lower the defensive value of urban target units.

OK, let's go with the easy solution.

The RAF did develop significant blind flying aids such as Oboe and H2S throughout the war. We might simply use Advanced Radar I and Advanced Radar II to modify the strength of the urban targets slightly to give more meaning to researching these (they are less helpful for the Allied player normally). Perhaps at the start of the scenario the urban targets defense rating is buffed by +4 and researching each of these reduces that by 2? What is easier - should I raise the units starting value by 4 in the rules or would you establish this via events and then remove the buffs with these techs?[/QUOTE]

 

[Prof. Garfield]

OK, let's go with the easy solution.

The RAF did develop significant blind flying aids such as Oboe and H2S throughout the war. We might simply use Advanced Radar I and Advanced Radar II to modify the strength of the urban targets slightly to give more meaning to researching these (they are less helpful for the Allied player normally). Perhaps at the start of the scenario the urban targets defense rating is buffed by +4 and researching each of these reduces that by 2? What is easier - should I raise the units starting value by 4 in the rules or would you establish this via events and then remove the buffs with these techs?

It's the same difficulty either way, and we'll still need to specify the default (and bonus/penalty) in the Events.lua, regardless of the choice. Since the civlopedia reports the current values anyway, I don't know of a reason to have a preference in the rules. It will probably be easier to have a default value, from which additions or subtractions are made when a civ has a particular tech.

I won't do anything with clouds until you give the go-ahead.

 

[JPetroski]

I wont do anything with the clouds until tomorrow morning (early morning). I'll post them again by 5 p.m.

Is it a huge deal to change the file extension in the events from OTR3 to OTR? I used the 3 simply because this is my 3rd shot at this scenario, however none have been released, and this scenario is simply called "Over the Reich" rather than "Over the Reich III" and I think of the two it is much more likely that a person who doesn't read the readme would pick OTR than OTR3, which I doubt anyone would choose.

It's a stupid minor detail but if easy enough to change I think we should.

 

[Prof. Garfield]

Is it a huge deal to change the file extension in the events from OTR3 to OTR? I used the 3 simply because this is my 3rd shot at this scenario, however none have been released, and this scenario is simply called "Over the Reich" rather than "Over the Reich III" and I think of the two it is much more likely that a person who doesn't read the readme would pick OTR than OTR3, which I doubt anyone would choose.

It's a stupid minor detail but if easy enough to change I think we should.

I only have to change a variable in the Events.lua from "OTR3" to "OTR". However, once that is done, the folder you're in must be OTR and not OTR3. For a little more work, I could probably make it so that a list of different potential folder names can be checked, just so that if someone makes a slight variation, things might still work.

 

[Knighttime]

@Prof. Garfield, regarding folder names, I see that in the events.lua for this scenario you're hardcoding a whole bunch of potential paths. What do you think of this as a more generic solution?

local eventsPath = string.gsub(debug.getinfo(1).source, "@", "")
require "package"
local scenarioFolderPath = string.gsub(eventsPath, "events.lua", "?.lua")
if string.find(package.path, scenarioFolderPath, 1, true) == nil then
   package.path = package.path .. ";" .. scenarioFolderPath
end

If you want to have ancillary lua events files in a specific subfolder instead of in the main scenario folder, that could be accomplished easily enough. I think this resolves some of your issues with installation paths and folders, but let me know if you see any loopholes or problems with this approach.

 

[Prof. Garfield]

@Prof. Garfield, regarding folder names, I see that in the events.lua for this scenario you're hardcoding a whole bunch of potential paths. What do you think of this as a more generic solution?

local eventsPath = string.gsub(debug.getinfo(1).source, "@", "")
require "package"
local scenarioFolderPath = string.gsub(eventsPath, "events.lua", "?.lua")
if string.find(package.path, scenarioFolderPath, 1, true) == nil then
   package.path = package.path .. ";" .. scenarioFolderPath
end

If you want to have ancillary lua events files in a specific subfolder instead of in the main scenario folder, that could be accomplished easily enough. I think this resolves some of your issues with installation paths and folders, but let me know if you see any loopholes or problems with this approach.

Excellent!!! If I understand the code, I think this solves the issue. At the very least, it works in place of what I had previously, including after a change of folder name to OTR instead of OTR3. I commented out the line require "package", since package.path is just a variable that tells what the package paths are, so I'm pretty sure require "package" is not correct (if you think it is, please speak up).

Thank you so much!! This also makes it much easier to recommend splitting scenario events into multiple files, which is a big help for organizing things.

 

[Knighttime]

You're right, it seems require "package" isn't needed in order for this to work (although it doesn't stop it from working either). I think I borrowed a portion of this approach from somewhere on the web, and maybe inherited some unnecessary code.

Glad this is helpful! I agree that it's probably a good idea to split huge scenario events files into multiple files, like you seem to be doing with the various modules for OTR. I actually didn't do that for Napoleon, but in retrospect it may have been a good idea.

EDIT: Actually, I remember now: I asked TheNamelessOne about this awhile back (see #1 of this post) and in his response he actually mentioned require 'package' so I think that's why I included that line. Also, as you can see there, he agreed that the scenario folder should be in the Lua search path and said he would add it in a future version of TOTPP. So if that ever happens, we wouldn't need this snippet of code, but in the meantime it seems to fit the bill.