Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I've redone the routing for the Whirligig map, could you check if the files are loading now with the correct routes on your end?
Here is a note that may save someone who is searching this thread later a bit of trouble: If your map loads fine in MapView 2 but looks distorted when loaded in OpenXcom.Spoiler:
Check your ufo: entry for that craft's map and make sure the mapDataSets: contains BLANKS before the rest of your tile sets.Spoiler:
The Whirligig map is one I made.
I'm guessing this is not the case but would the map and route files having a dash then number before the file extension cause this problem?
I've been saving map versions like this as I work on them:Spoiler:
So far I have not encountered the route problem again. I've been working around it by keeping a backup of the .MAP / .RMP files in a separate folder just in case I need to revert the .RMP if it corrupts.
The exact steps I've been doing:Code: [Select]. Start MapView 2
. Expand the tftdShips tree so that Craft & USO are visible.
. Select "USO" by Left click.
. Right Click "USO" and select "Add Tileset"
. In the MAP field either type the name of a new map, or click "..." and select an existing map file.
. Click create.
. Select (UEXT2, UEXT3, UINT1, UINT2, UINT3) and move each to the "allocated" window by pressing the "Left" button.
. Click Accept.
I also may have selected the "Save Maptree" option in the "File" menu in the past either right after creating the map or after working on it a bit.
I just tried it again and this time it created a 10x10 file with no routes.
Now that I know it should be 10x10 by default I'll keep an eye out for that, if the new map starts with anything else I'll assume it is corrupted and try to make another one.
I think the routes on the empty example map came from this craft's map 'Whirligig'. Interestingly the Whirligig's map also seems to have now started using yet other crafts routes and is throwing this error when I click on it:Spoiler:
whenever I try to make a new map there are already routes, it seems to be inheriting them from a different crafts map. Also sometimes adding a new map seems to corrupt a different map file causing the other map to use another craft's routes instead of its own.
An idea what could be causing this?
Here is an example, I just created this map with the "Add Tileset" command and it started with an empty map but it has the routes from a different craft already present.
Perhaps I'm creating the file initially incorrectly, the method I'm using is to click USO and select "Add Tileset" then add the (UEXT2, UEXT3, UINT1, UINT2, UINT3) terrain tile sets using the menu. Should I be doing something else?
I have another question about the tile limit. Is 253 just for the alien craft being made in MapView itself or does the sea floor and whatever X-Com craft the player sends to the location also count towards the limit when the file is loaded ingame?
- id: STR_ETHEREAL
members:
- STR_ETHEREAL_COMMANDER # commander
- STR_ETHEREAL_LEADER # leader
- STR_ETHEREAL_LEADER # engineer
- STR_ETHEREAL_LEADER # medic
- STR_ETHEREAL_LEADER # navigator
- STR_ETHEREAL_SOLDIER # soldier
- STR_SECTOPOD_TERRORIST # terrorist 1
- STR_SECTOPOD_TERRORIST # terrorist 2
- id: STR_SECTOID
members:
- STR_SECTOID_COMMANDER
- STR_SECTOID_LEADER
- STR_SECTOID_ENGINEER
- STR_SECTOID_MEDIC
- STR_SECTOID_NAVIGATOR
- STR_SECTOID_SOLDIER
- STR_CYBERDISC_TERRORIST
- STR_CYBERDISC_TERRORIST
- id: STR_AQUATOID
members:
- STR_AQUATOID_COMMANDER
- STR_AQUATOID_NAVIGATOR
- STR_AQUATOID_MEDIC
- STR_AQUATOID_TECHNICIAN
- STR_AQUATOID_SQUAD_LEADER
- STR_AQUATOID_SOLDIER
- STR_CALCINITE_TERRORIST
- STR_CALCINITE_TERRORIST
const int Node::nodeRank[8][7] =
{
{ NR_LEADER, NR_NAVIGATOR, NR_ENGINEER, NR_MISC2, NR_MEDIC, NR_SOLDIER, NR_SCOUT }, //commander
{ NR_LEADER, NR_NAVIGATOR, NR_ENGINEER, NR_MISC2, NR_MEDIC, NR_SOLDIER, NR_SCOUT }, //leader
{ NR_ENGINEER, NR_LEADER, NR_NAVIGATOR, NR_SOLDIER, NR_MEDIC, NR_MISC2, NR_SCOUT }, //engineer
{ NR_MEDIC, NR_MISC1, NR_SOLDIER, NR_MISC2, NR_NAVIGATOR, NR_LEADER, NR_SCOUT }, //medic
{ NR_NAVIGATOR, NR_LEADER, NR_ENGINEER, NR_SOLDIER, NR_MEDIC, NR_MISC2, NR_SCOUT }, //navigator
{ NR_SOLDIER, NR_ENGINEER, NR_NAVIGATOR, NR_LEADER, NR_MISC1, NR_MISC2, NR_SCOUT }, //soldier
{ NR_SOLDIER, NR_ENGINEER, NR_NAVIGATOR, NR_LEADER, NR_MISC1, NR_MISC2, NR_SCOUT }, //terrorist
{ NR_SOLDIER, NR_ENGINEER, NR_NAVIGATOR, NR_LEADER, NR_MISC1, NR_MISC2, NR_SCOUT } //also terrorist
};
enum NodeRank
{
NR_SCOUT = 0, // 0
NR_XCOM, // 1
NR_SOLDIER, // 2
NR_NAVIGATOR, // 3
NR_LEADER, // 4
NR_ENGINEER, // 5
NR_MISC1, // 6
NR_MEDIC, // 7
NR_MISC2 // 8
};
public enum NodeRankUfo
{
CivScout, // 0
XCOM, // 1
Soldier, // 2
Navigator, // 3 vs SquadLeader
LeaderCommander, // 4 vs Navigator/Commander
Engineer, // 5 vs Medic
Misc1, // 6
Medic, // 7 vs Technician
Misc2, // 8
invalid // 9 - WORKAROUND.
};
public enum NodeRankTftd
{
CivScout, // 0
XCOM, // 1
Soldier, // 2
SquadLeader, // 3 vs Navigator
NavigatorCommander, // 4 vs Leader/Commander
Medic, // 5 vs Engineer
Misc1, // 6
Technician, // 7 vs Medic
Misc2, // 8
invalid // 9 - WORKAROUND.
};
When using "Add Tileset" to place a new map in the Maptree, what are the limits to the number of tile packs that can be assigned to each map?
I noticed that in modify map size I can set the map to be taller than original X-Com height limit, what is the maximum height that I can build a new map at?
I'm getting the following error: "There are 88 route-nodes outside the bounds of the map"
I thought that I had placed them all inside the map tiles so I'm not sure what has gone wrong.
. TITAN_ALIEN_EDIT.MAP
. TITAN_ALIEN_EDIT.RMPCode: [Select]terrains:
- Triton
- UINT2
Just by placing this tile is enough to make an elevator right?
// Rules on nodes and node-links (OxC)
//
// - unittype is used for spawning and patrolling only; it is not used by
// links
// - noderank affects both spawning and patrolling, but note that noderank
// has a fallback mechanic for spawning such that if no node with an
// aLien's rank is found, a succession of (all) other ranks will be
// investigated (but not XCOM rank ofc)
// - re. unittypes: small units are allowed to use large nodes but not vice
// versa and flying units are allowed to use non-flying nodes but not vice
// versa. Thus 'Large' nodes are effectively identical to 'Any' nodes.
// - link distance is not used
// - spawnweight 0 disallows spawning at a node, but patrolpriority 0 is
// valid for patrolling to a node if a unit is flagged, by OxC, to "scout"
// (details tbd) else patrolpriority 0 disallows patrolling the node: the
// OxC "scout" flag appears to be, at least in part, another fallback
// mechanic - that is, an aLien will check for valid non-scout nodes first
// but if none are found, the routine then checks for valid "scout" nodes.
// But don't quote me on that; there's more going on between (a)
// patrolpriority, (b) noderank, and (c) the "scout" flag ...
// - it appears that if the OxC "scout" flag is not set, then the aLien to
// which it's being applied will not leave the block it's currently in.
// More investigation req'd
// - quote from the OxC code:
// "scouts roam all over while all others shuffle around to adjacent
// nodes at most"
// I believe, at a guess, that this is designed to keep Commanders in the
// command module, eg, or at least increase the chance of aLiens sticking
// around their non-CivScout patrol nodes. Long story short: OxC has
// hardcoded patrolling behavior beyond what can be determined by the
// Route files. (I didn't look at OxCe)
//
// 0 = Any, 1 = Flying, 2 = Flying Large, 3 = Large, 4 = Small <- UfoPaedia.Org BZZZT.
public enum UnitType
: byte // ca1028 - use Int32
{
Any, // 0
FlyingSmall, // 1
Small, // 2
FlyingLarge, // 3
Large // 4 - aka. 'Any'
};
public enum NodeRankUfo
: byte // ca1028 - use Int32
{
CivScout, // 0
XCOM, // 1
Soldier, // 2
Navigator, // 3
LeaderCommander, // 4
Engineer, // 5
Misc1, // 6
Medic, // 7
Misc2, // 8
invalid // 9 - WORKAROUND.
};
public enum NodeRankTftd
: byte // ca1028 - use Int32
{
CivScout, // 0
XCOM, // 1
Soldier, // 2
SquadLeader, // 3
LeaderCommander, // 4
Medic, // 5
Misc1, // 6
Technician, // 7
Misc2, // 8
invalid // 9 - WORKAROUND.
};
Here are the files:
Does the TFTD Navigator rank share the Leader/Commander rank, I didn't see it listed in the "Node Data" "Node Rank" menu.
I'm getting an error when I press the "tally" button in the RouteView window:
I tried deleting Node 67 but the error still appears when I press the "tally" button.
When I click a tile in the top view window that already has been assigned floors/walls/etc the images stop being black for those parts.
Do I need to duplicate routes from the same node for both "Small Flying" and "Small", or will a small flying unit also use a route marked with just a "Small" route?
@kevL: After making hundreds, or perhaps thousands of maps, I can't recall a single case where "link forward and back" should be off. Even if it ever happened, it's super rare. Can we please make the "link forward and back" button pressed by default? It would be one click less for me every session.
You don't have to set patrol routes, they're only for priority. So 0 is fine too.
Thank you KevL, I appreciate the screenshot:
Here is the edited map and route files for Wolwerin's Double Scout (GT0005)
If I've done this correctly the map now supports this many spawn points inside the alien craft:
Soldiers: 5
Squad Leader: 1
Medics: 1
Technician: 1
Leader/Commander: 2
Terror #1: 1
Terror #2: 1
I've also made it so that if Terror units #1 or #2 are used for a flying unit it will move to a patrol pattern above the ship.
Do I need to set "Patrol Priority" to "1 : Lo" for every node or can I leave them at "0 : LoLo" and still have the AI use them?
(UFO_GT0005-3 is setup to use "1 : Lo" for almost all the nodes.)
Selecting "UseMono: True" does display the previously blacked out images correctly. However it also causes the program to run at what feels like 1 frame per 60 seconds. (I tried Stoddard's build but the result was the same.)
I think I can work around it for now using the "UseMono: False" setting even with the graphical errors as the only effected areas seem to be the 'Floor' 'West' 'North' 'Content' 'Part' icons in the "Top/Route Views" and the "TopView" windows.
/* snip */ Is this tile normally black in the "TileView" because it fills the currently selected tile with nothing leaving it empty/blank or is it a graphical error caused by me not using the Mono = True setting?
To confirm if I understand the RouteView controls correctly, to place and link alien movement nodes:
. Right click an empty tile to create a new node.
. Select one of the Link1 through Link5 options
. Assign "Dest" to the number of another existing Node.
. Assign "Unit" to the type (Or any if all aliens) are able to move from the selected node to that "Dest" node.
. In the "Node data" settings assign it a "Patrol Priority" of at least 1 so that the alien has a chance of wanting to vist that node from other nodes.
. Aliens may now choose to move from the selected node, configuration is complete and up to 4 (5 total) other nodes can be linked from the selected node.
And to make the Node a spawn point for an alien unit:
. Select an existing node.
. In "Node data" select "Node Rank" and assign it the value of the rank of alien to be spawned from the alienRaces: .rul file.
. So long as "Spawn Weight" is set to greater than 0 that tile 'could' be used to place one of the aliens of that type.
Do I need to make sure each node links to another node without going through walls or solid objects, or will aliens automatically path around everything to get to the other linked node?
With this new node between the two alien crafts aliens can choose to move to from node 1 or node 6 to node 49.
Have I done this correctly?
(Node 49: Link1 = 1, Link2 = 6)
(Node 1: Link4 = 49)
(Node 6: Link5 = 49)