24-09-2004 18:40									#1
	In Which Techumseh Instructs Allie in MultiMapping Got spare money?

And so we gather for another instructional discussion, between mentor (this time played by Techumseh) and student (this time featuring Allie). The topic of discussion today is how to make a civilization invincible in ToT by placing their cities on different maps.

And now for our feature presentation. Techumseh?

edit: put in 3 h's.

	24-09-2004 21:10									#2
	In which the lesson begins. Enter the AD-FREE zone

First we must ask this question: Why does the original game have one map, the extended have 2 and fantasy and sci-fi have 4 each?

This is determined by a section in the Rules Txt. called "@Secondary Maps". This is described in the Prima Guide for ToT in the following terms: "This one is funky, and we don't encourage casual scenario designers to mess with it." But we're serious so let's carry on as if we're in our right minds.

This section is missing in the Rules Txt. of the original game. But we can find it in the others. Here is the @Secondary Maps section from the Sci-fi game. It's located immediately following the @Terrain section:

; Secondary Map Characteristics
; (modify at your own risk)
;
; 0, 1,2, 3,4, 5,6,7,8, D1,M1,F1, D2,M2,F2, D3,M3,F3
;
; 0=map type: 1-subsea, 2-subdirt, 3-floating, 4-land dominant, 5-gas giant, 6-std
; 1=avg blob size (types 3 and 5 only)
; 2=avg # of blobs (types 3 and 5 only)
; 3=avg bridge length: 0-no bridges (types 3 and 5 only)
; 4=avg bridges per blob: 1-4 chance, 0-none (types 3 and 5 only)
; 5=# blue rooms
; 6=# ice rooms
; 7=# fire chambers
; 8=# storms
; DMF=desired length, minimum length, frequency
; specific effects depend on map type
; for SF game:
; DMF1=Mts, Hil, No
; DMF2=For, Mts, Hil
; DMF3=Hil, No, No

@SECONDARY_MAPS
3, 15,22, 18,2, 0,0,0,0, 3,1,50, 6,1,50, 0,0,0,
4, 25,30, 0,0, 0,0,0,0, 12,1,50, 8,1,50, 3,1,50,
5, 15,17, 25,3, 0,0,0,17, 8,3,50, 0,0,0, 0,0,0,

Clear enough. Now we only want to make a scenario with two maps, using 2 premade maps. So we don't need most of this stuff.

This is what we need:

@SECONDARY_MAPS
6, 0,0, 0,0, 0,0,0,0, 0,0,0, 0,0,0, 0,0,0,

Stick this in the Original game Rules Txt. right after the @Terrain section and start a game. Select "start on pre-made world", and you will be prompted to select 2 maps. They must be the same dimensions. Save your game. Lesson #2 to come.

	24-09-2004 21:26									#3
	In which a Reading is assigned Support Apolyton, pre-order Civilization IV

http://coc.apolyton.net/guides/map_transport.shtml

Questions?

	25-09-2004 05:31									#4
	Support Apolyton buy from Amazon

No questions, just comments. That article is quite confusing and indeed erroneous in some sections.

When dealing with map transport relationships all you really need to know is that there is a total of 6 possible combinations for map connectivity (with the maximum allowable number of maps, ie, 4). These are: (0,1), (0,2), (0,3), (1,2), (1,3) and (2,3). The game gives you a choice of 3 graphic icons (cities.bmp) to depict your transport sites. Therefore, you have a maximum number of 18 (6 x 3) possible function/graphic combinations. Since the data is stored in 2 bytes, the game permits only 16 of these.

The article is fine up until the point where it describes the use of sites and native transport ability, ie, Advanced Units sections E and F. I'll use an example to explain myself.

I have a 4-map scenario with the following relationships:

