Current MapView version?

[SolariusScorch]

Hello, I have a question to @kevL. (I was directed here by @ratzlaff).

KevL, I noticed that you are still working on newer versions of MapView. Do you have anything newer than the 1.2.1 release that most people use? Any way to try it?

I am an OpenXCom modder, I use this program almost every day, so I'm quite interested in its development!

Best regards!

[kevL]

hi Solarius,

yes I'm familiar wit' ye (am a longtime lurker on the OXC forum)

I made a few commits on OpenXcom back in the day... then decided to just fork it and adapt it into my own dream-game :)

re. OpenXCOM.Tools

It's written in C# and i didn't know squat about c# until getting fed up with several of the bugs and exceptions in the prior code (1.2.1, i guess). the code in my repo is 1.6.0.0 (not sure why i just tried to edge everything up till it was higher than the highest ver I could find that was already used). here's the repo:

https://github.com/kevL/OpenXCOM.Tools

look in the Distribution directory, those 4 files should be a stand-alone/self-contained version of MapView. (be careful 'cause I've changed defaults, like "link both ways" to "don't link" etc.)

I don't use PckView but it should work as well as the prior version. a long time ago I encountered some problems with the y-offset using PckView and ditched it in favor of other graphics tools.

before using my ver 1.6, I advise making full backups of your MAPS,RMPS,MCDS,TABS,PCKS. (you know the drill..)

as stated, i know next to nada about C# and have no idea if anything I did made a spring go sproing. Other than that, the tertiary files and directory-format that you're currently using with the prior version is/should be an identical match for what's needed w/ 1.6

... it's 32-bit, but i recently got a 64-bit machine so if I feel a need to compile it again that'd likely change.

[SolariusScorch]

Hi kevL,

Pleased to meet you. Sorry about the late response, I somehow missed the alert. Glad to hear about the update. Is there a specific changelog somewhere? Was it just fixed exceptions and some defaults, or are there other features? Also, are you taking requests for further development? The OpenXCom forum has a thread devoted to MapView, there are some feature proposals (mostly top view and an Undo button): http://openxcom.org/forum/index.php/topic,1321.msg78666.html#msg78666

best regards, Solar

[kevL]

unfortunately no i'm not taking requests (am not familiar enough w/ the code, plus have a whack of other stuff on the plate..)

(but if someone notices something that's just wrong, or is something i myself would want, i'd get around to it) I'll keep an eye on the thread ....

