MAPVIEW upgrade

[Keth01]

I was sure I was, but purging and installing off your link instead of mine has fixed literally everything. Clearly I goofed. Thanks so much for your help!

[kevL]

coolio,

May your maps be robust (so to say)

[kevL]

looking ...

I hope it's something "obvious" in the code ...


edit: as a (hopefully temporary) workaround, try turning off the InfoOverlay

[kevL]

see my suggested workaround (edit) in previous post

I looked at the wonky function and nothing obvious smakked me in the face yet :\

[kevL]

Wait? I think i found out the issue. Nevermind!

huh? status report pls?

[kevL]

Anyways, thank you for reading my MVII issue/bug reports btw.

np. I'd like to fix the issue but don't have TFTD (it never caught my interest the way UFO does)

After poking around on the web etc ... am thoroughly confused. Ufopaedia.org implies that the structure of .RMP files is the same for UFO and TFTD (because it documents the file-format only for UFO routes, implying that the structure of those files is the same for TFTD, for lack of anything stating otherwise, that I found). And, as far as i'm aware, OxC loads routes from UFO or TFTD the same way, further implying that the formats should be the same. Yet once i managed to load the TRITON.MAP/.RMP in MVII using the files in the OpenXcom TFTD Patch, what I'm initially seeing tends to indicate that the x/y coordinates are reversed* between UFO/TFTD specs. I mean, those should be "fixed files" but route-nodes are appearing off of the Triton-map's area.

For me to have any hope of debugging what's really happening, perhaps you can message me a link to a zip containing:

ALSHIP12.MAP
ALSHIP12.RMP

at a minimum, and several of the TFTD Terrain files would be useful also:

GRUNGE1.PCK/.TAB/.MCD
GRUNGE2.PCK/.TAB/.MCD
GRUNGE3.PCK/.TAB/.MCD
GRUNGE4.PCK/.TAB/.MCD
UFOBITS.PCK/.TAB/.MCD

(so I don't have to use UFO Terrains looking all borky...)


* but I really don't think so, based on how the nodes look decently placed on the RouteView screenshots above - if x/y were reversed, nodes would likely appear inside walls etc. At this point i suspect that stock TFTD route-files are simply derpy. but firsthand investigation is req'd

--
Question: when loading a Map containing buggy nodes, does MVII ask if you want to remove out-of-bounds nodes? If so, after choosing Yes what sort of results do you get?

[kevL]

Well, it does ask me to remove, but i choose not to remove them, and i want to keep the missing nodes because ...

that'd cause problems. The OxC code outright ignores such nodes (although it has to do some jiggery-pokery to keep links straight). They don't exist, when playing the game.

https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/BattlescapeGenerator.cpp#L1660

user has the option of keeping them in MVII only to have the possibility of hex-editing their coordinates right inside the .RMP files to acceptable values (thus keeping their links, priorities, etc.)

I don't see why you'd want to keep them unless you're going to do that but it's up to you,


in any case, to handle out-of-bounds nodes in the editor would be a tad more difficult than simply ignoring them ...,,,
in any case2, i've got an inscrutable error in my IDE (project file) and it has to be resolved before I could even begin to do anything :\

/see what happens

ps. You could backup the specific RMPs that are buggy, and remove the bad nodes in MVII, and still have the backups.

[kevL]

here's something that worked for me with the Triton (it has 1 out-of-bounds node)

1) open the Map
2) Don't remove bad nodes
3) resize the map under MainView|File|Resize Map.
4) make a guess as to how big the new dimensions have to be to catch the bad nodes in its area (or, uh, use a hex-editor to see what dimensions are needed...)
5) anyway, save *only* the Map -> MainView|File|Save Map.
6) click the maptree to a different Map, then click back to the Map you're working on (this should refresh things and show the previously bad nodes within the bigger Map dimensions)

7) if another node out-of-bounds error appears, repeat and resize to an even larger dimension.

Then you should be able to move the nodes around with Drag&Drop, or Copy/Delete/Paste, etc etc.

optional. resize the Map back to its original dimensions.

When satisfied, save all.

PS. I don't expect problems but it's a good idea to backup each .MAP and .RMP before attempting this. (and delete the backups sometime later after things have been tested)

[kevL]

(whew, got my IDE to build again)

lemme know how it goes, cause sooner or later I'll have to sink my skull into the code again


i feel little crawly things creeping up my leg /jk

[kevL]

update, Feru

the issue is NOT out-of-bounds nodes (although they are still a problem to be wary of and can cause exceptions)

The issue strongly appears to be TftD SpawnRanks. I see the route-files have #9 for a spawnrank, while UFO only goes up to #8. Unfortunately I have no idea what the developers meant with a #9 .... unless TftD can have up to 3 different types of terror-units on a mission (like Mutons in UFO can have up to 2 different terror units)

Other than that, both games appear to have 6 ranks of aliens, 2 ranks of terror-units, plus #0 for Civ/Scout = 0..8

ie, max spawnrank should be "8" unless i'm missing something


give me a day or two to ponder the meaning of existence hehe

--- posts merged ---

the more i look, the more I think they're TFTD route-file bugs ...

eg, OxC defines only 9 noderanks
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/Node.h#L26