@MAP_TRANSPORT_RELATIONSHIPS
0,1 ;Graphic 1
0,1 ;Graphic 2
0,1 ;Graphic 3
0,2 ;Graphic 1
0,2 ;Graphic 2
0,2 ;Graphic 3
0,3 ;Graphic 1
0,3 ;Graphic 2
0,3 ;Graphic 3
1,2 ;Graphic 1
1,2 ;Graphic 2
1,2 ;Graphic 3
1,3 ;Graphic 1
1,3 ;Graphic 2
1,3 ;Graphic 3
2,3 ;Graphic 1

Here, I have the maximum number of 16 different combinations defined – Graphic 2 (2,3) and Graphic 3 (2,3) missed out.

Transport sites are named in Labels.txt. There are 3 slots, 1 for each graphic type. In this example, we'll call them Stargate (graphic slot 1), Cave Entrance (graphic slot 2) and Stairs (graphic slot 3). We'll allow the Stargate to have connections from any map to any other map, the Cave Entrance to connect maps 0 and 1, and the Stairs to connect maps 0 and 1, and maps 1 and 2.

For 3 types of builder units with the ability to exploit all of the connection possibilities for each site type, section D would look like this:

1001001001001001 ;Stargate Builder
0000000000000010 ;Cave Builder
0000100000000100 ;Stairs Builder

Note that half of the relationships I have defined in my @MAP_TRANSPORT_RELATIONSHIPS table aren't used.

Where the article goes wrong is in the explanation of site usage. It suggests that you can restrict usage according to graphic type. This is only true if each of the 3 types shares no map connectivity relationships. You can only define a unit's inter-map movement by the 6 possible types of map connectivity – the type of transport site is irrelevant.

Example: Same scenario as above. Assume that you wish to restrict a Troglodyte unit to use Cave Entrances (movement only possible between maps 0 and 1). You'd have this defined in section E as follows (according to the article):

0000000000000010 ;Troglodyte

However, this does not actually restrict the Troglodyte from using any Stargates or Stairs that also connect maps 0 and 1. In fact any of the following combos (with the map transport relationships as they are defined above) would have identical effects in the game:

0000000000000001 ;Troglodyte
0000000000000010 ;Troglodyte
0000000000000100 ;Troglodyte
0000000000000011 ;Troglodyte
0000000000000101 ;Troglodyte
0000000000000110 ;Troglodyte
0000000000000111 ;Troglodyte

This should be even more obvious with native transport ability, since defining a relationship with a transport site type is pointless. If you wanted native transport ability between maps 0 and 1 in this example, again any of those 7 combos listed for the Troglodyte above would be suitable for section F.

A few other things to note:

• Transport sites can be pillaged. They have ownership like other terrain improvements, so pillaging a site belonging to another civ is an act of war. When a transport site is created (either by unit or cheat menu), ownership is determined by its proximity to the nearest city (regardless of who built it).
  
• Transport relationships are saved to the .sav file the first time it's created. They can only be changed thereafter by events (the Transport action) or hex editing. Further modifications to rules.txt cannot be transferred to the .sav game by simply resaving.
  