• of ~100 commits to my repo, 90% is simply code-reformatting (great way to learn what's going on, and looks nicer :). Past that, There's a bit of refactoring, cleared out all warnings when compiling, fixed the exception I kept getting over and over when using the mousewheel to scroll up/down z-levels in the RmpView panel (that was the major thing that drove me to do this), fixed an apparent bug when copy/pasting nodes (i think the "attack base" value was getting arbitrarily switched w/ ... a different val.), prevented some uninitialized selection boxes from appearing ... and about the only enhancement is, show current x/y coordinates down on the status bar of MapView panel whenever a tile gets selected (which might just be a substitute thing for what iirc hellrazor wants, in the forum thread) (the problem i was having was with finding the tile on MapView that i'd selected on RmpView )

Undo btn would be way difficult: beyond my 'powers'.

unfortunately or not, I wasn't designing my commits with an eye to public respectability -- so they're basically a hodgepodge of "get things done" rather than "oh what nice, clearly defined change to the code". So, while you could browse the commits for descriptions and code-changes, it's prob. not helpful

future consideration: My version is the non-linux version. ie, windows. Apart from that consideration I branched from TheBigSot, iirc, and he contributed massive improvements. My code should be fine ... it's probably the place for future fixes and enhancements to resume work from (that's of course an opinion)

But again, I strongly suggest making backups of any/all MAPS, RMPS, MCDS, PCKS, AND TABS. remember the bug that would wipe out the config? well, i noticed in general that the code is rather footloose & fancy-free ( ie, not tight or robust )

feel free to let me know if the Distribution files even work for ya,

oh, and if you noticed in the MapView panel, that when zooming in and out on hills, some tiles would set down or lift up awkwardly. It's purely graphical and was caused because the graphical scaling factor wasn't applied to y-offsets. fixed,

and i changed the font to Verdana ...

[kevL]

plus i added a bit of code to check for the notorious "node out of bounds" warnings/errors. untested tho

[SolariusScorch]

Thanks for the thorough response KevL. The fixes you described sound like a really good thing (even though I never encountered this bug myself), and the coordinates sound like a good thing too - having to switch to RmpView to do something on TileView was a bit unwieldy.

Is there a compiled version somewhere, or do I need to compile it myself? If the latter, what settings would I use? (Windows for me, not sure about other users.)

[kevL]

hey Solarius,

these are the files, output from the build process: https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution

those should be current from a Release config. But C#/.NET has a funny way of doing things. It's designed as a high-level language (think, Java; not C/C++) and it's supposed to "just work" ... yeah right.

Actually, it did "just work" for me -- I used #develop 4.4 [http://www.icsharpcode.net/] on a 32-bit XP machine and had a successful compile in 5 min. Today i use 64-bit w/ #develop 5.1 and the current build is by that/this. [it was a bit more tedious 'cause of Microsoft bugs re. the Windows SDK installation... ]

okay, about those 4 files in /Distribution

dsshared.dll mapview.exe pckview.exe xcom.dll

roughly speaking, to test them copy your current MapView directory structure (to your desktop or a temp folder or wherever). Backup your .Maps/etc etc etc also, someplace safe. Or make copies of them that, bleh ... it's up to you.

I don't know if you set your MapView configs with the program or by editting them manually (i do the latter) -- go over them manually and either change the specified paths to your temporary .Maps etc or ... it's up to you, again.

Then drop in the above four files [overwrite all 4] and double-click MapView.exe ( don't forget to sacrifice a small pigeon first..)

ps. If you want to compile it yourself, set up an IDE and open MapView.sln -- the solution.

[SolariusScorch]

Many thanks! I'll give it a try and come back to you with some feedback. Will take a few days though - right now I'm modding like crazy, no time for distractions. :)

[kevL]

k, Lol. np

[SolariusScorch]

Hello,

I gave it a shot and it seems to be working just fine! We've used it with Dioxine for the past two days and, well, no issues to report. I'll keep an eye on speed though, since it really lagged a lot, but it could be because the maps were relatively high.

I have a small request: would it be possible to have the eraser at the beginning of each tile category, not just under "all"?

regards, Solar

[kevL]

cool ( lag = uncool )

did you know a double RIGHT-click clears the tile-part, in TopView's content-boxes (ground,west,north,object) ? i never use the eraser

honestly i tried putting it in, and it worked for Culta but throws "Object reference not set to an instance of an object." for most other Maps. kinda strange 'cause it's just a 'null' and shouldn't be trying to 'reference' anything ...

anyway, i may look at it some more out of curiosity/challenge.

[kevL]

I think i got it if you really want it.

https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution

also seem to have changed the target-platform of the build from "x86-64" to something more generic: "Any processor"

runs okay here. But you should keep a backup of a version you know you like,

[SolariusScorch]

Whoa, I didn't know about that RMB trick. Thanks! But I'll also try your new version.

[kevL]

I just noticed another way to clear a tile-part in TopView. first select the box (ground,west,north,object) for the part-type to erase, then right-click on the tile in the top panel.

[kevL]

fixed something that was irritating me: when changing a tile-part by using those boxes (they're misleadingly referred to as "quadrants" in the code, but okay once used to it..) ... the Views didn't refresh to show a changed tile until a mouseover was done on each View (separately..).

i found a hook and put a Refresh() on each one.

re. BACKUPS. I know you do a lot of efforts, Solar. Do regular backups, preferably to a 2nd drive, just say Yes.

[SolariusScorch]

Man, I'm doing it to a second PC :)

[kevL]

:)

now i have to do it too ... gotta lotta stuff in the Neverwinter Nights 2 realm (also).

been working on the MapView code pretty heavily the last few days. refactoring as well as irky little things that are hard to describe. Now I'm forcing a 32-bit build since it gets rid of some warnings and my debugger likes it as well. That might actually improve performance. But be warned I recently reworked a bunch of stuff dealing with the registry entries and the Paths editor ... 97% chance it's okay.

[SolariusScorch]

OK, it's all great news.

BTW would it be doable to have a "save map as..." feature? For example loading urban01, changing a few things and saving it under a different name.

[kevL]

strikes me as a good feature, probly pretty simple even fer me

but it'll be some time before I get to look at it; I want to run the code through 'static analysis', thoroughly vet the Paths Editor, and implement YAML for the config files.

[kevL]

Solarius, question:

in the RouteView screen, do you ever use the "ExtraHeight" parameter? It seems to be some kind of fudge-factor and, I believe, is not a standard parameter in stock .RMP files.

I want to - let's face it, i'm going to - take it out.

but this may break any .RMPs (all pathing nodes for a given Map file) for which ExtraHeight has been set to a non-zero value ...

thoughts? have you ever used or encountered the ExtraHeight as a non-zero value?

in fact it looks like it tacks an extra byte onto the end of the .RMP file ... it wants a closer inspection atm.

[kevL]

2017 march 19: I tweaked and renamed the config files. Basically your old ones won't work unless new ones are created and the old data is copied in.

my version of the code is entering a high state of flux; if & when i do the config-files in YAML it's pretty much a whole new program /shrug.

[SolariusScorch]

TBH I don't even know what ExtraHeight does. Is it related to Z levels?

As for the change of files... Not gonna lie, it sounds like a huge pain - I have over 100 custom terrains. I hope moving them would be relatively trivial... Else I'll request an automatic converter. :P

[kevL]

it sounds like a huge pain, it's not really ... you'd just have to know the rules for it ...

eg, I changed the extensions from .dat and .pth to .cfg (for all 4 files)

inside, i changed any string/substring of "Rmp" to "Route"

ie. Images.Cfg and MapEdit.Cfg remain the same, internally. In MVSettings.Cfg, any string/substring "Rmp" changes to "Route"

and Paths.Cfg remains the same, internally.

That said, backup everything!

re. ExtraHeight: "This amount will be added to the link's vertical position. Helps in UFO maps when the UFO terrain maps have basement floors."

• that's what the tip says, but i don't believe it ... I looked through the file format technicalities at Ufopaedia.org and didn't see any mention of it. So I'm pretty sure it results in a non-standard .RMP file;

yeh I thought about automatic converters for the stuff in MapView. lot on my plate tho.

whether you're interested or not, I finally reworked the link-connection routine. select a node and have the ConnectionType set. Then right click on another tile (with a node or without). If ConnectionType is Oneway, the current node will be connected toward the right-clicked tile; if Twoway it goes both ways. If a node doesn't exist on the right-click it's created.

caveat: unless you're feeling experimental, I'd just sit on things if i were you. I'm finding all sorts of unused code and simply commenting it out, still refactoring things, etc. This can easily introduce bugs and there's still lots I see to do before even considering more thorough tests of the app as a whole.

[SolariusScorch]

OK, thanks for all the info. I don't really feel the need to update right now, so I'll wait on a more stable version. Thanks for all the hard work!

[kevL]

np. will make a post here when i get something am happy with, could be ... a while.

[kevL]

do you use TopRouteView (the combined TopView & RouteView window)? I don't, and it's causing distractions in the code ...

status: window sizes and positions are loading/saving via YAML :)

