Need help with multimaps

The Person

Deity +2
Joined
Oct 7, 2003
Messages
2,712
Location
Trondheim, Norway
As the thread title says, I need some help with the "multimap" feature of ToT. When I look in the rules.txt I notice a few parameters that oviously play part in it. But it seems so complicated. Could someone explain those to me?

BTW, could somebody tell me about their experiences with CivConverter? I have something from MGE that I want to port to ToT, because of its multimaps feature. That's why I ask.

Any help is appreciated.
 
The Person said:
As the thread title says, I need some help with the "multimap" feature of ToT. When I look in the rules.txt I notice a few parameters that oviously play part in it. But it seems so complicated. Could someone explain those to me?
Are you referring to the @SECONDARY_MAPS section? If so, as a scenario designer (presumably using a pre-made map), you won't have to worry about those settings; they're used for the generation of random maps, eg, Fantasy and Sci-Fi scenarios. There's a good explanation of these settings in this thread at Apolyton. What you do need to worry about is the number of lines you have. Each extra line will create an additional secondary map (to a maximum of 3).

Therefore, a 4-map scenario would require 3 lines:
Code:
@SECONDARY_MAPS
6, 0,0, 0,0, 0,0,0,0,    0,0,0,  0,0,0,   0,0,0, ;2nd map
6, 0,0, 0,0, 0,0,0,0,    0,0,0,  0,0,0,   0,0,0, ;3rd map
6, 0,0, 0,0, 0,0,0,0,    0,0,0,  0,0,0,   0,0,0, ;4th map
Edit: I just read the excerpt from the official ToT guide (in the link) in full and noticed this sentence:
Each of the three entries (There must be three, no matter how many maps you actually have in your scenario) controls the overall layout of the terrain in one of the secondary maps - in order.
This is in fact a load of bulldust (and it's not the first time that source has been incorrect). It's one line per additional map. Just check the @SECONDARY_MAPS section for the Extended Original game: 2-map scenario, 1 line.
The Person said:
BTW, could somebody tell me about their experiences with CivConverter? I have something from MGE that I want to port to ToT, because of its multimaps feature. That's why I ask.
It works, but it's not without its problems - and if you're going to be importing extra maps at a later date, you're going to have more (eg, map transport relationships). It can be done, but it's not for the faint-hearted. Here's a thread which outlines a few CivConverter issues/problems. Other issues not listed there include mirroring left-facing units, mapping unit sounds, sorting out sprite options, hex editing out casualty lists, amongst others.
 
The Person said:
I've checked the Cradle of Civilization, and found something there, too.
You might also want to check this thread at Apolyton. The article on map transport relationships over at CoC requires some amendments.

Basically, if you convert a (single-map) scenario, you're going to have to include in your rules.txt file additional @TERRAIN sections (1 for each map), the @SECONDARY_MAPS section (1 line for each secondary map) and everything missing following the @ATTITUDES section (the critical part being @MAP_TRANSPORT_RELATIONSHIPS). Look at the rules.txt files for some of the official multi-map scenarios and use those as a guide. After importing your map(s) you'll then need to set up map transport relationships for your units (columns D, E and F under @UNITS_ADVANCED). However, the only way to write the units' transport relationships to a pre-existing .sav/.scn file, bar hex editing, is to use the Transport action via events (as Techumseh explained in the link).

The Person said:
This is all so darn complicated!
Don't say that, you'll scare people. ;)
 
Luckily it is not a scenario I want to port (just some modified files). I'll just copy and paste the @MAP_TRANSPORT_RELATIONSHIPS from the Sci-fi or Fantasy game, then just set every parameter to zero before I start.

Again, thanks for the help!

Wobbegong said:
Don't say that, you'll scare people. ;)
Yes, the truth hurts. ;)
 
Boco said:
Do have any tips on how to encourage the AI to move between maps?
What's your situation? Are you using isolated pockets of units on the secondary maps for your El Aurens reinforcement schedule? In WotR I found that there were some locations on the secondary maps where the AI units would take their own sweet time leaving and other areas where they couldn't get out fast enough. What was the difference? I had a hunch that the ones farting around in some of the pockets (isolated by impassable terrain) were targeting unreachable areas on the same map. I decided to change the landmass numbering of each pocket to see if this was influencing the AI. It did. When I gave each pocket a different landmass number the offending units came streaming out. This was done by hex-editing. If you generate a map that uses "islands" created from impassable terrain instead of ocean, obviously the entire map will have the same landmass number.