alienRaces.rul defines only 8 ranks [+1 for civ/scout]
https://github.com/SupSuper/OpenXcom/blob/master/bin/standard/xcom2/alienRaces.rul

pmprog's MapView1 defines only 9 noderanks
https://github.com/pmprog/OpenXCOM.Tools/blob/master/XCom/GameFiles/Map/RmpFile.cs#L115

I've looked at the code in MvII to check if maybe wires got crossed (eg. mistaking patrol-priority for node-rank, etc.) and this doesn't appear to be happening either.

(btw, for nonprogrammers, counting starts at 0, so 9 possible ranks count from 0 to max 8: so the value of "9" in the tftd routes is causing the exception [the enumerator for the dropdown box only goes up to 8])



I've looked at (at least my version of) the OxC code and it's not a big problem there. i mean such nodes won't work quite right, but since node->getNodeRank() is simply treated as an integer and compared for equivalency it doesn't throw.

[kevL]

after looking more closely at the nodes and patrol-links, my guess is that rank #9 is supposed to be a terror-unit. That is, it should be "8" or even "7"

I shouldn't decide because I can't see the corridors (large terrorists need 2-tile wide corridors & spawnpoints).

If you want, Feru (based on my screenshot of HxD above), grap a copy of HxD.

backup each RMP you wish to modify, then load it in HxD, change the line-width from 16 to 24 and the faulty ranks should line up beneath offset 0x14. (each digit is 4-bits, so they're grouped in pairs to make bytes)

at that point, all you're dealing with is a glorified text-editor.


ps. The GRUNGE12 map has an out-of-bounds node ... and since it's at coords (254,246,1) i think you should hex-edit it down to a reasonable y,x,z-position (rather than trying the Resize Map tactic). The coordinates are the first three bytes on each row in HxD -- in GRUNGE12, "FE F6 01"

i'd change it to "00 00 01" before loading the Map

[kevL]

you bet. take yer time, hex-editing is straightforward.

thanks to Ufopaedia and others

[kevL]

if you scroll up to my screenshot of HxD, "TFTD_ALSHIP12_NODE_WEAKSPOTS.RMP"

the tall red vertical box tells you what you gotta know. Change all the "09" digits in that column to ... err, idk. I suggest changing them to "08" (terror-unit Misc2 rank). But it depends on what the node is expected to do ingame.

At least if they're changed to "08" ... or simply "00" (generic Civ/Scout node), the RMP should load okay.

repeat for each buggy .RMP file. [line width 24, get rid of every "09" in the column under offset 0x14] -- no value greater than "08"


(i have a build of MV2 that allows such routes to load and simply enumerates them as '9:INVALID' but i'm changing the build-configuration and want a couple days to mull things over...)


ps. i called them '9:kL_Misc3' as a temporary measure only. I strongly suggest not thinking of any rank as 'Misc3' eh.

Since i've hex-edited my map to try finding the out-of-bounds node, your trick kinda worked for me.

yep, that's where it should appear 


pps. in case you haven't figured it out yet... each row in HxD is a node's data (iff line-width is set to 24 bytes)

[kevL]

... worked well (Damn, HxD fired me up while hex-editing). ^_^

hex-editing = untold power

sounds like you got it to work.

Maybe i'll copy the old version of one of the route files until we have a version of MVII having 9 or 10 spawn ranks instead of 8 so that it can help me out with learning patrol data in order to remake my old maps from January to April 2018.

Since the bugs on vanilla TFTD map RMP files happened, i guess i'll agree with a build of MVII with allowing the limit of node ranks from 8 to 9 or 10 (9:INVALID1 and 10:INVALID2) maybe next month or October.

meh. afaiac, there is no "node rank 9" ... unless some one comes along and says "btw, node rank 9 in TFTD is for blehbheh"

my thoughts/plan atm is to limit every value that can appear in RouteView's dropdown boxes to their maximum enumerated values (as data is read from an .RMP). Or more likely add a generic case "INVALID" that would appear in any combobox that would otherwise have an invalid value.

... which leads to a further issue of informing the user about what that might mean

And will agree on this build instead of the MVII build i'm using that has the "bugged and broken nodes" problem for me. I'll be waiting for 1 or 2 months i guess. VnV'

It shouldn't take me more than a week, i guess. Am trying out a c#/.NET AnyCPU build, but seem to notice the jitting. Tempted to go back to forcing 32-bit builds ....

And also, i need to stop harassing Reaver (The Reaver of Darkness) ...

good idea, peeps are busy about their own things too, Feru



edit: woohoo (getting there... )

[kevL]

thanks Feru, y you too

have got (what I consider to be) a/the solution done re. Noderanks 9+

for those interested in c# code:
https://github.com/kevL/OpenXCOM.Tools/commit/b105d50a84810367abbbe467dc048f3071cbace5


then set to work implementing a Search function ... (and found it's not at all simple to do on a multi-level tree, with a start-node that could be anywhere, and with wrap-and-exit if not found <- that's what I'm doing right now.)

and i want to deal with out-of-area Nodes better (in case user does not tell Mv2 to auto-fix them...) because they leave bogus link-lines and can throw exceptions if using the Go-buttons,

/cheers