am going to try to set things up so that when the program is first run from a fresh directory, it should automatically create complete configs based on the current /MAPS /ROUTES /TERRAIN resource-directories ... lots to do /shrug, carry on

[SolariusScorch]

Hi kevL,

Yes, I'm afraid I only use the combined view... there is no need for keeping these two things in separate windows, and even more importantly, I'm already starving for screen space in all but the smallest maps.

regards, Solar

[kevL]

ok, it stays

[SolariusScorch]

Thanks, and sorry for the trouble ;)

[kevL]

s'okay, am letting MapView simmer while giving PckView a big massage.

mousewheel scroll, woohoo

[kevL]

re. lag

The place i'm getting the most lagginess is when drag-selecting tiles in MainView. The bigger the map, the more noticeable it is ... up/down is also a bit laggy.

ironically, if the drag-select is done in TopView, and you watch the selection happen in MainView - the drawing is quick & responsive.

So idk. I'm not much of a bit-twiddler tbh. Am guessing the lag has something to do with MainView being active, so winforms would want to calculate/redraw/update/mouseover/etcetcetc much more often, instead of perhaps using some sort of a buffer (with the sprites already laid out) if & when TopView is the active window.

other than that things are coming along very nicely. have pretty much got code-flow under my belt, so that's bonus.