Hope that helps.
 
Yep, it helps. AFAIK, you're the only one who's tested this area very much, and nothing breeds more questions than a good answer. ;) Feel free to answer just a few of these.

Good guess...the question stems from El Aurens' Tribal map, which is simply a whole bunch of >4 square islands holding bunches of Sanusi units capable of entering impassable terrain. The units mill about without fortifying, but never leave their islands via teleporters to enter the main map.

  • What's the highest land index number that you've seen orcs(?) tumble out of? Or the lowest idx # that they simply milled about? [Edit]Btw, my Map1 has an idx range from 65 (main ocean) to 124 (58 islands?). [Edit2]I can reduce the number of continents from which I want Sanusis and Turks to spew down to 7.[/Edit]
  • If I show my usual ineptness at hex-editing, would you have time to help?
  • What kind of mf and terrain cost values have you worked with on your 'spawning' map?
  • Would it help to use one continent on the Tribal map broken into pockets using another civ's impassable terrain units (air, 0m)? Or will the Sanusis fortify themselves adjacent to the 'terrain units'?
  • Do units take equal advantage of one-way and two-way teleporters?
  • Do you know of any rules-of-thumb that the AI follows when teleporting native style? I have U-Boats (domain 2), too.
 
Boco said:
What's the highest land index number that you've seen orcs(?) tumble out of? Or the lowest idx # that they simply milled about? [Edit]Btw, my Map1 has an idx range from 65 (main ocean) to 124 (58 islands?). [Edit2]I can reduce the number of continents from which I want Sanusis and Turks to spew down to 7.[/Edit]
I set my own indices in the following ranges: 1-63 (map 0), 65-127 (map 1), 129-191 (map 2) and 193-255 (map 3). Indices 63, 127, 191 and 255 are reserved for small water bodies. For my values I simply used consecutive numbers beginning with the lowest in the range. On my secondary maps, the maximum number of indices is only around half a dozen. To be honest, I don't think the actual value of the index is relevant. Units stopped milling around when the index value of the "pocket" differed from the rest of the map.

Clearly your "islands" already have different landmass indices. It may be the case that your problem is unrelated to landmass index.
Boco said:
If I show my usual ineptness at hex-editing, would you have time to help?
OK, be a pain in the neck and send it over (saved game and rules.txt). ;) I'll take a look.
Boco said:
What kind of mf and terrain cost values have you worked with on your 'spawning' map?
In my case terrain costs are all 1. Movement factors are 1 - 4. No problems.
Boco said:
Would it help to use one continent on the Tribal map broken into pockets using another civ's impassable terrain units (air, 0m)? Or will the Sanusis fortify themselves adjacent to the 'terrain units'?
I doubt it. Again you'll be creating a situation where areas with the same landmass index will be isolated from each other. The AI doesn't handle this well. I don't know whether or not they'd fortify in adjacent squares - you'll have to test.
Boco said:
Do units take equal advantage of one-way and two-way teleporters?
Yes.
Boco said:
Do you know of any rules-of-thumb that the AI follows when teleporting native style? I have U-Boats (domain 2), too.
I'm not using any units with native transport ability, so I can't offer anything there. Again you'll have to conduct your own experiments. :p
 
Wobbegong said:
Clearly your "islands" already have different landmass indices. It may be the case that your problem is unrelated to landmass index.
OK, be a pain in the neck and send it over (saved game and rules.txt). ;) I'll take a look.
Thanks, but let me experiment a bit before afflicting your neck (you must be in a good mood to refer to that part of your anatomy). :D

I'm wondering whether I've caused the AI paralysis that I've read about when using too many islands. So I'll experiment with a map1 having only 7 continents.
 
Pretty sure it's okay. At least it works when I play the Sanusis.

Field E in @UNITS_ADVANCED for the unit in question:
Code:
0000000000000111
Then,
Code:
@MAP_TRANSPORT_RELATIONSHIPS
0,1 ;  0 NE Theatre-Tribal maps, Type 0, used by Sanusis 
0,1 ;  1 NE Theatre-Tribal maps, Type 1, not used yet
0,1 ;  2 NE Theatre-Tribal maps, Type 2, not used yet
On my secondary maps, the maximum number of indices is only around half a dozen.
Looks like I'll have time to set up some tests this weekend. If so, I'll let you know whether reducing the continent count to seven works. Otherwise...

