MAPVIEW upgrade

[kevL]

no worries,

will look into it if/when i get a chance,

[edit]
oh sweet. Am getting toolstrip buttons to operate on firstclick when the window is inactive. eg. "Options" btn

that always annoyed me ...

[edit2]
bingo. Got TopView to accept 1-click placement (or single/double-click whatever). gimme a day or two to package a release ...

[edit3]
found some more ui-anomalies to plonk away at ...

[kevL]

2022 jan 18

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220118

- mainly address the issue of .net's ToolStrip control ignoring a mouseclick when its parent window is inactive.
- TopView had the same issue except for different reasons.

The fix has not been extensively tested (nor tested when built against Mono at all) and although i don't expect probs, lemme know if anything glitches out,

[luke83]

Hello,
  Just working on a little something something and getting this exception.... Good to see your still maintaining this 

Note: im  thinking as i was being  last and didn't make RMP maps for some new blocks, that this might be causing the error, well at least that's my current thought.

[kevL]

hey Luke, good to hear from ya,

Are you using the latest build? (i addressed very similar errors over the past few months)

a missing RMP file shouldn't matter; iirc. It's highly unlikely to be related to the error ... MainView doesn't care about routes.

if the newest release (i changed the download to github itself, btw) is borking, will need a link to your mapfile etc ...



from the stacktrace i notice this is a pseudo-known .net issue ... MainViewOverlay.DrawTile() should be calling a function MainViewOverlay.DrawSprite() before the Graphics.DrawImage() call ...

while i've seen it before, no one seems to have a good explanation of it,


anyway, try the latest and/or perhaps get in touch by PM so we can poke this.

[luke83]

i assume its the newest build, i still think it was the routes as I got sick of the errors and fixed it and (so far) have not had the same error again ( but i have not done much in the past 24 hours), will let you know for sure once I do a few more map blocks.

[kevL]

yep that's the latest. Did you fix it simply by creating .RMP file(s) ?

am going to try to reproduce it here, i don't like the app thowing that error ...

[edit]
dang can't repro... Map loads fine here without any RMP file.

[kevL]

MapView 4.3.0.0
- x2 scale button for RouteView

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220315

[kevL]

McdView 4.1.1.0
- bugfix: clear selected id when a terrain loads, before its parts are
  instantiated not after. Else the tilepanel could try to scroll to a part past
  a terrain's total parts id.

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220326

[Delian]

I tried opening one of the PCK files using PckView and got an error: "File data overflow a sprite's length."

This is a valid PCK file and is used in one of the mods without a problem. But PckView and consequently MapView2 give me an error if I try opening a map/terrain that uses such a PCK file.

[kevL]

does it have a .TAB file? If so pls link it also

PckView doesn't open .PCK files unless they have a .TAB file ...

[Delian]

It has a TAB file.

[kevL]

Tks, will have a look

[edit]
corrupt TAB file, try this one

I tried opening one of the PCK files using PckView and got an error: "File data overflow a sprite's length."

This is a valid PCK file and is used in one of the mods without a problem. But PckView and consequently MapView2 give me an error if I try opening a map/terrain that uses such a PCK file.

perhaps because OxC/e doesn't use the TAB files (idk). They're redundant but MapView2 / PckView will continue to use TAB files.

[Delian]

Corrupt in what way?

I can't say for sure either, but all the PCK files have cooresponding TAB files. Maybe you could improve the error handling of PckView, so that despite errors in the tab files, it's still able to load the PCK file anyway?

[kevL]

the highlighted data in first screenshot is the 7th sprite in the PCK file, the 8th sprite begins at offset 0x0c0b ... but the second screen shot shows the offset of the 8th sprite in the TAB file as 0x0c06

0c06 != 0c0b

All of the remaining offsets are borked also ...

I have a small routine that rewrites TAB files, but it's not robust enough for general use. At some point i might put in an option to rewrite the TAB file if my time and health permit,

[kevL]

woohoo! no auto-rewrite routine (yet?) but better error messages

(not committed to repo atm)

yeh i was getting fed up with the other cr*p i was working on ...