The big thing left is using YAML for the configs. Viewer positions have already been removed from the Windows Registry and are using YAML (not robust but it works). And, yeh, i've written a basic proof-of-concept for a ConfigConverter ...

... it came as bit of a shock when i realized that MCD/PCK files are not ref'd directly by MAP files .... that is, those refs have to be setup externally.

and i wish MadHaTr well on whatever projects he pursues, it's a long road

[kevL]

anyway if you want a bit of something to sink your teeth into: changes include but are not limited to - the MainView map-lozenge no longer takes on quirky proportions, added user options for interpolation (eg. bilinear, bicubic, nearest neighbor) when the sprites get resized, plus gamma adjustment for the sprites, and higher quality pixel-offset makes lines draw a bit crisper. Map-resizing is tighter in all views. Clicking stuff tries to assign each control's focus to something intuitive/obvious; clicking outside the map-bounds no longer selects a tile. etc

[SolariusScorch]

Exciting news. Thank you for your effort!

[kevL]

got the maps to load strictly from YAML (woohoo!)

not public yet.

now to clean up the mess and get PathsEditor to play nice (ie, save to YAML)

/update

[kevL]

done.

treat it as a new, separate program. See my repo's Distribution directory...

if you want suggestions, or have questions just ask

ps. Good luck, it's beta!

[kevL]

bugs

• creating a tileset on the MapTree when the tileset already exists in another category
• when reconfiguring the resource-paths and/or recreating the default tileset config file.

[kevL]

not quite happy yet ...

[kevL]

@SolariusScorch

added Save As ...

the app appears to be working fine on the whole. The Paths Editor is gone, instead RMB-click on MainView's maptree brings up a context menu for adding/editing/removing groups, categories, and tilesets.

Note that each group-label must start with either "ufo" or "tftd" -- that sets the palette and default basepath (ie, XCOM installation path) for that group. Tilesets can be added from and/or saved to alternate paths, but must maintain the structure:

\parent\MAPS \parent\ROUTES

terrains will be accessed from the user's XCOM installation(s).

There is a ConfigConverter, and although it works for my MapEdit.dat/cfg (~1500 lines), you should likely browse its output (~10,000 lines). particularly to ensure that all groups start with "ufo" or "tftd" (case insensitive)

Am presently working up a Windows .chm helpfile, and will try to address any bugs/issues that i hear about,

[kevL]

MapView ii -- couldn't have happened w/out Ben! -- is pretty much complete.

but still bringing PckView back up to being a simple PCK editor (though not comparable to Volutar's MCDEdit), basically just for pixel-touchups.

... i really don't like (working with) image-formats (of any type), but I also really want the ability to fix rogue pixels quickly and easily when I see them in MapView. will see how it goes

[ratzlaff]

Sweet! Nice work!