I had a hunch that the ones farting around in some of the pockets (isolated by impassable terrain) were targeting unreachable areas on the same map.
Okay that makes sense for my EA map1 archeapelago, too.

I had a hunch that the ones farting around in some of the pockets (isolated by impassable terrain) were targeting unreachable areas on the same map. I decided to change the landmass numbering of each pocket to see if this was influencing the AI. It did. When I gave each pocket a different landmass number the offending units came streaming out.
When you gave a methane-saturated pocket :crazyeye: a new index number that caused streaming, was the new index lower? Was it still unique?
 
Boco said:
At least it works when I play the Sanusis.
Good enough.
Boco said:
Field E in @UNITS_ADVANCED for the unit in question:
Code:
0000000000000111
BTW, based on the map transport relationships you provided, any one of the 3 bits in that mask will create the (0,1) relationship for that unit.
Boco said:
Looks like I'll have time to set up some tests this weekend. If so, I'll let you know whether reducing the continent count to seven works.
Investigating the effect of the high number of continents seems to be the way to go.
Boco said:
When you gave a methane-saturated pocket :crazyeye: a new index number that caused streaming, was the new index lower? Was it still unique?
In all cases it was higher. All of my secondary maps consisted of a single continent and therefore used the lowest available index (for each map number), eg, map 1 would use index 65 (leaving me with 66-126). All "pockets" requiring inter-map movement from the AI have unique indices.
 
Wobbegong said:
Good enough.
BTW, based on the map transport relationships you provided, any one of the 3 bits in that mask will create the (0,1) relationship for that unit.
Yeah, I learned that the stupid way (i.e. not from reading threads). The triplicate entry just reminds me that relationships that differ only by transporter type but have the same map values are not different. Hope I said that right -- I'm in a hurry.

Thanks for the index info. That helps.
 
I'm still working with map relations, and came over a problem in the B coloumn of the @UNITS_ADVANCED section (the "not allowed on maps" coloumn). This coloumn confuses me a little bit. There are eight digits, but there can be only four maps. The help text didn't help much, either. It just says that "1" disallows the unit. I checked the rules.txt of the SF game, and found that only the last four digits were used. But I'm still not sure about how it works. And seeing as the first units who can make transporters don't come until mid-game, I think that it's easier to just ask about how it works before starting to experiment by myself.

So how does the B coloumn in the @UNITS_ADVANCED work?
 
That mask really should read: 'cannot build unit on map'. The mask only prevents a unit from being built on the specified map/s, it doesn't prevent a unit from accessing a map – that's what columns E and F are for. Don't worry about the 4 extra bits (digits), they're not used (remember, 8 bits make a byte). The masks in that table use reverse programmer notation. This means that you read them from right to left – and that explains why only the last 4 digits are ever used. In the example below, you would only be allowed to build the specified unit on maps 0 and 2.

Code:
;   A        B
@UNITS_ADVANCED
11111111, 00001010,…
 
Wobbegong said:
Don't worry about the 4 extra bits (digits), they're not used (remember, 8 bits make a byte).
That's what I thought myself, but I wanted to be sure. Thanks again. Your help is highly appreciated.

But I wonder why all the new features in ToT use Reverse Programmer Notation. Wouldn't it be easier (for the users) if everything wasn't "swapped around"?
 
The Person said:
But I wonder why all the new features in ToT use Reverse Programmer Notation.
Only the bit masks use it, ie, in the Advanced Units section and events. The Leaders2 table doesn't use it – it reads left to right – but in that case each digit represents a byte.

The Person said:
Wouldn't it be easier (for the users) if everything wasn't "swapped around"?
For coders, that notation would be very familiar. Do you really think coders ever consider the users? ;)
 
Wobbegong said:
Only the bit masks use it, ie, in the Advanced Units section and events. The Leaders2 table doesn't use it – it reads left to right – but in that case each digit represents a byte.
Don't you mean a bit?

For coders, that notation would be very familiar. Do you really think coders ever consider the users? ;)
OK, I've started getting used to it myself, so I'll stop whining. ;)
 
Top Bottom