• You can create one-way transport sites by deleting one of them in the cheat menu – can have a dummy transport site at the destination square or nothing at all. Here's a quote from me over at CFC (it refers to creating one-way transport sites with a dummy destination site):
  
  

  quote: An interesting side effect of this latest transport site quirk is that you can actually create one-way portals (which I'm now doing). For example (using the cheat menu): Create a transport site linking map 2 to an impassable terrain tile in map 3. Delete both sites. At the same (x,y) coordinates, create a site on map 1 that links to map 2. This will allow access to map 2. However, the original attributes of the map 2 site will not be cleared – it's still linking to the impassable location in map 3. Therefore, map 1 -> 2 is allowed while 2 -> 1 is not.

	25-09-2004 07:04									#5
	Put an end to popups!

I'm aware of this error, which goes beyond William's tip. It's implied in the Prima Guide as well, co-written by John Possidente himself. I discovered it trying to find extra hiding places for Frodo and Sam while working on the 4 map version of your LOTR scenario.

However, the tip is very good for outlining the concept, and from there we'll go on to modifying the @MAP_TRANSPORT_RELATIONSHIPS section, and cover the 2 ways of fixing these relationships in a scenario. We'll have a working 2 map scenario for Allie shortly. Stay tuned.

Last edited by techumseh on 26-09-2004 at 02:38

	25-09-2004 17:41									#6
	In Which the Audience Asks a Question of the Instructors Inflate your Upload Space

Query the First: The scenario is already quite far advanced in city building and map placements are concerned. Will a scenbuilder need to restart in order to include a second map?

Query the First-and-a-half: Said scenario only has one map. Will a second map be insertable at this stage?

	25-09-2004 21:39									#7
	Support Apolyton, buy Galactic Civilizations

OK, that's easy to to as well. Your second map must be of exactly the same dimensions as the first. Load the scenario, go to the Map menu above and select "import map". Pick your map file and save. Once done it's permanent, so back up your original save and scenario files first.

To set the intermap relationships on an existing scenario requires a temporary events file. What units of what civs do you want to move from the new map (world 1) to to the original (world 0)?

BTW, be sure that you make Terrain 3 and 4 bmps for your new map as well. Depending what folder everything is in, it's possible to have no terrain for your new map, which is a bizarre experience.

Last edited by techumseh on 25-09-2004 at 21:45

	26-09-2004 00:22									#8
	Support Apolyton buy from Amazon

Will the same improvements and cities be used on both maps?

I had an idea to have a moon map as well as an Earth map.
That is doable enough, but it seems impossible to tailor the moon world to the other graphics.

Unless I used an alien race with 'moon' cities, and was
not intending to have an 'Earth' race conquer them.

Oh well, seems like I may have to ditch the moon idea!

	26-09-2004 00:39									#9
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

Curt, have you played Kestral's scenarios? He was doing multimap scns back when the rest of us were still complaining about ToT's bad graphics. His first (and still my favorite) is Escape from Sol, which involves a moon map. It and the others are downloadable from the Cradle site. http://coc.apolyton.net/scenarios/scn-escsol.shtml

	26-09-2004 02:33									#10
	Support Apolyton buy from Amazon

Back to the subject at hand.

Just as an example, suppose you have a Tarzan scenario, with 2 maps. Map 0 is the jungle floor and map 1 is the treetops. You want your Tarzan unit to be able to move between them, in order to escape from the lions, the badguys, and Jane, who wants him to do housework.


Once the initial game is launched, you can no longer change the inter-map relationships by editing the Rules text. (This also goes for @CIVILIZE2 and @LEADERS2 which control the researchability and ownability of technologies.)

Fortunately, you can modify these things by means of events. I always use this method anyway. You'll need a temporary events file. But first, go back to your Rules text and add this:

@MAP_TRANSPORT_RELATIONSHIPS
0,1 ;0/1

This sets the first map transport relationship entry as between the map 0 and 1 - the jungle floor and the treetops.

Rename your existing Events Txt. so it doesn't function and create a new one, as follows:

@BEGINEVENTS

@IF
SCENARIOLOADED
@THEN
JustOnce
Transport
Unit=Tarzan
State=On
mode=Native
Type=0
@ENDIF

@ENDEVENTS

Native means that Tarzan has the native ability to move from one map to the other - he does not need a transporter. Type 0 refers to the first of the 16 map transport relationships which you have already set as 0,1. Launch the scenario, selecting whichever civ moves first so you don't have to reposition a bunch of units, and save it. You may want to do a little clean up on any extra shield your cities may have accumulated as well.

Tarzan now has the ability to move between the maps, regardless of what's in the @UNITS_ADVANCED field. But he wants Queen La to join him in the treetops. So the same type of event would have to be included to allow this, substituting Queen La for Tarzan.

If you wanted to give this ability to any unit you could also do so by editing column F in the the @UNITS_ADVANCED field, BEFORE STARTING THE ORIGINAL GAME IN THE FIRST PLACE, as follows:


; A B C D E F G

@UNITS_ADVANCED
11111111, 00000000, 0, 0000000000000000,0000000000000000,0000000000000001
, 00000000 ;Queen La

It's reverse programer notation, so the 0 slot comes last.

The badguys, in the meantime have found a way up the trees - a rope ladder (transporter site). But they need a little help from events. So we add this to our temporary events:

@IF
SCENARIOLOADED
@THEN
JustOnce
Transport
Unit=Badguys
State=On
mode=Use
Type=0
@ENDIF

In this case, the badguys can only get into the trees using the transporter, hence Use instead of Native.

If you wanted to do this without temp events, before starting the initial game, you could modify the Rules as follows

; A B C D E F G

@UNITS_ADVANCED
11111111, 00000000, 0, 0000000000000000,0000000000000001,0000000000000000
, 00000000 ;Badguys

The E field affects transporter use.

Now Jane is not worried about the badguys, who Tarzan has already dispatched, but she is concerned about Queen La. However, the rope ladder is now gone. So being a resourceful woman, she has engineering abilities, and will build her own ladder. These events are added so she can:

@IF
SCENARIOLOADED
@THEN
JustOnce
Transport
Unit=Jane
State=On
mode=Build
Type=0
@ENDIF

And she wants her lawyer to also be able to build ladders, so the same event is added for her. If she was really planning ahead, she would have edited the Rules file before starting her game as follows:

@UNITS_ADVANCED
11111111, 00000000, 0, 0000000000000001,0000000000000001,0000000000000000
, 00000000 ;Divorce Lawyer

The D field affects ability of a settler or engineer to build a particular type of transporter.

But La is a bit smarter than Tarzan, so she has found a way to keep Jane's lawyer out of the treetops. The Rules have been modified accordingly.

@UNITS_ADVANCED
11111111, 00000010, 0, 0000000000000001,0000000000000001,0000000000000000
, 00000000 ;Divorce Lawyer

The last 4 spaces of the B field control which units can enter which map. The last spot corresponds to map 0 and the second last to map 1, which is our treetops map. So no lawyer in the treetops, not that it helped Tarzan in the end.

Once you've loaded the scenario with the temporary events and saved it as a scenario, remove the temporary events and restore your original events. The changes are now permanently embedded in your scenario. New events are unaffected.

This is probably all you need. Let me know how it goes.

Last edited by techumseh on 26-09-2004 at 10:44

	26-09-2004 06:03									#11
	Support Apolyton buy from Amazon

quote: Query the First-and-a-half: Said scenario only has one map. Will a second map be insertable at this stage?

After some Scottish ale, my recollection is dim, but I remember losing my cities (or they were somehow corrupted) when I added a map to EA.

Btw, this thread reads like a book series my son is into: "A Series of Unfortunate Events" by Lemony Snicket.

	26-09-2004 06:26									#12
	Support Apolyton

quote: Originally posted by techumseh Launch the scenario, selecting whichever civ moves first so you don't have to reposition a bunch of units, and save it. You may want to do a little clean up on any extra shield your cities may have accumulated as well.

If you load the scenario as you would a saved game you can avoid all of this (and it can be a big deal if your scenario is at an advanced stage). Your new events file will be loaded either way.

quote: Originally posted by techumseh She now can, without another event being necessary. Having established the 0,1 relationship by events, you can now give the same ability to any unit by simply editing column F in the the @UNITS_ADVANCED field...

This doesn't make sense to me. You seem to be suggesting that if you use the Transport action to alter one type of transport relationship (build, use, native) for a particular unit, then the corresponding bytes for all others are rewritten from rules.txt. That essentially means that you would be restoring the original values from that file – something you don't want. If I've completely misunderstood what's happening here, I'll confess to being a retard.

BTW, I am familiar with the layout of these bytes in the .sav/.scn file, after all I hex-edited in all of the transport relationships for the War of the Ring scenario after the aforementioned article lead me up the garden path.

quote: Originally posted by Boco After some Scottish ale, my recollection is dim...

Are you actually ever sober in these forums?

	26-09-2004 09:46									#13
	Support Apolyton, buy Civilization III: Complete

Well, I better go back and see if my recollection is correct. I'm pretty sure that the event sets a map relationship rather than how a specific unit relates to it. I'll report back soon.

Once one is into Lemony Snicket, Scottish Ale is just around the corner.

	26-09-2004 10:05									#14
	In which Catfish Instructs Techumseh Help yourself to an AD-FREE life

Catfish is right. The temp events file must have a separate event for each type of unit. The adjustments to the @UNITS_ADVANCED field will merely serve to reflect what is stored in the scn file.

I'm not sure about the assertion that the events file will be loaded if the game is launched from a save file. As I understand it, the events file is only read when a scenario is first started and has no effect when you load a saved game. The events for a saved game are stored in the sav file. But hey, I've been wrong before.

Note: The offending post has been edited to remove all traces of my previous error. Except this. For now.

Last edited by techumseh on 26-09-2004 at 10:48

	26-09-2004 16:10									#15
	Support Apolyton

quote: Originally posted by techumseh I'm not sure about the assertion that the events file will be loaded if the game is launched from a save file. As I understand it, the events file is only read when a scenario is first started and has no effect when you load a saved game. The events for a saved game are stored in the sav file.

You can load the game from either a .scn file or a .sav file. The .scn file can be loaded in the same manner as a .sav file (ie, Ctrl+L). It won't appear in the file list; you will need to type "ScenarioName.scn" in the File name box. The .sav file may or may not contain embedded events. If it does, you will need to run delevent.exe on it first to clear the old events before you can successfully load the new ones. If you want to be certain that an events file has loaded, add a text message.

	29-09-2004 08:22									#16
	Increase the size of your Attachments

Any luck?

	29-09-2004 17:52									#17
	Support Apolyton, pre-order Civilization IV

*still digesting*

Should have more time to work this evening.

	07-10-2004 07:45									#18
	Support Apolyton, buy GURPS/ Alpha Centauri

quote: Originally posted by Boco After some Scottish ale, my recollection is dim, but I remember losing my cities (or they were somehow corrupted) when I added a map to EA. Snicket.

This effect can be eliminated by going to "Scenario Parameters" and selecting "Wipe All Goodie Boxes".

	22-10-2004 07:13									#19
	Inflate your Upload Space

Thanks for the help on this, everybody! It's great to have a skilled elite to offer their insights...

I just moved house AGAIN (for the 5th or 7th time in four months). But hopefully once work and home are sorted out, I can get back to working on this properly like an intelligent rational person.

I think the scenario would probably have two maps. One for the earth's surface, and one for the orbital level map above it. The sorts of things that could go into the orbital level would obviously include satellites (which have no attack but can shift between the maps to help take GPS photos of various areas) and long range missiles.

My thinking is that I'll have satellites either have infinite fuel or have a very high fuel rating, so they can travel around the world many times and "warp" into the world map to take pictures. If there is a way of doing so, I would like to impose a limitation that they have to end their turn in the orbital map, not the surface map.

Long range missiles too would have the ability to shift between the two levels. They would have extended fuel supplies, so they could take multiple turns to get to their destinations. If they stayed on the normal surface map all the time, this would cause realism problems as your average fighter jet could take them out (which isn't really feasible... yet). Using an orbital map, they could fly overhead towards various beneficiary cities before delivering ther payloads. The targets would never see them coming, unless they had satellites up there.

Further ideas may be to come later but right now I need a beer.