OpenXcom Forum

Modding => Tools => Topic started by: luke83 on June 19, 2013, 03:12:15 pm

Title: MAPVIEW upgrade
Post by: luke83 on June 19, 2013, 03:12:15 pm
Hello,

 Any of you excellent Coders want to try your luck at making a few Upgrades to MAPVIEW? I downloaded the source out of curiosity but have no clue where to start :P

I PM Daishiva but since i have not heard from him in over a year i guess LIFE has gotten in the way of the last upgrade i asked for :-[

My Suggestions for Upgrading Mapview:
1) Fix existing Bugs EG: the PATHS can only be modified by Notepad as doing it by the program wipes everything.
2) Specify Default Node type was added last time By Daishiva at my request , we need a extra Option to tell it to AUTOLINK to previous Node in both directions ( this will save alot of time)
3) Extra Visual clues as to what Unit type a NODE will be spawning ( Just some letters added to the Green box to represent a Class would be helpful)
4)Move Node Option, There is nothing worse than realising you have fully setup a NODE 1 block to the right of the desired location, a tick box to Drag and drop node at a new location and Keep all current LINK nodes would be awesome
5) Numbered Grids ( around the images) i hate goign cross eyed tryign to work out if i am in the right Row or not , a simply Number system down the side on ALL screens could be useful.
6) AUTO-Link : Not sure HOW you will handle this but this would save alot of headaches if i only needed to clean up a few LINKS instead of manually modding every one of them.
7) RMP Statistics = Would be great if there was a option somewhere to do a count of all Spawn Ranks per level and a overview of spawn Ranks across the entire map set, just Pop open a new window to display this when requested.
8) Some kind of import Wizard for the PAths , Mapedit page as i have Lots of differnt , half finished maps to import and its very time cinsuming to do them one by one. It would be good if it was clever , and noticed if i selected a Map without a ROute file, that it could ask if i want to make a empty file for it. ALso if you can improve the way the Map tree is controlled ( and allow Drag and Drop to change the sequence) that would be great.


This is a Fantastic program it just needs some work to make it easier for people like me to make LOTS of new map types, Any part time coders for OXC want to take a look ?
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 19, 2013, 04:39:15 pm
What's it written in? and where can one find the code?
Title: Re: MAPVIEW upgrade
Post by: AndO3131 on June 19, 2013, 05:19:04 pm
Code is here (https://sourceforge.net/projects/xcmapedit/files/old_files/MapView/MapView.1.11.zip/download)

It's written in C#.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 19, 2013, 06:01:20 pm
I'll try and have a look at that later. No guarentees though
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 19, 2013, 10:28:03 pm
Thanks pmprog,  i would appreciate any help you could possibly provide. modding a few small map blocks is not to bad , modding large buildings/UFO can take several hours per mapblock so anything to help reduce that would be a benefit to the community. I have spoken to many potential modders over last 2 years and most of them give up once they see how time consuming it is.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 20, 2013, 12:51:52 pm
Thanks pmprog,  i would appreciate any help you could possibly provide. modding a few small map blocks is not to bad , modding large buildings/UFO can take several hours per mapblock so anything to help reduce that would be a benefit to the community. I have spoken to many potential modders over last 2 years and most of them give up once they see how time consuming it is.

Could you do me a favour: For the things you want me to look at, can you write a step-by-step guide from starting the program to where the issues occur?

That way, I can follow it to where your issues are, then dig in.
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 20, 2013, 04:42:15 pm
Like this?

https://openxcommods.weebly.com/mapview_upgrade.html (https://openxcommods.weebly.com/mapview_upgrade.html)
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 20, 2013, 05:10:02 pm
I've not really read it yet, but it looks the sort of thing I was expecting. I'll have a proper read tonight or over the weekend, depends on what free time I get.

Who's the original author of these tools? I guess there wouldn't be any issues with me putting the source codes in my GitHub seeing as though you can get them from Sourceforge

I noticed the PckView tool is also in there, and there was a few things I would like to do with that (basically allow zooming really). I was also thinking a simple pixel editor, but now that externalised graphics are supported, that really isn't necessary any more.
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 21, 2013, 09:50:58 am
Sorry i added one more WISH , i hope you find the will to look into these  ;)

The original author was Daishiva , i am not sure if he held off on doing these upgrades himself because of time restraints or because there was discussion at the time to moving to a new format, that would then make his program obsolete. Its been 12 months since then and i don't hear about much desire for a NEW format right now so i am really hoping this can be fixed up to make it easier for new modders to get started.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 21, 2013, 11:15:48 am
Luke,

 I've fixed the DAT file saving now (point 1.), and I've also added your auto link (point 2.). So as you drop nodes, it'll add a link back to the previous node, and also try and add a link from the previous node to the new one. I think that's what you were asking for. The source code on SourceForge didn't have the "Default" checkbox shown in your screenshot. I should be able to add it back in, if you can tell me what it does?

Source code can be found here:
https://github.com/pmprog/OpenXCOM.Tools

Binary downloads are here:
https://github.com/pmprog/OpenXCOM.Tools/tree/master/Distribution

I need to go and do some less exciting, but more important stuff, so I'll come back to the other bits later. If you could test out my changes though, that would be helpful
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 23, 2013, 01:16:22 am
Basically, you select a NODE that you that has all the setting you are after ( Spawn type , Rank etc) and you check the Default tick box, now every link that you place after has all the same settings.


***UPDATE****


Maybe its me, but i cant get it to open :-[
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 23, 2013, 11:58:59 am
Basically, you select a NODE that you that has all the setting you are after ( Spawn type , Rank etc) and you check the Default tick box, now every link that you place after has all the same settings.
Okay, I can add something like that in

Maybe its me, but i cant get it to open :-[
Does it say anything?
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 23, 2013, 12:08:25 pm
Commandwindow thing flashes pretty quick.

If i use the "Run AS" option in windows i get a message stating it cant create a temp file somewhere .
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 23, 2013, 03:09:00 pm
Commandwindow thing flashes pretty quick.

If i use the "Run AS" option in windows i get a message stating it cant create a temp file somewhere .

Did you replace the exe's in you existing installation? Did you get all three files from the distribution folder?

Also, might be worth checking if there are any Microsoft .NET v2 service packs that you don't have installed

The other thing you can try is run the program, then right click on My Computer, and select Manage, then go to the Event Viewer and look at the Application Logs. Might have something in there
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 24, 2013, 01:06:02 pm
I tried a stand alone install and i also tried replacing my existing files with all 3 of your new ones.

I am setting up a VM on my work PC , i will try it there also , looking at the Event viewer( that i have never seen before) there is a error for .NET so i will update that next to test.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 24, 2013, 01:07:11 pm
Okay, let me know
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 24, 2013, 02:01:43 pm
Got it running on VM , .NET3.5 was the winner , 4.0 doesn't work
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 24, 2013, 02:46:21 pm
Good stuff. Okay, I'll try and do some more on it tonight
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 24, 2013, 11:10:15 pm
Got it running on VM , .NET3.5 was the winner , 4.0 doesn't work

New release - Rather than a default checkbox, I've added Copy and Paste buttons on the node. I've also added an overlay in RmpView to show your mouse co-ordinate and what spawn type you're hovering over.

Can you have another play and let me know, thanks
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 25, 2013, 01:32:18 pm
New release - Rather than a default checkbox, I've added Copy and Paste buttons on the node. I've also added an overlay in RmpView to show your mouse co-ordinate and what spawn type you're hovering over.

Can you have another play and let me know, thanks

Just tried your second version, here is some feedback:
Path Menu-Save functions in PATH is workign correctly
RMP - Node -Copy and paste work but can we add Keyboard shortcuts to this window also?
RMP- Node number when Hovering is a nice touch
Graphic updates nicely on other windows to show current cursor position
Can we expand "Reverse Link" to handle previously created node, so if its active and i link node 1 to 3, can it attempt to autolink back?
Found new error , RMP window crash's ( appears to be at random) and generates attached
Found new error - I have 2 different versions of UFO active in my C:\  .  I added a Map via the Paths menu from my secondary folder (not the one Mapview is pointed at) everything was fine when i saved it, but once i went back to main menu, it couldnt find the new map i added. I believe the issues is it switch back to checking the default UFO file for my  NEW UFO Map when it was in the other directory, as such it generates a error as it cant find it ;)

So are you  having fun yet ? You making my day , i have decided to take this week off from study to focus on the next set of Ufos  ;D I have added another useful option to the first list, just incase you want to be my friend for ever and ever :P
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 25, 2013, 02:03:18 pm
Yeah, I am enjoying coding at the minute. As well as this, I'm working on a launcher called The Tournament Hub for the OpenPandora.

It's quite difficult to follow the code some times, but getting there. Also makes it a little more complicated because I don't really know what I'm doing with the tool.

I've added your extra notes onto the GitHub Issues page. So you can keep track of progress
https://github.com/pmprog/OpenXCOM.Tools/issues

I've added your 2nd "new error" about the new map paths, but I'm not quite sure what the problem is with that. If you could do a YouTube video or something demoing it, that would be great.
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 25, 2013, 02:18:22 pm
I dont have video recording on that PC ( its a work PC ), i will try to explain it again:

I have Mapview linked to "C:\Ufo
I also have a second UFO install  C:\ufo_m

I added a File from  the UFO_M directory into Mapviews "Mapedit" file via the PATHS screen, at this point it saved without any issues.

Back on the main windows, everything looked good until i selected that file in the main window , it then gave me a error saying it couldn't find the file i just added via the Paths screen. I assume this is because it was not in C:UFO ( that mapview is linked to) so i assume that was the cause , it  was looking in the wrong directory for the file.
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 26, 2013, 02:07:38 pm
I have joined Github so i can post issues direct and keep this topic for the positive things
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 26, 2013, 03:11:27 pm
Should I expect several dozen newly raised issues now? ;)

Oh, I've seen 1 new :)
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 26, 2013, 04:41:25 pm
lets hope not , i dont think the program is "THAT BAD" it just needs some things fixed and a few upgrades made, i love your suggestion about changing the MCD data, right now i use MCDEDIT for that and its would be nice to intricate it all under this one program.

I do have other suggestion for this program but the ones that are listed are the most important ::)
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 26, 2013, 04:54:36 pm
lets hope not , i dont think the program is "THAT BAD" it just needs some things fixed and a few upgrades made, i love your suggestion about changing the MCD data, right now i use MCDEDIT for that and its would be nice to intricate it all under this one program.

Actually, that was a request from Warboy
Title: Re: MAPVIEW upgrade
Post by: Warboy1982 on June 28, 2013, 07:18:40 pm
this is a very useful program...
Title: Re: MAPVIEW upgrade
Post by: moriarty on June 28, 2013, 10:51:59 pm
Oooh, I see the door where the skyranger front-row-rookies go in for their "specialist training"  ;D
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 29, 2013, 01:29:32 am
Nice work Warboy, it looks really nice.

I am so glad this program is getting it long overdue bug fixes, i am checking everyday for Pmprogs next release as his current upgrades and Fixes have already saved me heaps of time on my UFOs i have almost finshed the current ships.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 29, 2013, 01:13:12 pm
I'm afraid it'll probably have to wait for a few days before I get chance to look at it again. I've got stuff on most of the weekend

Will try and get back to it soon
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 29, 2013, 01:29:04 pm
No problems mate , your the Boss, your work so far as already saved a lot of time in setting up and building maps so i will just remind you every few weeks  ;)

FYI: The expanded functionality for "Auto connect nodes" would be great next ( auto linking existing Nodes).
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 29, 2013, 07:36:48 pm
FYI: The expanded functionality for "Auto connect nodes" would be great next ( auto linking existing Nodes).

That the one that when you set up a link from one node to another, it'll ask you if you want to try and set up a reverse connection too?
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 30, 2013, 12:16:38 am
Yes, don't ask with a message box or anything , that will be annoying , either select the existing auto link tick box or add another one to use with this feature :) 

By adding all these Auto linking node rules,it will take 1/3 of the time to create the RMP data, that's a huge time saver when your building  big map sets like i do.
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 30, 2013, 04:03:24 pm
Hmmm, does it crash for anyone else when you open UFO - Ships -> Alien -> UFO_01a?

I don't have this map file in my steam lot. I do have a "UFO1A.MAP" file though.

Also, if I open UFO_000, I get some really skewed graphics
(https://s21.postimg.org/e4jrdw7yf/UFO000_Map_View_Bug.png)

Anyway. Posted a new version where the AutoConnect now works with existing nodes that are newly linked together
Title: Re: MAPVIEW upgrade
Post by: luke83 on July 01, 2013, 01:34:37 pm
I have the same error on the First 3 UFOs.

Also added Linking error to Github, every return link is being saved as i scroll through the list of possible links, the save of the return links should only happen once you click out of the currently selected "Link" dropdown box.
Title: Re: MAPVIEW upgrade
Post by: pmprog on July 01, 2013, 01:39:57 pm
I have the same error on the First 3 UFOs, not sure why.

Also added Linking error to Github, every return link is being saved as i scroll through the list of possible links, the save of the return links should only happen once you click out of the currently selected "Link" dropdown box.
Stick it as a bug on my git repo, and I'll sort that out later :)
Title: Re: MAPVIEW upgrade
Post by: luke83 on July 01, 2013, 01:46:31 pm
UFO_110 had the wrong map sets loaded. ( should be U_ext02, U_wall02, U_bits)
Ufo1a loads the wrong file as you noticed, you then just need to assign it the correct MCD set ( UFO1.mcd).
Title: Re: MAPVIEW upgrade
Post by: pmprog on July 01, 2013, 02:02:06 pm
Is this something that should be fixed in the MapView tool too? I assume so, as that creates the dat files. Can you stick an issue on for that too please? ;)
Title: Re: MAPVIEW upgrade
Post by: pmprog on July 11, 2013, 10:12:42 am
I've released a new version that fixes the Autoconnect "scrolling through the combobox" issue; and you can now connect nodes by rightclicking in the RmpView (If Autoconnect is checked, it will also try and create the reverse link too).

I have been thinking about redesigning some of this tool to work better with OpenXCOM data, and merge with M.A.R.S. (I don't know if you've been following the other OXCTools thread). After all, one of the issues on my repo is remove "unused UFOs", but if we use OXC ruleset data, we will only process valid data anyway.

I'm not sure on timescale for that merge, but you'll start to see a MARS binary join the distribution folder when it's a bit further down the line
Title: Re: MAPVIEW upgrade
Post by: luke83 on July 11, 2013, 12:31:51 pm
Excellent i will try the new version soon.

One question what is MARS?
Title: Re: MAPVIEW upgrade
Post by: pmprog on July 11, 2013, 12:49:11 pm
One question what is MARS?
https://openxcom.org/forum/index.php/topic,1361.0.html

Basically, it's a UI for editing OXC rulesets. So it should be easier to make mods etc.


Edit: Updated the build again to fix some crashes - see Issue 10. Would be good to know if I've fixed this properly

Cheers
Title: Re: MAPVIEW upgrade
Post by: Warboy1982 on July 12, 2013, 04:48:56 am
Mod Authored Ruleset Suite (MARS)
Title: Re: MAPVIEW upgrade
Post by: luke83 on June 18, 2014, 01:43:44 pm
Luke,

 I've fixed the DAT file saving now (point 1.), and I've also added your auto link (point 2.). So as you drop nodes, it'll add a link back to the previous node, and also try and add a link from the previous node to the new one. I think that's what you were asking for. The source code on SourceForge didn't have the "Default" checkbox shown in your screenshot. I should be able to add it back in, if you can tell me what it does?

Source code can be found here:
https://github.com/pmprog/OpenXCOM.Tools

Binary downloads are here:
https://github.com/pmprog/OpenXCOM.Tools/tree/master/Distribution

I need to go and do some less exciting, but more important stuff, so I'll come back to the other bits later. If you could test out my changes though, that would be helpful


So OXC has reached version 1.0 and I missed the big event...Bummer... Anyway, 6 more months people and I will start showing my ugly head around this community again. In the mean time, I need to start setting up my Modding environment again and stat tracking down all my programs and files.

 Now there is a thriving community of modders, I must ask, has any further improvements been made to this program since I have been gone?
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 20, 2014, 08:46:28 pm
I'm trying to run this version on Windows 7 64 bit but it doesn't work. But my older version works fine. Anything I can do to get the new version running?
Title: Re: MAPVIEW upgrade
Post by: davide on June 20, 2014, 09:47:15 pm
do you have installed the visual studio 2010 SP1 runtime system ?

https://www.microsoft.com/en-US/download/details.aspx?id=5555 (https://www.microsoft.com/en-US/download/details.aspx?id=5555)

I have rebuilt MapView now
Title: Re: MAPVIEW upgrade
Post by: Aldorn on June 21, 2014, 02:39:29 am
do you have installed the visual studio 2010 SP1 runtime system ?

https://www.microsoft.com/en-US/download/details.aspx?id=5555 (https://www.microsoft.com/en-US/download/details.aspx?id=5555)

I have rebuilt MapView now
Your attached version does not work for me on Win 7 x64

I failed to install the visual studio 2010 SP1 runtime system because of a newer version already installed

I confirm my old version of mapview still works
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 21, 2014, 02:41:49 am
Does not work for me (on Win 7 x64)

Have you tried davide's upgrade version attached on the post right before yours?
Title: Re: MAPVIEW upgrade
Post by: Aldorn on June 21, 2014, 02:46:27 am
Have you tried davide's upgrade version attached on the post right before yours?
What are you talking about ?

 ;)
Sorry, I updated my post while you were answering me

Does this new Release.rar work for you ?
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 21, 2014, 02:56:57 am
What are you talking about ?

 ;)
Sorry, I updated my post while you were answering me

Does this new Release.rar work for you ?

Yes. I unzipped everything to the folder where I had my old version and it worked without a problem.
Title: Re: MAPVIEW upgrade
Post by: Aldorn on June 21, 2014, 02:58:00 am
Ok so let's forget it
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 25, 2014, 12:18:35 pm
I'll be honest, I've done very little personal programming in any respect for a while, Luke's asked if I could fix some bugs, I can try and take a look at a few other bits this weekend too, if others are having problems
Title: Re: MAPVIEW upgrade
Post by: Aldorn on June 25, 2014, 01:08:26 pm
That's kind of you !

But as soon as someone make it work, this means it is just an install issue, isn't it ?

I have an old version that works well, so I use it
Title: Re: MAPVIEW upgrade
Post by: pmprog on June 26, 2014, 01:50:32 pm
That's kind of you !

But as soon as someone make it work, this means it is just an install issue, isn't it ?

I have an old version that works well, so I use it
Well, if I can squeeze the time, I'll wrap up an installer or something. If you use my builds though, you'll need .NET v3.5; I can't really remember all the other details at the minute
Title: Re: MAPVIEW upgrade
Post by: davide on June 26, 2014, 02:30:21 pm
The project target framework is .Net Framework 4.0

Title: Re: MAPVIEW upgrade
Post by: pmprog on June 30, 2014, 09:23:04 am
Really? because I use VS2008, which can't target .NET v4. I assume if you loaded a copy into VS2010, it'll have upgraded it.

Anyhoo, I had no time to work on this at the weekend :( Sorry
Title: Re: MAPVIEW upgrade
Post by: davide on June 30, 2014, 10:51:04 am
Yes I open it with VS2010 (Full and Express)
Title: Re: MAPVIEW upgrade
Post by: luke83 on July 06, 2014, 12:39:29 am
FYI: on Win8 version, i get heaps of errors and cant add new maps into the game without it crashing so i have been forced to install a Virtual Machine and boot up XP again, once i do that, this is the best version of Mapview out there ( mostly because of the new features PMPROG added for me).
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on July 09, 2014, 08:20:43 am
 :D
Hello there

I would like to contribute in the coding.

I saw
https://sourceforge.net/p/xcmapedit/code/HEAD/tree/trunk/dev/
svn checkout svn:https://svn.code.sf.net/p/xcmapedit/code/trunk xcmapedit-code
https://github.com/pmprog/OpenXCOM.Tools/trunk

I wanted to learn about how the routes are stored.. but there was too much hairy scary code.

I noted that the routes arent working in this new version, but like more the pmprog version

Reviewed the code and I think it needs some structural improvements like:
1- Error handling.
2- Organize some of the classes by functionality.
3- Separate and reuse code.

Anyway let me know if I can help

PS - Didnt experience any problem installing and running the code
Title: Re: MAPVIEW upgrade
Post by: pmprog on July 09, 2014, 09:26:26 am
:D
Hello there

I would like to contribute in the coding.

I saw
https://sourceforge.net/p/xcmapedit/code/HEAD/tree/trunk/dev/
svn checkout svn:https://svn.code.sf.net/p/xcmapedit/code/trunk xcmapedit-code
https://github.com/pmprog/OpenXCOM.Tools/trunk

I wanted to learn about how the routes are stored.. but there was too much hairy scary code.

I noted that the routes arent working in this new version, but like more the pmprog version

Reviewed the code and I think it needs some structural improvements like:
1- Error handling.
2- Organize some of the classes by functionality.
3- Separate and reuse code.

Anyway let me know if I can help

PS - Didnt experience any problem installing and running the code
Feel free to fork my repo (btw, there's no "/trunk" on the end), as it has a few changes luke83 asked for in.

One of my plans was to do some of the improvements you suggested, but time and motivation were issues.

Luke also PM'd me an error he was having, I've not even looked at it yet, but if it's something you feel like you want a shot at, I (or Luke) can send you on the information
Title: MapView & PckView upgrade - New Version
Post by: TheBigSot on August 04, 2014, 12:08:23 am
Basically
* Fixed some bugs
   * Scrollbar issues
   * Color issues
   * Etc
* Integrated PckView into MapView  (Havent done deep testing on functionality, but should be interesting)
Title: Re: MAPVIEW upgrade
Post by: Aldorn on August 04, 2014, 12:30:37 am
Thanks, I will try it  :)
Title: Re: MapView & PckView upgrade - New Version
Post by: Aldorn on August 09, 2014, 12:46:23 am
Basically
* Fixed some bugs
   * Scrollbar issues
   * Color issues
   * Etc
* Integrated PckView into MapView  (Havent done deep testing on functionality, but should be interesting)
This works perfectly !
Thanks  :)
Title: Re: MAPVIEW upgrade
Post by: Hobbes on August 09, 2014, 08:01:23 pm
I've been trying this version, I haven't had the opportunity to check the PCKView integration but here's my experience:
* the error message when encountering bugs is too big (gets annoying) when compared with the previous version.
* Plus, the bug with the "Array out of bounds" isn't fixed and previously it was possible to continue working but now I have to restart MapView.

Could you fix those? It would be great to have someone continuing developing this tool :)

A few other things that need to be improved:
* When switching between maps, any changes made to the RMPs are lost, without the editor asking/warning if you want to save the changes.
* When changing the height of an existing map, the RMP and MAP files get different results. For instance, when increasing a map height from 4 to 6, the editor adds 2 empty levels to the MAP file, on top of the existing ones. However, on the RMP it adds the 2 extra levels below the existing ones.
Title: Re: MAPVIEW upgrade
Post by: luke83 on August 12, 2014, 09:17:08 pm
I've been trying this version, I haven't had the opportunity to check the PCKView integration but here's my experience:
* the error message when encountering bugs is too big (gets annoying) when compared with the previous version.
* Plus, the bug with the "Array out of bounds" isn't fixed and previously it was possible to continue working but now I have to restart MapView.

Could you fix those? It would be great to have someone continuing developing this tool :)

A few other things that need to be improved:
* When switching between maps, any changes made to the RMPs are lost, without the editor asking/warning if you want to save the changes.
* When changing the height of an existing map, the RMP and MAP files get different results. For instance, when increasing a map height from 4 to 6, the editor adds 2 empty levels to the MAP file, on top of the existing ones. However, on the RMP it adds the 2 extra levels below the existing ones.


have the ability to automatically add levels below a existing map set could be a very useful feature...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on August 22, 2014, 08:25:36 am

have the ability to automatically add levels below a existing map set could be a very useful feature...

Agreed.
Title: Re: MAPVIEW upgrade
Post by: Falko on September 20, 2014, 08:29:21 am
does pckview use different colors?
i looked at https://github.com/pmprog/OpenXCOM.Tools/tree/master/PckView/_Embedded
to determine what colors are used by pckview export
these are not the same as the colors described in the act files supsuper or warboy published some time ago
e.g.:
pckview second color: 236,236,236
actfile/my images second color: 252,252,252

there are only very few correct colors
is there a reason for that?
Title: Re: MAPVIEW upgrade
Post by: robin on September 20, 2014, 12:01:40 pm
does pckview use different colors?
there are only very few correct colors
Yes the palettes are quite different. See my observations:
https://openxcom.org/forum/index.php?topic=1557.msg29995#msg29995
https://openxcom.org/forum/index.php?topic=1557.msg30945#msg30945
https://openxcom.org/forum/index.php?topic=1557.msg30946#msg30946

I don't know the reason though.
Title: Re: MAPVIEW upgrade
Post by: NoelBuddy on October 08, 2014, 04:11:18 am
First a big thank you to everybody working on this.

I've been using the MapView_PckView.zip and had a few questions:

Is there a way to define the folder it looks in for the map files after the initial start up? Not a big deal but I only told it where to look for UFO files when first testing it out and wound up deleting it and reloading to tell it where to look for TFTD files.

Is there a simple way to add maps that aren't default? I wanted to edit one of the alloy crafts and had to write it into the MapEdit.DAT file, is this how it's done or is there a simpler way?

When I select Open from the file menu it doesn't seem to do anything.

I'm having some trouble with nodes, I can edit/delete existing ones but I'm not sure how to put in a new one or move one?  Also issue mentioned above with all level adding one on top of the map and at the bottom of the RMP. :/
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on January 09, 2015, 05:01:54 am
For anyone on OS X, wine doesn't really work so well. Crashes, and the dreaded index color 1 shows black so seeing anything is tough. However, you can run it in virtual box using a machine image from https://www.modern.ie/en-us

Workflow isn't ideal, but it's at least viable.
Title: Re: MAPVIEW upgrade
Post by: bladum on January 09, 2015, 02:58:03 pm
when i was on mac i used https://www.virtualbox.org/ without any issues
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on January 15, 2015, 05:13:52 am
So I've tried editing the images.dat file but my custom pck crashes the system every time. Am I missing something? I've attached my pck files to this post and the error below

 Windows XP in virtual box with .net 4 and the VS extensions mentioned earlier.
Loading a renamed PCK file seems to work as expected, is there a limit to the number of PCK images in a file maybe? I didn't add many, and it was a short set already, so I wouldn't think that was it. Or maybe I've got an MCD error in the set?

System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at XCom.XCTile.set_Tiles(XCTile[] value)
   at XCom.GameFiles.Map.XcTileFactory.CreateTiles(String basename, String directory, PckFile pckFile)
   at XCom.ImageDescriptor.GetMcdFile(Palette p)
   at XCom.XCMapDesc.GetMapFile()
   at MapView.MainWindow.LoadSelectedNodeMap()
   at MapView.MainWindow.mapList_AfterSelect(Object sender, TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on January 19, 2015, 06:39:07 am
Further investigation seems to indicate that the pck/mcd files I created in mcd edit are somehow corrupted. The index note makes me wonder if something isn't right with the indexed color, though I saved as png with the correct battlescape pallet. Looks like I'm going to have to test each frame individually to try and learn what's causing the problem.
Title: Re: MAPVIEW upgrade
Post by: volutar on January 19, 2015, 09:25:33 am
Perhaps you've reached 256 tile limit per map?
Title: Re: MAPVIEW upgrade
Post by: robin on January 19, 2015, 11:01:27 am
@ TheBigSot or pmprog

There's a modification that should be done to MapView: "unlocking" the maximum value supported for "Target_Type" byte of an MCDs.
In MapView the value should be the one labeled "special proprieties", for example "special proprieties: StartPoint".

In vanilla that byte can have a value ranging from 0 (which means "nothing") to 14.
But OXC ruleset gives us the "specialType" entry which enables us to link any object with an MCD with the same "Target_Type" value, obviously starting with values > the ones already used (so > 14).
The problem is, if we do that (assigning a value > 14 to a MCD, that is), MapView can't read anymore the MCD itself (or it can read it, but goes crazy because it finds an out of range value?), and the whole library of tiles containing such an MCD becomes completely unavailable (big red cross instead of all the tiles).

I hope I explained the issue comprehensively.

You can actually take countermeasures against the issue, to avoid it (like assigning the values only after you have done your maps), so it is not a "show stopper" thing, but it's not ideal.
Warboy said it should be an easy modification, just "un-restricting" or something that byte.

Thanks.
Title: Re: MAPVIEW upgrade
Post by: volutar on January 19, 2015, 11:37:43 am
From my point of view it's just dropdown menu index. Dropdown menu is hardcoded with values and it can't know what's beyond. It can't set index value with position exceeding number of lines there. There are two ways to make a workaround:
1. Add 200 extra lines for unknown values.
2. Change input UI element type from dropdown to editbox. Deciphered values could be drawn close to it.

I recommend pm the guy who made recent version.
Title: Re: MAPVIEW upgrade
Post by: robin on January 19, 2015, 12:22:59 pm
I recommend pm the guy who made recent version.
Done.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 19, 2015, 03:45:39 pm
Hello, thanks for the feedback, and posting the error information.

I'll be reviewing the bugs and the feature requested, and I'll let you know when I'm finish.
Title: Re: MAPVIEW upgrade
Post by: robin on January 19, 2015, 04:09:40 pm
Hello, thanks for the feedback, and posting the error information.

I'll be reviewing the bugs and the feature requested, and I'll let you know when I'm finish.
Thank you a lot!
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 19, 2015, 06:56:19 pm
...

System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at XCom.XCTile.set_Tiles(XCTile[] value)
   .....

Added the console window
Now it will shown a message in the console similar to 'WARNING: In the MCD file U_EXT02-C, the tile entry 34 have an invalid alternative tile (# 49 of 41 tiles)'

Now checking "SpecialType" so far i found some bugs. and here is the current options:

    public enum SpecialType
    {
        Tile = 0,
        StartPoint,
        IonBeamAccel,
        DestroyObjective,
        MagneticNav,
        AlienCryo,
        AlienClon,
        AlienLearn,
        AlienImplant,
        Unknown9,
        AlienPlastics,
        ExamRoom,
        DeadTile,
        EndPoint,
        MustDestroy
    };
Title: Re: MAPVIEW upgrade
Post by: robin on January 19, 2015, 07:15:36 pm
Yeah, default goes up to 14 "MustDestroy". Any higher value and the whole MCDs library (containing the MCD with the unsupported value) is not available anymore in MapView.

Maybe Warboy (or volutar, I don't know) can explain better the whole "Target_Type" -->  ruleset's "specialType" relationship. As far as I know it's just a value, and if the value is equal for both the item is linked to the MCD, so that each instance of the MCD present on the map means an instance of that specific item present in the battlescape (and eventually recoverable at the end of the mission).

(I don't know if this kind of info are useful to you or not. Probably not).
Title: Re: MAPVIEW upgrade
Post by: volutar on January 19, 2015, 07:34:29 pm
I've made addition to rmp format description and something in respective talk area of https://ufopaedia.org. I bet there is quite detailed info. I can't say more now since I'm at vacation in Hungary.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 20, 2015, 02:08:39 am
Latest Version is available.  ;D :D

Added the console to mapview.
Improved how the errors are shown (now some are warnings that are shown in the console) [Invalid Alternate Tile, invalid Dead Tile]
Changed the way nodes connect in the "RmpView", now there are 3 options "Connect One way" "Connect Two ways" "Dont Connect", instead of autoconnect
Changed the text of "RmpView" to "Waypoint view"
Now the app wont crash or raise errors if the MCD contains a not defined "SpecialType" (higher than 14)
    ** (But they wont have a background, the MCD Viewer will show the number)
Added message when changing the map or closing the app and there are routes RMP not saved
Fixed some errors performing Copy or Cut in the Map Editor


(Next things that might be worked on in another time.)
   Changing the details of a RMP should raise the save message if necessary
   Improve the way floors are added   
   Issues with the palette

Thanks again for all the feedback.
GL HF
Title: Re: MAPVIEW upgrade
Post by: robin on January 20, 2015, 12:14:34 pm
Nice!
Title: Re: MAPVIEW upgrade
Post by: Hobbes on January 20, 2015, 03:07:16 pm
Thank you!
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 21, 2015, 01:08:37 pm
I am just testing this with wine on Linux,
is there a copy of the source code anywhere, i would like to get a gtk build of.


Wow that's a total fail on wine. I guess the drawing code is really only for windows....
Not even the menues are working properly...
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on January 24, 2015, 08:40:00 pm
Using virtualbox and windows XP, having issues saving image of the map out. I get the "OOPS" message but no details.

System.NullReferenceException: Object reference not set to an instance of an object.
   at XCom.Interfaces.Base.IMap_Base.SaveGif(String file)
   at MapView.MainWindow.miSaveImage_Click(Object sender, EventArgs e)
   at System.Windows.Forms.MenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.MenuItem.MenuItemData.Execute()
   at System.Windows.Forms.Command.Invoke()
   at System.Windows.Forms.Command.DispatchID(Int32 id)
   at System.Windows.Forms.Control.WmCommand(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ContainerControl.WndProc(Message& m)
   at System.Windows.Forms.Form.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 24, 2015, 11:12:09 pm
Good, Ill review the SaveGif method once my computer stops acting like an Idiot (upgrading then degrading the windows 8.1 installation)

Thanks for the info
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 24, 2015, 11:40:58 pm
Should be fixed now, let me know if this fixed the issue. :)
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 24, 2015, 11:44:32 pm
Wow that's a total fail on wine. I guess the drawing code is really only for windows....
Not even the menues are working properly...

Hi there, I'm not sure how to perform test for your environment, but I may be able to help if you attach some screenshots or videos of the problems.

You can find the code in 'https://github.com/TheBigSot/OpenXCOM.Tools'
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 25, 2015, 06:48:02 pm
Since Code is in C#, i maybe will give it a try and compile it manually here on Linux.

I did this before with the stuff from pmporg, but this build was also failing on the drawing and also had the windows errors.
Maybe the code should be revisited. Do you use WPF (System.Windows.Forms and System.Drawing and so) for the menues?
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 25, 2015, 07:12:07 pm
Just tested the Version you appended to your last post.

Wine complitly failes to load the Programm:

18:07:11 user@my-machine:~/games/openxcom/MapView_PckView$ wine MapView.exe
fixme:wincodecs:PngDecoder_Block_GetCount stub

Unhandled Exception:
System.TimeZoneNotFoundException: Exception of type 'System.TimeZoneNotFoundException' was thrown.
  at System.TimeZoneInfo.get_Local () [0x00000] in <filename unknown>:0
  at System.CurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00000] in <filename unknown>:0
  at System.TimeZone.GetLocalTimeDiff (DateTime time) [0x00000] in <filename unknown>:0
  at System.DateTime.get_Now () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.TextBoxBase..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.TextBox..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.TextBox:.ctor ()
  at MapView.Forms.Error.ErrorWindow.InitializeComponent () [0x00000] in <filename unknown>:0
  at MapView.Forms.Error.ErrorWindow..ctor (System.Exception exception) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.Forms.Error.ErrorWindow:.ctor (System.Exception)
  at MapView.Forms.Error.ErrorWindowAdapter.HandleException (System.Exception exception) [0x00000] in <filename unknown>:0
  at MapView.Startup.RunProgram () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.Startup:RunProgram ()
  at MapView.Program.TestRun () [0x00000] in <filename unknown>:0
  at MapView.Program.Main () [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TimeZoneNotFoundException: Exception of type 'System.TimeZoneNotFoundException' was thrown.
  at System.TimeZoneInfo.get_Local () [0x00000] in <filename unknown>:0
  at System.CurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00000] in <filename unknown>:0
  at System.TimeZone.GetLocalTimeDiff (DateTime time) [0x00000] in <filename unknown>:0
  at System.DateTime.get_Now () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.TextBoxBase..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.TextBox..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.TextBox:.ctor ()
  at MapView.Forms.Error.ErrorWindow.InitializeComponent () [0x00000] in <filename unknown>:0
  at MapView.Forms.Error.ErrorWindow..ctor (System.Exception exception) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.Forms.Error.ErrorWindow:.ctor (System.Exception)
  at MapView.Forms.Error.ErrorWindowAdapter.HandleException (System.Exception exception) [0x00000] in <filename unknown>:0
  at MapView.Startup.RunProgram () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.Startup:RunProgram ()
  at MapView.Program.TestRun () [0x00000] in <filename unknown>:0
  at MapView.Program.Main () [0x00000] in <filename unknown>:0

Same error on Pckview:

18:07:57 user@my-machine:~/games/openxcom/MapView_PckView$ wine PckView.exe
fixme:wincodecs:PngDecoder_Block_GetCount stub

Unhandled Exception:
System.TimeZoneNotFoundException: Exception of type 'System.TimeZoneNotFoundException' was thrown.
  at System.TimeZoneInfo.get_Local () [0x00000] in <filename unknown>:0
  at System.CurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00000] in <filename unknown>:0
  at System.TimeZone.GetLocalTimeDiff (DateTime time) [0x00000] in <filename unknown>:0
  at System.DateTime.get_Now () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.WinFileSystem..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.MWFVFS..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.FileDialog..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.OpenFileDialog..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.OpenFileDialog:.ctor ()
  at PckView.PckViewForm.InitializeComponent () [0x00000] in <filename unknown>:0
  at PckView.PckViewForm..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) PckView.PckViewForm:.ctor ()
  at PckView.Program.Main () [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TimeZoneNotFoundException: Exception of type 'System.TimeZoneNotFoundException' was thrown.
  at System.TimeZoneInfo.get_Local () [0x00000] in <filename unknown>:0
  at System.CurrentSystemTimeZone.GetUtcOffset (DateTime time) [0x00000] in <filename unknown>:0
  at System.TimeZone.GetLocalTimeDiff (DateTime time) [0x00000] in <filename unknown>:0
  at System.DateTime.get_Now () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.WinFileSystem..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.MWFVFS..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.FileDialog..ctor () [0x00000] in <filename unknown>:0
  at System.Windows.Forms.OpenFileDialog..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.OpenFileDialog:.ctor ()
  at PckView.PckViewForm.InitializeComponent () [0x00000] in <filename unknown>:0
  at PckView.PckViewForm..ctor () [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) PckView.PckViewForm:.ctor ()
  at PckView.Program.Main () [0x00000] in <filename unknown>:0

Looks like the exceptions are not being handled correctly.

Also:

18:10:45 user@my-machine:~/games/openxcom/MapView_PckView$ wine MapView.vshost.exe

Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
File name: 'Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
File name: 'Microsoft.VisualStudio.HostingProcess.Utilities.Sync, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 29, 2015, 05:11:04 am
Hey I just saw the exceptions, by the type of exception it looks like the environment needs some more configuration to make the app work, I may be able to add code to auto-fill missing system configuration information, but then a lot of other configurations might be missing and a lot of other auto-filling code might be needed.

I may have time to look at this issue in the weekend. Source "https://msdn.microsoft.com/en-us/library/system.timezonenotfoundexception(v=vs.110).aspx" Remarks

The other Exception 'FileNotFoundException' if you are compiling the code, you may want to look at the following link, where they talk about issues that come when compiling different platform target 
"https://stackoverflow.com/questions/14657361/naoqi-and-leap-problems-an-unhandled-exception-of-type-system-badimageformatex"
Else google the error, because I don't think I can help you with this one.
"https://bit.ly/1zDG1fg"
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on January 30, 2015, 02:08:40 am
Hey, I was talking about this issue with some co-workers, and they recommend that you use Mono instead of Wine, after reading this 'https://askubuntu.com/questions/31273/difference-between-wine-and-mono' it makes sense that your environment is missing configuration.

So I would highly recommend using mono.
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 31, 2015, 11:47:09 pm
Hey, I was talking about this issue with some co-workers, and they recommend that you use Mono instead of Wine, after reading this 'https://askubuntu.com/questions/31273/difference-between-wine-and-mono' it makes sense that your environment is missing configuration.

So I would highly recommend using mono.

Well thanks for your response anyway, if fired up virtualbox with windows7 for the time being. But i really would like participate in rewriting some of the Code of Mapview PCKview, to make it portable to Linux.

I am just making an education as an IT Systems Engineer and we are currently developing with csharp, so i am interested in getting some more skills.

Likewise i find the gui of mapview a real mess, no shortcuts for quicker editing and those windows... just make one big one and integrate everything in it or something else.
I also took the freedom to take a look in the codebase on github, to understand alittle bit more.
Title: Re: MAPVIEW upgrade
Post by: volutar on February 01, 2015, 08:48:59 am
I have a long-term plan of extending my mcdedit to the scope of map+mcd editor. But the vision of the final result is pretty blurry. It's pretty hard to find elegant and usable solution.
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on February 01, 2015, 07:02:26 pm
Honestly your preview map is a great step towards that. Would it be possible to do a tabbed window interface, with the mcd in one tab, pck in a second, and the preview map in a third? It would be grat if the PCk editing toos could persist across the last two tabs, but I'd really like to see the map larger on the edit window.
Title: Re: MAPVIEW upgrade
Post by: volutar on February 01, 2015, 08:18:49 pm
@jackstraw2323
Would it be possible to do a tabbed window interface, with the mcd in one tab, pck in a second, and the preview map in a third?
If you'll be seeing either pck editor or preview - it would be really bad. Preview should persist ALONG with pck editor, to quickly reflect all changes.
Quote
It would be grat if the PCk editing toos could persist across the last two tabs, but I'd really like to see the map larger on the edit window.
Yeah, that's the problem of mixing all this stuff together... It's not easy to find really elegant workaround. And I won't even start trying doing this, until I "see" whole picture consistent. Don't forget, with MAP editor it's not just 3 windows. Include MCDset editing for the map (I'd like to see MCDSet being editable handy way not by config editing like in MAPviewer), and the route layer (tho it'd be better to mix them with map itself).

Though it's whole new tool, and goes slightly off this topic, I guess. It'd need another one, to discuss and find solution without interfering other discussions.

And I didn't think over the MAP editor design and layout (and how it can be integrated with mcd editor), yet.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 01, 2015, 11:40:48 pm
Nice, I would rather focus on functionality since there are some missing tools or buttons here and there,
But if we are going to design an interface we need to know the workflow of the app and woot tools are needed for each step.

To my understanding the workflow and tools required are :

1. Edit tiles and tile sets - requires volutar tool MCD edit, tile set viewer, external image editor
2. Map tileset editor (dont think it exists)
3. Map edit - requires most of map view tools except RMP editor
4. Route (RMP) edit - requires most of map view tools except tiles editor/selector

** if i'm missing a step please reply

So based on this 4 stepz we could create a combo or some buttons to change the feel of the app depending on the step the user is working

But if u guys like the idea i can point some changes to volutars tool to be able to integrate it, also ideas are welcome

But again, i would first do the level layer add/remove function

GL HF
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 01, 2015, 11:46:48 pm
Btw if a new thread is created for the "Complete Picture, map editor integration" PM me.
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on February 03, 2015, 03:27:33 pm
If we look at the adobe tools we could take some UI elements to improve mapedit. Photoshop has a lot of different options, that are either tabbed, or set in groups with the sidebar drawer. Similar to the pallet or layers UI groups in photoshop you could have the mcd tiles in a collapsible sidebar pallet that could be pulled out or left open for the topview interface. Dreamweaver also had a good UI element, with code below and preview above. I could see the preview map living above the topview, with tabs for Topview, RMPView.

Better file tools would be really helpful, as right now I have to set paths etc manually and copy my files in and out of the default UFO defense folder. To version control, to openxcom folder, and to mcdedit folders.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 03, 2015, 06:47:56 pm
Can you create some mockups of ur vision

Like sceeenshot of how u see it all together
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on February 03, 2015, 09:16:45 pm
Something like the attached maybe?
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 07, 2015, 09:02:20 pm
Looks interesting and may fulfill the 3rd and 4th points of the workflows.,
maybe
I'll work on it.
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on February 08, 2015, 04:05:51 pm
The project target framework is .Net Framework 4.0
after installing https://www.microsoft.com/en-US/download/details.aspx?id=5555
and the .net framework on a new VM i get
.NET Framework Initialization Error
unable to find a version of the runtime to run this application
Okay had to download the 3.5 framework as well to get it running. Any way to include a readme with requirements and dependencies or change the EXE so it only needs 4.0?
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 08, 2015, 06:33:46 pm
I don't think it requires the framework 4, but ill review requirements
Title: Re: MAPVIEW upgrade
Post by: Hobbes on February 12, 2015, 01:05:49 pm
Hi,

I've seen several bugs while using it:
* The copy/paste function for nodes doesn't seem work
* It is possible to move from one map to the other without the dialog asking if you want to save the routes (it was supposed to be implemented IIRC)
* Adding new levels doesn't adjust the existing route nodes (it was requested, don't know if it was implemented)
* Choosing a category (NWall, etc.) that doesn't have any entries gives an automatic error message
* Using TAB to switch between boxes on the individual nodes gets me an error message
* The error messages are simply too big (and annoying)
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 13, 2015, 12:57:12 am
I'll Review the code, but please send me a PM, with all the information shown in the error window, that can speed up the process for this or next time :D
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 13, 2015, 02:24:11 am
After reviewing

1- In the Route view, the copy/paste function only copies the Node info without the links, I'll change the GUI to reflect this
2- Yeaa, a route verification for saving was added in order to prevent losing unsaved route changes. The verification is shown every time you make a change in the map and try to change it without saving first, I added functionality so the hotkey ctrl + s  work on routes and topView, this way you should be able to save faster and skip the dialog.
3- yaaa, the levels hmmmm... maybe later
4- Fixed the issues with the empty category
5- I was not able to replicate this error, I did fix some of the tabs indexes, but if you provide more information I can try later.
6- Well the error message provides me with all the information I need in order to fix the bugs quickly, but be sure the more I'll work on this project the less anyone will see that window.

New version will be ready soon
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 13, 2015, 05:29:46 am
New version, I also included the so famously wanted level route fix to add levels and moving the routes correctly, and many other minor fixes.

 :D

I'm also working on a integration with Volutar, now there is a button, but it only opens the Volutar editors,
Ill make it refresh it self from the changes @ volutar's later.

Hmm that was like 5 hours of work huh. Hope you guys enjoy it. I'm tired now.. work tomorrow.. more coding :D
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 14, 2015, 11:32:36 pm
Today I wake up a bit worry about the code for the leveling, because I didnt take into consideration the Links, are there going to be missing links if u remove a level?

I'm going to do some testings, and if I have time today or tomorrow maybe I'll work on an autoUpdate feature
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 14, 2015, 11:35:15 pm
Hmm yes missing links are kept, this is probably a minor bug, but I'll fix it
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 15, 2015, 12:02:35 am
Here, sorry for the inconveniences and happy friends day
Title: Re: MAPVIEW upgrade
Post by: Hobbes on February 15, 2015, 10:02:55 pm
Here, sorry for the inconveniences and happy friends day

I'll try it in the next days. Thanks :)
Title: Re: MAPVIEW upgrade
Post by: kikimoristan on February 15, 2015, 11:20:55 pm
just tried is works fine.

When i save images as bmp from spk file (sometimes) it gives a crash with option to close or quit. Clicking close does nothing . Clicking quit works. Image is still saved. So the program works just thinks it doesn't  :)

Thank you for the hard work you put into this. Thank you very much.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 16, 2015, 06:47:11 pm
Hi, I added some new styles to the Top view and Waypoint view.
Title: Re: MAPVIEW upgrade
Post by: volutar on February 18, 2015, 10:08:22 pm
TheBigSot
How do you identify these small "corner" tiles?
I suppose you're deciphered bigwall flag for the topview, but there's no "corner" piece there. Is it just an object with "free movement"?
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 19, 2015, 12:07:24 am
Hi, Im using loft information, but not all loft (ex: Some corners) are identified as the correct object shape, maybe later i'll add other loft combinations,

Im not sure woot thoes flag(big wall, or some others) do or represent, since they are edited in ur tool, got lil experience on them
Maybe ill check the mcd info later

Happy coding
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 23, 2015, 02:10:47 pm
Some minor improvements, including better topview corners and capacity to set routes to dif height in UFO, to eliminate a problem with basement UFO levels
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 23, 2015, 02:33:10 pm
One question:
Is it possible to include seperate Map/route paths for custom maps?
Or do they all have to be in the OpenXcom folder. i like to keep this seperate and it would also make more sense.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 23, 2015, 02:50:02 pm
One question:
Is it possible to include seperate Map/route paths for custom maps?
Or do they all have to be in the OpenXcom folder. i like to keep this seperate and it would also make more sense.

I'd also very much prefer to have them separated from vanilla stuff, mainly for ease of modding. Hopefully it'll happen some day.
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 23, 2015, 08:40:12 pm
I'd also very much prefer to have them separated from vanilla stuff, mainly for ease of modding. Hopefully it'll happen some day.

I am just trying to take a look into some of the expanded ubase maps, to see which is what and write a working mapscript.

But how can i integrate/show those maps in Mapview? Because Mapview only knows UFO Path and ONLY! lists the default maps.
This is Bullshit! Just read the complete fucking directories...
MAPS, ROUTES and TERRAIN. So that all maps can pop up.

Sry... just rageing about mapview.
Title: Re: MAPVIEW upgrade
Post by: Arthanor on February 24, 2015, 01:31:29 am
I remember it being a pain to edit non-vanilla maps the one time I tried to use it. Have you seen this page? https://openxcommods.weebly.com/mapview.html

With that info, I ended up managing to get the map opened and poke around a bit.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 24, 2015, 03:35:36 am
Because Mapview only knows UFO Path and ONLY! lists the default maps.
This is Bullshit! Just read the complete fucking directories...
MAPS, ROUTES and TERRAIN. So that all maps can pop up.

Hey, take it easy there, this is one good tool and we are making it a great tool, but it takes time and patience.

Also remember that there is a huge weird mapping of the files, that is stored separated from the actual files,
but the good news is that I'm sure we can tackle all those issues somewhere in the near future.
:D
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on February 24, 2015, 03:40:36 am
Have you seen this page? https://openxcommods.weebly.com/mapview.html

I hope to be able to replace the GUI of the 3rd and next images, with a more wizard like window.
But I'll probably will keep the old option windows for backward compatibility.

We'll see
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 24, 2015, 11:32:38 am
Hey, take it easy there, this is one good tool and we are making it a great tool, but it takes time and patience.

Also remember that there is a huge weird mapping of the files, that is stored separated from the actual files,
but the good news is that I'm sure we can tackle all those issues somewhere in the near future.
:D

Ey nevermind your doing a great job, i am just wondering how should one edit custom maps. Replace maps from the original dataset?

Or is there another way.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on February 25, 2015, 08:58:12 pm
I am just trying to take a look into some of the expanded ubase maps, to see which is what and write a working mapscript.

But how can i integrate/show those maps in Mapview? Because Mapview only knows UFO Path and ONLY! lists the default maps.

It's pretty easy to add existing modded maps to MapView by either editing the Paths and Image.dat files or using the tool's function. 
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 25, 2015, 09:52:37 pm
It's pretty easy to add existing modded maps to MapView by either editing the Paths and Image.dat files or using the tool's function.

Uhh ok. I will give it a try even thou i have no clue how, but i will try. Btw the way any news from luke83?
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 25, 2015, 11:02:02 pm
I am not sure what i am doing wrong but maps do not want load any more...
I get the following Error Msg

Code: [Select]
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei MapView.RmpViewForm.RmpView.set_Map(IMap_Base value)
   bei MapView.Forms.MainWindow.MainWindowsManager.SetMap(IMap_Base newMap, IMap_Observer observer)
   bei MapView.Forms.MainWindow.MainWindowsManager.SetMap(IMap_Base map)
   bei MapView.MainWindow.LoadSelectedNodeMap()
   bei MapView.MainWindow.mapList_AfterSelect(Object sender, TreeViewEventArgs e)
   bei System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   bei System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   bei System.Windows.Forms.TreeView.WmNotify(Message& m)
   bei System.Windows.Forms.TreeView.WndProc(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

When trying to load a custom map.

Got the Map to load, but maybe you can improve the code anyway:)
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on March 11, 2015, 06:54:08 am
Hi people, I haven't had time to continue working here, but hopefully I'll have some time in the weekend.

Some minor improvements, including better topview corners and capacity to set routes to dif height in UFO, to eliminate a problem with basement UFO levels
Be sure to download the latest version on the end of the page 8
https://openxcom.org/forum/index.php?action=dlattach;topic=1321.0;attach=13340

Something like the attached maybe?
'https://openxcom.org/forum/index.php?action=dlattach;topic=1321.0;attach=12954;image' from jackStraw
Last time I was coding the infrastructure, changing it to be able to make this mockup

Maybe I'll have time to finish that and review what else is in here, I also was adding the capacity to zoom in and out of the preview window (that looked kool, but I have to remember to be able to zoom in with the scrollbar!).

I wish i could find something to fix my problem with custom maps and the textures.
You can send me a PM if you need something, maybe I can help.

I also added a small bar in the routeView to be able to see how likely a alien is to spawn, move or rank (not really sure what it does, I changed its name to "Importance")

I'll give you guys a teaser
Title: Re: MAPVIEW upgrade
Post by: Hobbes on March 11, 2015, 06:05:10 pm
I also added a small bar in the routeView to be able to see how likely a alien is to spawn, move or rank (not really sure what it does, I changed its name to "Importance")

Flag = probability that the alien will move to that node when patrolling
Zero = unconfirmed, the leading hypothesis for the original game is that it determines probability that the alien will attack the object on that node since it is mainly found in nodes on XCom Base maps and the Skyranger map. I don't think this is actually implemented on OXC though.
Spawn = probability that an alien will spawn on that node

Also, I think there must be a bug since when I select the Lightning using the vanilla files I get an error message saying that there are routes located outside the vertical limits of this map. This has also happened to Dioxine with his Ventura craft (which is a modded version of the Lightning) and can cause crashes.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on March 16, 2015, 07:45:35 am
A little bit more feedback on the latest version. :)

First, with the .map editing functions, everything is working great to me and has been a much welcomed improvement in years I've used this program. With the .rmp editing I'm also very satisfied, specially with how autoconnect nodes work. However, there is still some small glitches where repeated links are added to nodes, which I think are related with autoconnect trying to to link nodes in different levels. If this is the issue, my suggestion would be for autoconnect to never link nodes in different levels because I always prefer to do it manually to ensure they're working.

Thanks for all your work :)
Title: Re: MAPVIEW upgrade
Post by: Warboy1982 on March 16, 2015, 10:17:34 am
Zero = unconfirmed, the leading hypothesis for the original game is that it determines probability that the alien will attack the object on that node since it is mainly found in nodes on XCom Base maps and the Skyranger map. I don't think this is actually implemented on OXC though.

can confirm, and it is.
basically if an alien patrols to one of these nodes, it will then, as part of the patrol routine, start targeting base facility modules whose MCD has the "baseModule" flag.
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494 (https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494)
Title: Re: MAPVIEW upgrade
Post by: Hobbes on March 16, 2015, 06:03:59 pm
can confirm, and it is.
basically if an alien patrols to one of these nodes, it will then, as part of the patrol routine, start targeting base facility modules whose MCD has the "baseModule" flag.
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494 (https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494)

Thank you. It would be nice then if it was possible for MapView to allow editing these 'Zero' values.

Warboy1982, one further question about the AI. When Tactical initializes during a UFO mission and it is placing the alien units, any alien with a 'scout' or 'start outside UFO' flag is only placed on routes with 0 rank, right? If there are routes with other ranks (Soldier, Navigator, etc.) those are simply ignored, and the aliens are placed randomly on rank 0 nodes, despite of their actual rank.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on March 20, 2015, 02:48:55 am
can confirm, and it is.
basically if an alien patrols to one of these nodes, it will then, as part of the patrol routine, start targeting base facility modules whose MCD has the "baseModule" flag.
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494 (https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L494)

Good, I will update MapView to include this.

But in other note, I noticed that the code to shoot to base module is HardCoded to always look in the second floor, and not in the floor of the current unit.

https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L510
https://github.com/SupSuper/OpenXcom/blob/master/src/Battlescape/AlienBAIState.cpp#L514

...Position(i, j, 1)...

Thank you for your time

Title: Re: MAPVIEW upgrade
Post by: TheBigSot on March 20, 2015, 03:10:33 am
any alien with a 'scout' or 'start outside UFO' flag is only placed on routes with 0 rank, right? If there are routes with other ranks (Soldier, Navigator, etc.) those are simply ignored, and the aliens are placed randomly on rank 0 nodes, despite of their actual rank.

This is so good to know, if found this codes:
      if (outside)
         node = _save->getSpawnNode(0, unit); https:// when alien is instructed to spawn outside, we only look for node 0 spawnpoints
      else
         node = _save->getSpawnNode(Node::nodeRank[alienRank], unit);

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

Which basically confirms what you are saying, I may then add a button tool to set all nodes to 0 alienRank, so all nodes can spawn (if other parameters are correct)
Title: Re: MAPVIEW upgrade
Post by: Warboy1982 on March 24, 2015, 05:52:21 am
yes and no, if they fail to find a spawn node as a scout, they'll try as a non-scout instead, and vice-versa. there's some percentage of how many aliens on average will be scouts and how many won't, defined in the deployment rules.

so for example on a crashed battleship, the commander will always spawn in the control room, the terror units will spawn in the corridors near the lift, engineers will be in the engine rooms in the feet, and so on. some % of each rank (plus any that couldn't find a ranked node) will use rank 0 nodes instead, and spawn outside the ship.

basically, put ranked nodes in the ships, and unranked nodes in the terrain.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on March 24, 2015, 01:27:00 pm
Thanks
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on April 04, 2015, 03:19:04 am
Finally a new version, I lost track of all the changes, but they are mostly GUI improvements like
  * The auto-zoom
  * Tabbed Top and Route views.
  * Some tool tip and labels change in the route view.

Hope you guys like it.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on April 04, 2015, 11:20:46 am
Works like a charm. The Auto-Zoom is nice. Clearly a progress!
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on April 04, 2015, 07:58:19 pm
I think most of the bugs are solved now, I'll probably will work on import and maintenance wizards of path and related things.
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on April 07, 2015, 03:36:29 pm
Feature request: some kind of report or indicator for unused mcd entries. I've got some overly large terrain sets right now, and that would help me edit them down a bit without having to click on the tiles to try and figue it out by eyeballing it.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on April 07, 2015, 03:40:32 pm
I think most of the bugs are solved now, I'll probably will work on import and maintenance wizards of path and related things.

Haven't had time & opportunity to check this update yet but will give you feedback when I restart map designing soon.

Feature request: some kind of report or indicator for unused mcd entries. I've got some overly large terrain sets right now, and that would help me edit them down a bit without having to click on the tiles to try and figue it out by eyeballing it.

Have you tried the Visible option in TopView's window? It allows you to choose which elements you want visible (Ground, West Wall, North Wall, Object) on screen.
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on April 07, 2015, 05:19:53 pm
I don't think that's what I'm after. I want to know which mcd tiles aren't used at all on the map. That's tricky if you have two tiles that look very similar. Or for instance the wing tiles on the plane are so small sometimes it's tough to see them on the top view.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on April 07, 2015, 05:33:44 pm
I don't think that's what I'm after. I want to know which mcd tiles aren't used at all on the map. That's tricky if you have two tiles that look very similar. Or for instance the wing tiles on the plane are so small sometimes it's tough to see them on the top view.

The opposite might be better: something to display which tiles are used on the map. This because from my experience each map block uses, on average 20-30 different tiles, depending on size, etc, and tilesets used on the maps have a total of 150-255 tiles.
Title: Re: MAPVIEW upgrade
Post by: davide on April 08, 2015, 08:30:36 pm
I wish I know the occurrence of any tile on the current map

because it could be drive to remove some unused  tile from a .pck

An othe feature, unconnected with the current map,
could be a main item menu to select a map or a group of maps, and
for each map,
increment or decrement map tile index that are between a couple of value  to allow resizing  tileset used on maps.

Something such as this pseudocode
that I inspired by here  8)
https://openxcom.org/forum/index.php/topic,3120.msg35775.html#msg35775 (https://openxcom.org/forum/index.php/topic,3120.msg35775.html#msg35775)

I do not know pyton, if someone would correct it ... :-[
Code: [Select]
from sys import argv

filename = argv[0]
startindex = argv[1]
offset = argv[2]

with open(filename, 'rb') as irdata:

    routes_bytearray = bytearray(irdata.read())
   
    print ''USAGE: map_filename startindex offset''

    print "Do you want to proceed? y/n"
   
    if raw_input('> ') == 'y':
   
        with open(filename, 'wb') as orfh:
         
            for i in range(startindex, sizeof(routes_bytearray) - 1):
                routes_bytearray[i] += offset
           
            orfh.write(routes_bytearray)
   
    else:
        print "Next time."


startindex must be greater than 2 to skip map dimension


Title: Re: MAPVIEW upgrade
Post by: Hobbes on April 08, 2015, 11:35:29 pm
Finally a new version, I lost track of all the changes, but they are mostly GUI improvements like
  * The auto-zoom
  * Tabbed Top and Route views.
  * Some tool tip and labels change in the route view.

Hope you guys like it.

Love the auto-zoom. I've been wanting something like that for a long time. :)

The new icons for Top View are great. The green square instead of triangle for objects is new but works, along with the door icons. A different ground color for lifts would also be useful, and something to distinguish between UFO and regular walls. 

EDIT: just started using it more and I like the change to the walls, showing the windows and so on, but there seems to be some issues when displaying outside walls like fences. Check image below where I show one map in both real and top view.
Title: Re: MAPVIEW upgrade
Post by: TheBigSot on April 09, 2015, 08:30:23 am
Nice, thanks for all the feebbacks.

Davide and jackstraw2323 - I think what you guys need is something like a MapSet optimizer, something to do all the work and return you a cleaner pack of PCK and whatnots, I may work on that.

Hobbes -
A different ground color for lifts would also be useful
yea I was thinking about that some time ago, but I forgot, I may look into it.

issues when displaying outside walls like fences

Can you PM me the MCD and stuff, cuz what I use is the LOFT info, and I would like to see it to figure out what is it, probably the issue is that thoes are "Tall fence" so they contain no "air", but still would like to make sure thats the case, I attached an image of how I figured out a Cultiva fence using Volutar's tool
Title: Re: MAPVIEW upgrade
Post by: jackstraw2323 on April 09, 2015, 07:03:17 pm
An optimizer would be great, but the report would probably be simpler to implement and let us optimize ourselves.

Along those lines if there were a way to select all mcds on the map and swap them with a different mcd it would help. When I change my mcd files my maps can get messed up if I'm removing a mcd I found I didn't need after all.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on April 09, 2015, 07:44:45 pm
Along those lines if there were a way to select all mcds on the map and swap them with a different mcd it would help. When I change my mcd files my maps can get messed up if I'm removing a mcd I found I didn't need after all.

This.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on April 09, 2015, 09:34:15 pm
Can you PM me the MCD and stuff, cuz what I use is the LOFT info, and I would like to see it to figure out what is it, probably the issue is that thoes are "Tall fence" so they contain no "air", but still would like to make sure thats the case, I attached an image of how I figured out a Cultiva fence using Volutar's tool

The MCD is in the attachment
Title: Re: MAPVIEW upgrade
Post by: hellrazor on April 21, 2015, 09:49:30 am
Btw were can i find the newest Version of Mapview?
Title: Re: MAPVIEW upgrade
Post by: hellrazor on June 03, 2015, 12:56:34 am
Soo i was just on the IRC with good old JonnyH,

and he made a branch for Linux -> here (https://github.com/JonnyH/OpenXCOM.Tools)

We were able to get the tools to compile under mono, the main culprit were the usage of "\" in paths instead of "/"....

Well anyway after this was solved, the programm compiled and i was able to get a map to display.
Somehow the transparency is not being used either in PCK or MapView directly...
Title: Re: MAPVIEW upgrade
Post by: Arthanor on June 03, 2015, 03:54:24 am
A linux version would be great. I would love to edit maps but don't own a windows computer..

I had managed to run mapview in wine earlier, but had the same transparency issue. Seeing mostly black backgrounds kind of ruins the whole thing. :/
Title: Re: MAPVIEW upgrade
Post by: hellrazor on June 03, 2015, 09:46:52 am
A linux version would be great. I would love to edit maps but don't own a windows computer..

I had managed to run mapview in wine earlier, but had the same transparency issue. Seeing mostly black backgrounds kind of ruins the whole thing. :/

I am assuming that this has to do something with System.DrawImage and how it handles transparency Alpha Channel stuff and for some odd reason the current code seems to produce different result on Linux and Windows.

But my c# skills are insufficient to solve something like this.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 11, 2015, 05:40:57 pm
I'm currently converting the ships from TFTD and I've ran into a few issues with MapView when editing large maps (30x30 or bigger). I've attached a pic of the biggest resolution I can achieve while editing to illustrate the ideas below:
* Is it possible to add the Zoom function to the Top and Routes views?
* I've tried to adjust to the new colors/symbols for the tiles but there are still a few kinks that are distracting: yellow is a color that I usually dislike and but before it had a lesser tone and was more hidden. Would it be possible to have some other way to mark ground tiles?
* The bars used to represent walls can be hard to distinguish from the squares used for objects. Perhaps go back to the straight line used in the previous versions of MapView?

All of this is really very particular to the use (very large maps) that I'm recently doing. Other than that, everything is working well :)
Title: Re: MAPVIEW upgrade
Post by: davide on June 12, 2015, 01:52:00 pm
Backgroud color and pen size used to draw bars could be app settings
Title: Re: MAPVIEW upgrade
Post by: hellrazor on June 15, 2015, 12:18:10 pm
Well i guess the copy function isn't working properly.

Cut or copy a selection of fields and try to paste them somewere, won't work as expected...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on June 15, 2015, 12:28:15 pm
Well i guess the copy function isn't working properly.

Cut or copy a selection of fields and try to paste them somewere, won't work as expected...

What is the problem exactly?
Title: Re: MAPVIEW upgrade
Post by: hellrazor on June 18, 2015, 09:58:10 am
What is the problem exactly?

Hm.. i can't reproduce it right now, maybe it was in a older Version. Nevermind.
Title: Re: MAPVIEW upgrade
Post by: XOps on June 25, 2015, 05:52:58 pm
Just a small note for future revisions. The older versions had the madID in the tileset window corner. See top left of the image linked below.
https://www.openxcom.com/content/modimages/BXWGGNOP062520150949.png
This is very handy for those of us working within tile limitations. It would be nice if this info was displayed somewhere.

I'm currently converting the ships from TFTD and I've ran into a few issues with MapView when editing large maps (30x30 or bigger). I've attached a pic of the biggest resolution I can achieve while editing to illustrate the ideas below:
* Is it possible to add the Zoom function to the Top and Routes views?
* I've tried to adjust to the new colors/symbols for the tiles but there are still a few kinks that are distracting: yellow is a color that I usually dislike and but before it had a lesser tone and was more hidden. Would it be possible to have some other way to mark ground tiles?
* The bars used to represent walls can be hard to distinguish from the squares used for objects. Perhaps go back to the straight line used in the previous versions of MapView?

All of this is really very particular to the use (very large maps) that I'm recently doing. Other than that, everything is working well :)
I second this. I've had to use the older version for working on new large UFO maps so I can see the walls.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 25, 2015, 06:25:24 pm
And a request to bring back a missing functionality (I think) from Map View: on the previous versions, when on Top View if you double clicked on any of the Ground/Walls/Content boxes it would bring forward and superimpose the Tile View over Top View.

This was very useful when editing. :)
Title: Re: MAPVIEW upgrade
Post by: pjlasl on July 04, 2015, 06:14:01 am
Anyway of getting this tool to work on windows 8?

I tried to dowload it but unfortunately it won't run on windows 8...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on July 04, 2015, 11:41:18 am
I tried to dowload it but unfortunately it won't run on windows 8...

...I think I'll withhold that Windows 10 update.
Title: Re: MAPVIEW upgrade
Post by: davide on July 04, 2015, 05:21:48 pm
Anyway of getting this tool to work on windows 8?

I tried to dowload it but unfortunately it won't run on windows 8...

Last year I used it on Win8.1
Title: Re: MAPVIEW upgrade
Post by: hellrazor on July 20, 2015, 01:20:21 pm
Whati i noticed and what was driving me nuts recently,
If you edit your Routes of a map, you have to explicitly save the file,
before switching to another map.
Would be nice to be asked for saving the file in case of modified routes.
Title: Re: MAPVIEW upgrade
Post by: kikimoristan on August 12, 2015, 03:17:20 am
i always get crashes when loading tftd pck files

also my mouse wheel no longer working so it seems i cannot move levels up or down. perhaps some other shortcut key could be useful like maybe A and Z to go up and down. or maybe there is but i don't know.
Title: Re: MAPVIEW upgrade
Post by: AncientSion on May 10, 2016, 03:57:01 pm
I downloaded the tool and i want to open the mod directory of Piratez mod. However, whatever i do i always only get the stock list

Can someone advise ?

https://prntscr.com/b2d4re
Title: Re: MAPVIEW upgrade
Post by: Hobbes on May 10, 2016, 04:14:51 pm
I downloaded the tool and i want to open the mod directory of Piratez mod. However, whatever i do i always only get the stock list

Can someone advise ?

https://prntscr.com/b2d4re

MapView doesn't automatically recognize all the maps in a mod directory, only the vanilla maps. You'll still need to add the new maps either through Paths or by manually editing the MapEdit.dat file on /settings
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on May 10, 2016, 04:32:48 pm
MapView doesn't automatically recognize all the maps in a mod directory, only the vanilla maps. You'll still need to add the new maps either through Paths or by manually editing the MapEdit.dat file on /settings

How do you do it through Paths? I always edit the MapEdit.dat. Is there another, hopefully better way?
Title: Re: MAPVIEW upgrade
Post by: AncientSion on May 10, 2016, 06:54:40 pm
Can you be a bit more specific on the actual how-to ?
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on May 10, 2016, 07:21:35 pm
Can you be a bit more specific on the actual how-to ?

Sure.

First, you need a new empty map. Unfortunately, MapView won't let you create an empty file, you have to go and copy some old .map file, then rename it to the new name.
For example take a Supply Ship map - it's called UFO_170.MAP. Rename the copied file to something else, like for example MYFIRSTUFO.MAP.

Then, make sure that your Images.dat contains all terrain you want to use (files in the TERRAIN folder). If it's X-Com 1, put it in the section starting with ${ufoImg}:${ufo}\TERRAIN\. If it's TFTD, put it in the section starting with ${tftdImg}:${tftd}\TERRAIN\.
Let's assume you are going to use tilesets: TERRAIN1, TERRAIN2 and TERRAIN3. (Each of them is contained in three different files of the same name: .mcd, .pck and .tab.) If they're not in the Images.dat, under the right section, add them:

Code: [Select]
TERRAIN1{ufoImg}
TERRAIN2{ufoImg}
TERRAIN3{ufoImg}

Then open MapEdit.dat. Let's say you want to make a new UFO (as opposed to a terrain). Find this line:

Code: [Select]
Tileset:UFO - Ships
type:1
rootpath:${varPath3}
rmpPath:${varPath4}
blankPath:${varPath5}
palette:ufo-battle

This starts the section for UFOs (and crafts too). Put your new entry here. It should look like this:

Code: [Select]
MYFIRSTUFO:TERRAIN1 TERRAIN2 TERRAIN3

Now start up MapEdit - your map is ready for work! Well of course it contains the Supply Ship, so you'll have to remove all the tiles.

These are the most basic basics I could think of. Try it, experiment a little, ask questions.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on May 11, 2016, 03:43:02 pm
Unfortunately, MapView won't let you create an empty file, you have to go and copy some old .map file, then rename it to the new name.

I have big news for you :D

To create empty maps:
* Navigate to Edit -> Paths -> Map Files
* Click on + to open the Group you want (UFO Ships, UFO Terrains)
* Select the Subgroup with left click, then right click and choose Add Map -> New Map (or you can select several already existing maps)
* Afterwards you be prompted for the map name and dimensions
* Finally, you'll need to assign some MCD files (Images) to start putting map elements on the map itself, so click on the map you created and assign some images to it

If you just imported a whole terrain with several maps it's easier to add all maps using the steps above except for the last and manually add the corresponding Image entries to Images.dat and MapEdit.dat (which can be found on /settings), as Solarius has described on his post
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on May 11, 2016, 07:18:29 pm
To create empty maps:
* Navigate to Edit -> Paths -> Map Files
* Click on + to open the Group you want (UFO Ships, UFO Terrains)
* Select the Subgroup with left click, then right click and choose Add Map -> New Map (or you can select several already existing maps)
* Afterwards you be prompted for the map name and dimensions
* Finally, you'll need to assign some MCD files (Images) to start putting map elements on the map itself, so click on the map you created and assign some images to it

What can I say? Neato! :)

If you just imported a whole terrain with several maps it's easier to add all maps using the steps above except for the last and manually add the corresponding Image entries to Images.dat and MapEdit.dat (which can be found on /settings), as Solarius has described on his post

Yes, that's how I do it too, but I wanted to show our beginner the simplest way.S/he will discover more later.
Title: Re: MAPVIEW upgrade
Post by: AncientSion on May 12, 2016, 08:13:27 pm
Thanks for the help, guys.
Title: Re: MAPVIEW upgrade
Post by: hellrazor on July 28, 2016, 08:45:51 am
I started working on bigger maps, sizes 40*40*8 and bigger.
What i notice is i am constantly couting tiles to find proper positions.

In this regard I suggest two badly needed improvements:
1.) Show the actual position of the mousecursor while either on top view, route view and grapghic view. Just seeing the current position in a format like : 2:5:6 - x:y:z would be a great help. Startcount zero.

2.) Grid with cootdinate numbers drawn. Or draw 10*10 blocks to make positions more visible.

Maybe i find time to add some pictures.
Title: Re: MAPVIEW upgrade
Post by: REDACTED_KUN on September 05, 2016, 05:22:37 pm
I think it's best that everyone can fix the bugs/glitches with Large Scout and other maps.

That's what my problem is with looking around with the Large Scout map.
https://openxcom.org/forum/index.php/topic,4842.0.html
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on January 11, 2017, 11:57:20 pm
I have a problem with a faulty node. It is outside the map boundaries:

"Bad node in RMP file: ROUTES/VES_170.RMP Node #0 is outside map boundaries at X:0 Y:13 Z:2. Culling Node."

This log output is correct; the map is 10x20, which puts 13 outside of it.

However, even if I enlarge the map to 20x20, it's still not showing up correctly:

(https://i.imgur.com/agBHFof.jpg)

To make things funnier, the offending node is on level 2 (third from the bottom), while the picture above is from level 1. Actual level 2 shows nothing suspicious:

(https://i.imgur.com/BNVCJ9s.jpg)

So I have no idea where that node is and I can't delete/fix it.

Please explain what I can do about it (other than deleting .RMP and starting from scratch). Can it be done through MapView? Maybe I can delete it with some hex editor or something?

Attaching the problematic map, with terrain. Tileset order is: U_EXT02, U_WALL02, U_OPER2, U_BITS.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on January 12, 2017, 03:18:58 pm
On the first image you posted there's a node that has a link to apparently nowhere. That 'nowhere' should be the bad node.

Add extra levels both below and above that level until you can see the bad node. At least that how's I usually fix those issues

Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on January 12, 2017, 04:07:04 pm
On the first image you posted there's a node that has a link to apparently nowhere. That 'nowhere' should be the bad node.

Add extra levels both below and above that level until you can see the bad node. At least that how's I usually fix those issues

That's exactly what I did, and I still couldn't see the node (even though I should).

But Dioxine helped me resolve this issue. Apparently all you have to do is: enlarge the map, save, reopen; the faulty node is now visible.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on January 12, 2017, 05:57:40 pm
But Dioxine helped me resolve this issue. Apparently all you have to do is: enlarge the map, save, reopen; the faulty node is now visible.

Yeah, that is needed as well. But in case you've added levels above 0 and still can't find the node, try adding levels below 0 - IIRC that's what was happening one time I had this issue.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on January 12, 2017, 06:52:06 pm
Yeah, that is needed as well. But in case you've added levels above 0 and still can't find the node, try adding levels below 0 - IIRC that's what was happening one time I had this issue.

Actually the problem wasn't related to the Z axis, but to the Y axis - the map was 10 tiles wide, and the problematic node was at Y position 13. But your advice may well be relevant to some other case.

And BTW, TheBigSot: are you considering further improvements to the program, or is it absolutely final?
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 06, 2017, 09:04:00 pm
Oh man, you all are still using MapView?

I feel kinda bad for abandoning it, but as Luke has postulated on the first post of this thread, LIFE has gotten in the way of everything.
Since then:
Got married
Bought a house
Had two kids

So apparently I'm living the american dream. The downside is that I cannot do anything for longer than 15 minutes without being interrupted. My development machine is still packed up in boxes - I barely use my laptop these days for anything but browsing the internet while we watch things from our Hulu queue.

It appears that kevL has taken over maintenance of the code? That's awesome, I am relieved to see that someone has tried to keep it going.
https://github.com/kevL/OpenXCOM.Tools

Glad to see the project (OpenXCOM) is still going alive and well. Ya'll have created something truly special here!
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 06, 2017, 09:14:39 pm
Oh man, you all are still using MapView?

Well, sometimes... I mean, a few hours a day... :P

It's not like we have an alternative! :)

I feel kinda bad for abandoning it, but as Luke has postulated on the first post of this thread, LIFE has gotten in the way of everything.
Since then:
Got married
Bought a house
Had two kids

Well... That escalated quickly. :)
Good for you!

It appears that kevL has taken over maintenance of the code? That's awesome, I am relieved to see that someone has tried to keep it going.
https://github.com/kevL/OpenXCOM.Tools

Hmmm, it appears kevL is actually still developing it. Are you aware of any way to contact this person, or download a newer version? I can't find much on Google.

And thanks! Without this program, modding X-Com would be pretty much impossible.
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 06, 2017, 09:55:15 pm
Well... That escalated quickly. :)
Good for you!

Hmmm, it appears kevL is actually still developing it. Are you aware of any way to contact this person, or download a newer version? I can't find much on Google.

And thanks! Without this program, modding X-Com would be pretty much impossible.

You're welcome!

Probably the easiest way to get kevL's attention is to open a new issue on the main project: https://github.com/pmprog/OpenXCOM.Tools/issues and reference @kevL in the message. he will get a notification that he's being mentioned in some other issue and he will (probably?) read it.

Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 06, 2017, 10:08:52 pm
OK, many thanks. I did as you suggested.

I guess in the worst case scenario we could simply get his latest code and compile it, but I'd rather not do it blindly. ;)
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 06, 2017, 11:40:16 pm
OK, many thanks. I did as you suggested.

I guess in the worst case scenario we could simply get his latest code and compile it, but I'd rather not do it blindly. ;)

What is the process for retrieving the 'current version' today?

Just read your notification message. You should change 'DaiShiva' to @ratzlaff, since thats who I am on github =)
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 06, 2017, 11:56:50 pm
What is the process for retrieving the 'current version' today?

You go and ask someone who uses GitHub. :P

Just read your notification message. You should change 'DaiShiva' to @ratzlaff, since thats who I am on github =)

OK, thanks!
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 07, 2017, 03:41:26 pm
Jeah github is the way to go today,
I really would to have some kind of grid in the Topview perspective.
Working with bigger maps and needing to count fields to set them correctly is a pain;D
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 07, 2017, 06:56:49 pm
Oh, so it's time for requests already? :)

Then I also have one: an UNDO button. :P
Title: Re: MAPVIEW upgrade
Post by: R1dO on February 07, 2017, 10:06:26 pm
Then I also have one: an UNDO button. :P

That goes entirely against the X-com spirit ... make expensive mistakes and learn to live with it   ;)
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 08, 2017, 04:01:22 pm
Oh, so it's time for requests already? :)

Then I also have one: an UNDO button. :P

Actually i think this is a good idea, mapediting is a pain without this.
Also it would be nice for resizing maps to pic the side on which the map will be extended.
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 08, 2017, 06:49:30 pm
I imported the history I had from the old sourceforge page to a new github repo.

https://github.com/ratzlaff/XCom-tools

Add your feature requests as issues. I have no idea what state the code is in yet. I only brought up the 'set your paths' dialog with Xamarin Studio (on my mac, no less) last night, so it compiles, yay!

Anyone want to be a collaborator?
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 08, 2017, 08:11:08 pm
Add your feature requests as issues.

It's a good idea, but first I'd like to wait on Sot's response and the current .exe. Because these features might just as well be in already. ;) And, well, if there is no response, there isn't much point in suggesting new features, unless somebody else picks up the torch.
Title: Re: MAPVIEW upgrade
Post by: Hobbes on February 10, 2017, 04:44:14 pm
Oh man, you all are still using MapView?

Hey DaiShiva, long time no see. Nice to hear life is going well for you :)

MapView has allowed me (and others) to create amazing things for XCom over all these years, specially for OpenXCom and nearly all of my modded terrains wouldn't be possible without it, so thank you again :)
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 10, 2017, 05:13:58 pm
Hey DaiShiva, long time no see. Nice to hear life is going well for you :)

MapView has allowed me (and others) to create amazing things for XCom over all these years, specially for OpenXCom and nearly all of my modded terrains wouldn't be possible without it, so thank you again :)

Long time indeed man! Hope things are going equally well for you also!
Title: Re: MAPVIEW upgrade
Post by: davide on February 11, 2017, 12:49:29 am
it is a privilege to have you here with us :)
Title: Re: MAPVIEW upgrade
Post by: JonnyH on February 13, 2017, 05:30:29 pm
I imported the history I had from the old sourceforge page to a new github repo.

https://github.com/ratzlaff/XCom-tools

Add your feature requests as issues. I have no idea what state the code is in yet. I only brought up the 'set your paths' dialog with Xamarin Studio (on my mac, no less) last night, so it compiles, yay!

Anyone want to be a collaborator?


Is that the "One True Upstream" now? I had some patches trying to get it to work properly under linux, and half a mind to see if it's worth trying to extend for Apocalypse (or at least shamelessly rip off code that happens to do the same thing if it turns out to be 'too' different to keep in the same codebase)
Title: Re: MAPVIEW upgrade
Post by: DaiShiva on February 13, 2017, 06:02:24 pm
Is that the "One True Upstream" now?

It could be. I would want to first get some collaborators on board to avoid repeating the current situation where the code goes years without any activity.
Title: Re: MAPVIEW upgrade
Post by: SteamXCOM on June 09, 2017, 11:47:27 pm
MAPVIEW, on a Windows 7 computer, it works fine

HOWEVER, on a Windows 8.1 it seemed to develop the issue of  once the main window is open, other windows cannot be worked with. 
Only one other window at a time can be open.  This seems to be on all versions of Mapview. 
Small Edits are  not a  problem, I could not imagine using it otherwise on bigger projects.

As indicated , works fine on a Windows 7 computer I have access to.
The feature of the MAGNIFIER is good. I can see easily the project being worked on.
I prefer to have CUT/COPY/PASTE in text in the Map Editor window as in some versions rather than icon becasue I have to hover my mouse over to doublecheck UI have the right thing seclcted.

If possible you may wish to make the link for latest version of MAPVIEW more prominent, i had to dig for this one. 
Thanks
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 16, 2017, 09:01:52 pm
Been using MapView in the past days and also noticed this problem. It most likely is related to the recent security patch released for Windows since MapView was running great on Windows 10 before.

I've checked kevL's github page but I couldn't find a release version. Anyone knows how to get one?
Title: Re: MAPVIEW upgrade
Post by: davide on June 16, 2017, 10:35:08 pm
do you try to run the app with admin privilegy ?(there is an options on context menu)
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 16, 2017, 11:00:00 pm
do you try to run the app with admin privilegy ?(there is an options on context menu)

Doesn't solve anything but thanks for the idea
Title: Re: MAPVIEW upgrade
Post by: Kammerer on June 17, 2017, 07:15:04 am
I've checked kevL's github page but I couldn't find a release version. Anyone knows how to get one?

The kevl's current build is here: https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution
Title: Re: MAPVIEW upgrade
Post by: Hobbes on June 17, 2017, 06:33:24 pm
The kevl's current build is here: https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution

Thanks, just tried it but the windows are still messed up on his latest version.

Plus it breaks compatibility since it doesn't load my old map sets...
Title: Re: MAPVIEW upgrade
Post by: SteamXCOM on June 18, 2017, 04:23:28 am
Latest MAPVIEW June 2017
JUST got this
THIS version is getting close for a release upon the unwashed masses:

--It got rid of the offending UFO000 UFO01a  UFO010 so people won't think their MAPview is broke.
--it lists settings errors in the MCD file such as if a non-existent swap frame was referenced
--a "save as" feature for the map file is included, one can rename their map (still testing to see how this works)

EDIT Yes it does, it places the renamed files in the routes and map folder both.

Yes, one still has to edit settings files to add tilesets, and that interface to add them has been removed probably since MAPVIEW could not find them anyway

Hobbes==> Plus it breaks compatibility since it doesn't load my old map sets...

I hope you find a work around for incompatibilities , you must have tonnes of maps by now

Hobbes==>Been using MapView in the past days and also noticed this problem. It most likely is related to the recent security patch released for Windows since MapView was running great on Windows 10 before.

if YOU MUST have an older version of Windows (even with with an ISA slot):
http://www.nixsys.com/

Bought a Win XP/7 unit for the old stuff
One can get cheaper elsewhere refurbished, but it IS refurbished.
Title: Re: MAPVIEW upgrade
Post by: RSSwizard on January 17, 2018, 09:16:29 pm
I just grabbed the Mapview 2 from here
https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution
and ive got a problem with running it... all that comes up is a blank command prompt window and then it closes, no other error messages really. The program also didnt write any initial configuration files either. I tried loading the mapview help file (.chm) and windows help just says it cannot load the help file.
> im running Win7 Home Premium 32 bit
Title: Re: MAPVIEW upgrade
Post by: kevL on January 23, 2018, 03:06:19 pm
hi.

I'm the guy who reworked MapView -> MapView II

i'm good with code but absolutely crappy with .NET versioning, how it interacts with various operating systems, etc. I'd like to see a distribution of MV2 working for general use but it's extremely unlikely I can fix a problem if i can't replicate it. (i can't replicate it)

Note: after reading the above 2 posts I cleaned everything and re-built and re-installed MV2 on my computer - win7 64-bit.

and as far as I can tell, it's working great even the .Chm help


So if someone who knows - or who can replicate the issues and wants to twiddle with .NET - wants to fork the repo and produce a well working distribution that'd be excellent,


caveat: apart from not understanding .NET and the .NET build procedures, I'm heavily involved in other stuff, but am willing to discuss things

/thanks
Title: Re: MAPVIEW upgrade
Post by: kevL on January 23, 2018, 05:03:33 pm
:) good luck

like i said, or implied, if someone can't get MV2 working on their machine I'm as lost as they are.


I do know, that the design of MapView and MapView2 does stuff that later versions Windows (eg. 10) considers security breaches. That is, it wants to write files to a subfolder of itself. Apparently "Program Files" does not like that.

so you'd be wise/smart to install MapView outside of the Program Files hierarchy ...
Title: Re: MAPVIEW upgrade
Post by: kevL on January 24, 2018, 02:03:52 am
k

/salut
Title: Re: MAPVIEW upgrade
Post by: RSSwizard on January 24, 2018, 07:48:32 pm
Maybe there's something I did wrong with installing MV2...
I placed it in its own subdirectory (mapview) under the openxcom directory. I play xpiratez with it but I have the appropriate vanilla files located under the required folders.

My MV2 doesnt have a configuration file, but I was expecting it to load and ask me "okay where are the files" so that I could dictate the proper locations for them and it could find what it needed. It didnt have a config file with it on github.

If ive got it in the wrong folder and its crashing because of that, then where am I supposed to put it? (openxcom root folder? ufo or tftd files root folder?)

Again the crash that I am getting with it is... upon execution a blank Dos Cmd window opens up and then it closes (thats all she wrote). I dont have any antivirus running so I know thats not getting in the way of it.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 24, 2018, 10:30:48 pm
I have no idea, i really don't.


If i were you, as a test I'd create a directory on the root of your C: drive, dl the 7 files from the github distribution dir (you don't need the ConfigConverter..) to that new dir on your C:

double-click MapView.exe


then a smallish window should pop up asking about installation.

--
I don't know what limitations win7 Home has or not, I don't know if it has .NET 3.5, I don't know what MS redistributables are required, I don't know when the dinosaurs went extinct.

The .Chm helpfile was manufactured with the standard Windows Chm creator (HTML Help Workshop), and if even *that* doesn't open ... that's just mind-boggling
Title: Re: MAPVIEW upgrade
Post by: RSSwizard on February 13, 2018, 09:01:29 pm
If i were you, as a test I'd create a directory on the root of your C: drive, dl the 7 files from the github distribution dir (you don't need the ConfigConverter..) to that new dir on your C:

Here you go sir. What is "NTVDM" by the way?
Title: Re: MAPVIEW upgrade
Post by: kevL on February 14, 2018, 03:37:38 am
NTVDM = Windows NT Virtual DOS Machine

(supposedly) it's for running 16-bit programs in a Dos-shell. But MapView I/II are not 16-bit programs ... I forced MVii to 32-bit build; i could be wrong because I'm just not sure about that stuff. In this case, however, it's highly unlikely - i suspect that it would be very difficult to even compile a program to 16-bit in today's age.

Also, when I run MV2, if it were 16-bit (which it isn't ;) ) ntvdm.exe should show up in my TaskManager. It doesn't. Neither does it show up when i run PckView2, which is built with the same settings. Also, in the Help screen for PckView i twiddled-in a brief system-inspection routine that prints the build-type (release or debug), the bit-type (for lack of a better way of putting it), and the OS-interaction-type (ditto). Mine says:

release
X86
WoW64

meaning it's a release-build, 32-bit, running under WoW64

It'd be kinda nice if you could get PckView2 to run, just to check that ... but NOTE: PckView2 should not be run until *after* MapView2 runs at least once (because settings that pckview relies on are written to disk only *after* MVII runs).


> im running Win7 Home Premium 32 bit

hm. There's something called a VirtualStore in windows. I don't know much about it; it seems to be a so-called virtual space on the harddrive that Windows will write things like MapView's configuration files to if MapView is installed to a protected space. It has its problems because files are being written to places they aren't expected to be.

I mention the VirtualStore since in your 2nd screenshot i think i see "@MSITStore:C\Mapview2\MapView.chm" .... "Store" suggests to me that Windows is trying to shuffle stuff into the VirtualStore ... eg, it could be trying to make a copy of the .CHM file to the store before opening it.


Have you checked for malware recently? (personally i doubt it 'cause there'd likely be a lot else going wrong on your computer if so)

my best **guess** at this point, is that Win7 Home has extra security that aggressively clamps things into protected spaces. I suggest hunting down things like UAC (User Access Control) and Ownership properties on the Mapview directory ....... personally i obliterated as much of that stuff as I could as soon as I got Win7 64. .. i tried, i really tried to live with it but just couldn't,




edit: Another way of looking at it, why is your computer trying to open a dos-box ? o.O

edit2: it's a long shot but you could try right-click mapview.exe, Properties, Compatibility, Windows XP (Service Pack 3)
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 08, 2018, 04:00:15 am
Hi KevL!

Just a quick question- my copy of MapView 2 (latest build, downloaded last night) can't/won't save .MAP files. It saves images of the map
 (.GIF) correctly, and doesn't display any error message, but the file just doesn't appear.

I'm running it with admin permissions on a Windows 8.1 machine.
Title: Re: MAPVIEW upgrade
Post by: kevL on April 08, 2018, 04:31:29 am
to create a .MAP file

use the MapTree (left panel of MainView). you'll need a Group (top level branch), a Category (a branch under the Group), and select the Category w/ a click. Then right-click it and choose Add Tileset ...

Make sure the Tileset's Path is correct (change it w/ the ... button). Type in the name of your new .MAP/.RMP in the Map input-box. Click "Create". Add some terrrainsets from the lower right panel and gtg.


To save a .MAP, have it open in MainView. use File|Save Map, or File|Save All (also saves the .RMP and the MapTree), or File|Save As ... (also saves the .RMP iirc)

It should get saved to its basepath as specified in Edit Tileset, the Path field (left-click the map in the MapTree, right-click it, choose Edit Tileset ... to see the path)

--
ps. be careful with permissions under Program Files etc etc. I'm not a multi-machine programmer and can't debug problems in operating systems other than Win7 64. So i don't know what "admin permissions" really does (and doesn't do) in 8.1 ... for that matter, i don't know what "admin permissions" does and doesn't do in win7 also.

i'm just a dos 6.22 guy. /jk


Edit: maybe i'll have to run a check after saving files, that tells if a file was successfully saved or not ...

that's in the future tho

Edit2: oh, if a map is created and saved to disk okay, but doesn't appear in the MapTree, it's likely because the MapTree wasn't explicitly saved. And if using File|Save As ... it won't appear in the MapTree unless/until it's added w/ Add Tileset ...


( it's been a while and, needless to say, the whole MapTree business is ... complicated. )
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 10, 2018, 06:36:30 am

Okay, here's an interesting one. MapView was running fine but my computer powered down unexpectedly (power cut) and afterwards MapView won't load- it 'encounters a problem' according to Windows with no useful error messages.

The tricky art is that I deleted and redownloaded MapView off GitHub and fired it up again- but the issue persists!

I'm guessing it's trying to look at something in my OpenXCOM install and not finding it/finding garbage but I have no insight as to what or how to fix it. Any advice you can offer would be appreciated!
Title: Re: MAPVIEW upgrade
Post by: ohartenstein23 on April 10, 2018, 06:43:30 am
MapView has some configuration/data files for remembering settings and paths to the map and terrain files, maybe one of those was messed up and is saved somwhere that wasn't removed on uninstall?
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 10, 2018, 07:31:39 am
That's my suspicion, but I don't know where... I killed everything I could find. Hence asking the astonishingly helpful author :)
Title: Re: MAPVIEW upgrade
Post by: kevL on April 10, 2018, 09:19:43 am
if that's me idk ...

unexpected shutdowns can cause weird things to the hardrive. (I once had to reformat an entire drive because chkdisk/scandisk refused to reset the "dirty bit". so ... sounds like you can wipe the sweat off yer brow on that one.)

without sitting at your computer there's not much i know - you could try installing to different directory, try running a deep-scan on the hardrive (takes all night), uhh

Mapview1 writes to the registry, so if that's an issue try a registry cleaner like CCleaner. Mapview2 does not write to the registry and all its files ought be under its parent dir.

unless it's using a so-called virtual store ... which you could search around for .. on my machine it's under C:\Users\User\AppData\Local\VirtualStore and perhaps delete a MapView folder (or rename it like, "Mapview_") I've done that with a few other old programs that wanted to use the virtual store and it doesn't seem to cause problems but you should google it first, i guess.

It partly depends on what the computer was doing when the power was cut.

I really can't think why an app that ran before would refuse to run again. I'd try installing to a different directory. and google is our friend, try "power cut application won't run" ( + permutations )
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 10, 2018, 09:23:52 am
Thanks for weighing in. I'll check the virtual store possibility later tonight.

Failing that, I'm getting a new machine in a couple of weeks so I guess I'll start over on a clean system :P
Title: Re: MAPVIEW upgrade
Post by: kevL on April 10, 2018, 09:36:16 am
that's a bingo  ;D
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 14, 2018, 08:54:53 am

Okay, I've got it starting again, which is progress. But none of the 'right click' functions (such as viewing/editing tilesets or starting a new map) are working, nor am I able to change level in the main window unless I close the tile view and top view.

I'm only mentioning this on the off chance that these particular errors shed some light on the problem?
Title: Re: MAPVIEW upgrade
Post by: kevL on April 14, 2018, 09:02:26 pm
not to me unfortunately :|

Quote
But none of the 'right click' functions (such as viewing/editing tilesets or starting a new map) are working, nor am I able to change level in the main window unless I close the tile view and top view.

That sounds like a problem that was/is happening on circa post-Win7 machines. MainView would refuse to take focus if any of the other viewers were open. So i put in an option under MainView->Edit->Options->AllowBringToFront

it should default to FALSE - which is a 'safe' setting. Ie, a user would have to change it to TRUE to allow the bring-to-front behavior, when MainView is clicked to take focus (but TRUE is the setting that could also enable the bug.)

So, and this might be a longshot, since MainView (specifically the view-panel) needs focus for the mousewheel to scroll through levels ... and probably for a right-click on the MapTree to work also ... have a look at MainView->Edit->Options and check the "AllowBringToFront" setting. suggested: FALSE
Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 20, 2018, 01:45:29 am

For some reason it's not showing 'AllowBringToFront' as an option on the screen you suggested...
Title: Re: MAPVIEW upgrade
Post by: kevL on April 20, 2018, 01:29:09 pm
from here?

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

I just downloaded those files and ran MapView.exe in a clean dir, and after the installation dialog this appears under MainView|Edit|Options

Title: Re: MAPVIEW upgrade
Post by: Keth01 on April 20, 2018, 03:10:44 pm

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!
Title: Re: MAPVIEW upgrade
Post by: kevL on April 20, 2018, 09:25:58 pm
coolio,

May your maps be robust (so to say)
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 02:13:54 am
looking ...

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


edit: as a (hopefully temporary) workaround, try turning off the InfoOverlay
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 02:34:46 am
see my suggested workaround (edit) in previous post

I looked at the wonky function and nothing obvious smakked me in the face yet :\
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 02:43:43 am
Wait? I think i found out the issue. :o Nevermind!

huh? status report pls?
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 06:39:43 am
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 (https://openxcom.org/downloads-extras/), 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?
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 08:41:39 am
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.
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 10:02:47 am
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.

8) 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)
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 03:57:00 pm
(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
Title: Re: MAPVIEW upgrade
Post by: kevL on August 29, 2018, 07:49:20 pm
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.
Title: Re: MAPVIEW upgrade
Post by: kevL on August 30, 2018, 02:30:08 am
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
Title: Re: MAPVIEW upgrade
Post by: kevL on August 30, 2018, 07:42:59 am
you bet. take yer time, hex-editing is straightforward.

thanks to Ufopaedia (https://www.ufopaedia.org/index.php/ROUTES) and others
Title: Re: MAPVIEW upgrade
Post by: kevL on August 30, 2018, 02:37:26 pm
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. :D
(https://openxcom.org/forum/index.php?action=dlattach;topic=1321.0;attach=39147;image)

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)
Title: Re: MAPVIEW upgrade
Post by: kevL on August 31, 2018, 04:03:10 pm
... worked well (Damn, HxD fired me up while hex-editing). ^_^

hex-editing = untold power

sounds like you got it to work.

Quote
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. :D

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

Quote
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 ....


Quote
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... )
Title: Re: MAPVIEW upgrade
Post by: kevL on September 04, 2018, 07:50:14 am
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
Title: Re: MAPVIEW upgrade
Post by: kevL on September 05, 2018, 08:16:53 pm
new toolbar look

+ fixing holes, lots of holes glitches oversights etc

TopView and TopRouteView(Top) are playing nicer together ...

search feels pretty sturdy, next is out of bounds nodes getting RouteView and TopRouteView(Route) to play nicer together i guess.
Title: Re: MAPVIEW upgrade
Post by: kevL on September 08, 2018, 09:13:54 pm
preview
https://drive.google.com/file/d/1oz2aj1BnOvlsynPDWI2vtwY2MJ2eOpd9/view


edit: wow, glitches galore when a guy pokes his nose around for a bit,

guess I'll have to start versioning :\

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

suggest: backup your current exe's and dll's since ver 2.2 has beta-like stuff in it. ( /settings folder has not changed )



I'll be fine eventually. -o-
http://files.libertyfund.org/pll/quotes/207.html
Title: Re: MAPVIEW upgrade
Post by: hellrazor on September 22, 2018, 10:59:40 am
Thanks for your effort so far. I am gonna try out your new version.

Even thou I am still missing some way to run this natively under Linux...

Fixing that paths are read the normal with "/" would help a lot...

EDIT: The configconverter seems to be working correctly. What also would be nice is if you would allow convert of Images.dat file, which handles custom MCD File entries.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 22, 2018, 04:56:55 pm

Even thou I am still missing some way to run this natively under Linux...


It does run under wine, although quite slowly.

Instructions:


re TFTD - it does spew some fishy warnings about route nodes being outside the map for some of them
Title: Re: MAPVIEW upgrade
Post by: hellrazor on September 22, 2018, 05:05:58 pm
It does run under wine, although quite slowly.

Instructions:

  • Add wine repository as per https://wiki.winehq.org/Ubuntu (https://wiki.winehq.org/Ubuntu)
  • install wine-stable: apt update ; apt install winehq-stable winetricks
  • initialize 32bit prefix: WINEARCH=win32 winecfg
  • Install dotnet35sp1: winetricks dotnet35sp1

re TFTD - it does spew some fishy warnings about route nodes being outside the map for some of them

I know you can run it under wine, but that really is not performant in any way.

The main issue with running it under linux, ewith a mono compiled set is a Alpha transparency issue.
See here: https://openxcom.org/forum/index.php/topic,1321.msg46066.html#msg46066

Not a problem of MapView in itself thou.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 22, 2018, 05:30:30 pm
Well yes, it's unacceptably slow under wine.

Compiling with Mono fails -

Code: [Select]
CSC: error CS2001: Source file `XConsole.cs' could not be found



@kevL maybe you know what's this about?

EDIT: aha, it's XConsole.cs in .csproj, but xConsole.cs on disk.
Title: Re: MAPVIEW upgrade
Post by: hellrazor on September 22, 2018, 05:33:34 pm
You know what would be really cool, if you could just import your OpenXcom TERRAIN definition via YAML into MapView.

Then just paths to MAP, RMP and MCD files would need addition, adjustment (for custom stuff).
Title: Re: MAPVIEW upgrade
Post by: kevL on September 22, 2018, 05:54:47 pm
EDIT: aha, it's XConsole.cs in .csproj, but xConsole.cs on disk.

Ben was in mad genius mode when he originally coded Mapview ... (and MV is a work of genius) ... the "mad" part, however, means that the original code is a spaghetti monster.

i'll be frank : I spent over 1000 hr sorting things into something more maintainable. There's lots left to do, in that respect.

thanks for pointing that one out - I could see it being a problem especially under linux/Mac

But i don't have linux or Mac or TFTD. /shrug

You know what would be really cool, if you could just import your OpenXcom TERRAIN definition via YAML into MapView.

Then just paths to MAP, RMP and MCD files would need addition, adjustment (for custom stuff).

y, it would be ... unfortunately my headspace is elsewhere atm. It'd take me many many hours to get back in there and do it correctly ..,


Ps. both you guys strike me as experienced Xcomers, so just poke away at it if you want and i'll wait for something concrete (from my perspective) to pop up

pps. XConsole is a thing that's been disabled in Mv2. It's one of those things that I left the code in though (many other things were outright deleted) - it's basically a debugging tool, but if you're debugging you probably have an IDE so it's unnecessary.

ppps. I think i fixed it : https://github.com/kevL/OpenXCOM.Tools/tree/master/XCom
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 22, 2018, 06:19:54 pm
I'll just document this here so that it isn't completely forgotten:

Title: Re: MAPVIEW upgrade
Post by: kevL on September 22, 2018, 06:30:00 pm
I'll just document this here so that it isn't completely forgotten:

  • This xconsole thing is the only thing that fails the build under mono/linux.
  • The second thing is cursor.pck not being found because of backslash - just change it to forward slash in XCom/SharedSpaceServices/SharedSpace.cs:17
  • the build also spews errors for not being able to copy exes somewhere, this can be safely ignored
  • the transparency bug is in Mono and is apparently being worked upon - see https://github.com/mono/mono/issues/8514 (https://github.com/mono/mono/issues/8514)

1. should be fixed in latest commit [but I changed the filename on disk instead of in the project file... to keep things consistent with the other XC*.* files]
2. not sure how that plays out on Win systems ... probly ok but investigation req'd
3. look at the post-build events for the MapView assembly; delete them. I'm simply copying the .exe's and .dll's to a working directory (release and debug builds - but am going to delete the debug post-build copying since I'm doing things differently here/now). Anyway, look through the build events, blablah
4. okay
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 22, 2018, 06:40:34 pm
1. should be fixed in latest commit [but I changed the filename on disk instead of in the project file... to keep things consistent with the other XC*.* files]
Thank you.

Quote
2. not sure how that plays out on Win systems ... probly ok but investigation req'd
Should be ok, but I'm no windows person

Quote
3. look at the post-build events for the MapView assembly; delete them. I'm simply copying the .exe's and .dll's to a working directory (release and debug builds - but am going to delete the debug post-build copying since I'm doing things differently here/now). Anyway, look through the build events, blablah

Yeah, please remove that, it kinda messes up the future automated builds.



EDIT:

the build is here  https://lxnt.wtf/oxem/#/MapView (https://lxnt.wtf/oxem/#/MapView)
the patches applied:
https://github.com/StoddardOXC/OpenXCOM.Tools/commit/141ae7fff8f73e797c4da1565ba966eac107aff6 (https://github.com/StoddardOXC/OpenXCOM.Tools/commit/141ae7fff8f73e797c4da1565ba966eac107aff6)
https://github.com/StoddardOXC/OpenXCOM.Tools/commit/287b9bbae6ab401ba416e31605c202efdb5f3725 (https://github.com/StoddardOXC/OpenXCOM.Tools/commit/287b9bbae6ab401ba416e31605c202efdb5f3725)

now we only have to wait for the mono people to sort out the transparency, and MapView would finally be usable on linux.
Title: Re: MAPVIEW upgrade
Post by: kevL on September 22, 2018, 08:25:09 pm
re Path separator

https://github.com/kevL/OpenXCOM.Tools/commit/46dbaa754e30fbfa67dac796262e3cc3bcc3773b
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 22, 2018, 09:16:51 pm
re Path separator

https://github.com/kevL/OpenXCOM.Tools/commit/46dbaa754e30fbfa67dac796262e3cc3bcc3773b

It works.

Thank you.

Title: Re: MAPVIEW upgrade
Post by: kevL on September 22, 2018, 09:28:22 pm
sweet

just have to wait for the mono guys to get up to speed, looks like they're hot on the trail too



@Stoddard
beware : https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L1036

etc.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on September 23, 2018, 11:57:37 am

beware : https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L1036

etc.

Yeah, like I said I'd first wait for the mono bug resolution.
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 02, 2018, 09:34:57 am
Hi guys!

I make 2x2 and 3x3 large facilities. But the problem is in game can not work the walls (when builded next to the othe building, the wall can not disappear), so tis need doors, but it not looks good. So its needed to cut 1x1 pieces, but its uncomfortable..  how to cut easier?

Thank you!
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on October 02, 2018, 09:51:23 am
Base facilities can only be 1x1.
We must live with it.
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 02, 2018, 09:52:36 am
Base facilities can only be 1x1.
We must live with it.

I know, but 3x3 building easy create first..but how can cut easier to pieces?
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on October 02, 2018, 10:02:22 am
I know, but 3x3 building easy create first..but how can cut easier to pieces?

What do you mean by "how"?

Make 9 copies and modify each to remove the unwanted parts... Or do you mean something else?
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 02, 2018, 10:05:45 am
What do you mean by "how"?

Make 9 copies and modify each to remove the unwanted parts... Or do you mean something else?

Its terrible.. i think have some option i can automaticly cut 9 pieces.. now can only copy and paste many times, because can not copy 2 levels just 1. and counting the 10 from left and upper corner..
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on October 02, 2018, 11:28:07 am
Eh, it's 5 minutes of copy-paste.
If routes are involved, then it's much worse, as you have to do it anew for every map block.
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 02, 2018, 11:50:10 am
Eh, it's 5 minutes of copy-paste.
If routes are involved, then it's much worse, as you have to do it anew for every map block.

Yepp, routes to, so its not 5 mins :(

Who made the Mapview2?
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on October 02, 2018, 12:41:01 pm
KevL made the new MapView.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 02, 2018, 10:38:26 pm
the code is opensource

/go nutz, it'd take a lot longer than 5 min to implement ...

( for me at least )
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 03, 2018, 09:29:01 am
the code is opensource

/go nutz, it'd take a lot longer than 5 min to implement ...

( for me at least )

Yeah, i know :) But if u have time and no other bug or idea.. ;)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 03, 2018, 01:29:31 pm
+1
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 05, 2018, 06:33:44 pm
+1

Dear kevL!

Another request (if you like and have time). Can make 2D pictures from the top? I think its very helpfull for base shape!

Thank you!
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on October 05, 2018, 07:06:32 pm
Dear kevL!

Another request (if you like and have time). Can make 2D pictures from the top? I think its very helpfull for base shape!

Thank you!

You mean, minimap rendering?
Yeah, could be useful.
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 05, 2018, 07:52:05 pm
You mean, minimap rendering?
Yeah, could be useful.

I need for the facilities base shape (its very hard to draw for me). but yes, its good for minimap too.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2018, 10:50:57 pm
Quote
minimap rendering

i like the idea... plate's full for forseable future tho...
Title: Re: MAPVIEW upgrade
Post by: kevL on October 19, 2018, 02:18:39 am
@luke83 [op]

Hello,

Any of you excellent Coders want to try your luck at making a few Upgrades to MAPVIEW? I downloaded the source out of curiosity but have no clue where to start :P

I PM Daishiva but since i have not heard from him in over a year i guess LIFE has gotten in the way of the last upgrade i asked for :-[

My Suggestions for Upgrading Mapview:
1) Fix existing Bugs EG: the PATHS can only be modified by Notepad as doing it by the program wipes everything.

paths, a monster - I rewrote it from scratch. Ie, PathsEditor is gone, replaced by right-click on the maptree. The dataset is stored in a Yaml file and this is the reason that Mapview2 has the "2" (ie, is NOT backward compatible.)

Quote
2) Specify Default Node type was added last time By Daishiva at my request , we need a extra Option to tell it to AUTOLINK to previous Node in both directions ( this will save alot of time)

auto-link seems to work fine in 2 ...

Quote
3) Extra Visual clues as to what Unit type a NODE will be spawning ( Just some letters added to the Green box to represent a Class would be helpful)

not done. There are still the 2 small, side-by-side ImportanceMeters tho, (showing spawn priority and patrol priority iirc)

Quote
4)Move Node Option, There is nothing worse than realising you have fully setup a NODE 1 block to the right of the desired location, a tick box to Drag and drop node at a new location and Keep all current LINK nodes would be awesome

yeh really. Done: drag&drop routenodes.

Quote
5) Numbered Grids ( around the images) i hate goign cross eyed tryign to work out if i am in the right Row or not , a simply Number system down the side on ALL screens could be useful.

good idea -- is not done like that in 2, but i went to some length to ensure that x/y/z coords print accurately on relevant viewers.

Quote
6) AUTO-Link : Not sure HOW you will handle this but this would save alot of headaches if i only needed to clean up a few LINKS instead of manually modding every one of them.

there's auto-link, and checks to ensure that node coordinates are within bounds of the (currently displayed) Map ...

Quote
7) RMP Statistics = Would be great if there was a option somewhere to do a count of all Spawn Ranks per level and a overview of spawn Ranks across the entire map set, just Pop open a new window to display this when requested.

that's actually a fair idea ... not done tho.

Quote
8) Some kind of import Wizard for the PAths , Mapedit page as i have Lots of differnt , half finished maps to import and its very time cinsuming to do them one by one. It would be good if it was clever , and noticed if i selected a Map without a ROute file, that it could ask if i want to make a empty file for it. ALso if you can improve the way the Map tree is controlled ( and allow Drag and Drop to change the sequence) that would be great.

no Wizards, sry (although an empty Routes file ought be written on SaveAs ... if there aren't any route nodes) And, to change the order of the maptree, I guess you'd have to change the order of the Yaml-nodes in your favorite text editor ( read: is not native )*

Quote
This is a Fantastic program it just needs some work to make it easier for people like me to make LOTS of new map types, Any part time coders for OXC want to take a look ?

uh, there's a Search function?


96.78325% of the credit goes to Ben/Daishiva (and others)

caveat. Atm am up to my eyeballs in other projects. but some month, day, year will be back to hacking my way through OxC again,



*edit oh wait, I think the maptree is sorted alphanumeric -- so.
Title: Re: MAPVIEW upgrade
Post by: luke83 on October 19, 2018, 12:31:00 pm
New version works well, great job. I did notice one thing today though, Crt+Z is not UNDO as i was hoping, it was the shortcut to change map dimensions, not sure if there was an undo button on the control bar somewhere that i may of missed.
Title: Re: MAPVIEW upgrade
Post by: Biggieboy on October 19, 2018, 12:33:05 pm
New version works well, great job. I did notice one thing today though, Crt+Z is not UNDO as i was hoping, it was the shortcut to change map dimensions, not sure if there was an undo button on the control bar somewhere that i may of missed.

Yepp, i realy like too Undo!
Title: Re: MAPVIEW upgrade
Post by: kevL on October 19, 2018, 02:22:36 pm
https://stackoverflow.com/questions/3973557/how-to-implement-undo-redo-operation-without-major-changes-in-program#answer-3973598
Title: [REQUEST] load maps/tileset from mod folder
Post by: davide on October 24, 2018, 08:59:32 am
It requires looking for the definitions of ufo / craft / terrain in rule files
It is difficult, I known :-\
Title: Re: MAPVIEW upgrade
Post by: davide on October 27, 2018, 09:50:28 pm
I cannot load maps from mod folder.

Before i tried from UI by context menu.
After a tried to update MapTilesets.yml by notepad++

The issue is that basepath attribute was not used

Code: [Select]
#----- XenoOperations ----------------------------------------------------------#
#----- craft ------------------------------------------------------------------#
  - type: XOPSNEWSKYWARDEN
    terrains:
      - XOPSTRANSPORT2
      - XOPSTRANSPORT3
    category: craft
    group: ufoXenoOperations
    basepath: C:\Users\davide\Documents\OpenXcom\mods\XenoOperations
  - type: XOPSHURRICANE
    terrains:
      - XOPSTRANSPORT2
    category: craft
    group: ufoXenoOperations
    basepath: C:\Users\davide\Documents\OpenXcom\mods\XenoOperations
  - type: XOPSARCANGEL
    terrains:
      - XOPSTRANSPORT3
    category: craft
    group: ufoXenoOperations
    basepath: C:\Users\davide\Documents\OpenXcom\mods\XenoOperations

but I got the error.

To force the map load I have to change MapResources.yml:

Code: [Select]
ufo: C:\Users\davide\Documents\OpenXcom\mods\XenoOperations


Title: Re: MAPVIEW upgrade
Post by: luke83 on October 27, 2018, 11:33:36 pm
Anyone else having issues with autolink not working all the time?  Not sure if its because this map is very different in sizing (its one of the unused maps from the original game) or if its just a random bug....you can see in the screen shot, only SOME autolinked, others did not.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 27, 2018, 11:47:16 pm
@davide

in MapTilesets.yml
Code: [Select]
#----- ufo_test ---------------------------------------------------------------#
#----- area51 -----------------------------------------------------------------#
  - type: AREA51BASE00_T # .MAP and .RMP files renamed w/ "_T" to not conflict with already existing "AREA51BASE00" type (from my regular UFO folders - ie, "_T" is for test)
    terrains:
      - AREA51W # these terrains are in the TERRAIN folder under the Configurator's basepath
      - AREA51X
      - AREA51Y
      - AREA51Z
    category: area51
    group: ufo_test
    basepath: C:\0xC_kL\editors\t # and this is where the new .MAP and .RMP files reside

I think i see what you're saying though; it would be nice to be able to configure a different sprites directory ... that is, different than the one expected in the Configurator basepath

--- please do not double-post unless it can't be helped ---


Anyone else having issues with autolink not working all the time?  Not sure if its because this map is very different in sizing (its one of the unused maps from the original game) or if its just a random bug....you can see in the screen shot, only SOME autolinked, others did not.

it's possibly a bug. I'd need a testcase w/ MAP RMP MCD PCK TAB files. And directions to replicate ...

The only reason auto-link should fail is if the link slots (on one or the other or both nodes) are already full, and if so it ought show a message to that effect
Title: Re: MAPVIEW upgrade
Post by: davide on October 28, 2018, 12:08:54 am
...
I think i see what you're saying though; it would be nice to be able to configure a different sprites directory ... that is, different than the one expected in the Configurator basepath

moreover, if the sprites are not in the module-name/TERRAIN folder, it should be useful to look them up automatically in the ufo / tftd TERRAIN folder by group prefix.

Often the mods define maps that use both the standard pck and their own

 ::)

Title: Re: MAPVIEW upgrade
Post by: kevL on October 28, 2018, 12:19:07 am
ah ..........
Title: Re: MAPVIEW upgrade
Post by: luke83 on October 28, 2018, 12:22:15 am
it's possibly a bug. I'd need a testcase w/ MAP RMP MCD PCK TAB files. And directions to replicate ...

The only reason auto-link should fail is if the link slots (on one or the other or both nodes) are already full, and if so it ought show a message to that effect


I have attached the Zip file for this, MAP-5 is the resized version that i will be playing with, it is made from map3 & 4. Was just going to get it to a point where i could see if i can bring it into OXC to see what issues arise (not sure if anyone else has every tried to bring these old maps into the game yet).
Title: Re: MAPVIEW upgrade
Post by: kevL on October 28, 2018, 01:03:26 am
strange, the nodes already present connected np. So i made a dozen new nodes all over Map5, different levels, across the entire map, OneWay, TwoWay, post-create connect, new-node connect, even tried to make it duplicate already existing connections ...

no glitches.


idk,
make sure there's an origin node selected before doing link or createnode+link
and remember that each time opening Mv2, the dropdown defaults to DontConnect ...

But if you can set me up with a consistent, reliable bug (or at least something with a decent probability) I'll check it out again,


----
note to self, implement

a) user-chosen MapTilesets.yml (so user has less chance of overwriting a config : please note that each time MapTilesets is saved a backup is made w/ extension .old -- you have *one* and only *one chance* to recover an accidental overwrite of MapTilesets.yml (!)

b) user-chosen Configurator basepath(s) for sprites ...
Title: Re: MAPVIEW upgrade
Post by: luke83 on October 28, 2018, 02:19:45 am
right, it looks like its caused because i was placing nodes, but every now and then i needed to click on the graphical window ( to make sure i had it on the correct location or to move the view windows around). So i did a quick test, it works as long as i dont click out of the Node window.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 28, 2018, 02:23:50 am
k, good luck w/ the Maps - they're friggin.. friggin friggin Pyramids of Doom.
Title: Re: MAPVIEW upgrade
Post by: luke83 on October 28, 2018, 02:25:04 am
----
note to self, implement

a) user-chosen MapTilesets.yml (so user has less chance of overwriting a config : please note that each time MapTilesets is saved a backup is made w/ extension .old -- you have *one* and only *one chance* to recover an accidental overwrite of MapTilesets.yml (!)

b) user-chosen Configurator basepath(s) for sprites ...

If your looking for suggestions, a copy and paste options for the Node window could be useful, currently i cheat by deleting, duplicating and renaming route files on similar map blocks and then tweak to get exactly right.... Would be nice if i could copy a group of nodes from one map, paste them into another, have them rename the node points to suit the new map and still maintain the links.

--- people, what's with all these double posts??? ---

k, good luck w/ the Maps - they're friggin.. friggin friggin Pyramids of Doom.

They may not be  to everyone tastes, but i like the idea of resurrecting the original game files as much as i can :)  It like these other unused maps, right now i just want to bring them in as a separate mission for instant battle just because its (based upon) original data.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 28, 2018, 02:37:08 am
... a copy and paste options for the Node window could be useful, currently i cheat by deleting, duplicating and renaming route files on similar map blocks and then tweak to get exactly right.... Would be nice if i could copy a group of nodes from one map, paste them into another, have them rename the node points to suit the new map and still maintain the links.

k, noted
Title: Re: MAPVIEW upgrade
Post by: davide on October 28, 2018, 05:50:07 pm
@davide

in MapTilesets.yml
Code: [Select]
#----- ufo_test ---------------------------------------------------------------#
#----- area51 -----------------------------------------------------------------#
  - type: AREA51BASE00_T # .MAP and .RMP files renamed w/ "_T" to not conflict with already existing "AREA51BASE00" type (from my regular UFO folders - ie, "_T" is for test)
    terrains:
      - AREA51W # these terrains are in the TERRAIN folder under the Configurator's basepath
      - AREA51X
      - AREA51Y
      - AREA51Z
    category: area51
    group: ufo_test
    basepath: C:\0xC_kL\editors\t # and this is where the new .MAP and .RMP files reside

I think i see what you're saying though; it would be nice to be able to configure a different sprites directory ... that is, different than the one expected in the Configurator basepath

basepath could be used to customize source tileset too by few line of code:

..\OpenXCOM.Tools-master\XCom\FileDesc\Descriptor.cs

Code: [Select]
        public string ResolveTilePath(string terrain)
        {
            string pathTerrain = _dirTerrain;
            string pathMod = Path.Combine(this.BasePath, Descriptor.PathTerrain);
            if (string.Compare(_dirTerrain, pathMod) != 0)
            {
                string pfSpriteset = Path.Combine(pathMod, terrain) + SpriteCollection.PckExt;

                if (File.Exists(pfSpriteset))
                    pathTerrain = pathMod;
            }
            return pathTerrain;
        }

public McdRecordCollection GetTerrainRecords(string terrain)
{
            string pathTerrain = ResolveTilePath(terrain);           

    var tiles = XCTileFactory.CreateTileparts ( terrain,
                                                                         pathTerrain,
GetTerrainSpriteset(terrain, pathTerrain));
    return new McdRecordCollection(tiles);
}

        public SpriteCollection GetTerrainSpriteset(string terrain, string pathTerrain = null)
{
            if (pathTerrain == null)
                pathTerrain = ResolveTilePath(terrain);
             
            return ResourceInfo.LoadSpriteset(terrain, pathTerrain, 2, Pal);
}
Title: Re: MAPVIEW upgrade
Post by: davide on October 28, 2018, 06:43:41 pm
The are issues to open pck/mcd but today I end my free time, sigh.

KevL  could you review my suggestion ?
 
thanks
Title: Re: MAPVIEW upgrade
Post by: kevL on October 29, 2018, 02:46:02 am
bleh. i doubt it would be that simple ...

i mean it might be. I started tracing your suggestion but soon realized it would take a lot of re-learning and investigation, just to check if what you're suggesting is robust.


( personally, if i were in a rush, I'd create a working directory and copy whatever resources to it - as a non-coding solution - setup Mapview to use those files. And after changes were done, copy any modified files back to where they should be )

--
what you need to keep in mind, is that once terrains get their own paths, that path has to follow its terrain around througout the code ...

----
note to self re. PckView
manage MCD records when sprites are manipulated.
Title: Re: MAPVIEW upgrade
Post by: luke83 on November 10, 2018, 02:07:51 am
Hey,
 Can you confirm, it looks like you have re-built PCKView as well when you rebuilt mapview???

The old PCKVIEW allowed you to export the entire tileset as one image, this made it super quick to change colours across an entire tileset at one go with GIMP, looks like the new version does not allow this.... So i  went ahead and export an image our of the old one, made my changes and turned it back into a PCK & TAB files. Every looks good except the NEW MCDEDIT and NEW PCKBIEW doesn't appear to open these files any longer.

Anyone else been having any issues like this?

I found a workaround for my current issue but i had to save everything out item by item and then re-imported tile by tile, so much extra work.

SO my workaround failed, how is everyone else importing extra animations into a tileset?

Update 2 - Finally found a workaround - New MCDEDIT allows PNG imports not BMP like the old ones did...Still i have not seen anyway to import a entire set in or out yet.
Title: Re: MAPVIEW upgrade
Post by: kevL on November 10, 2018, 04:42:22 am
yes I reworked PckView also. Not as extensively as Mapview -- am not a graphics person, i just want(ed) an app that allows sprite touchups.

that said, it's still a spriteset editor but it doesn't recognize spritesheets. If/when i get back into it, I'd also like to do away with .BMP format and go with .PNG


do what you have to for now, i guess
Title: Re: MAPVIEW upgrade
Post by: luke83 on November 10, 2018, 05:27:20 am
If/when i get back into it, I'd also like to do away with .BMP format and go with .PNG

Dont mind what format you go with, but having the option to export a full tileset into 1 image and then bring it back in ( and have it divided up correctly automatically) was extremely useful.
Title: Re: MAPVIEW upgrade
Post by: kevL on November 10, 2018, 11:08:44 am
i see ... will prioritize it after I get this (https://raw.githubusercontent.com/kevL/yata/table/images/screenshots/yata2.png) to beta (it's very close)


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

PckView upgrade
- File menu gets import/export spritesheet.

notes:
minimal testing, worked w/ Avenger.Pck
totally untested for TftD
warning, importing a spritesheet replaces the current spriteset
.BMP format

and for those who want to browse the pieces:
https://github.com/kevL/OpenXCOM.Tools/commit/77c024438e01f5c53e2d6b98365c80f9c8f7936d
Title: Re: MAPVIEW upgrade
Post by: luke83 on November 14, 2018, 11:31:53 am
The new Mapview, does it only check for the MCDs in the original UFO directory? Or does it also go looking for the User/Mod Archive?
Title: Re: MAPVIEW upgrade
Post by: kevL on November 14, 2018, 11:39:11 am
it looks only the directory set by the Configurator. (usually the UFO installation dir)
Title: Re: MAPVIEW upgrade
Post by: davide on November 14, 2018, 01:35:40 pm
Mine beta version try to solve this issue
Title: Re: MAPVIEW upgrade
Post by: kevL on November 14, 2018, 07:52:39 pm
+1


Note that it's possible to open a spriteset in PckView from Mapview (dbl-click a tilepart in TileViewer). so,

TileView.OnPckEditorClick() expects to find a tilepart's terrainset in the SharedSpace ...

not sure if there's anything else to be wary of,
Title: Re: MAPVIEW upgrade
Post by: davide on November 14, 2018, 08:02:59 pm
Yes i have to complete the update, do You check my previous source code update that i attache in previous post? Tile descrittori contains mod Path and could Be used to find tileset, First in mod Path and After in UFO path
Title: Re: MAPVIEW upgrade
Post by: kevL on November 14, 2018, 08:29:18 pm
do You check my previous source code update that i attache in previous post?

no sry. My time/interests are currently invested in getting another program finished (plus there's other stuff waiting on that getting done). And i suspect the ModArchive feature will require a fair bit of concentration for the twiddly bits ...

and, uh, my build of OxC doesn't use the Mod design -- so this isn't a feature for me personally, i'd barely even know what I'm looking at, and would have to go out of my way to test it in practical situations.

(at present the workaround is to set up a "scratch" directory, copy all terrains to "scratch/TERRAINS", and point the configuration to "scratch" -- it also needs a cursor, "scratch/UFOGRAPH/CURSOR.*")


It just occurred to me that, to code ModArchives into Mapview, there ought be an option in Mapview for user to specify what ModArchive needs to be loaded into Mapview; else there could be terrains with the same name that conflict in different mods .....
Title: Re: MAPVIEW upgrade
Post by: davide on November 17, 2018, 10:08:13 am
.. else there could be terrains with the same name that conflict in different mods .....

I use the entry md basepath to search tileset first, only when not found, search into ufo/tftd folder

    basepath: C:\Users\Davide\Documents\OpenXcom\mods\Pyramid_rebirth


In this way you could not copy anything from original folder

Code: [Select]
#----- Pyramid_rebirth ----------------------------------------------------------#
#----- ufo ------------------------------------------------------------------#
  - type: PSCOUT
    terrains:
      - U_EXT01
      - U_WALL01
      - U_DISEC1
      - U_OPER1
      - PUFOL83
    category: ufo
    group: ufoPyramid_rebirth
    basepath: C:\Users\Davide\Documents\OpenXcom\mods\Pyramid_rebirth
Title: Re: MAPVIEW upgrade
Post by: kevL on November 17, 2018, 04:03:27 pm
but i'm wondering what happens if, say, PyramidRebirth has a .map "PSCOUT" and Piratez has a .map "PSCOUT" but they're different. And further they might both access terrain(s) "UFO_BITS" but again they're different ...

at that point i'd be sorely tempted to implement user-chosen MapTree configurations

eg. Filemenu->Open Maptree ...
Title: Re: MAPVIEW upgrade
Post by: davide on November 17, 2018, 04:13:52 pm
Mods have differenti basepath , therefore each load their Maps/Terrain
Title: Re: MAPVIEW upgrade
Post by: kevL on November 17, 2018, 06:12:48 pm
okay. It should work, right?
Title: Re: MAPVIEW upgrade
Post by: davide on November 17, 2018, 07:59:02 pm
https://openxcom.org/forum/index.php/topic,1321.msg105714.html#msg105714 (https://openxcom.org/forum/index.php/topic,1321.msg105714.html#msg105714)

There are the two sorce updated

It is olready missing the same update to open pckview on tileset, a probably other UI actions, I update  MapTilesets.yml with notepad++.

An other usefull function could be an action to add to MapTilesets.yml terrains/crafts/ufos maps found into a rule file selected by a file explorer. It has to be set basepath
Title: Re: MAPVIEW upgrade
Post by: luke83 on November 24, 2018, 10:38:21 am
Anyone else getting an error when opening the original urban map set with mapview (the newset build is what i am using)? My son wants to start learning how to mod but it keeps crashing with vanilla maps. Once he goes to bed i will get the exact error.

Error shown below, anyone else getting this?


Update: is fixed, i must of picked up a corrupted file from somewhere , once i copied over a fresh install its started working.


Title: Re: MAPVIEW upgrade
Post by: kevL on November 24, 2018, 08:39:24 pm
browsing the code, i'd say it was a bad Pck file (but i wouldn't want to try to re-code things to handle it gracefully w/out said bad Pck file )
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 07, 2018, 02:35:20 pm
Hey mate,
 Just making sure there i am not going blind, there is no way to export a Sprite Sheet as PNG out of the current version is there?

Thanks
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on December 07, 2018, 02:49:38 pm
Hey mate,
 Just making sure there i am not going blind, there is no way to export a Sprite Sheet as PNG out of the current version is there?

Thanks

It's definitely possible in the MCDEdit.
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 07, 2018, 10:16:43 pm
It's definitely possible in the MCDEdit.

but i cant do unit animation sprites in MCD edit right? I am now using MCDEDIT for almost everything :)

Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on December 07, 2018, 10:18:33 pm
but i cant do unit animation sprites in MCD edit right? I am now using MCDEDIT for almost everything :)

Ah... no, but Aseprite is perfect for this ;)
Title: Re: MAPVIEW upgrade
Post by: kevL on December 07, 2018, 11:58:47 pm
Hey mate,
 Just making sure there i am not going blind, there is no way to export a Sprite Sheet as PNG out of the current version is there?

Thanks

hey luke, nope. Ben/Daishiva* wrote a routine to output to .BMP and so i simply re-implemented it ... but since i'm a huge fan of PNG this should happen uh, eventually.

*pretty sure it was Ben ...


EDIT: update PckView
output a spritesheet whose dimensions (should be) compatible w/ OxC ... although .BMP

is not thoroughly tested but seems straightforward enough,
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 18, 2018, 10:46:28 am
Hello,
 New spritesheet work ( see image)

However trying to export any TFTD sprites now gives a error ( note older version had same issue), see other image. Note on this occasion i tried exporting a Deepone which generated the below error.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 18, 2018, 01:49:11 pm
... i tried exporting a Deepone ...

rather, do you mean you tried *loading* a Deepone PCK file? And PckView borked on it w/ "Cannot access a closed file"? I was expecting something more like "Index was outside the bounds of the array" tbh.

I don't have TFTD or any of its resources ... I managed to generate the latter error just by tinkering around tho ...

if you can upload and PM me a link to, eg. Deepone.Pck+Tab (or any battlefield, 32x40 spriteset from TFTD, that you have reasonable confidence is valid/correct/working properly) I'll look into it and should (hopefully) be able to straighten up a few things.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on December 18, 2018, 02:08:47 pm
I know it's not the right thread, but since this keeps coming up: attached are various alien sprites from both games, some in several variants. This should be enough.

Warning: some TFTD sprites are in X-Com palette.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 18, 2018, 02:19:23 pm
attached are various alien sprites from both games, some in several variants. This should be enough.

thanks Solarius. Those will help, but i also really need Tab-offsets from the original Pck spritesets ...


although it's probly enough for Luke, i'd guess
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on December 18, 2018, 05:49:45 pm
To be honest I can't guess at any relationship between MapView and unit sprites. :P
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 18, 2018, 06:25:39 pm
thanks Solarius. Those will help, but i also really need Tab-offsets from the original Pck spritesets ...


KEVL- i have uploaded a file to my website for you to test.

Solarius - i am downloading your resources now to have a look  :P. - Update - i still need a few other sprite objects but thanks for this, the recoloured aliens in here will come in handy for my project  :D
Title: Re: MAPVIEW upgrade
Post by: kevL on December 18, 2018, 07:23:59 pm
To be honest I can't guess at any relationship between MapView and unit sprites. :P
many people may not know this, but PckView.exe ships with MapView and it's a PCK spriteset editor. I'm not sure if it works for unitsprites, but if they're 32x40 true pck images like battlefield terrain i don't see why not


KEVL- i have uploaded a file to my website for you to test.

Link pls?
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 18, 2018, 08:43:19 pm
http://openxcommods.weebly.com/lukes-data.html
Title: Re: MAPVIEW upgrade
Post by: kevL on December 19, 2018, 02:26:14 am
great, thanks

ps. "Cannot access a closed file" has been replicated.


EDIT: the current distribution (should) load and export TFTD spriteset/spritesheet -- tested on DEEPONE.PCK/TAB

I noticed something odd, however. It seems that outputting .BMPs (at least the sheets, maybe not individual sprites, not sure) sets the background index to #255. I'd think that ought be #0. This apparently happens for both UFO and TFTD palettes. You can/should correct it in your favorite sprite editor, by flood-filling the background color to index #0 (so that OxC recognizes it, and treats it as transparent)

if/when i implement PNG output, will look more closely.
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 19, 2018, 09:43:51 am
The version you sent me via PM the yesterday doesnt work, can you confirm you have a Newer version and if so  do you have a link to download it, i will test it tonight.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 19, 2018, 02:26:40 pm
https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 20, 2018, 07:04:50 am
Hello,
 I can report, all units work except for Bigobs (see error below).
Title: Re: MAPVIEW upgrade
Post by: kevL on December 20, 2018, 07:42:42 am
okay. Aside: it's a relief the build worked 'cause i'm lousy with 'predicting' builds for other peeps (i'd rather that, ala Linux, they could build from source on their own machines, really)

anyway, Bigobs aren't allowed atm. iirc, they're 32x48 ... but it should go on my TODO, yep.

Tell me something here. Okay, think back to the old days: BombBloke's toolkit was the goto for exporting sprites. Not exactly as user-friendly as PckView, eh. But that's what i still use when I want to break sprites out of a PCK ... it handles bigobs, unit-sprites, everything. So is this what you're looking at PckView for?

If you're finding it useful for that task [ie, the exported sprites can then be converted into an OxC-compatible spritesheet, for use by an OxC ruleset as extraSprites] -- i haven't tried using PckView for that purpose -- I can (and would) gradually prioritize that aspect of the app

i mean, are you looking at PckView as a convenient replacement for (the exporting aspect of) BB's toolkit?
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 20, 2018, 08:37:15 am
Hey,
 Even back in the day, BobmBlokes Toolkit was very hard for me to get working ( mostly due to my limited intelligence :), i have always used PCKview for all my units and terrain ( note i have never tried working on TFTD units until now but i did the Armed Civilians and others with this tool) since returning to OXC 2 months back, i now do most of my quick colour changes with MCDEDIT for terrain items but still need PCKVIEW for sprites. PCKVIEW is perfect for when you want to find and replace an entire sprite set at once, i never used it on a image by image basis, only sprite sheets. Tonight i just colour changed another 2 units from TFTD using your tool and gimp :) 


Note: in a perfect world i would say please duplicate MCDEDITS colour change tools into PCK as than it would be AWESOME, when i did my Underground recolour with MCDEDIT it took me about  a hour to recolour everything, i only did it this way as i couldnt remember how to use gimp at the time ( i have since renewed my skills in Gimp and now i know IRFANVIEW can quickly fix my colour pallet issues its all green light for modding again  ;D).
Title: Re: MAPVIEW upgrade
Post by: kevL on December 20, 2018, 08:55:43 am
*whoosh sounds like you're smarter than i am /whatever :)

srsly, it'll take me a while to ingest what you just said there.

i can't give an ETA on handling Bigobs -- am currently trying to implement Undo/Redo in a non-trivial program (not MapView...) and until i can nail it it bites.



etc
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 23, 2018, 02:22:10 pm
Hey,
 Can you translate this error, i have a map set i started 1 month back and just returned to work on it and i cant load the MCD/PCK data as it crashes out. If you need the Files Kevl, let me know and i will compile them for you.

Thanks
Title: Re: MAPVIEW upgrade
Post by: kevL on December 23, 2018, 04:49:41 pm
It's trying to draw the TileView window but not finding MCD data (*guesstimate*)

TileView wants MCD data for
- the background color of each part displayed in the table
- the part's y-offset (ie, elevation)
- and for printing "door" under the sprite, if it's a door

things to try:
- open a good map and close TileView, then try the bad map (without the TileView window open) just to see if any other error pops
- ensure that the filename(s) of the .MCD(s) are the same as that of the .PCK/TAB file(s) ... for all terrains used by the .Map
- also have a look in your settings/MapTilesets.yml file, search for the .MAP filename, and check that its terrains are listed correctly


If it still borks, pls package and link me to the .Map/.Rmp + .Mcd/.Tab/.Pck terrains
& i'll try to load it here,



EDIT: package received

It looks like the ORGANIC3L83 terrain is muffed in some way. I removed it from the terrainset of ORGANIC_CITY01.MAP, then closed and reopened MapView, and TileView starts okay.

notes from looking at the PCKs in PckView ...
ORGANIC1 looks ok
ORGANIC2 has 12 empty images at the end of its set (be wary of stuff like that, it's not invalid but it can be misleading)
ORGANIC3 is WTF. It has 40 weird images, but MCDEdit shows only 4 records
ORGANIC4 has 16 empty images at the end of its set


definitely fix ORGANIC3 (or remove it) and re-think terrains,
Title: Re: MAPVIEW upgrade
Post by: luke83 on December 24, 2018, 02:20:35 pm
It's trying to draw the TileView window but not finding MCD data (*guesstimate*)

TileView wants MCD data for
- the background color of each part displayed in the table
- the part's y-offset (ie, elevation)
- and for printing "door" under the sprite, if it's a door

things to try:
- open a good map and close TileView, then try the bad map (without the TileView window open) just to see if any other error pops
- ensure that the filename(s) of the .MCD(s) are the same as that of the .PCK/TAB file(s) ... for all terrains used by the .Map
- also have a look in your settings/MapTilesets.yml file, search for the .MAP filename, and check that its terrains are listed correctly


If it still borks, pls package and link me to the .Map/.Rmp + .Mcd/.Tab/.Pck terrains
& i'll try to load it here,



EDIT: package received

It looks like the ORGANIC3L83 terrain is muffed in some way. I removed it from the terrainset of ORGANIC_CITY01.MAP, then closed and reopened MapView, and TileView starts okay.

notes from looking at the PCKs in PckView ...
ORGANIC1 looks ok
ORGANIC2 has 12 empty images at the end of its set (be wary of stuff like that, it's not invalid but it can be misleading)
ORGANIC3 is WTF. It has 40 weird images, but MCDEdit shows only 4 records
ORGANIC4 has 16 empty images at the end of its set
definitely fix ORGANIC3 (or remove it) and re-think terrains,

Thanks mate, yeps looks like i saved over Organic3 at some point, all fixed now. The Empty spaces in the others are because i am still building the MCD sets, they will be full soon enough :)
Title: Is this the place to discuss Linux build of MapView?
Post by: tkzv on December 26, 2018, 12:23:56 am
I compiled MapView under Ubuntu 16.04 with only 1 warning after changing the target framework to "Mono/.Net 4.5". So far, there are 2 problems:

1. I can't make windows large — the upper limit is 632x481 pixels (630x433 without title, menu and borders). The version from https://github.com/ratzlaff/XCom-tools doesn't have such problem.

TileView, TopView, RouteView and TileRouteView windows have no resizing problems. They even have better decorations. Options and Configurator windows use the same decorations as the main window, but can be enlarged.

2. The tiles are not transparent. See the attached "mapview-linux.png". Ratzlaff's version has the same problem.

Any suggestions how to fix that?


Ah, finally found this post: https://openxcom.org/forum/index.php/topic,1321.msg103891.html#msg103891

But MapView doesn't work in Wine-staging 4.0-rc2 either.

UFO1A.MAP doesn't appear in the new version. What's wrong?
Title: Re: MAPVIEW upgrade
Post by: kevL on December 26, 2018, 04:45:34 am
I compiled MapView under Ubuntu 16.04 with only 1 warning after changing the target framework to "Mono/.Net 4.5". So far, there are 2 problems:

1. I can't make windows large — the upper limit is 632x481 pixels (630x433 without title, menu and borders). The version from https://github.com/ratzlaff/XCom-tools doesn't have such problem.

I can't say for sure, but it could be the effect of this workaround:

https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L173
vs
https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.Designer.cs#L451

at some pt I found that the designer of SharpDevelop IDE was increasing the size of some Forms incrementally, so I set a MaxSize for such form(s) in the designer, which stopped the repetitive increase, then in the constructor of the Form(s) the limitation gets removed.

that could be what's hampering things in Ubuntu/4.5 somehow


Quote
TileView, TopView, RouteView and TileRouteView windows have no resizing problems. They even have better decorations. Options and Configurator windows use the same decorations as the main window, but can be enlarged.

2. The tiles are not transparent. See the attached "mapview-linux.png". Ratzlaff's version has the same problem.

Any suggestions how to fix that?


Ah, finally found this post: https://openxcom.org/forum/index.php/topic,1321.msg103891.html#msg103891

But MapView doesn't work in Wine-staging 4.0-rc2 either.

UFO1A.MAP doesn't appear in the new version. What's wrong?

i removed any unused Maps (ie, unused in original XCOM) from the default MapTilesets configuration. If you want UFO1A (or any of the others) in, add it in /shrug

am glad you got it to build, am sad that Mono hasn't been updated yet. (Perhaps there's a 3rd party PNG decoder that can plug-in to Mono, idk)
Title: Re: MAPVIEW upgrade
Post by: tkzv on December 26, 2018, 08:45:01 am
I can't say for sure, but it could be the effect of this workaround:

https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L173
vs
https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.Designer.cs#L451

at some pt I found that the designer of SharpDevelop IDE was increasing the size of some Forms incrementally, so I set a MaxSize for such form(s) in the designer, which stopped the repetitive increase, then in the constructor of the Form(s) the limitation gets removed.
Looks like it. The funny thing is: after a few launches the window started behaving correctly.

i removed any unused Maps (ie, unused in original XCOM) from the default MapTilesets configuration. If you want UFO1A (or any of the others) in, add it in /shrug
UFO1A is the small scout: https://www.ufopaedia.org/index.php/MAPS#UFO1A.MAP_.28Small_Scout.29

am glad you got it to build, am sad that Mono hasn't been updated yet. (Perhaps there's a 3rd party PNG decoder that can plug-in to Mono, idk)
There's got to be some way. I'll ask around.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 26, 2018, 04:22:31 pm
UFO1A is the small scout: https://www.ufopaedia.org/index.php/MAPS#UFO1A.MAP_.28Small_Scout.29

oh right, i should have left that one in ... i get the small scout confused with the spherical scout ...
Title: Re: MAPVIEW upgrade
Post by: tkzv on December 27, 2018, 12:07:54 am
Long story short, there's no readily available fresh GTK3# package. For now I replaced the calls to Graphics.DrawImage with manually checking and drawing every pixel. Looks OK for wall sprites, but not OK for floor and content. And the speed is low. But it works. Maybe a faster processor can help :)

Anybody is welcome to try. The source is here: https://github.com/tkzv/OpenXCOM.Tools
The relevant commits are:
https://github.com/tkzv/OpenXCOM.Tools/commit/28fb294da7e723e0f860d1dd3f56b19a98e62c85
https://github.com/tkzv/OpenXCOM.Tools/commit/de7a5d975a8fa104551a383b5cc992ac5eae0765
Title: Re: MAPVIEW upgrade
Post by: kevL on December 27, 2018, 12:27:31 am
cool. very cool :)

... what's wrong with floor & content sprites? (*curious)
Title: Re: MAPVIEW upgrade
Post by: tkzv on December 27, 2018, 01:17:13 am
cool. very cool :)

... what's wrong with floor & content sprites? (*curious)
They are drawn only partially.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 27, 2018, 07:31:22 am
it sorta looks like the drawing sequence is clearing pixels of previously drawn sprites ... *

note, tilepart-type visibility can be toggled for each type in TopView->Visibility (might be useful somehow)


It seems that true transparency is ultimately req'd.



* perhaps if your algorithm checks the color of the current pixel, as well as the color of the pixel-to-be drawn, and if the first is non-0 and the second is 0, pass the old color to the new pixel (?)
Title: Re: MAPVIEW upgrade
Post by: tkzv on December 27, 2018, 08:54:42 am
it sorta looks like the drawing sequence is clearing pixels of previously drawn sprites ... *
It does look that way, but the algorithm simply skips black (supposedly transparent) pixels. It doesn't draw anything in their place.

* perhaps if your algorithm checks the color of the current pixel, as well as the color of the pixel-to-be drawn, and if the first is non-0 and the second is 0, pass the old color to the new pixel (?)

I don't know how to draw a single pixel. This is why I draw them as rectangles ::)

note, tilepart-type visibility can be toggled for each type in TopView->Visibility (might be useful somehow)
What is it used for?

Speaking of which, what does _spriteShadeEnabled do? Now I just copy everything pixel by pixel regardless of _spriteShadeEnabled value.

It seems that true transparency is ultimately req'd.
Of course. It's faster :)
Title: Re: MAPVIEW upgrade
Post by: kevL on December 27, 2018, 09:49:06 am
It does look that way, but the algorithm simply skips black (supposedly transparent) pixels. It doesn't draw anything in their place.

y, that's ... odd ....

Quote
I don't know how to draw a single pixel. This is why I draw them as rectangles ::)

i think it's just a 1-pixel rectangle /lul, at least that's how i do it
hm,
System.Drawing.Bitmap.GetPixel()
System.Drawing.Bitmap.SetPixel()

but it'd be complicated 'cause you'd have to get the pixel out of the client-area ... i'd think ... and compare it with the pixel in the sprite ... or something like that ... ie, lots of deltas and what not


Quote
What is it used for?

TopView->Visibility [F1,F2,F3,F4 when TopView has focus] - these toggle on/off the drawing of tileparts (the blob-representations in TopView itself, and any sprites of that parttype in the MainView window). So if you want to see the floorparts that are directly behind, therefore hidden by a wall, the wall-parts can be toggled off to show the flooring ... etc. It's purely for visual convenience and doesn't affect saves at all.

But i'm thinking that by toggling parts on and off, you could get a better idea of what's actually going on with those floor and content sprites.


Quote
Speaking of which, what does _spriteShadeEnabled do? Now I just copy everything pixel by pixel regardless of _spriteShadeEnabled value.

spriteshade gets enabled when user sets spriteshade between 10..100 in Mainview Options. It's a gamma-adjustment for sprites (i run my monitor dark and need sprites a bit brighter).  Otherwise, spriteshade is disabled since SetGamma() is a sort-of-expensive call

I don't think it's important here, esp. if you haven't turned sprite-shading on in Options.

note: MainViewOverlay handles sprite-shading ... it's kinda confusing because SpriteShade is stored as an int (because options doesn't like floats, last i checked) which is then converted to a float-value SpriteShadeLocal, and that is used for the gamma
Title: Re: MAPVIEW upgrade
Post by: RSSwizard on December 28, 2018, 12:20:36 am
I ended up getting a new computer so the previous issue might've gone away.
Are there any compiled (current) versions of MapView2?
Im not a coder so I cant compile anything.
Title: Re: MAPVIEW upgrade
Post by: kevL on December 28, 2018, 03:36:41 am
Here's a recent build for Windows (.net 3.5 required)
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


ps. I strongly suggest not installing to Program Files.
Title: Re: MAPVIEW upgrade
Post by: RSSwizard on December 29, 2018, 10:33:22 pm
Thanks matey. It works like a charm.
(program files? geez I almost never do that, I toss everything on D: drive)
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 03, 2019, 01:49:18 pm
So was building some maps and when i returned they are all garbled ( see image below), now i am assuming this is because i have too many tilesets used on this mapset, my question for the experts is:
 Is this a limitation that OXC has overcome and its only just Mapview that is not updated OR does OXC have this same restriction ( and just has not been updated)?  In the old days i remember there was a limit but i thought OXC overcome all these pesky issues.
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on January 03, 2019, 02:25:59 pm
Hi Luke,
The limits on OXC maps are the same as in the original game, because it's the same file format.
Therefore, you are limited to 256 tiles per terrain (doesn't matter if it's in one or multiple tilesets).
There are however several tricks you can use:
1) Destroyed tiles are not saved in a map, so you can go over 256, as long as the excess tiles are limited to destroyed tiles. So try putting destroyed tiles at the end of your last tileset.
2) UFOs and crafts use different tilesets. If your particular map does not include them, you can make a terrain block with different tilesets and spawn it as a UFO/craft.
3) If you're using OXCE (like pretty much any serious modder these days), you can combine terrains by defining another terrain in the mapscript. (This is the most robust option, unless you are only a few tiles over the limit, in which case it's better to just use option 1.)
If I think of anything else, I will also mention it, but for now that is all.
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 03, 2019, 07:02:50 pm
Thanks Mate, I am about 50 over the limit which should be fine, i was being Lazy anyway and i just importing Several Custom Tilesets from other maps instead of only what i needed so  i will just bite the bullet and make another Custome Tileset for this map also ;).
Title: Re: MAPVIEW upgrade
Post by: kevL on January 03, 2019, 07:10:02 pm
1) Destroyed tiles are not saved in a map, so you can go over 256, as long as the excess tiles are limited to destroyed tiles. So try putting destroyed tiles at the end of your last tileset.

not sure you mean this, but i'll try to clarify something ...

pretty sure that destroyed parts have to be kept within the Terrain that references them (eg, i don't believe it's valid to have a terrain that consists purely of destroyed parts at the end of a terrainset -- ie. MCD references need to be within their own MCD file)

I mean it doesn't *strictly* make sense to reference part#250 (or #275 ...) in an MCD that contains only 50 records.

(caveat: it may work, but that doesn't mean it strictly makes sense: because it would mean you could have a Map with a terrain that references a part that doesn't exist in the overall set)


note2: in TileView if you select a part, the titlebar ought display its MCD-ID (aka part#) -- first its position in the total terrainset ( MapID ), then its position in its own terrain ( TerrainID ).

@luke you probly know that, it's just a general note
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 03, 2019, 07:31:24 pm
note2: in TileView if you select a part, the titlebar ought display its MCD-ID (aka part#) -- first its position in the total terrainset ( MapID ), then its position in its own terrain ( TerrainID ).

@luke you probly know that, it's just a general note

Yep, i noticed it AFTER my maps were corrupted ( good news is its only 3 maps that i did before i noticed  ;))

A suggestion for a future update to help new modders (or old modders like me that forget the rules), add a message box on load that lets the modder know they have gone over the limit with set XYZ. Not desperately needed, but i know how easy messageboxes are to add in code so just thought i would mention it.


On another topic, do we have a guesstimate on when TFTD Bigobbs support will occur for PCKVIEW, i still have a few items i have not been able to steal from other Modders or Export myself. 
Title: Re: MAPVIEW upgrade
Post by: kevL on January 03, 2019, 08:07:58 pm
Yep, i noticed it AFTER my maps were corrupted ( good news is its only 3 maps that i did before i noticed  ;))

A suggestion for a future update to help new modders (or old modders like me that forget the rules), add a message box on load that lets the modder know they have gone over the limit with set XYZ. Not desperately needed, but i know how easy messageboxes are to add in code so just thought i would mention it.

+3½


Quote
On another topic, do we have a guesstimate on when TFTD Bigobbs support will occur for PCKVIEW, i still have a few items i have not been able to steal from other Modders or Export myself.

well i just finished with this : https://github.com/kevL/yata/blob/master/UndoRedo.cs
so i should be able to make some time in the next few days and see how it goes ...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on January 03, 2019, 08:19:01 pm
not sure you mean this, but i'll try to clarify something ...

pretty sure that destroyed parts have to be kept within the Terrain that references them (eg, i don't believe it's valid to have a terrain that consists purely of destroyed parts at the end of a terrainset -- ie. MCD references need to be within their own MCD file)

Yes of course, destroyed tiles must be in the same tileset as good tiles. I just didn't mention it since I thought it was kinda obvious.
In practice, the tileset with the most destroyed tiles should ideally be last.

+3½

Agreed :)
Title: Re: MAPVIEW upgrade
Post by: kevL on January 05, 2019, 10:42:20 pm
PckView - bigob support
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

minimal testing -- I got it to load TFTD/UFO Bigob.Pck and output a spritesheet. Again the background color seems to get set to #255 ... so floodfill to #0 req'd after output.

On the File menu there ought be 2 Open commands: 1st for rego PCKs, 2nd for Bigob PCKs. I noticed, in my meanderings, there are 2 Bigobs (at least there is for UFO, not sure about TFTD) -- there's Bigob.PCK/TAB in the UNITS directory and Bigob.PCKs (individual sprites, no TABs) in the UFOGRAPH directory. i didn't test the latter but feel free to try ... i have no idea if they're different



EDIT:
MapView2 upgrade 2019 jan 7

    add UFO1A (small scout) to the default MapTilesets.YML ... note to those who want access to the small scout but don't want to bork their current MapTilesets config: generate a MapTilesets.TPL via the Configurator and copy type:UFO1A to their working MapTilesets.YML

    issue a warning if the quantity of allocated Terrain MCD-records exceeds 256. The warning, if applicable, is shown when the Map loads by selecting it in the MapTree or when a Map's descriptor is modified causing the Map to reload (eg. terrains have been added or removed)


EDIT2:
upgraded upgrade (see 2nd screenshot)



EDIT3:
debug from 8bbp PNG source:
Width= 32
Height= 40
PixelFormat= Format32bppArgb

debug from 8bbp BMP source:
Width= 32
Height= 40
PixelFormat= Format8bppIndexed

AAAAARGHT why does .net/gdi+ do this to me

Edit3b:
found this workaround and it seems to work
https://stackoverflow.com/questions/44835726/c-sharp-loading-an-indexed-color-image-file-correctly#answer-45100442
Quote
I had this problem too, and it seems that any paletted png image that contains transparency can't be loaded as being paletted by the .Net framework, despite the fact the .Net functions can perfectly write such a file. In contrast, it has no problems with this if the file is in gif format, or if the paletted png has no transparency.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 12, 2019, 09:32:00 pm
@note: Currently working w/Stoddard on a Linux build that overcomes the Mono/transparency issue

initial results are promising ...

is based on the original footwork by tkzv.
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 14, 2019, 05:58:24 am
@note: Currently working w/Stoddard on a Linux build that overcomes the Mono/transparency issue

initial results are promising ...

is based on the original footwork by tkzv.

I am seriously looking forward to a version which can work without the transparency issue.
Fiddling around with this win 7 VM is a maze...
Title: Re: MAPVIEW upgrade
Post by: kevL on January 14, 2019, 08:17:49 am
i believe the transparency issue is completely solved. (at least bypassed, by simply not painting sprite-pixels that're palette-id #0)

at the moment i've punted the ball to Stoddard, who is (if i understand...) trying to get either a decent multi-platform build against Mono, or a decent Windows build that runs as well as possible on Linux with the Mono libraries.


there's still stuff to puzzle through, however. like, is there going to be a different build for Windows vs [other], what .NET version is best, etc .. should the sourcecode be maintained in two different branches/repos .....

other issues are popping up, needless to say, but atm it's up to Stoddard to say whether any show-stoppers happen,


--
in other news, am sitting on a version of PckView that supports PNG in/out and also supports pck-spritesets for UFO/TFTD terrain, units, and bigobs. I want to wait till the Net vs Mono thing gets sorted out a bit better,
Title: Re: MAPVIEW upgrade
Post by: Stoddard on January 16, 2019, 10:22:53 am
Yep, transparency done.

Binaries:
windows-built - https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190115.7z (https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190115.7z)
linux-built - https://lxnt.wtf/oxem/builds//MapView/MapView-612a2ce-2019-01-16-mono.7z (https://lxnt.wtf/oxem/builds//MapView/MapView-612a2ce-2019-01-16-mono.7z)

source the linux-built build is built from - https://github.com/StoddardOXC/OpenXCOM.Tools/tree/net45 (https://github.com/StoddardOXC/OpenXCOM.Tools/tree/net45)


I am seriously looking forward to a version which can work without the transparency issue.
Fiddling around with this win 7 VM is a maze...

Please try out the above.




EDIT:

Here's the latest build and as far as I can see it's fully usable on Linux/Mono (and should be on Mac/OSX/whateverthereisforMono)

https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190118.7z (https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190118.7z)

This needs testing. Please help.




EDIT:

Running it on Mono:

1. Get the latest from https://lxnt.wtf/oxem/#/MapView (https://lxnt.wtf/oxem/#/MapView)
2. Run it.
3. Tell it where the vanilla data is.
4. Close and relaunch it
5. Go to Edit->Options and set UseMono to True
(bottomost on this:

(http://imgur.com/NHBn7i9l.png)
Title: Re: MAPVIEW upgrade
Post by: kevL on January 19, 2019, 11:22:12 pm
source:
https://github.com/kevL/OpenXCOM.Tools

2019 jan 19 - build on Windows:
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

note: .NET 4.5.1 req'd ( older versions are available for net 3.5 )


And like Stoddard says, needs testing on Mono.



EDIT - in other news, am presently working on the ability for each terrain to hold a custom path ...
it's gonna take a while thar be dragons


EDIT2 - on case-sensitive filesystems (ie, Linux, Mac) there are some casing issues where files/directories might not be found. I'll fix these as I find them or they're reported ...

- also, i introduced a bug when cancelling the TilesetEditor : you might have to Ok a created Tileset (that you want to cancel instead), then delete it from the MapTree (if you really want it deleted). Should be fixed in next release, but until then I advise saving everything (Map,Routes,Maptree) before opening the TilesetEditor,
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 25, 2019, 11:05:48 pm
Hey,
 Been working on a lot of maps lately so i have some feedback for you on Mapview.

So your program lets you add new levels of terrain to either Above existing block levels or below, this is great, but it looks like the Routes are  not updated correctly when this happens as i have several map blocks where my Routes are on Levels 3 and 4 but  i have nothing on levels 1 & 2. I will try to recreate this for you tonight and see if i can find out exactly how this happens.

For pre-existing route notes, your software allows you to easily drag around to new positions (which is great), any chance of a button to move it down or up a level?

On the Topview tab, on the outside of the grid, could you add little colour line indicating where  the 10th block end in both X and Y  axis, hell you could even link this up to a filed so custom values can be set,  i am currently doing some larger map blocks and square counting is very common place especially since i am trying to copy and paste data from one mapset to another and place everything in correct locations.

To help on the same above large map blocks, it would be useful if when i am highlighting a group of parts, there was some user feedback somewhere that tells me i have 6 blocks in X and 5 blocks in Y currently selected, once again to avoid me counting square by square.

I still have months of mapbuilding in front of me so i thought i would bring this up now just in case you like any of my feedback and decide to add it :)


Also a little off topic, I see OpenApoc is coming along nicely, Could Mapview2 handle its maps?
Title: Re: MAPVIEW upgrade
Post by: kevL on January 26, 2019, 12:02:40 am
So your program lets you add new levels of terrain to either Above existing block levels or below, this is great, but it looks like the Routes are  not updated correctly when this happens as i have several map blocks where my Routes are on Levels 3 and 4 but  i have nothing on levels 1 & 2. I will try to recreate this for you tonight and see if i can find out exactly how this happens.
hm that's not good. I'll have a look ...

offhand comment: when it happens it should happen only if adding levels to the top of the Map. Or the bottom i fergit -- but it should be only one of the two cases: top OR bottom

or, you know, it could be both it's just speculation atm.

Quote
For pre-existing route notes, your software allows you to easily drag around to new positions (which is great), any chance of a button to move it down or up a level?

On the Topview tab, on the outside of the grid, could you add little colour line indicating where  the 10th block end in both X and Y  axis, hell you could even link this up to a filed so custom values can be set,  i am currently doing some larger map blocks and square counting is very common place especially since i am trying to copy and paste data from one mapset to another and place everything in correct locations.

To help on the same above large map blocks, it would be useful if when i am highlighting a group of parts, there was some user feedback somewhere that tells me i have 6 blocks in X and 5 blocks in Y currently selected, once again to avoid me counting square by square.

added to my TODO.txt

(okay, this is an unadvertised feature: when dragging route-nodes, if the drag is started and with the mousebutton still held down, if you can also scroll your mousewheel to change level, then release the node on an empty tile on that level, it may work ... I remember testing that scenario when i was implementing node-drags just to see if my computer would explode but it didn't, so i didn't investigate further -- granted it's very awkward to try to use a mouse like that but it might well be a legitimate move)

Quote
Also a little off topic, I see OpenApoc is coming along nicely, Could Mapview2 handle its maps?

i know nothing about OpenApoc, sry. I'm an XCOM-only guy and even TFTD is substantially outside my jurisdiction,

--
but, in other news, substantial progress has been made on Custom terrain paths ... and since it relates closely to (real as well as imagined) case-sensitivity issues on Linux/Mac (with Mono) i'd like to do what I can to sort some (more) of that out before moving on ...


thanks for feedback, Luke
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 26, 2019, 12:10:08 am
Just tried the scrolling to change levels, yes its akward but it works so i can live with it, up until now i have been deleting them all and recreating them, that sucks when you just need to move them down 1 level.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 26, 2019, 12:18:57 am
y, anything's better than deleting and re-creating route nodes .........  :-\


EDIT @luke83

i couldn't get MapResize to bork ....

https://github.com/kevL/OpenXCOM.Tools/blob/master/XCom/Resources/Map/MapFileChild.cs#L427

that handles route-nodes when #levels change, so will need instructions to reproduce...
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 27, 2019, 04:59:33 pm
Yep, transparency done.

Binaries:
windows-built - https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190115.7z (https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190115.7z)
linux-built - https://lxnt.wtf/oxem/builds//MapView/MapView-612a2ce-2019-01-16-mono.7z (https://lxnt.wtf/oxem/builds//MapView/MapView-612a2ce-2019-01-16-mono.7z)

source the linux-built build is built from - https://github.com/StoddardOXC/OpenXCOM.Tools/tree/net45 (https://github.com/StoddardOXC/OpenXCOM.Tools/tree/net45)


Please try out the above.




EDIT:

Here's the latest build and as far as I can see it's fully usable on Linux/Mono (and should be on Mac/OSX/whateverthereisforMono)

https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190118.7z (https://lxnt.wtf/oxem/builds//MapView/MapView2_Net451_190118.7z)

This needs testing. Please help.




EDIT:

Running it on Mono:

1. Get the latest from https://lxnt.wtf/oxem/#/MapView (https://lxnt.wtf/oxem/#/MapView)
2. Run it.
3. Tell it where the vanilla data is.
4. Close and relaunch it
5. Go to Edit->Options and set UseMono to True
(bottomost on this:

(http://imgur.com/NHBn7i9l.png)

Confirmed. It is running and when using Mono natively under Linux, the transparency issue is gone.
The CPU load gets pretty high thou. Around 30% constantly on my X220.

Also i experienced some crashes, when trying to resize/recontainer the seperate windows with i3 windows manager.
Rescale and redraw routine seems not so good....

Also any decent keyboard shortcuts avaible?

In any case thank you all for enabling me to create maps natively under Linux :)
Let the map making maze begin. As soon as is have enough time thou ;)

Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 27, 2019, 05:07:27 pm
Any way to easily convert my old MapView settings into the new format?

See attached files.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on January 27, 2019, 05:28:15 pm
The CPU load gets pretty high thou. Around 30% constantly on my X220.

Same here on phenom2 975. It isn't easy on the cpu on windows either. No easy way around it alas.


Quote
Also i experienced some crashes, when trying to resize/recontainer the seperate windows with i3 windows manager.
Rescale and redraw routine seems not so good....

Also any decent keyboard shortcuts avaible?

I have no idea.. report them here I guess.

Quote
In any case thank you all for enabling me to create maps natively under Linux :)
Let the map making maze begin. As soon as is have enough time thou ;)

Thank you. I'm glad something good came out of this effort.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 27, 2019, 10:26:09 pm
The CPU load gets pretty high thou. Around 30% constantly on my X220.

Also i experienced some crashes, when trying to resize/recontainer the seperate windows with i3 windows manager.
Rescale and redraw routine seems not so good....

have to wait for a Linux c#/.net programmer to have a look ... and, y, it's not a highperformance app ( I get the impression that .net is not the way to go for HP. Am sure that a coder w/ more experience than me would have an assortment of so-called tricks to use, though )

Quote
Also any decent keyboard shortcuts avaible?

not really. They're all mentioned in the CHM help ...


Any way to easily convert my old MapView settings into the new format?

unfortunately, ConfigConverter handles only simple/straightforward MapEdit.DAT files. Terrains/Images in multiple directories is a no-go. I might try to re-code the converter to handle Images.Dat at some pt

i can only suggest setting up your tilesets in smaller chunks (as you need them) for now. That is, avoid the tempation of "I want it all. now" if you know what i mean,


/cheers

ps. If you need to setup Maps with terrains in multiple folders (as I believe the OxC mod-system works) wait just a day or so. I'll be releasing a build that supports terrains from multiple folders soon here:

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

(not sure when Stoddard's linux-build will pick it up tho)


EDIT__
next: Codename Luke ;)

- Option to embolden every 10th gridline (color & width)
- print current selection size x/y in statusbar of MainView
- Routes Editmenu: nodeup/nodedown 1 level

- working on MapEdit/Images.dat converter ... could take a couple days, no guarantees but looks feasible. (note, a restriction of Mv2 is that MAPS and ROUTES must be sibling dirs)
Title: Re: MAPVIEW upgrade
Post by: hellrazor on January 29, 2019, 09:56:04 am
have to wait for a Linux c#/.net programmer to have a look ... and, y, it's not a highperformance app ( I get the impression that .net is not the way to go for HP. Am sure that a coder w/ more experience than me would have an assortment of so-called tricks to use, though )

Jeah its not such a big issue for the time being. Performance optimisation always comes last. More important is to make it functional, with the features we need and want, Then bugfree (mostly), then performance can be somehow achieved.

not really. They're all mentioned in the CHM help ...

Blind me... Maybe something more traditional like README.txt or KEYBOARDSHORTCUTS.txt or so?

unfortunately, ConfigConverter handles only simple/straightforward MapEdit.DAT files. Terrains/Images in multiple directories is a no-go. I might try to re-code the converter to handle Images.Dat at some pt

i can only suggest setting up your tilesets in smaller chunks (as you need them) for now. That is, avoid the tempation of "I want it all. now" if you know what i mean,


/cheers

ps. If you need to setup Maps with terrains in multiple folders (as I believe the OxC mod-system works) wait just a day or so. I'll be releasing a build that supports terrains from multiple folders soon here:

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

(not sure when Stoddard's linux-build will pick it up tho)

Each mod has its own directories for MAPS, ROUTES and TERRAIN if the modder so desires.
MAPS is for *.MAP files, ROUTES for *.RMP. Each MAP file needs to have a corresponding RMP file.
Also the directory names are hardcoded to uppercase, if i recall correctly.

The directory TERRAIN, includes the mods own created or modified *.MCD, *.PCK and *.TAB files. Each set here forms one useable terrain set (limited to 256 per file (and or map), if i recall right).

It would be very much appreciated if we are simply allowed to hook, TERRAIN files towards the respective MAP/RMP configuration, which we desire.


EDIT__
next: Codename Luke ;)

- Option to embolden every 10th gridline (color & width)
- print current selection size x/y in statusbar of MainView
- Routes Editmenu: nodeup/nodedown 1 level

- working on MapEdit/Images.dat converter ... could take a couple days, no guarantees but looks feasible. (note, a restriction of Mv2 is that MAPS and ROUTES must be sibling dirs)

Looking forward to the gridlinecolor, for bigger maps. Maybe even tailor this down to 5?

Thank you so far for the great work and your time!
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 29, 2019, 10:16:19 am
OK, i can recreate this error with Routes jumping to wrong level
Open a existing map
change the Level ( i  changed a 1 level map to a 2 level map), i
f you check in the Routeview screen it looks correct.
Switch to another map and when it asks, tell it to save changes
Switch back to map you changed, the Routes are now on wrong level.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on January 29, 2019, 02:39:42 pm
(not sure when Stoddard's linux-build will pick it up tho)

Builds track the master branch on https://github.com/kevL/OpenXCOM.Tools.git (https://github.com/kevL/OpenXCOM.Tools.git)

It's checked at least once an hour.

Title: Re: MAPVIEW upgrade
Post by: kevL on January 30, 2019, 12:06:24 am
Each mod has its own directories for MAPS, ROUTES and TERRAIN if the modder so desires.
MAPS is for *.MAP files, ROUTES for *.RMP. Each MAP file needs to have a corresponding RMP file.
Also the directory names are hardcoded to uppercase, if i recall correctly.

sounds right. Mv2's recent change to non-windows compatibility -- ie, file system case-sensitivity -- lends some awkwardness. Eg, the file-labels in MapTilesets used to be allcaps regardless of case on the HD. But since case is now respected, it's possible to add terrain "ufo1" to a Map that is already shown using "UFO1" ...

as long as we all keep our heads screwed on it should be alright

to that end, Suggest that all directories be uppercase (MAPS,ROUTES,TERRAIN) and all files in them uppercase also.

( and.. ASCII is good )


Quote
The directory TERRAIN, includes the mods own created or modified *.MCD, *.PCK and *.TAB files. Each set here forms one useable terrain set (limited to 256 per file (and or map), if i recall right).

i was actually looking deeper into this the other day. The maximum terrain-ID is 253 in a mapfile: the value is stored in a byte (256) but when written to/read from the Mapfile they are offset by 2. So, 254 (0..253)

Quote
https://www.ufopaedia.org/index.php/MAPS

The reason for this is that, within the separate MAP files, a value of 2 maps to the index 0 within the associated MCD set (the first tile). This is as opposed to MAP.DAT, where a value of 2 maps directly to index 2 in the collated MCD array (the third tile). Values of 0 always mean "no tile" (except at ground level, where tile 1 of BLANKS.MCD will be used for to stop mysterious holes appearing in the bottom of the the battlescape), and tile 1 of BLANKS.MCD (burnt earth) is available for use by all tilesets.


qotd: "Nobody needs more than 640k ram"


I recently changed the Mapfile write code to cap assigned IDs to 253. Assigned tileparts that exceed that ID get replaced by a null-part. A warning is issued either when the Map loads or on returning from the TilesetEditor (but not on Map save). It's a warning and not an error, because it seems okay to have tilepart IDs that exceed the limit -- as long as they are not placed on the Map.



Quote
It would be very much appreciated if we are simply allowed to hook, TERRAIN files towards the respective MAP/RMP configuration, which we desire.

on the urging of davide this has been implemented (recently).

In Mv2 the def'n of a "basepath" is "the parent of a MAPS, ROUTES, or TERRAIN folder". Files for .MAP have to be in MAPS, for .RMP have to be in ROUTES (but only a sibling of the Map's MAPS directory), and for .MCD/PCK/TAB have to be in TERRAIN. The Configurator needs a basepath. The Map does not need a basepath if it's in the Configurator's basepath (but each Map can be set to its own basepath). Terrains can use the basepath of the Configurator, or the basepath of their Map, or be read from their own (specified) basepath individually. In effect any terrain can now be anywhere, as long as its in a TERRAIN directory.


Quote
Looking forward to the gridlinecolor, for bigger maps. Maybe even tailor this down to 5?

am gonna try it on 10 for a while... the grids are beginning to look a bit busy atm...


ConfigConverter2 is coming along. It requires MapEdit.dat, Images.dat, and Paths.pth and outputs MapTilesets.yml ... i hardly expect it to work BUT IT MIGHT /luL




Builds track the master branch on https://github.com/kevL/OpenXCOM.Tools.git (https://github.com/kevL/OpenXCOM.Tools.git)

It's checked once an hour at most.

thankie



@luke83 - will investigate soon(ish)
I couldn't get it to bork by following (my interpretation of) your directions, but there's still some fishy stuff going on ... will vet through the mapresize code and see what happens.
REPLICATED
RoutesChanged = true; should fix it ... doh.


2019 jan 30
the changes mentioned in my previous coupla posts have been pushed to Master and should be available via Stoddard's linux-build anytime,
I'll release a windows-build tomorrow ... today

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

2019 feb 4 - update

2019 feb 5
- fix for first run: the initial Configuration threw a KeyNotFoundException exception (by trying to show the current, nonexistent, configuration paths in the Configurator's textboxes)
- etc

2019 feb 7
- RouteView: export/import .RMP files (ie, use .RMP files as templates and/or replace route-nodes of a Map with nodes from a different Map, see RouteView's File menu)
- etc
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 09, 2019, 05:01:47 pm
I am wondering if i am getting into a issue with the following MCD file group. Since the asigned PCK's are over 256.
See Screenshot attached.
Title: Re: MAPVIEW upgrade
Post by: Stoddard on February 09, 2019, 05:22:15 pm
Let's maybe design a map format without that 256 MCD limit?

I propose a YAML structure like

Code: [Select]
- name: THEMAPNAME
    size: [ x, y, z ]
    terrains:
        - BLANK
        - etc
        - etc
          ...
    maybeExpectedTerrainSetSizes:
        - 2
        - 23
          ...
    routes:
     - id: arbitrary string
       posn: [ x, y, z ]
       links:
         - target: {id|N|W|E|S}
           distance: <int> # is used as weight?
           unit: {any|flying|flying_large|large|small}
         - target: ...
           ...
    tiles: !binary |
        # deflate-compressed (gzip header present),
        # base64 encoded and multiline - only to keep text editors happier
        # x*y*z of
        # { uint32_t floor, west, north, object }[]
        # in the same order as is .MAP :
        # left to right, top to bottom, top floor to bottom floor


naming in the rulesets would not change:
    NAME - old .MAP/.RMP stuff.
    THEMAPNAME - new-style maps, override the old-style ones,
                     and they don't pay any attention to what missiondef
                     says about terrain. Implicit terrain stuff is only
                     for the old-style maps.



It would allow text editing of routes only, the rest would be read-only, but still informative.
(can't change terrain sequence without changing the binary data or hilarity ensues)

maybeExpectedTerrainSetSizes can record MCD set sizes at creation, so changing that after the map was baked could be caught.

Title: Re: MAPVIEW upgrade
Post by: ohartenstein23 on February 09, 2019, 07:09:09 pm
We already have a way around this in OXCE - you can combine multiple terrains in a single map script (terrain tag in a mapScript command), or layer multiple maps with different terrains (verticalLevels tag in a mapScript command).
Title: Re: MAPVIEW upgrade
Post by: Stoddard on February 09, 2019, 08:20:29 pm
We already have a way around this in OXCE - you can combine multiple terrains in a single map script (terrain tag in a mapScript command), or layer multiple maps with different terrains (verticalLevels tag in a mapScript command).


Um, well, I overlooked that development.

Still I think it'd be better to keep terrain definition closer to the map.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 09, 2019, 08:52:05 pm
I am wondering if i am getting into a issue with the following MCD file group. Since the asigned PCK's are over 256.

a Mapfile doesn't store Pck entries, it stores Mcd record ids (which then have pointers to Pck data)

so the quantity of images isn't limited by the Mapfile format;


Still I think it'd be better to keep terrain definition closer to the map.

you're probly right -- though that's a decision for OXC/E
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 10, 2019, 03:34:04 pm
a Mapfile doesn't store Pck entries, it stores Mcd record ids (which then have pointers to Pck data)

so the quantity of images isn't limited by the Mapfile format;

Good to know then i can make this UFO =)
Title: Re: MAPVIEW upgrade
Post by: tkzv on February 11, 2019, 12:53:14 am
Thanks for trying to make this work in Mono, kevL.

To answer your question on GitHub: I treated all black pixels as transparent, because not drawing only colour #0 did not have the desired effect. As far as I can tell, you replaced my check with (palid != Palette.TransparentId) in case the transparent colour isn't 0. This makes sense. Unfortunately, this doesn't work for me. I downloaded your version ab4868e, compiled it and again got black rectangles.

UPDATE: My bad, forgot to define LOCKBITS. Now it looks more or less fine. Does it have to draw gaps between tiles? Also, when I move mouse over the window, a number of horizontal lines appear, vaguely in a shape of the craft displayed. What may be causing them?

UPDATE 2: Found "Use Mono" option. Now everything is fine.

Stoddard's latest build https://lxnt.wtf/oxem/builds//MapView/MapView-ab4868ec-2019-02-08-mono.7z does not work in my system (Ubuntu 16.04), giving the error:

For System.MissingMethodException: Method 'String.Format' not found.
  at YamlDotNet.RepresentationModel.YamlStream.Load (IParser parser) <0x40cbb760 + 0x0003b> in <filename unknown>:0
  at YamlDotNet.RepresentationModel.YamlStream.Load (System.IO.TextReader input) <0x40cb99b0 + 0x00047> in <filename unknown>:0
  at MapView.XCMainWindow.LoadOptions () <0x40cb7f20 + 0x0013b> in <filename unknown>:0
  at MapView.XCMainWindow..ctor () <0x40c17b80 + 0x006bb> in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.XCMainWindow:.ctor ()
  at MapView.Startup.RunProgram () <0x40bd6fe0 + 0x000db> in <filename unknown>:0
Title: Re: MAPVIEW upgrade
Post by: kevL on February 11, 2019, 03:43:06 am
Thanks for trying to make this work in Mono, kevL.
np. you did the groundwork, i had the time, it was interesting ....... tks.

Quote
To answer your question on GitHub: I treated all black pixels as transparent, because not drawing only colour #0 did not have the desired effect. As far as I can tell, you replaced my check with (palid != Palette.TransparentId) in case the transparent colour isn't 0. This makes sense.

note that (const)Palette.TransparentId is defined as "0" in the code elsewhere -- it's not, eg, getting the transparency ID out of an image and using that, it's just avoiding the use of "0" (as a magic number).

The thing is, if you want to test against palette ids, this is the necessary step:

Code: [Select]
    palid = bindata[++i];

bindata is retrieved from an XCImage object, in this case a terrain-sprite at the right animation frame

ps. LOCKBITS is an experimental routine that draws sprites pixel by pixel; but i didn't notice any speed increase so its on hold indefinitely.


Quote
UPDATE 2: Found "Use Mono" option. Now everything is fine.
i guess I should make note of that on the Distribution page ... a bit of my bad


Quote
Stoddard's latest build https://lxnt.wtf/oxem/builds//MapView/MapView-ab4868ec-2019-02-08-mono.7z does not work in my system (Ubuntu 16.04), giving the error:

For System.MissingMethodException: Method 'String.Format' not found.
  at YamlDotNet.RepresentationModel.YamlStream.Load (IParser parser) <0x40cbb760 + 0x0003b> in <filename unknown>:0
  at YamlDotNet.RepresentationModel.YamlStream.Load (System.IO.TextReader input) <0x40cb99b0 + 0x00047> in <filename unknown>:0
  at MapView.XCMainWindow.LoadOptions () <0x40cb7f20 + 0x0013b> in <filename unknown>:0
  at MapView.XCMainWindow..ctor () <0x40c17b80 + 0x006bb> in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) MapView.XCMainWindow:.ctor ()
  at MapView.Startup.RunProgram () <0x40bd6fe0 + 0x000db> in <filename unknown>:0

hm, appears Mono doesn't interpret something in YamlDotNet quite right. perhaps @Stoddard can give it a run and get the line # of the offending String.Format() ? Does it happen with an empty /settings folder? Ie, try deleting MapViewers.yml (window positions)



hm, i googled for "mono MissingMethodException string.format"

a couple of possible leads ...

a) Unable to execute build.sh in Ubuntu due to "Error: Method 'String.Format' not found."
https://github.com/cake-build/cake/issues/1929
(resolution: upgrade Mono)

b) Method not found: 'System.String System.String.Format(System.IFormatProvider, System.String, System.Object)
https://stackoverflow.com/questions/30558827/method-not-found-system-string-system-string-formatsystem-iformatprovider-sy
(resolution: force a different overload for String.Format())


here's a better stacktrace of what i think is going on,
https://github.com/kevL/OpenXCOM.Tools/blob/master/YamlDotNet/Core/ParserExtensions.cs#L46
called from
https://github.com/kevL/OpenXCOM.Tools/blob/master/YamlDotNet/RepresentationModel/YamlStream.cs#L100
called from
https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L573

which means parser.Allow<T>() is null, which means parser.Accept<T>() is false, which means parser.Current is *not* T, which throws a YamlException with the string.Format() call that borks.

Try deleting MapViewers.yml
Title: Re: MAPVIEW upgrade
Post by: tkzv on February 11, 2019, 08:56:20 am
(resolution: upgrade Mono)
Most likely for me. 16.04 has frozen the version.
Title: Re: MAPVIEW upgrade
Post by: luke83 on February 11, 2019, 11:49:38 am
Hey KevL, do these errors mean anything to you?

I get this on mapset Grunge1, if i make ANY changes to that mapset ( even just changeing the shade of 1 pixel in the set), when i try to load it back into Mapview it gives the below errors. At first i thought it was MCDEDIT corrupting the file but it loads perfectly in Openxcom ( and displays correctly) its only mapview that crashes out.

Any thoughts?
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 11, 2019, 12:05:54 pm
Kevl, is there any method of converting the old mapedit.dat/images.dat information to your format?
I would like to give your work a try, but I have hundreds of custom terrains and mapblocks, and there's just no way I'm going to do this manually.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 11, 2019, 03:56:33 pm
@luke83
loading ...

EDIT:
GRUNGE1_L83.PCK/TAB looks borked. It won't open in PckView (correctly) either. suggest recreating if poss.



@Solarius Scorch
in the .7z package (windows build) there's a subdir /ConfigConverter

it's a standalone app that requires MapEdit.dat, Images.dat, AND Paths.pth (input)

and outputs MapTilesets.yml

There's a ReadMe.txt ...


It's only been tested with what I have here, and a couple other dats that unfortunately strike me as a bit buggy, or at least quirky from the git go ...

am curious what results you could get from it. Pls pay attention to any dialogs that pop, the output (MapTilesets) could well need tweaking,

but i'd be happy to work on it with ya if it comes to that,
Title: Re: MAPVIEW upgrade
Post by: luke83 on February 11, 2019, 06:27:00 pm
Borked? It looks fine on my end, what are you seeing?

Yes i can recreate it, problem is, as soon as i change anything at all, it "breaks" again...its loading into OXC ok but i would like to have a working file, i might try changing the images through PCK view then and see if that avoids what ever is going on.

Thanks again mate :)
Title: Re: MAPVIEW upgrade
Post by: kevL on February 11, 2019, 07:51:07 pm
i did a bit of debugging ...

for some reason there's a mismatch between the quantity of sprites in the PCK and the quantity of sprites expected by the TAB.

Code: [Select]
SpriteCollection..cTor
. fsTab.Length= 106
. tabOffsetLength= 2
. tabSprites= 53
pckSprites= 56 tabSprites= 53


looking at the PCK and TAB files in a hexeditor shows that the last few blank sprites have somehow caused a mismatch between the PCK and TAB data. (i fixed it with the hexeditor to make it work, but the point is that something went distinctly screwy somewhere along the production line)

OXC and MCDEdit can let things go through okay -- no harm done perhaps. But PckView/MapView do error-checking to ensure the quantity of sprites match the quantity expected by the TAB file. If they don't the spriteset goes null,

that's just the way it is, Luke


(but i'll put a note in my TODO, to issue an error... hrm, it's problematic due to the UFO vs TFTD taboffsets... bleh)
Title: Re: MAPVIEW upgrade
Post by: luke83 on February 12, 2019, 08:03:34 am
Used your awesome PCKview to change the graphics over without any issues, i dont know what caused the issue but its great to be able to work around them :)
Title: Re: MAPVIEW upgrade
Post by: kevL on February 12, 2019, 09:33:21 am
sweet :)

but all i've been doing is riff off what Ben did,
Title: Re: MAPVIEW upgrade
Post by: luke83 on February 13, 2019, 07:46:42 am
Still, your doing great work, keep it up, the community appreciated you keeping the tools alive.

I wish Apoc had someone working on the modding tools, i just found a image extractor that is dos based, still looking for any newer programs. I am looking into the idea of doing my Foxy ( Fantasy Open Xcom) in APoc instead of OXC so am now looking at tools.
Title: Re: MAPVIEW upgrade
Post by: tkzv on February 15, 2019, 12:02:56 pm
MapView with Mono has troubles saving GIF images. The background is filled with garbage.


And a few questions to avoid creating an extra post:

Is there any easier way to add custom maps to the tree, other than modifying MapTilesets.yml and restarting?

Is there an undo?

Are there keyboard shortcuts for map editing (move cursor, change level, cut/copy/paste...)?
Title: Re: MAPVIEW upgrade
Post by: kevL on February 15, 2019, 04:19:01 pm
MapView with Mono has troubles saving GIF images. The background is filled with garbage.

I'd like to output screenshots in PNG (eventually), i glanced at the SaveGif() function when implementing PNG input/output for PckView ... hoped it was working ok, guess not :\


answers to these questions are in the CHM-help file. if there's a viewer for CHM on non-windows ...

Quote
Is there any easier way to add custom maps to the tree, other than modifying MapTilesets.yml and restarting?

right click on the Maptree and, depending on what node is selected, options should pop up in a menu

Quote
Is there an undo?

no. Implementing Undo/Redo in a nontrivial codebase that wasn't written with it in mind is (very) nontrivial.

Quote
Are there keyboard shortcuts for map editing (move cursor, change level, cut/copy/paste...)?

cut = Ctrl+x
copy = Ctrl+c
paste = Ctrl+v
delete = Delete

(but not sure about non-windows systems)

move cursor - nope, am thinking about it at some point tho.
change level - nope.

because of the way MapView was originally coded, implementing shortcuts is a fair bit more complicated than normal,
Title: Re: MAPVIEW upgrade
Post by: Stoddard on February 15, 2019, 04:44:52 pm
I'd like to output screenshots in PNG (eventually), i glanced at the SaveGif() function when implementing PNG input/output for PckView ... hoped it was working ok, guess not :\

This very much looks like uninitialized memory, like, dest image not cleared before drawing. Maybe windows does it automatically while mono does not.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 16, 2019, 01:05:23 am
hey Stoddard,
unfortunately the first call in SaveGifFile() is CreateTransparent() which SEEMS to create the bitmap-area and fill all pixels w/ paletteId #0

but there are several other drawing and cropping calls going on after that, I don't understand them atm ... this'll wait for a better day,


EDIT:
I just pushed a commit to master : output MainView screenshot as PNG

Stoddard's auto-mono build should pick it up soon ... (but is not in windows build yet)
Title: Re: MAPVIEW upgrade
Post by: tkzv on February 19, 2019, 07:57:56 am
Saving as GIF is no longer available. Saving as PNG works, but fills black with garbage too. (Staircases in the air and missing walls and roof are correct.)
Title: Re: MAPVIEW upgrade
Post by: kevL on February 19, 2019, 11:42:20 am
huh, ok

unfortunately i'm not setup to build or debug Mono ... I'd just be chasing cats up trees.

maybe someone who is can give it a go,


EDIT: back on the ranch ... implemented an overhead ScanG viewer.
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

File->ScanG view
- mousewheel does levelup/down
- doubleclick toggles between multilevel view and single-level view
- requires ScanG.Dat in the GEODATA folder of the Configurator's basepath

EDIT: 2019 feb 21
- added check to ensure that a tilepart's ScanG reference doesn't exceed those available in the .Dat file

EDIT: screenshot3
- rigging PckView to view/edit ScanG.Dat (not done)
Title: Re: MAPVIEW upgrade
Post by: luke83 on February 24, 2019, 12:01:32 pm
EDIT: back on the ranch ... implemented an overhead ScanG viewer.
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

File->ScanG view
- mousewheel does levelup/down
- doubleclick toggles between multilevel view and single-level view
- requires ScanG.Dat in the GEODATA folder of the Configurator's basepath

EDIT: 2019 feb 21
- added check to ensure that a tilepart's ScanG reference doesn't exceed those available in the .Dat file

EDIT: screenshot3
- rigging PckView to view/edit ScanG.Dat (not done)

So for all the maps i have built i have never even tried to correct the ScanG data ( and i am embarrass for it, with my new maps i wont have a choice as they are very different to the original data so at some point i will need to fix all these.),  Are you planning just a viewer OR are you going to allow us to create new artwork and correct these from mapview?
Title: Re: MAPVIEW upgrade
Post by: kevL on February 24, 2019, 06:21:55 pm
are you going to allow us to create new artwork and correct these from mapview?

tl;dr yes


hey luke,

I'm adapting PckView to open/edit/save SCANG.DAT (UFO/TFTD, although as usual i can't test TFTD's scang.dat) -- it's halfway done.

hopefully OXC/E doesn't cap the quantity of entries when loading the ScanG file (i wouldn't expect it to but it's a possibility). That is, hopefully we can add icons to ScanG.Dat and assign MCD records to use them and it all works fine.

Note that OXC and probly E *might* already be able to add extra scang-icons. I forget the specifics, and perhaps i did a bit of recoding to make it work, but it's sorta like defining a new icon as an extraSprite then specifying it as an ID in extraMapdata or whatever it is ...

anyway, personally i want to be able to add new icons directly to SCANG.DAT and reference them in MCD files seamlessly.


/Let the mayhem continue as ~25 variations of the DAT become available...
Title: Re: MAPVIEW upgrade
Post by: Meridian on February 24, 2019, 07:36:10 pm
hopefully OXC/E doesn't cap the quantity of entries when loading the ScanG file (i wouldn't expect it to but it's a possibility). That is, hopefully we can add icons to ScanG.Dat and assign MCD records to use them and it all works fine.

No, we don't limit the number of entries.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 24, 2019, 07:59:49 pm
what about mod design?

I'm not familiar with OXC/E mod design/adaptability... offhand, do you think it will handle something like this:

my_mod_override_files/GEODATA/SCANG.DAT

ie, use a mod's custom SCANG.DAT instead of the standard (UFO/TFTD) SCANG.DAT ?
Title: Re: MAPVIEW upgrade
Post by: Meridian on February 24, 2019, 08:21:03 pm
yes
Title: Re: MAPVIEW upgrade
Post by: kevL on February 24, 2019, 08:30:01 pm
thank ya (excellent work, guys)


EDIT:
2019 February 25

 - PckView: support for SCANG.DAT files
 - PNG output sets palette-id #0 transparent
 - minor fixes and code improvements

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

attached: stock ScanG iconset w/ 14 green shoreline icons added


EDIT:
2019 February 26

 - more integration of ScanG viewer; update when the Map changes; etc.
 - ScanG view: double right-click to reload SCANG.DAT from disk
 - File->ReloadTerrains: reload Map/Routes/Terrains from disk (without having to click to a different Map and back, or reload the app)
 - MCD Info: fix TU_Slide/TU_Fly inversion
 - extend MainView's SpriteShade setting to TileView and TopView sprites and refresh all sprites when user changes the shade
Title: Re: MAPVIEW upgrade
Post by: Alex_D on February 27, 2019, 08:51:57 am
Thanks for the new version. The ScanG is a great feature.

Is there any plans on viewing the LOFTS?

- File->ReloadTerrains: reload Map/Routes/Terrains from disk (without having to click to a different Map and back, or reload the app)

I downloaded the 2019-Feb-26 version, installed on a clean folder except for the "settings", ran it and I don't see the option above . Do I need to modify something else?

By the way, my antivirus program keeps on warning the file is so uncommon that might be dangerous, blah, blah. Please (to others), keep using the program so there is a proper database and the flag can be removed by the AV database.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 27, 2019, 08:01:57 pm
oops i goofed. (i put the feb25 files in the feb26 archive)

go for the MapView2_190226b.7z arch. "Reload terrains" should appear just beneath "ScanG view" -- sry and thanks for the catch


Thanks for the new version. The ScanG is a great feature.

refresher:
double LMB - toggle between single-level ("1" is appended to the titlebar caption) and multi-level (default)
double RMB - reload ScanG.Dat from disk (shows message success or fail)
mousewheel - level up/down

Quote
Is there any plans on viewing the LOFTS?

not in Mapview at present. I am however currently coding McdView... based on the appearance of Volutar's MCDEdit but it won't have PCKEdit (if i can help it.. I'm not an artist and have no clue what's going on in PCKEdit..)

McdView ought show the LofTs like MCDEdit does. If you have a more specific request to show the LofTs within the design of Mapview i'd consider it ....


Quote
By the way, my antivirus program keeps on warning the file is so uncommon that might be dangerous, blah, blah. Please (to others), keep using the program so there is a proper database and the flag can be removed by the AV database.

i know so little about coding viruses ... but I suppose it's due to the over-complexity that Mapview was coded with (originally, Daishiva had his reasons for doing it that way)

... watching those in the know at the AV companies could be humorous to watch analyzing it, scratching their heads going, huh whot?

/anyway :|


if i goofed again, pls let me know


EDIT: screenshot -- McdView in progress...

EDIT2: McdView is almost finished. ~1mth of daily code
See screenshot 2.

ps. I expect there to be Mono transparency issues on the IsoLoFT panel ... *shrg
Title: Re: MAPVIEW upgrade
Post by: kevL on April 07, 2019, 11:10:36 am
(new post to hit the unread flag)

2019 apr 7
MapViewII gets MCD editor -- mcdview.exe

is integrated w/ TileView, like PckView already was.

+several tweaks to MapView itself

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


EDIT: ops i left SpriteShade at 10 default -- that's kinda bright for most i imagine -- it should have been -1 fixed
Title: Re: MAPVIEW upgrade
Post by: luke83 on April 07, 2019, 11:17:07 am
(new post to hit the unread flag)

2019 apr 7
MapViewII gets MCD editor -- mcdview.exe

is integrated w/ TileView, like PckView already was.

+several tweaks to MapView itself

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

Nice, i will try it out next weekend  :)
Title: Re: MAPVIEW upgrade
Post by: kevL on April 12, 2019, 01:41:20 am
am currently working on keyboard navigation

I think i see some (rather innocuous) bugs in RouteView's NodeEditor group buttons as well ... eg. the Paste is dysfunctional. *

* nah, just right-click to create a new node first, then Paste
Title: Re: MAPVIEW upgrade
Post by: luke83 on April 12, 2019, 10:11:04 am
Hey, just checked out MCDEDIT, looks very nice, not sure if you plan on doing the art edit side of things or not to replicate VOutars version?

I do have a feature request for it though,I am always merging MCDs from different sets to create my own, what would be good would be if open a separate view window on the side of the main window,  Select another MCD set and copy over the  MCDdata and MCDimage from the secondary MCD into the main one.

Currently i am using BombBlokes MCDADD to handle this and it requires you to make Batch files to achieve this, it would be great to have a visual method to do this quickly ( Note it can be done in VOltares MCDEDIT but you must jump back and forth between MCD sets and you must copy the image and MCD separately, its a little painful).

THanks again for upgrading these programs :)

Title: Re: MAPVIEW upgrade
Post by: kevL on April 12, 2019, 11:14:10 am
Hey, just checked out MCDEDIT, looks very nice, not sure if you plan on doing the art edit side of things or not to replicate VOutars version?

i have no plans for it at present... my sentiment is that pixel-editing is best suited to a dedicated pixel-editor (a real image editing program). Granted, i'm not an artist so it doesn't occupy much of my thoughts...

some time ago I adapted PckView with the ability to touch-up sprites that have rogue pixels, which is sorta common in the stock resources. So, if i need a project in future, am leaning toward handling sprite-editing in PckView. idk

Quote
I do have a feature request for it though,I am always merging MCDs from different sets to create my own, what would be good would be if open a separate view window on the side of the main window,  Select another MCD set and copy over the  MCDdata and MCDimage from the secondary MCD into the main one.

this sounds more interesting. Like a new command: File|Open copy panel...

- shows an overview of a secondary MCDset and allows multiple records to be copied to McdView's internal copy-buffer

( have gotta get keyboard navigation sorted first tho )

EDIT: whackloads of keyboard-shortcuts incoming ...


EDIT2:

2019 April 22
- keyboard shortcuts: see keyboard_cheatsheet.txt or the CHM Helpfile
- several UI changes, insubstantial (mechanically) but noticeable
- the Maptree gets double-buffered to stop flicker (non-Mono build only)

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

Reminder to backup yer stuff.


EDIT3:
next... the Copypanel (see screenshot)


EDIT4:
2019 April 27
- add CopyPanel to McdView + tweaks. The CopyPanel is a subsidiary window that can open an MCDset, from which records may be copied for insertion into McdView proper.


EDIT5:
screenshot#2 - InsertAfterLast (alpha, not in master branch yet) - an operation that inserts tileparts from the CopyPanel along with their sprites and sub-parts to Main. (note: a regular copy/insert from the CopyPanel transfers MCD-data only, that is sprites and sub-parts usually need to be tweaked up after insertion).


EDIT6:
2019 May 10
McdView's CopyPanel gets InsertAfterLast: optionally inserts sprites as well as death/alternate parts to the terrainset.


EDIT7:
screenshot #4 -- calculate on-the-fly TabOffsets in PckView (not in master branch yet)


EDIT8:
2019 May 12 - PckView upgrade.
- arrow-keys navigate sprites
- [Delete] selects next sprite (allowing quick deletion of a range of sprites)
- shortcuts have been re-assigned
- update CHM helpfile
- confirmation on save if spriteset has changed
- and the selected sprite's TabOffset is printed to the statusbar along with the offset of the 'next' sprite.
Title: Re: MAPVIEW upgrade
Post by: kevL on June 24, 2019, 10:41:23 pm
(new post to hit the new post flag)

2019 June 24
MapView2_190624.7z

- possible fix for intermittent exception related to MCD Info, caused by discrepancy between the way MCD records load in MapView and (external) McdView (after being invoked via TileView).

reported by Kato /thks

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md
Title: Re: MAPVIEW upgrade
Post by: Roxis231 on July 03, 2019, 09:36:30 am
Hi KevL

I've downloaded the latest copy - but when I try to run it I get this error.

(https://openxcom.org/forum/index.php?action=dlattach;topic=1321.0;attach=43552;image)

Any Ideas? Error file Included.
Title: Re: MAPVIEW upgrade
Post by: kevL on July 03, 2019, 07:54:24 pm
The error is simply saying that MapView.exe can't find XCom.dll (or one of its dependent .dlls -- DSShared.dll, YamlDotNet.dll)

I get errors like that when i try to run the .exe either
a) without the .dll(s) in the same directory
b) when it's still inside the archive

possible fixes:
a) keep the program's .exe and .dll files in the same directory together
b) unzip the archive ...


Or i guess it could be a funky new security feature MS came out with, in which case i rly din't have a clue,

(other than to /not/ install to the "Program Files" folder)


ps. I notice that the pic says "XCom, Version=3.1.2.0" but Error.txt says "XCom, Version=3.0.0.0" ... so i suppose you tried an earlier version. These are the (correct/compatible/should-all-work-together) versions for 2019 june 24:

MapView.exe - 3.1.3.0
XCom.dll - 3.1.2.0
DSShared.dll - 3.0.0.1
YamlDotNet.dll - 0.0.0.0

McdView.exe - 3.2.1.0
PckView.exe - 3.1.0.0
Title: Re: MAPVIEW upgrade
Post by: Roxis231 on July 04, 2019, 05:07:12 am
Downloaded the June 9th version - got that working

June 24th seems to be missing DLLs
Title: Re: MAPVIEW upgrade
Post by: kevL on July 04, 2019, 07:52:08 am
MapView2_190624.7z looks okay t'me and seems to run fine,
:|


I can think of two people who (i hope) would have mentioned it ...
Title: Re: MAPVIEW upgrade
Post by: Roxis231 on July 04, 2019, 08:55:28 am
Just re-downloaded it to check.

Seems the first time I got a copy without DLLs - not sure how, but they are there now.
Title: Re: MAPVIEW upgrade
Post by: kevL on July 04, 2019, 09:58:43 am
good :)

i think it's a good version.


( tho i'm working on a new, anti-pasta version at present <g> )

EDIT: wip ->

Feature request: some kind of report or indicator for unused mcd entries. I've got some overly large terrain sets right now, and that would help me edit them down a bit without having to click on the tiles to try and figue it out by eyeballing it.

four yrs late ... (see screenshot1). I'm working on a subsystem that opens via File|MapInfo. Sort of a "show detail" dialog.

// TODO:
// - MapDetail      (Terrains in the Tileset: label + count)
// - RouteDetail    (routenodes, spawnnodes + ranks, attacknodes in the Tileset or Category)
// - CategoryDetail (Tilesets in the Category)
// - GroupDetail    (Categories + Tilesets in the Group)
// - TerrainDetail  (all Tilesets that use a Terrain or all Terrains used in the Maptree)

but those are just thoughts about it ... the underlying code isn't really set up for this (the MCD records aren't actually stored as independent collections; at present, the Tileset only grabs what it needs and disregards the rest)


EDIT2: SpawnInfo (screenshot#2)


EDIT3: 2019 aug 26
this might amuse someone ... not for the faint of heart

RulesetConverter demo
https://drive.google.com/file/d/17qXON7f_4i1r65HdfhgV2GJzyJnO6h_I/view?usp=sharing
Title: Re: MAPVIEW upgrade
Post by: kevL on August 30, 2019, 03:43:55 am
Saving as GIF is no longer available. Saving as PNG works, but fills black with garbage too.

next release has a MainView option to output screenshots to PNG or GIF (that might help, no guarantees tho). It also has an option to bypass the cropping algorithm (maybe that's where the glitches were creeping in but i don't think so, am suspecting that it's an issue w/ Mono's PNG handling although that's merely a guess atm)

is there any method of converting the old mapedit.dat/images.dat information to your format?
I would like to give your work a try, but I have hundreds of custom terrains and mapblocks, and there's just no way I'm going to do this manually.

next release has RulesetConverter. It'd be best to figure out the basics of how MvII's "basepath" system works first, however, or figure it out on the fly. Basically there are
1. Configurator basepath (set on first run, or under the Edit menu): the parent directory of MAPS,ROUTES,TERRAIN, + UFOGRAPH (for the cursor sprite), and GEODATA (if you want ScanG and LoFT for use in McdView).
2. Tileset basepath: overrides the configurator's basepath of MAPS and ROUTES for a particular Map, if set (see the TilesetEditor).
3. Terrain basepath: can be one of three settings - use the Configurator basepath for terrains, use the Tileset's basepath for terrains, or specify a custom basepath to any other TERRAIN folder. (also see the TilesetEditor)

(note that ConfigConverter2 will still be shipped in a subdirectory of MapView2 - and (a) if it works for ya, and (b) you're looking for a "MapTilesets.yml" from scratch - ie are willing to set Mapview's Configurator basepath to wherever the ConfigConverter wants - it could be more useful than the RulesetConverter.)

eta for ver.3.3 is ... close, and it will be beta or "release candidate" or NOT THOROUGHLY TESTED if ya'll get my drift
Title: Re: MAPVIEW upgrade
Post by: kevL on August 31, 2019, 10:20:59 am
Time to release this upon the suspecting ... treat as Beta software.

This is a very large update.

IMPORTANT: The MapOptions.Cfg file in your /settings folder will be changed. So back that file up if you like your current MapViewII customizations and want to transfer them to a/the new MapOptions config (i would strongly suggest using the Options dialogs instead of dicking about with the textfiles).

IMPORTANT: The so-called backup mechanic for MapView, McdView, and PckView has also changed. This is not a comprehensive backup mechanic and was never intended to be that. It's intended only to give the user (including yours truly) that ONE (1) chance on a misclick to go "oh sh*t i shouldn't have done that" and have a chance of recovering the file you just overwrote*. The problem was that the routines were inconsistent; sometimes you got a .bak file, sometimes it wrote to an "MV_Backup" subdirectory, sometimes you got nothing at all, etc -- so I've implemented a plan: any and every time a file on the hardrive** is changed by MapView, McdView, or PckView, it is first copied to an "MV_Backup" subdirectory of its original location, with its original filename.

* note: This should also handle more hazardous failures like a power outage during file-write but let's not go there. Get yourself a UPS. (seriously.)

** note: Does not include image-output; exporting images does *not* perform backups. But saving MAP, RMP, MCD, PCK, and TAB files as well as configuration files should/will get their instant backups.

changelog ->

MainView
- RMB-drag scrolls the Map when scrollbars are visible
- Ctrl+F1..F4 toggles parttype visibility as per TopView F1..F4
- F1 opens the CHM Helpfile (was start animations)
- F2 toggles animations (was stop animations only)
- always draw targeter-cursor during keyboard navigation
- fixed multi-tile select by keyboard
- fixed exception on [Esc] and/or MouseWheel when no Mapfile is loaded
- moved ModifyMapSize from File menu to Edit menu
- reworked statusbar aesthetic
- allow keyboard navigation through the Maptree without loading any Maps until [Enter] is pressed
- expand/collapse parent nodes on the Maptree w/ [Enter]
- changed the hotkey for opening the Maptree's context menu from [Enter] to [Space]
- refactored the MenuManager (handles viewer-open/close from the Viewers menu)
- fixed CTD when taking full-level screenshots.
- tightened up Maptree handling (loading/writing the Maptree; allow a blank MapTree; don't write group or category padding-text to "MapTilesets.yml" if there are no tilesets in the group/category anyway).
- faster loading of Tilesets (much faster if you have many toplevel groups)
- added to Options: screenshot background color (default Transparent) and crop background (default false) and choice of PNG or GIF output (default PNG)
- added to Options: color toners for SelectedTiles (none,grayscale,redscale,greenscale,bluescale - default grayscale)
- rewrote the CollapsibleSplitter (the divider between the Maptree and the main panel)

TileView
- changed the null-sprite aka. eraser-sprite
- added mnemonics to menus
- reworked statusbar aesthetic
- prevent tab flicker

TopView
- tweaked the parttype null-sprites
- double-leftclick on a tile selects the tilepart of the currently selected quadrant (also [t])
- rightclick and double-rightclick (also [Enter] and [Shift+Del]) operate on either a tile or the quadrant-panel.
- display the currently selected tilepart's sprite in the quadrant-panel; click (also [q]) selects its proper quadrant-slot
- ignore the spaces between quadrant-types when clicking to select a type
- reset the quadrant-panel's sprites after loading or resizing a Map
- fixed multi-tile select by keyboard
- added mnemonics to menus
- added Test->Test parts in tileslots to check the types of all parts (floor, westwall, northwall, content) that are currently assigned to tiles against the type of tileslot they occupy. The result is shown in a dialog.

RouteView
- Tally button displays current spawn info for the tileset and its category
- clear previously selected tile's coordinate info after resizing a Map
- print mouseovered node's baseattack-weight in the overlay, iff non-zero
- add a Save button to the data area (doubles as a "routes changed" indicator)
- fixed: set MapLocation on LMB-dragnode so that keyboard-dragnode doesn't go dysfunctional.
- added mnemonics to menus and arranged menuitems

TopRouteView
- prevent tab flicker

TilesetEditor
- fixed up Tab-order (ie. keyboard navigation around the dialog)
- try to keep listboxes focused with a reasonable item selected when allocating/deallocating terrains
- disable the ACCEPT button until a Descriptor is valid.
- fixed the global descriptor changer (if a tileset with the same basepath exists in 2+ categories, both get their metadata changed)
- handle terrain-not-found errors less annoyingly
- added a checkbox to suppress the MCD RecordsExceeded warning (saved in MapTilesets.yml w/ each tileset)

ScanG
- fixed: don't draw the SE quadrant of large units (sic)
- added viewer to the zOrder list
- register its screen position on MainView quit
- moved item from File to Viewers menu
- switch icons and palette between UFO/TFTD resources when a Mapfile loads.
- enable/disable the ScanG menuitem depending on tileset and available resources

MapInfo
- moved item from File to Help menu
- added a Detail button that shows what MCD records are used/unused in the currently displayed Map's terrainset

Configurator
- use custom messagebox to display info/errors that need to print paths (prevents wrapping long paths)
- don't close the configurator when simply generating a MapTilesets template

General
- reworked load/save Options (MapOptions.cfg) incl/ fixes to Content-type blob updates
- rewrote Options interaction in toto (tighter integration w/ viewers' shortcuts, improved code refactorability, etc.)
- reworked load/save viewer locations and sizes (MapViewers.yml)
- try to maintain z-order on (1) open/close McdView or PckView (2) MinimizeAll/RestoreAll (3) option "AllowBringToFront" when MainView takes focus.
- changes to spriteset loading (determine tabword-length based on the tab-file data instead of failure to instantiate a 2-byte wordlength spriteset) [idea lifted from OXC code]
- rewrote tile-loading and the default-tileset creation routines
- reworked double-buffering calls to what I believe are the most simple/efficient yet effective
- re-select the current treenode on the Maptree if the Configurator forces a restart; plus use what seems to be a more stable restart routine.
- rewrote the Infobox (a dialog that replaces .net's stock MessageBox here and there)
- restrict keyboard shortcuts to exact key or key-combinations (eg. [Shift+Enter] no longer invokes an operation that's intended for [Enter] only)
- tighter file handling, IO exception handling, one-time safety backup handling, to-load-or-not-to-load handling, file corruption handling, file IO error message handling, handling handling and file-fondling in general.

McdView
- ensure that the CopyPanel is closed on exit, else it can stick open when invoked via TileView
- RMB-click on the IsoLoft panel reverts slider to show all layers
- fixed: write the ScanG ushort as little-endian regardless of computer architecture.
- allow loading of filetype via Explorer's file-associations
- properly dispose temporary LoFT and ScanG bitmaps
- allow the IsoLoft viewer to track all the way down to 0 layers and use 3-step shading (instead of 2-step) while tracking layers.

ScanG chooser
- fixed: handle iconsets that have less than 35 icons (the first 35 icons are for units not terrains)

PckView
- fixed saving sprites that do not have a fully transparent top row(!)
- fixed File|Export Sprites ...
- reworked statusbar aesthetic
- minimize/restore the Sprite and Palette windows when the main window's state minimizes/restores
- bring Sprite and Palette windows to front when the main window takes focus
- apply MapView's gamma adjustment to sprites and swatches (can be toggled from the Palette menu, default is On)
- resolved conflict between contextmenu shortcut [p] (export sprite) and mnemonic [Alt+p] (open Palette menu)
- allow loading of filetype via Explorer's file-associations

SpriteEditor
- flag Changed if pixels changed
- reworked statusbar aesthetic
- added mnemonics to menus

Palette viewer
- properly dispose created brushes
- reworked statusbar aesthetic

Updated CHM helpfile and keyboard_cheatsheet.

ConfigConverter
- properly dispose the openfile dialog

RulesetConverter
- add.


IMPORTANT: This is a good time to backup your irreplaceable MAP, RMP, MCD, PCK, and TAB files(!)

Backing up your \settings folder is a good idea also. Especially MapTilesets.yml (... the other configuration files are easy to replace or regenerate) and, for the reasons given above, MapOptions.Cfg.


That is, this update has vast tracts of code refactoring, duplicated code removal, standardization of various routines, generally increased readability/maintainability/documentation even ...

But backup yer stuff,


( welcome to the QualityAssurance dep't -- ie, treat this release as BETA )

in fact, if i were you I'd simply rename my current MapView2 installation ( eg. MapView2_ ) and install this version alongside it. Run it once to create the /settings directory, quit and *copy* in your MapTilesets.yml ... Then take it from there,


Assembly Versions:
3.3.0.0
- MapView.exe
- McdView.exe
- PckView.exe
- XCom.dll
- DSShared.dll
2.1.0.0
- ConfigConverter.exe
1.0.0.0
- RulesetConverter.exe

YamlDotNet.dll by Antoine Aubry et al. retains ver 0.0.1.0

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


ps. woohoo got  through Stoddard's auto-builder for Mono (this was by no means certain...)

Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on September 29, 2019, 12:46:53 pm
Hello!
Thank you for your efforts in MapView.
I managed (with lots of efforts) to run it on Linux (Linux Mint 19.2, Mono 6.6.0 Preview).

I wish to warn you, though, that the Mono-ready builds won't work on me, for a strange reason: my output is:
on terminal
Quote
WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v4.0.30319

followed by a "oop exception"
Quote
System.ArgumentNullException: Value cannot be null.
Parameter name: path
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x00014] in <9535effa99f042c5a94ca386690497e6>:0
  at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <9535effa99f042c5a94ca386690497e6>:0
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at System.IO.File.Open (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <9535effa99f042c5a94ca386690497e6>:0
  at XCom.LogFile.WriteLine (System.String line) [0x00001] in <7d46fe1e90db48a1b282fb30c553e539>:0
  at MapView.XCMainWindow..ctor () [0x00036] in <2b76cbc6c63f42d294898d08a5ee383e>:0
  at (wrapper remoting-invoke-with-check) MapView.XCMainWindow..ctor()
  at MapView.Startup.RunProgram () [0x0001e] in <2b76cbc6c63f42d294898d08a5ee383e>:0

But, if I compile my build from sources, with .NET 4.5.1 as target framework, it works well. Can't figure why...

Well, time to discover it and to enter in the world of xcom modders. Thanks again!
Title: Re: MAPVIEW upgrade
Post by: kevL on September 29, 2019, 09:20:27 pm
thanks for the report,

the Mono builds are Stoddard's baby but unfortunately I haven't seen him post for a couple months. It looks like a problem with creating/opening the "debug.log" file, which is enabled by preprocessor directive "DEBUG" in DSShared/LogFile.cs ... which, uh, should not be happening ... Ah, on the last release i moved LogFile from XCom to DSShared (for increased visibility); there might be some lingering, persistent reference to the old namespace somehow.

will keep my eyes open and good luck with the app,
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on September 30, 2019, 10:25:30 pm
Hi, thank you for your answer.
In the end I switched the entire OpenXcom modding environment in a Windows 7 virtual machine, due to a ton of sudden crashes, the sudden death of Monodevelop (something about the number of generic arguments provided doesn't equal the arity of the generic type definition, but this even on new projects), and VS Code for Linux supporting only .NET Core 3.0

(I wonder, is it really necessary to build this tool on so high .NET framework SDKs?)

Anyway, I wish to flag you this:
even if my TFTD folder is correct, looks like it still searches in the UFO directory for the TFTD resources, can you check about?
Thank you!
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 12:57:52 am
heya,

In the end I switched the entire OpenXcom modding environment in a Windows 7 virtual machine, due to a ton of sudden crashes, the sudden death of Monodevelop (something about the number of generic arguments provided doesn't equal the arity of the generic type definition, but this even on new projects), and VS Code for Linux supporting only .NET Core 3.0

that's too bad ... this project needs a dedicated Linux/Mono developer ... unfortunately it's not something I'm interested in or have the time for at present

Quote
(I wonder, is it really necessary to build this tool on so high .NET framework SDKs?)

I was happy w/ 3.5 but was informed that Monodevelop (or similar?) wanted something around 4.5+ ... I had/have 4.5.1 installed and just went with it.

Quote
even if my TFTD folder is correct, looks like it still searches in the UFO directory for the TFTD resources, can you check about?

Can you give specific details? Eg, steps to reproduce, what specific resource borks up ... resource paths are cached by the constructor (https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainView/MainViewF.cs#L365) and at that point it looks okay. Also, have a glance at your settings/MapResources.yml file, it should look similar to this:

Code: [Select]
ufo: C:\basepath_of_UFO
tftd: C:\basepath_of_TFTD
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 01, 2019, 07:26:58 pm

Can you give specific details? Eg, steps to reproduce, what specific resource borks up ... resource paths are cached by the constructor (https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainView/MainViewF.cs#L365) and at that point it looks okay. Also, have a glance at your settings/MapResources.yml file, it should look similar to this:

Code: [Select]
ufo: C:\basepath_of_UFO
tftd: C:\basepath_of_TFTD

Without seeing yet the code (I am installing VS Community hoping it will work...)...

Even if paths are corrected, looks like TFTD resources are still searched in UFO directory, and not in TFTD.
UFO resources instead appear corrected.

Later (in this period I have to run everywhere!) I'm going to have a look to try to see what could be the issue...

ADD: was forgetting... my output of MapResources.yml appears to be correct:
Code: [Select]
ufo: C:\Users\vbox\Downloads\OpenXcom\bin\UFO
tftd: C:\Users\vbox\Downloads\OpenXcom\bin\TFTD
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 08:30:04 pm
yep. Looking ...

note I don't have TFTD so i'll set up a mock Tftd installation for debugging. While that should be enough to figure out what's going on, if you want to pursue this on your end also (barring RL ofc) that could well be a good thing.


[note that the logfile works in Debug only, and ought write itself to the executable's dir]
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 01, 2019, 09:10:34 pm
Well, maybe I discovered something.
Using Debug in VS Community and breaking the execution, I see this:

descriptor.cs, line 94
Code: [Select]
if (path == GlobalsXC.BASEPATH) // use this Tileset's basepath
return Path.Combine(Basepath, GlobalsXC.TerrainDir);

Looks like this is never true, so the path variable is always set to UFO\... rather than TFTD\

So, either the issue is there or something related, OR it is about that basepath missing from MapTilesets.yml (and yes, I tried to rebuild them).
The issue is I have still to learn how these files work. My C# skill is very little (tbh, all of coding skills), but I will write if I find something.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 09:22:21 pm
MapTilesets does not store a basepath if the basepath of a tileset is the same as the basepath set by the Configurator.

ie, if a tileset does not have a basepath in the YAML file, it is (or should be) using the basepath that was set by the Configurator,


ps. am about to look into descriptor line 94
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 09:41:27 pm
oh, Descriptor.GetTerrainDirectory(string) is for getting the path to alternate TERRAIN dirs

That is, a terrain can be taken from any directory (as long as it's called TERRAIN) and it can be different from the Map's basepath. So, in MapTilesets.yml a terrain can be specified in one of three ways:

Code: [Select]
    terrains:
      - U_EXT02 # use the TERRAIN dir under the Configurator's basepath
Code: [Select]
    terrains:
      - U_EXT02: basepath # use the TERRAIN dir under the Map's basepath
Code: [Select]
    terrains:
      - U_EXT02: C:\MyTerrains # use the TERRAIN dir under "MyTerrains"

the codeblock you quoted above happens in the 2nd case

It looks okay atm, i think the bug happens higher in the chain ... I'm going to search for instances of SharedSpace.ResourceDirectoryUfo and SharedSpace.ResourceDirectoryTftd ... see if i can spot where one of them doesn't make sense,
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 11:10:51 pm
I found some issues, daedalus. Don't bust yer head over it, it's a complicated issue. i'll start punching away at it ...

i might want for a true TFTD Map/Routes + terrains but i'll just work with a mockup for now (or I might even have some TFTD tilesets kicking around..), Basically it seems that the TileGroupManager.LoadTileGroups(string) isn't differentiating between UFO and TFTD.
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 01, 2019, 11:36:31 pm
I found some issues, daedalus. Don't bust yer head over it, it's a complicated issue. i'll start punching away at it ...

i might want for a true TFTD Map/Routes + terrains but i'll just work with a mockup for now (or I might even have some TFTD tilesets kicking around..), Basically it seems that the TileGroupManager.LoadTileGroups(string) isn't differentiating between UFO and TFTD.

Yes, reading at your explaination about basepath I started to ask myself "will the - U_EXT02: C:\MyTerrains # use the TERRAIN dir under "MyTerrains" return true sometimes or does it suffer from the same issue? In the last case is not only about TFTD but for every resource in another folder that is not UFO"... and then I started to panic thinking about a complete overhaul of the function  ;D

Waiting for your solution, then :)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 01, 2019, 11:55:53 pm
... and then I started to panic thinking about a complete overhaul of the function  ;D

lol, terrains are not pretty
Code: [Select]
    // get the Terrains of the tileset ->
    terrainset = new Dictionary<int, Tuple<string,string>>();


EDIT: will ya look at that (https://github.com/kevL/OpenXCOM.Tools/blob/master/XCom/Descriptor/TileGroup.cs#L65) -- that's a typo and a half ...

setting Pal outside the braces ... an oddity of the current code is that originally (MapViewI) it used Palette to determine if the gametype is UFO or TFTD. I've been gradually replacing that with an explicit Group/GameType variable. But somethings still rely on Palette, and that typo is effectively setting any GroupTypes (that rely on Palette to be correct) to GameType.Ufo ....

I'll poke around looking for any other self-inflicted shenanigans, but am pretty sure that's the major issue atm.

(screenshot) that's more like it ...


EDIT: yep that fixed it. But it brought a few other things to my attention that should be put in ...

@daedalus in the meantime, If you're building your own, just move that lower brace to below "Pal = Palette.UfoBattle;" and that ought get TFTD-editing up and running.
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 02, 2019, 09:16:28 am

@daedalus in the meantime, If you're building your own, just move that lower brace to below "Pal = Palette.UfoBattle;" and that ought get TFTD-editing up and running.

Ok, will do and put myself in /mode betatester == true ;)

ADD: at a glance, there are some issues with various TFTD maps, mostly about invalid routes or MCD entries but I guess these are part of the other things you are looking at
Title: Re: MAPVIEW upgrade
Post by: kevL on October 02, 2019, 10:23:31 am
tftd resources have issues, yes. Read: they're buggy even if they don't seem bugged while playing TFTD.

MapViewII simply points out any issues it recognizes but it's up to you to fix them if you want .... (make backups of all your resources first of course, or even set up a "scratch" directory for working on tilesets -- the CHM helpfile has things to say about stuff like that)

>I guess these are part of the other things you are looking at

nope i'm actually dealing with error messages about failing to load the CURSOR sprites (the targeter) and i want to change the Palette-variable to a Game-type variable (the one that caused the UFO vs TFTD bug). But if you notice behaviors of Mv2 that could be better, don't hesitate to mention them here
Title: Re: MAPVIEW upgrade
Post by: Meridian on October 02, 2019, 10:51:32 am
ADD: at a glance, there are some issues with various TFTD maps, mostly about invalid routes or MCD entries but I guess these are part of the other things you are looking at

Buggy TFTD resources are usually fixed directly inside of OpenXcom, either via MCDPatches ruleset, or via consistency checks and removal of faulty data (e.g. invalid routes/nodes). Some fixes are also in the universal patch as a separate download.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 03, 2019, 06:03:16 am
2019 October 2

MapView
- show error if configuration files failed to create.
- handle any errors while loading the UFO/TFTD targeters (CURSOR.PCK+TAB) better.
- force-quit if a targeter-sprite does not get loaded.
- use an explicit Descriptor.GroupType variable instead of current palette to determine whether a tileset is for UFO or TFTD.

PckView
- if a PCK vs TAB mismatched count error occurs print the counts in the error that pops.
- if a sprite-overflow happens don't assume that a Bigobs sprite was trying to load into a terrain/unit spriteset (just show a generic error).
- reset titlebar text if a spriteset fails to load (that is, don't assume that a spriteset will load when setting the titlebar text).

XCom
- set the GroupType (aka. GameType: UFO/TFTD) in the Descriptor of each tileset.
- fixed a bad typo that caused all tilesets to use the UFO battle-palette; this made editing TFTD tilesets problematic at best, since it also affected which terrains were trying to be accessed. Fixed ...
- slight refactor of TileGroup loading (based on above fix).
- use a bitwise int to store spritesets' failure-to-instantiate status, instead of three booleans.
- add spriteset fail-state: Taboffset overflow condition.

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


ps. Thanks osd_daedalus
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 03, 2019, 07:27:50 pm

ps. Thanks osd_daedalus

oh no, I have to thank you for your efforts on this project.
I wish to know enough coding to be much helpful...

Anyway, to return to the topic "Mapview on Linux":

even if my Monodevelop died for unknown reason, it is possible to compile as per these instructions:
https://medium.com/@hudsonmendes/build-net-4-5-on-linux-in-5-minutes-and-see-what-it-is-like-848ea45fc667

Which is, to be brief:
Code: [Select]
$ sudo apt-get install -y nuget mono-devel mono-xbuild
$ xbuild MapView.sln
(it builds in bin/Debug)

Then it works to me with mono Mapview.exe. Just remember to go immediately to Options and then set "Use Mono" to "true"


Of course, don't expect Mono to work like .NET... this can happen if you add a tile via Topview:
Code: [Select]
double free or corruption (fasttop)

=================================================================
Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

=================================================================
Native stacktrace:
=================================================================
0x5648b7509e15 - mono : (null)
0x5648b750a1ac - mono : (null)
0x5648b74b6741 - mono : (null)
0x5648b7509422 - mono : (null)
0x7f233b9d3890 - /lib/x86_64-linux-gnu/libpthread.so.0 : (null)
0x7f233accfe97 - /lib/x86_64-linux-gnu/libc.so.6 : gsignal
0x7f233acd1801 - /lib/x86_64-linux-gnu/libc.so.6 : abort
0x7f233ad1a897 - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7f233ad2190a - /lib/x86_64-linux-gnu/libc.so.6 : (null)
0x7f233ad29004 - /lib/x86_64-linux-gnu/libc.so.6 : cfree
0x7f233699d016 - /usr/lib/libgdiplus.so.0 : GdipDeleteRegion
0x41779f63 - Unknown

=================================================================
Telemetry Dumper:
=================================================================
Pkilling 0x7f2328709700 from 0x7f2328508700
* Assertion: should not be reached at threads.c:6254
Pkilling 0x7f2337ea5700 from 0x7f2328508700
Pkilling 0x7f233c1d2780 from 0x7f2328508700
Pkilling 0x7f231bfff700 from 0x7f2328508700
Pkilling 0x7f232890a700 from 0x7f2328508700
Pkilling 0x7f231bdfe700 from 0x7f2328508700
Pkilling 0x7f2328307700 from 0x7f2328508700
Entering thread summarizer pause from 0x7f2328508700
Finished thread summarizer pause from 0x7f2328508700.

Waiting for dumping threads to resume

=================================================================
External Debugger Dump:
=================================================================
[New LWP 17606]
[New LWP 17607]
[New LWP 17967]
[New LWP 17968]
[New LWP 17969]
[New LWP 17970]
[New LWP 17971]
[New LWP 17972]
Mono support loaded.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: File o directory non esistente.
  Id   Target Id         Frame
* 1    Thread 0x7f233c1d2780 (LWP 17605) "mono" __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
  2    Thread 0x7f233a3ff700 (LWP 17606) "SGen worker" 0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b7aea0a8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  3    Thread 0x7f2337ea5700 (LWP 17607) "Finalizer" 0x00007f233b9d16d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5648b7adb2c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  4    Thread 0x7f232890a700 (LWP 17967) "Timer-Scheduler" 0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b8b1d5e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
  5    Thread 0x7f2328709700 (LWP 17968) "Timer-Scheduler" 0x00007f233b9ceed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f2328708bc0, expected=0, futex_word=0x5648b7aeab68) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
  6    Thread 0x7f2328508700 (LWP 17969) "Thread Pool Wor" 0x00007f233b9d323a in __waitpid (pid=17978, stat_loc=0x7f2328505fd4, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  7    Thread 0x7f2328307700 (LWP 17970) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f2328306d50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  8    Thread 0x7f231bfff700 (LWP 17971) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bffed50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  9    Thread 0x7f231bdfe700 (LWP 17972) "Thread Pool Wor" 0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bdfdd50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205

Thread 9 (Thread 0x7f231bdfe700 (LWP 17972)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bdfdd50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f231bdfdd50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f231bdfdd50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f231bdfe700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 8 (Thread 0x7f231bfff700 (LWP 17971)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f231bffed50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f231bffed50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f231bffed50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f231bfff700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7f2328307700 (LWP 17970)):
#0  0x00007f233b9d18c2 in futex_abstimed_wait_cancelable (private=0, abstime=0x7f2328306d50, expected=0, futex_word=0x5648b7adbc08) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d18c2 in do_futex_wait (sem=sem@entry=0x5648b7adbc08, abstime=abstime@entry=0x7f2328306d50) at sem_waitcommon.c:111
#2  0x00007f233b9d19d3 in __new_sem_wait_slow (sem=0x5648b7adbc08, abstime=0x7f2328306d50) at sem_waitcommon.c:181
#3  0x00005648b770b705 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f2328307700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 6 (Thread 0x7f2328508700 (LWP 17969)):
#0  0x00007f233b9d323a in __waitpid (pid=17978, stat_loc=0x7f2328505fd4, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x00005648b750a125 in  ()
#2  0x00005648b750a1ac in  ()
#3  0x00005648b74b6741 in  ()
#4  0x00005648b7509422 in  ()
#5  0x00007f233b9d3890 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f233accfe97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7  0x00007f233acd1801 in __GI_abort () at abort.c:79
#8  0x00007f233ad1a897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f233ae47b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#9  0x00007f233ad2190a in malloc_printerr (str=str@entry=0x7f233ae49828 "double free or corruption (fasttop)") at malloc.c:5350
#10 0x00007f233ad29004 in _int_free (have_lock=0, p=0x5648b9adbdf0, av=0x7f233b07cc40 <main_arena>) at malloc.c:4230
#11 0x00007f233ad29004 in __GI___libc_free (mem=0x5648b9adbe00) at malloc.c:3124
#12 0x00007f233699d016 in GdipDeleteRegion () at /usr/lib/libgdiplus.so.0
#13 0x0000000041779f63 in  ()
#14 0x00007f2328a92070 in  ()
#15 0x00007f2328d16830 in  ()
#16 0x0000000000000000 in  ()

Thread 5 (Thread 0x7f2328709700 (LWP 17968)):
#0  0x00007f233b9ceed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f2328708bc0, expected=0, futex_word=0x5648b7aeab68) at ../sysdeps/unix/sysv/linux/futex-internal.h:142
#1  0x00007f233b9ceed9 in __pthread_cond_wait_common (abstime=0x7f2328708c60, mutex=0x5648b7aeab80, cond=0x5648b7aeab40) at pthread_cond_wait.c:533
#2  0x00007f233b9ceed9 in __pthread_cond_timedwait (cond=0x5648b7aeab40, mutex=0x5648b7aeab80, abstime=0x7f2328708c60) at pthread_cond_wait.c:667
#3  0x00005648b776304b in  ()
#4  0x00005648b776dfb8 in  ()
#5  0x00005648b770ae52 in  ()
#6  0x00005648b76a9ceb in  ()
#7  0x00007f233b9c86db in start_thread (arg=0x7f2328709700) at pthread_create.c:463
#8  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 4 (Thread 0x7f232890a700 (LWP 17967)):
#0  0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b8b1d5e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x00007f233b9ce9f3 in __pthread_cond_wait_common (abstime=0x0, mutex=0x5648b8b1d598, cond=0x5648b8b1d5c0) at pthread_cond_wait.c:502
#2  0x00007f233b9ce9f3 in __pthread_cond_wait (cond=0x5648b8b1d5c0, mutex=0x5648b8b1d598) at pthread_cond_wait.c:655
#3  0x00005648b77630ad in  ()
#4  0x00005648b76c070c in  ()
#5  0x00005648b76c1d5f in  ()
#6  0x00005648b76c2450 in  ()
#7  0x00005648b76a671d in  ()
#8  0x00005648b763a440 in  ()
#9  0x00000000418b83af in  ()
#10 0x00007f233a7504e0 in  ()
#11 0x00007f233a7506b0 in  ()
#12 0x00007f233a750410 in  ()
#13 0x0000000000000000 in  ()

Thread 3 (Thread 0x7f2337ea5700 (LWP 17607)):
#0  0x00007f233b9d16d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x5648b7adb2c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  0x00007f233b9d16d6 in do_futex_wait (sem=sem@entry=0x5648b7adb2c0, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007f233b9d17c8 in __new_sem_wait_slow (sem=0x5648b7adb2c0, abstime=0x0) at sem_waitcommon.c:181
#3  0x00005648b76f5858 in  ()
#4  0x00005648b76a9ceb in  ()
#5  0x00007f233b9c86db in start_thread (arg=0x7f2337ea5700) at pthread_create.c:463
#6  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f233a3ff700 (LWP 17606)):
#0  0x00007f233b9ce9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x5648b7aea0a8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x00007f233b9ce9f3 in __pthread_cond_wait_common (abstime=0x0, mutex=0x5648b7aea0c0, cond=0x5648b7aea080) at pthread_cond_wait.c:502
#2  0x00007f233b9ce9f3 in __pthread_cond_wait (cond=0x5648b7aea080, mutex=0x5648b7aea0c0) at pthread_cond_wait.c:655
#3  0x00005648b775335a in  ()
#4  0x00007f233b9c86db in start_thread (arg=0x7f233a3ff700) at pthread_create.c:463
#5  0x00007f233adb288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f233c1d2780 (LWP 17605)):
#0  0x00007f233adc16ac in __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007f233ad2b352 in __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3407
#2  0x00005648b777870b in monoeg_g_calloc ()
#3  0x00005648b77757a5 in monoeg_g_hash_table_new ()
#4  0x00005648b75f44c7 in  ()
#5  0x00005648b75f5230 in mono_class_load_from_name ()
#6  0x00005648b7610287 in  ()
#7  0x00005648b761041d in mono_exception_from_name_domain ()
#8  0x00005648b74b8113 in  ()
#9  0x00005648b7503662 in  ()
#10 0x00007f233ad253c1 in _int_malloc (av=0x7f233b07cc40 <main_arena>, bytes=0) at malloc.c:3612
#11 0xffffffffffff00ff in  ()
#12 0xffffffffffffffff in  ()
#13 0x0000000000000000 in  ()

=================================================================
Basic Fault Address Reporting
=================================================================
Memory around native instruction pointer (0x7f233accfe97):0x7f233accfe87  d2 4c 89 ce bf 02 00 00 00 b8 0e 00 00 00 0f 05  .L..............
0x7f233accfe97  48 8b 8c 24 08 01 00 00 64 48 33 0c 25 28 00 00  H..$....dH3.%(..
0x7f233accfea7  00 44 89 c0 75 1f 48 81 c4 18 01 00 00 c3 0f 1f  .D..u.H.........
0x7f233accfeb7  00 48 8b 15 a9 bf 3a 00 f7 d8 41 b8 ff ff ff ff  .H....:...A.....

=================================================================
Managed Stacktrace:
=================================================================
  at <unknown> <0xffffffff>
  at System.Drawing.GDIPlus:GdipDeleteRegion <0x000a2>
  at System.Drawing.Region:DisposeHandle <0x0004b>
  at System.Drawing.Region:Dispose <0x0002b>
  at System.Drawing.Region:Dispose <0x00073>
  at DoubleBuffer:Invalidate <0x0003b>
  at System.Windows.Forms.Control:InvalidateBackBuffer <0x00043>
  at System.Windows.Forms.Control:OnInvalidated <0x000cb>
  at System.Windows.Forms.Control:Invalidate <0x004da>
  at System.Windows.Forms.Control:Invalidate <0x00047>
  at MapView.Forms.MainView.MainViewOverlay:InvalidateObservers <0x0004b>
  at MapView.Forms.MainView.MainViewOverlay:FillSelectedQuads <0x0024b>
  at MapView.Forms.MainView.MainViewOverlay:FillSelectedQuads <0x00073>
  at MapView.Forms.Observers.QuadrantPanel:OnClicksElapsed <0x00063>
  at System.Timers.Timer:MyTimerCallback <0x0017a>
  at Scheduler:TimerCB <0x00133>

Just for the records... as I set up a VM for openxcom development :)
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 03, 2019, 09:48:03 pm

Just for the records... as I set up a VM for openxcom development :)

Erm... looks like not really true. Can you try to do this?

- open MapView
- load UFO_110
- go in TileView, select a tile
- go in Topview, rightclick somewhere to add that tile

In VSCommunity I got "unhandled exception" on TileView.cs, line 675. Check also my screenshot
Roughly translating from Italian according to the screenshot, it is saying Cross-thread operation invalid: the control access 'tcTileTypes' was executed from a thread different from the one which created it

Looks like I blamed Mono too early  :o
Title: Re: MAPVIEW upgrade
Post by: kevL on October 03, 2019, 10:38:39 pm
i just downloaded w/ fresh install, and unfortunately can't reproduce ...

notes:
- Mv2 is not multi-threaded
- my OS is Windows7 Pro SP1 64-bit
- right-clicks on TopView use a special algorithm to determine if it's a single or double click: a click is registered in mapview but delayed for the duration of the operating system's SystemInformation.DoubleClickTime (this design prevents the app from first doing a single right-click operation [place tilepart] followed by a double right-click operation [clear tilepart] in succession when double right-clicking, and you can notice this even on a single right-click -- there's a slight delay, which ought be the duration of your system's DoubleClickTime)

My guess at present is that a Windows VM doesn't handle that well,


i guess I could take it out (it's merely cosmetic), or put in a user-option (like "UseMono") to flag a bypass ....




EDIT: a workaround could/should be to use keyboard shortcuts instead of RMB clicks.

a) to place a part, select a tile as usual, select a tilepart as usual, and press [Enter] with TopView having focus. (Be careful to have the correct quadrant-type selected, since the part will be placed in the currently selected quad-panel.)
b) to clear a part, select a tile as usual, select a quadrant as usual, and press [Shift+Delete] with TopView having focus. (Note that pressing [Delete] clears all parts from the selected tile, while [Shift+Delete] clears only the selected quadrant's part from the tile.)

"quadrant" means "tilepart typeslot" but its easier to write "quadrant" or just "quad" instead ... y'll get the hang of it ;)
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 04, 2019, 12:38:55 am
So...

I booted to Windows 10 (native), installed VS Community, made same steps, and got same exception.

The issue won't happen, though, if I run the program as Release, rather than Debug.

In Debug, using ENTER instead of RMB click won't throw exception and works faster.

So...
- the issue is confirmed, and not an issue with my VM.
- Though, the program still goes on, the issue just manifests itself as a delay (when running Release)
- looks like then related to mouse button detection algorithm as you explained.

Quote
i guess I could take it out (it's merely cosmetic), or put in a user-option (like "UseMono") to flag a bypass ....

You decide :)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 04, 2019, 01:55:05 am
hm. I can't get it to throw in Debug on win7 ... :\

out of curiosity, since i'll likely put an option in, is there an issue (or not) with a Win10 Release build? these two seem to contradict ...

The issue won't happen, though, if I run the program as Release, rather than Debug.
Quote
- Though, the program still goes on, the issue just manifests itself as a delay (when running Release)

remember there is a short delay by design [SystemInformation.DoubleClickTime]. Are you saying that there is a longer delay, like the OS stalls for a second or two?

I'm trying to understand if this is an issue only in Debug builds,


EDIT:  Here's a commit to master
https://github.com/kevL/OpenXCOM.Tools/commit/4f0d8b6abdd51339bc4408dba54bb4db2075af1f

TopView Option: EnableRightClickWaitTimer (default false)
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 04, 2019, 06:25:05 pm
Hi,

hm. I can't get it to throw in Debug on win7 ... :\

out of curiosity, since i'll likely put an option in, is there an issue (or not) with a Win10 Release build? these two seem to contradict ...

remember there is a short delay by design [SystemInformation.DoubleClickTime]. Are you saying that there is a longer delay, like the OS stalls for a second or two?


To be sure, I waited to pull the latest commit and tested what I reported in these conditions: (placing a tile from Topview with right mouse button)

- Windows 10 native, opening Debug\MapView.exe from file explorer: just the short delay, the tile is placed.
- Windows 7 SP1 X64 from VM, opening Debug\MapView.exe from the file explorer:  just the short delay, the tile is placed

Same conditions of course if you run Release\Mapview.exe.

- Windows 10 native, running "run without executing debug" debug from IDE (VS 2019)  just the short delay, the tile is placed
- Windows 7 SP1 X64 from VM, running "run without executing debug" debug from IDE (VS 2019) just the short delay, the tile is placed

- Windows 10 native, running "run debug" debug from IDE: (VS 2019)  the exception is thrown, application won't crash, you can click "continue" two times, the tile is not placed, but the application is still running.
- Windows 7 SP1 X64 from VM, running "run debug" debug from IDE: (VS 2019)  the exception is thrown, application won't crash, you can click "continue" two times, the tile is not placed, but the application is still running.



Looks like is VS2019 debugging being quite picky, could explain the crash I get in Mono doing same thing.
I'm going to test with Mono if I manage to make my Monodevelop in a working condition, then I gladly test on your latest commit.

Hold on...

ADD 1 : for unknown reason, Monodevelop worked again.

- Linux Mint 18.2, Monodevelop 7.8.4, run debug: that's strange... it placed normally a tile, then I did on adjacent tile and the entire application got frozen, Monodevelop does not return a call stack. Could not close from Monodevelop: I had to xkill it.
- Linux Mint 18.2, Monodevelop 7.8.4, run "without debug": I placed various tiles until the application closed itself.

This is valid either if I run the Debug or the Release version: by pressing ENTER I can put all of tiles I want: with RMB the app will crash at a certain time.

If I use Mono outside Monodevelop, at the crash it returns that stacktrace I posted some posts above.


OK, I'm trying now with latest commit...

ADD 2: Basically, now RMB behaves like pressing ENTER: in all of combinations I can put all of tiles I want.
If I set EnableRightClickWaitTimer to true I have the issues as reported above.


In conclusion:

This issue exists, but affects mainly Linux/Mono users, and it is revealed only by Visual Studio 2019.

I don't know how much difficult would be to fix it, but your idea to opt-in the mouse delay is just simple as smart  ;D
Moreover, it made Mono builds much stable.
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 04, 2019, 09:06:45 pm
Ok, now we have (or better, you have) settled this, here's a purely cosmetic thing...

Could we have the UseMono also for TopView and TileView? So we can avoid all of those black backgrounds...

And... yes I tried to implement some if(UseMono) but the classes which contain it are internal sealed or private readonly and so can't use same classes from PckView-TopView-etc. I don't want to make a disaster with classes inheritance just for this :)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 04, 2019, 10:34:52 pm
excellent ...

Same conditions of course if you run Release\Mapview.exe.

great ...

Quote
Looks like is VS2019 debugging being quite picky,

grr...

( note i use SharpDevelop, not VS -- I'm a fan of lightweight apps that do the job, although #develop has been discontinued )

Quote
it made Mono builds much stable.

sounds about as good as it's going to get at present.

Ok, now we have (or better, you have) settled this, here's a purely cosmetic thing...

Could we have the UseMono also for TopView and TileView? So we can avoid all of those black backgrounds...

And... yes I tried to implement some if(UseMono) but the classes which contain it are internal sealed or private readonly and so can't use same classes from PckView-TopView-etc. I don't want to make a disaster with classes inheritance just for this :)

black backgrounds? i had't heard about that yet

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so

Code: [Select]
    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView (https://github.com/kevL/OpenXCOM.Tools/blob/master/PckView/PckViewForm.cs#L227). The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while :) But if you need a hint or tip on mapview's inner workings just ask,


ps. Monodevelop, I'm guessing, doesn't like getting SystemInformation.DoubleClickTime for whatever reason ... (it is a windows-specific setting but regardless i'm guessing that Linux and Mac have a very similar system-setting that Mono could replace it with)
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 05, 2019, 12:32:10 am


black backgrounds? i had't heard about that yet


check the screenshot attached :)
The top windows are on Windows, the bottom ones on Linux with Mono.

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so


Code: [Select]
    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView (https://github.com/kevL/OpenXCOM.Tools/blob/master/PckView/PckViewForm.cs#L227). The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while :) But if you need a hint or tip on mapview's inner workings just ask,


I can't guarantee, but I'll gladly attempt to work on it :)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2019, 01:35:01 am
i uh, I couldn't wish that on my ex-girlfriends JUST KIDDING

seriously, i was thinking it was just some BackColors that were black ... but those sprites need to be drawn with a custom algorithm. it's been fixed in MainView already (the app was basically unusable in Mono with black rectangles all over) -- since I know how to do i'll rig it up fairly quickly,



EDIT
hopefully the latest commit (https://github.com/kevL/OpenXCOM.Tools/commit/fd74c608e82706ae4fdb9684d46548bf758a4948) will take care of those black backgrounds

as you see it's fairly complicated, or at least nontrivial ...

If you want to see what the fix is at its core, have a look at MapView.CuboidSprite (https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/CuboidSprite.cs) -- functions with "Rembrandt" are regular .net draw routines, those with "Picasso" implement the transparency workaround. In short, pixels that are transparent aren't drawn; the binary data (byte arrays) of each sprite is iterated over, checking for non-zero/non-transparent color-ids

drawing to MainView has to scale each sprite, but the sprites in TileView and TopView are 1:1

I took the opportunity to consolidate redundant code in TopView's Quadrant panel also ...

i didn't test it thoroughly, so please check it (esp. in Mono w/ "UseMono" true),

and if by chance you want to see the full glory, so to speak, of the workaround have a look at MainViewOverlay.OnPaint() (https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainView/MainViewPanel/MainViewOverlay.cs#L1011) -- but don't get confused by #LOCKBITS, since that's purely experimental, non-functional code
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2019, 07:39:32 am
@daedalus

If you want something to try your hand at, try docking TopView's toolstrip to the top of its container if Mono (cf. screenshot)
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 05, 2019, 12:08:55 pm
Hi,

well... was much difficult than I expected... I looked at Rembrandt() and Picasso(), but I have thought it was just a matter of interpolation.

Going to testing: now Mono builds behave liks Windows builds. Well done!

Maybe I could manage to dock that toolstrip, and find a better Copy icon, it is so blended with the background it's almost transparent!
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2019, 10:10:55 pm
now Mono builds behave liks Windows builds

alrightie. Perhaps we've got decently functioning code on Mono (built natively )

Quote
Maybe I could manage to dock that toolstrip,

first just drag& drop the toolstrip to the top while running Mapview. In windows, those toolstrips can be repositioned to any of the four sides, and they line the icons either vertically (on the left or right) or horizontally (if on top or bottom, of the panel). There should be a handle at the very left (or top) end of the toolstrip ... the toolstrip should snap into place when moved.

I'm wondering/hoping that Mono positions them better along the top of the panel

Quote
and find a better Copy icon, it is so blended with the background it's almost transparent!

y, i notice that also. I think it's just a matter of increasing contrast/saturation (but haven't gotten around to it yet). I like the icons themselves tho .....
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 06, 2019, 12:18:35 pm

first just drag& drop the toolstrip to the top while running Mapview.

Looks like "that" is the issue...

https://stackoverflow.com/questions/4986087/does-not-move-toolstrip
 
Although very old, I checked and looks like still true: you cannot drag&drop toolstrips in Mono.

So... nothing to do that way. I'm going to look for another workaround...
Title: Re: MAPVIEW upgrade
Post by: kevL on October 06, 2019, 12:45:50 pm
hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]
    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 06, 2019, 04:09:36 pm
hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]
    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 06, 2019, 11:09:45 pm
That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

good idea (see screenshot)

but that would take a while, so for now ->
https://github.com/kevL/OpenXCOM.Tools/commit/57dadca3ff3a0ae5e1f39b0e6b4cafebe36e0e85

Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 07, 2019, 07:30:08 pm
That looks like... different from your screenshot.
Looks like good!

Title: Re: MAPVIEW upgrade
Post by: kevL on October 07, 2019, 10:04:58 pm
freaky. All i did was add the toolstrip in the cTor instead of in designer's InitializeComponent()

looks like a bingo ...




must resist urge to delete Windows™


Can I ask you a question... did you have

Code: [Select]
//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file
Title: Re: MAPVIEW upgrade
Post by: osd_daedalus on October 07, 2019, 11:58:35 pm

must resist urge to delete Windows™

Just make a dual boot Windows/Linux. Or install Virtualbox and create a Linux virtual machine.
There is no real reason you have to trash Windows over Linux, but it's an experience I really suggest.

(and I had also a tri-boot Win/Linux/Hackintosh, but I deleted the latter)

Just... I wish there is a Windows.Forms designer working for Linux.


Can I ask you a question... did you have

Code: [Select]
//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file

Nope, just git-pull and built. Wonders of Mono trying to do .NET work!

Wait a sec... trying to do right now...

ADD: find in attachment what happens if I uncomment the #define. Eeeek! DELETE IT!!!
Title: Re: MAPVIEW upgrade
Post by: kevL on October 08, 2019, 12:27:32 am
why the bleep does it to that /rant

anyway, i deleted that #define and kept the line that adds the toolstrip to the left side of the container ... hopefully it's all good, if it still renders properly. Because the 'logic' of what just happened is absurd.


/committed to master branch
Title: Re: MAPVIEW upgrade
Post by: kevL on October 25, 2019, 04:52:54 pm
2019 October 24

- fixed PckView not starting. Thanks to luke83 for reporting and helping troubleshoot the probl.
- plus tweaks for Mono (if applicable). Thanks to osd_daedalus for reporting Mono issues and testing changes.

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md
Title: Re: MAPVIEW upgrade
Post by: kevL on November 16, 2019, 11:05:26 pm
2019 November 16

Tileslot Substitution [Ctrl+U] - opens a dialog box for replacing tileparts of a given setId with tileparts of a different setId across the currently loaded Map. Tileparts of a given setId can optionally be cleared from a Map.

thanks to Kato for the suggestion
Title: Re: MAPVIEW upgrade
Post by: Finnik on November 30, 2019, 08:38:53 pm
cant see an option to create new map? am i blind?
Title: Re: MAPVIEW upgrade
Post by: luke83 on November 30, 2019, 09:45:09 pm
I dont think it does yet ( if it does, i have never found it, but to be honest, i have not gone looking before today), you just edit it through the "MapTilesets.yml" file in your favourite Text Editor, you will find this in the Settings folder of Mapview2.

the Process is:
Manually duplicate your desired  .map file and .Rmp files, renames these to what ever you want
Open MapTilesets.ym
Edit the file to create your new map names

as you can see below, the format of the MapTilesets.ym is pretty straight forward:
Code: [Select]
#----- base XCOM --------------------------------------------------------------#
  - type: XBASE_00
    terrains:
      - XBASE1
      - XBASE2
    category: base XCOM
    group: ufoLandscapes
  - type: XBASE_01
    terrains:
      - XBASE1
      - XBASE2
    category: base XCOM
    group: ufoLandscapes
  - type: XBASE_02
    terrains:
      - XBASE1
      - XBASE2
    category: base XCOM
    group: ufoLandscapes
Title: Re: MAPVIEW upgrade
Post by: kevL on November 30, 2019, 11:35:58 pm
what luke says is correct, but MapviewII's design policy is that ->

left/right clicks on the MapTree should/ought handle all procedures ...

a) create and/or select a Group->Category in the tree
b) select the Category you want to create the tileset (aka Map) in
c) right-click -> add Tileset ...
d) check the displayed Basepath (change it if you want to), type in a Map label (aka filename w/out extension)*, click "create"
e) add some terrains since Maps without terrains won't be saved, iirc.

ACCEPT the TilesetEditor and a fresh blank 10x10 tileset should appear


* or browse to an existing Map's file if you want to add one that already exists on your hardrive
Title: Re: MAPVIEW upgrade
Post by: Finnik on January 07, 2020, 02:14:38 am
is there a option to duplicate maps? im making a set of very similar maps and id like to see some option in UI like that
Title: Re: MAPVIEW upgrade
Post by: kevL on January 07, 2020, 04:05:45 am
is there a option to duplicate maps? im making a set of very similar maps and id like to see some option in UI like that

hm. good idea

not available at present though. @luke83 or others might have a finer answer, but I'd say go to your hardrive, MAPS and ROUTES directories, and copy the maps/routes you want over to new filenames ... then go back to MapView2 and set them up manually with the TilesetEditor

will put it on my TODO.


(note, there is a command to export/import routes in RouteView ...)
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 07, 2020, 07:53:19 am
I just manually copy the Maps and Routes to temp file, then use a Bulk Renaming Tool to change the names. In mapview, just open the Map Tileset.YML file, find the data you want and duplicate and rename there with your favourite Text Editor and your good to go.
Title: Re: MAPVIEW upgrade
Post by: Finnik on January 09, 2020, 05:27:29 pm
yeah, but it would be so nice to have a UI option to do that)
Title: Re: MAPVIEW upgrade
Post by: bulletdesigner on January 21, 2020, 12:11:47 pm
hello, i started using mapview 2 and it´s a better than mapview 1 on a lot of aspect , so thks for the upgrade.
Anyway i have a strange issue, on same maps the app crashes when taking a image, and i can´t figure out why, for example map_05 with the same MCDS of map_13 crashes and map_13 don´t and map_13 is even bigger
Title: Re: MAPVIEW upgrade
Post by: kevL on January 21, 2020, 06:33:16 pm
heya,

(i thought i fixed that...)

some things to try:
there are screenshot settings under MainView|Edit|Options|Screenshot
- BackgroundColor
- CropBackground
- Png_notGif

(esp. CropBackground and/or Png_notGif)

some questions:
what OS are you on?
how many levels of your Map are currently displayed when taking the screenshot? iirc, the previous bug happened when MainView was on its top level, ie taking a screenshot of all levels.


Could you send me a package w/ the .MAP and .RMP, plus the terrains? And steps to reproduce ...
Title: Re: MAPVIEW upgrade
Post by: bulletdesigner on January 21, 2020, 07:03:18 pm
well if you fixed, i download a long time ago, and started using now due to windows 10 i cant get the older mapview to work. Maybe i just need to update can you point out the latest update?
Title: Re: MAPVIEW upgrade
Post by: kevL on January 21, 2020, 07:41:13 pm
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

ps. there may have been some big changes since the version you have. I suggest backing up your old installation folder and reinstalling from scratch

(then copy in your MapTilesets.yml to /settings)

if you scroll down through the changelog on the linked page it has further info about this.
Title: Re: MAPVIEW upgrade
Post by: bulletdesigner on January 21, 2020, 08:38:26 pm
yap , its fixed now , thks
Title: Re: MAPVIEW upgrade
Post by: kevL on January 21, 2020, 09:03:32 pm
k, welcome
Title: [NEW request] Import from mod rule file
Post by: davide on January 26, 2020, 11:25:29 am
Hi Kevl,
i wish a new  import function in mapview to select a mod rule file and automatically load tilesets with ufo, terrain and craft maps (or 3 different actions to do it).

Code: [Select]
ufos:
  - type: STR_SURVEY_SHIP
    sprite: 1
    battlescapeTerrainData:
      name: UFO02
      mapDataSets:
        - BLANKS
        - UEXT2
        - UEXT3
        - UINT1
        - UINT2
        - UINT3
      mapBlocks:
        - name: UFO02
          width: 10
          length: 10
        - name: UFO02bl1
          width: 10
          length: 10
        - name: UFO02bl2
          width: 10
          length: 10
        - name: UFO02bl3
          width: 10
          length: 10
....

the rule file would enhance the maptilesets

Code: [Select]
#----- tftdShips --------------------------------------------------------------#
#----- USO --------------------------------------------------------------------#
  - type: UFO02
    terrains:
      - UEXT2
      - UEXT3
      - UINT1
      - UINT2
      - UINT3
    category: USO
    group: tftdShips_TWoTS
  - type: UFO02l1
    terrains:
      - UEXT2
      - UEXT3
      - UINT1
      - UINT2
      - UINT3
    category: USO
    group: tftdShips_TWoTS
...

When import a rule file you could create a new group name by path segment.
Title: Re: [NEW request] Import from mod rule file
Post by: kevL on January 26, 2020, 11:19:41 pm
noted, in my notes ...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 09, 2020, 07:30:16 pm
After some time spent with the new MapView, I must say I am really impressed with it. It runs smoothly, reliably and comfortably. Love all the new functions.

Having said that, I'd like two raise two issues - one which is actually serious and one small annoyance.

The serious one:

(https://i.imgur.com/1xlXUKa.png)

This position should be 0,0,0, but the editor shows 1,1,1. I understand it's a conscious decision, but for the life of me I cannot imagine any practical use for this. Map coordinates are coded starting with 0, so any time I want to define something by hand, I need to remember to subtract 0 from all the coords. This is really unwieldy and I can't see why I have to suffer this, since AFAIK there's no use for counting staring with 1.

The mild annoyance:

(https://i.imgur.com/UIksF4A.png)

Most of my terrains exceed 254 tiles by design. Thank you for the warning, but it's really unnecessary, and having to click this popup every time I open a map (which sometimes means several times per minute) is not my favourite thing about MapView. There are ways to check the number of tiles which do not involve annoying popups. Can I turn it off somehow?

These are minor complaints, but I guess every bit of feedback helps. Thank you for this marvellous project!
Title: Re: MAPVIEW upgrade
Post by: kevL on February 19, 2020, 07:35:22 am
hey Solar, sry been out of the loop for a bit


This position should be 0,0,0, but the editor shows 1,1,1. I understand it's a conscious decision, but for the life of me I cannot imagine any practical use for this. Map coordinates are coded starting with 0, so any time I want to define something by hand, I need to remember to subtract 0 from all the coords. This is really unwieldy and I can't see why I have to suffer this, since AFAIK there's no use for counting staring with 1.

i hear ya. Another member [you know who you are ;)] requested it, iirc. To me I'm kinda meh either way (programmers tend to think 0-based easier than 1-based). But i can see it as a problem given that you're mixing/matching Mv2 functionality w/ by-hand designs ...

Perhaps i should throw in an Option: 1-based counting (default 0-based)

I hope you can suffer it as is for now since i'm actually recovering from some pseudo-major surgery atm.

Quote
Most of my terrains exceed 254 tiles by design. Thank you for the warning, but it's really unnecessary, and having to click this popup every time I open a map (which sometimes means several times per minute) is not my favourite thing about MapView. There are ways to check the number of tiles which do not involve annoying popups. Can I turn it off somehow?

yes. Open the TilesetEditor for the current Map. near the bottom is a tickbox "bypass RecordsExceeded". Unfortunately it needs to be set for each Map that exceeds the terrain limit -- perhaps another Option is needed here: (global) ignore RecordsExceeded


Quote
These are minor complaints, but I guess every bit of feedback helps. Thank you for this marvellous project!

am glad. I'll put these near the top of my priority TODO list but again, need RnR for now,
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 19, 2020, 02:47:45 pm
hey Solar, sry been out of the loop for a bit

Hi KevL!


i hear ya. Another member [you know who you are ;)] requested it, iirc. To me I'm kinda meh either way (programmers tend to think 0-based easier than 1-based). But i can see it as a problem given that you're mixing/matching Mv2 functionality w/ by-hand designs ...

Perhaps i should throw in an Option: 1-based counting (default 0-based)

I hope you can suffer it as is for now since i'm actually recovering from some pseudo-major surgery atm.

Right, such an option would really help. Just to give you some perspective, these nunbers are used for:
- placing items
- placing unit spawns (well, technically also items)
- placing X-Com soldiers in custom deployments in the craft
- placing X-Com equipment pile in the craft
I probably missed something, but at least the first two points are kind of a big deal, because of how common they are. Whereas counting from 1 is, as I said before, quite useless.

yes. Open the TilesetEditor for the current Map. near the bottom is a tickbox "bypass RecordsExceeded". Unfortunately it needs to be set for each Map that exceeds the terrain limit -- perhaps another Option is needed here: (global) ignore RecordsExceeded

Yeah, I believe it would be necessary, since I don't think having to manually approve hundreds of maps makes sense. Please consider it.

am glad. I'll put these near the top of my priority TODO list but again, need RnR for now,

Sure. These are minor things anyway. Get well soon!
Title: Re: MAPVIEW upgrade
Post by: kevL on February 19, 2020, 11:15:51 pm
Right, such an option would really help. Just to give you some perspective, these nunbers are used for:
- placing items
- placing unit spawns (well, technically also items)
- placing X-Com soldiers in custom deployments in the craft
- placing X-Com equipment pile in the craft
I probably missed something, but at least the first two points are kind of a big deal, because of how common they are. Whereas counting from 1 is, as I said before, quite useless.

ok. here's what i'm thinkin' (since the way tiles are counted in the Mapfiles is not obvious /Lul -- that is, x and y are switched and z is counted from the toplevel downward )

default to 0-based, and keep the z-level count using 0 as the groundlevel (eg. the top of a battleship will still be level 3)

Can you pls confirm for me that, when placing items/xcom-craft-deployment-positions/etc, that z-level "0" is in fact the groundlevel ? I don't feel up to poking through oxc/e code to figure this out :\


Then i can define 2 options:
- 1-based count for X/Y-plane
- 1-based count for Z-level

(both would default to a 0-based count)


Quote
Yeah, I believe it would be necessary, since I don't think having to manually approve hundreds of maps makes sense. Please consider it.

yep, was never really happy with it. I just wanted a way to let newbs know that, hey, you can't go adding terrains ad infinitum ...

sidenote: at present that flag is stored in MapTilesets.yml for each tileset ( iff set true ). This is also an opportunity to clear (reset) all those flags per a menuitem ...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 19, 2020, 11:45:43 pm
ok. here's what i'm thinkin' (since the way tiles are counted in the Mapfiles is not obvious /Lul -- that is, x and y are switched and z is counted from the toplevel downward )

I... don't even want to think about this ;)

default to 0-based, and keep the z-level count using 0 as the groundlevel (eg. the top of a battleship will still be level 3)

Can you pls confirm for me that, when placing items/xcom-craft-deployment-positions/etc, that z-level "0" is in fact the groundlevel ? I don't feel up to poking through oxc/e code to figure this out :\

Yes, the ground level is defined as 0.

yep, was never really happy with it. I just wanted a way to let newbs know that, hey, you can't go adding terrains ad infinitum ...

Yes, but the current solution is like Windows handholding, doesn't help the newbies much but is really annoying to everyone else. As I'm sure you realize.
I think it would be good enough to just display the total number of tiles somewhere.
Title: Re: MAPVIEW upgrade
Post by: kevL on February 20, 2020, 12:34:09 am
the ground level is defined as 0.

tks.

Quote
Yes, but the current solution is like Windows handholding, doesn't help the newbies much but is really annoying to everyone else. As I'm sure you realize.

i totally agree. But again just for those who don't know, i wanted to give the user a sort of slapintheface as soon as a tileset loads (if you know what I mean)

Eg. transferring a Map + terrains from Mv1 (since Mv1 doesn't mention any limit at all, as far as i recall)

/anyway, onward

Quote
I think it would be good enough to just display the total number of tiles somewhere.

yes in both TileView's statusbar and in the TilesetEditor, the total records value should/will be printed reddish if >254 (no warning, just printed in red)


k, will twiddle away at stuff during the next week or so
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 20, 2020, 02:55:00 am
Is there a mono Version? Best would be as source so i can compile and optimize it against my cpu :)
Title: Re: MAPVIEW upgrade
Post by: kevL on February 20, 2020, 03:17:12 am
Is there a mono Version? Best would be as source so i can compile and optimize it against my cpu :)

my repo should be Mono compatible as is

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

notes:
Stoddard has successfully set up an automated build routine against Mono: https://lxnt.wtf/oxem/#/MapView

but osd_daedalus (see pages 29+) had issues with it [probably depends on the flavor of Linux] until he (seems to have) achieved good results by building OpenXCOM.Tools natively, on his own machine.

Note: Once you get a running build, go to MainView|Options and turn on "UseMono" -- which should resolve the quirky non-transparency issue that appears to be inherent in the Mono libraries. Unfortunately this also bypasses several graphical niceties of Mapview2, but ought to correct the black boxes that appear around all sprites (ie, no transparency) otherwise.

... if you identify any issues wrt/ Mono pls let me know since i'd like to maintain compatibility (within reason and feasibility, cause i'm strictly Windoze/.NET here)



/good luck :)
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 20, 2020, 03:21:34 am
my repo should be Mono compatible as is

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

notes:
Stoddard has successfully set up an automated build routine against Mono: https://lxnt.wtf/oxem/#/MapView

but osd_daedalus (see pages 29+) had issues with it [probably depends on the flavor of Linux] until he (seems to have) achieved good results by building OpenXCOM.Tools natively, on his own machine.

Note: Once you get a running build, go to MainView|Options and turn on "UseMono" -- which should resolve the quirky non-transparency issue that appears to be inherent in the Mono libraries. Unfortunately this also bypasses several graphical niceties of Mapview2, but ought to correct the black boxes that appear around all sprites (ie, no transparency) otherwise.

... if you identify any issues wrt/ Mono pls let me know since i'd like to maintain compatibility (within reason and feasibility, cause i'm strictly Windoze here)



/good luck :)
Any build / compile instruction ?
Title: Re: MAPVIEW upgrade
Post by: kevL on February 20, 2020, 03:25:31 am
Any build / compile instruction ?

nope. you know as much as i do ..........
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 20, 2020, 03:27:28 am
nope. you know as much as i do ..........

fuck.... boah now i have to research that...
Been ages since i worked with mono...

https://stackoverflow.com/questions/8264323/how-to-compile-a-visual-studio-c-sharp-project-with-mono

Lets try ^^

EDIT: xbuild MapView/MapView.csproj is the key ;) only problem i do not have a gui installed on the respective machine ;D So testing has to wait....
Title: Re: MAPVIEW upgrade
Post by: kevL on February 20, 2020, 03:31:40 am
( this could be interesting )
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 20, 2020, 03:46:30 am
( this could be interesting )

Well!!! See for yourself:

The Routeview window seems strange, maybe not drawing correctly?

Operating system Ubuntu 14.04 here on my Laptop. Will also work on the Desktop, compilation there worked ;)
And thanks so much for making it look really good and useable. Looking forward to spam MAPS!!
Title: Re: MAPVIEW upgrade
Post by: kevL on February 20, 2020, 04:23:20 am
holy serious RouteView shenanigans batman!

good job on the build, though. :)


here is the core function that draws the gridlines in RouteView ->

MapView/Forms/Observers/RouteView/RoutePanel.cs
DrawGridLines()

if you want to play with it idk.


note: HalfWidth and HalfHeight are (non-trivially) variables used to translate between cartesian and isometric coordinates ... but offhand i don't have a clue what's going on




EDIT: It might be the PixelOffsetMode on line #138

Code: [Select]
    _graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;

ie, try a different mode ... like none or half ...
Title: Re: MAPVIEW upgrade
Post by: hellrazor on February 20, 2020, 04:49:36 am
holy serious RouteView shenanigans batman!

good job on the build, though. :)


here is the core function that draws the gridlines in RouteView ->

MapView/Forms/Observers/RouteView/RoutePanel.cs
DrawGridLines()

if you want to play with it idk.


note: HalfWidth and HalfHeight are (non-trivially) variables used to translate between cartesian and isometric coordinates ... but offhand i don't have a clue what's going on




EDIT: It might be the PixelOffsetMode on line #138

Code: [Select]
    _graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;

ie, try a different mode ... like none or half ...

I think it has to do with the size of the window Routeview is drawn in.
I will have to run some tests while actually making some maps.
then i will see what issues come up.

In any case dude!!
You made me extremly happyQ!!!!!
Title: Re: MAPVIEW upgrade
Post by: kevL on February 21, 2020, 12:21:18 am
spam MAPS!!

absolutely <g>
Title: Re: MAPVIEW upgrade
Post by: kevL on February 22, 2020, 01:04:55 pm
2020 feb 22

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md

have at it. Let me know if i goofed ...
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 23, 2020, 02:47:20 pm
The coordinates are now displayed starting with 0; thank you!

Is there anything else new to check?
Title: Re: MAPVIEW upgrade
Post by: kevL on February 23, 2020, 03:25:17 pm
MainView|Edit|Options|Global|IgnoreRecordsExceeded = true

(default is false, you'll want it true i believe)
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on February 23, 2020, 06:44:27 pm
Ah, right. Works perfectly. Thanks again!
Title: Re: MAPVIEW upgrade
Post by: kevL on November 26, 2020, 12:58:03 am
heh - partids detected in the Mapfile that exceed the bounds of the allocated terrainset
Title: Re: MAPVIEW upgrade
Post by: kevL on December 07, 2020, 12:17:14 am
2020 dec 7

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

Please read the changes, back up your files, and report bugs.


found a bug re. tilepart deletion in TopView, pls wait ...

gtg!

found another one wrt/ tile placement at the top of the set ... looks tricky atm. pls wait

done, take 3 : https://www.youtube.com/watch?v=nzpnWuk3RjU
Title: Re: MAPVIEW upgrade
Post by: kevL on July 02, 2021, 08:42:45 pm
helloo,

Can someone who owns both UFO and TFTD tell me if the files CURSOR.PCK and CURSOR.TAB are *identical* in both games' UFOGRAPH folders?

if not, id appreciate a link to TFTD's cursor.pck/tab files ...


I want to put in a user-pref for which spriteset to use, in Mv2

all i could find on Ufopaedia.org is
https://www.ufopaedia.org/index.php/CURSOR.PCK
https://www.ufopaedia.org/index.php/Image_Formats#PCK


EDIT; I think i got it covered ...
Title: Re: [NEW request] Import from mod rule file
Post by: kevL on July 13, 2021, 06:43:27 am
from an old post

Hi Kevl,
i wish a new  import function in mapview to select a mod rule file and automatically load tilesets with ufo, terrain and craft maps (or 3 different actions to do it).

Code: [Select]
ufos:
  - type: STR_SURVEY_SHIP
    sprite: 1
    battlescapeTerrainData:
      name: UFO02
      mapDataSets:
        - BLANKS
        - UEXT2
        - UEXT3
        - UINT1
        - UINT2
        - UINT3
      mapBlocks:
        - name: UFO02
          width: 10
          length: 10
        - name: UFO02bl1
          width: 10
          length: 10
        - name: UFO02bl2
          width: 10
          length: 10
        - name: UFO02bl3
          width: 10
          length: 10
....

the rule file would enhance the maptilesets

Code: [Select]
#----- tftdShips --------------------------------------------------------------#
#----- USO --------------------------------------------------------------------#
  - type: UFO02
    terrains:
      - UEXT2
      - UEXT3
      - UINT1
      - UINT2
      - UINT3
    category: USO
    group: tftdShips_TWoTS
  - type: UFO02l1
    terrains:
      - UEXT2
      - UEXT3
      - UINT1
      - UINT2
      - UINT3
    category: USO
    group: tftdShips_TWoTS
...

When import a rule file you could create a new group name by path segment.

the RulesetConverter.exe ought handle this. It outputs any terrains found in a specified .RUL file to a .TPL (template) file -- converting the metadata from OxC-format to MapView2 format. Look in the latter and copy what you want into your settings/MapTilesets.yml ...


EDIT: oh wait, that's "ufos" -- will look into it ... (and "crafts")

edit2: ok, next release (or currently on Github), user can select "terrains", "crafts", or "ufos" and the RulesetConverter should parse the data out to Mapview2 metadata format. I've been jabbing away at ver4 code lately ...
Title: Re: MAPVIEW upgrade
Post by: kevL on August 24, 2021, 07:43:42 am
time to unleash this. I put a whackload of manhours in (again :)_~

There's a few minor fixes, but I wasn't keeping track ... there's a lot of
underlying code changes so things could screw up. Perhaps a couple of minor
enhancements i forget.

oh, PckView ought handle LOFTEMPS.DAT

So, for the time, consider this BETA version! Ie. if you back up your stuff
(MAPS,ROUTES,TERRAIN folders) and aren't afraid of glitches etc.

Paranoid usage: backup your current installation of Mapview2 by appending an
underscore to the label of its root folder. Unzip this version alongside it.
Copy your current MapTilesets.yml file into /settings. There are some
MapOptions.cfg changes that might bork on first run ... just keep yer eye on the
ball and things should be ok.


Pls report any weirdness (after trying to resolve it on your end ;),

on the other hand if you're happy with your current version of Mapview2 then
just hold tight


https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution
Title: Re: MAPVIEW upgrade
Post by: Grober Nitho on August 25, 2021, 05:06:36 pm
time to unleash this. I put a whackload of manhours in (again :)_~

There's a few minor fixes, but I wasn't keeping track ... there's a lot of
underlying code changes so things could screw up. Perhaps a couple of minor
enhancements i forget.

oh, PckView ought handle LOFTEMPS.DAT

Thank you, I'm downloaded, will trying today. I hope will good and usefull.

Working without problem, thank you again. This version is wonderfull.
Title: Re: MAPVIEW upgrade
Post by: Alex_D on August 25, 2021, 05:30:27 pm
Hi kevL.

I have a question, please forgive me if it was answered before.

One of my problems with maps in general is when I want to re-arrange the terrain orders without altering their index position on the map.

For example I want to switch positions 'JUNGLE' first and 'ROAD' second. And I want the Map program to perform the terrain position swap while retaining the overall indexes.

Is this sort of function implemented by Map View 2 ?
Title: Re: MAPVIEW upgrade
Post by: kevL on August 26, 2021, 01:37:51 am
One of my problems with maps in general is when I want to re-arrange the terrain orders without altering their index position on the map.

For example I want to switch positions 'JUNGLE' first and 'ROAD' second. And I want the Map program to perform the terrain position swap while retaining the overall indexes.

Is this sort of function implemented by Map View 2 ?

good question,

unfortunately there's no automatic way to do that.

note it should be half-possible with Edit|Tilepart Substitution. But since the max #id is capped at the max terrainset #id, it's /not/ possible to shift one terrain's #ids up out of the way of all terrains' #ids, to free them for use by the terrain that's being shifted ... (without doing that, the #ids of the 2 terrains would become mixed together)

I'll think about writing an Edit|swap terrains ... it's not immediately obvious how, though, what with 3+ terrains each having different total parts ... hm,
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2021, 03:09:09 am
@Alex_D

Mapview2 4.0.1.0

- Edit|Terrain Swap [Ctrl+W] opens a dialog box for rearranging the order of
  terrains in the current Map's terrainset without the tileset going all wtf.
- fix obscure bug in the TilesetEditor: if button at the bottom was clicked to
  apply allocated terrains to all tilesets that share Map+Path, and such a
  tileset shared the same Category-label as the current tileset, but is in a
  different Group, said tileset failed to update its metadata. Fixed.
- when the button at the bottom of the TilesetEditor is clicked to apply
  allocated terrains to all tilesets that share Map+Path, show an infobox with
  how many tilesets got updated. (It was irksome to click it and nothing seemed
  to happen.)

+ slight refactors to TilesetEditor and TilepartSubstitution etc.

| I'll think about writing an Edit|swap terrains ... it's not immediately obvious how, though, what with 3+ terrains each having different total parts ... hm,

it factored down to this little ditty:

Code: [Select]
for (int i = 0; i != _terCount; ++i) // subtract part-ids until the terrain becomes the 'first' terrain ->
{
    if (order0 == i) break;
    part.SetId -= _partCounts[i];
}

for (int i = 0; i != _terCount; ++i) // add part-ids until the terrain goes to its 'final' position in the terrainset.
{
    if (order1 == i) break;
    part.SetId += partCounts[i];
}

Beta. Take the necessary precautions: Backup your stuff, tks -- this can seriously screw up .MAPs if it goes wrong.
Title: Re: MAPVIEW upgrade
Post by: Alex_D on October 06, 2021, 09:59:02 pm
Thank you kevL
Title: Re: MAPVIEW upgrade
Post by: Nord on October 16, 2021, 11:31:12 am
Hi. Noticed that vanilla tftd map of alien base level 1 can not be opened via MapView. Something looks wrong, maybe with map height.
Title: Re: MAPVIEW upgrade
Post by: robin on October 16, 2021, 12:08:40 pm
I get this when I try to copy-paste an area of tiles from a map to another.
Happens both if if I try to paste on the same level or on a different level from source map.
The maps use the same MCD libraries.

The MCDs count for these maps exceeds the 255 limit, but all the MCDs in the copy-pasted area are not among the ones beyond that limit.

Let me know if you need more info.
Title: Re: MAPVIEW upgrade
Post by: robin on October 16, 2021, 12:09:32 pm
double post sry.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 16, 2021, 10:05:23 pm
@robin I think i got it ... gimme a day or so to look it over.

@Nord I don't have TftD myself and so can't check the Maps... is there an error? or is it silent... what happens?
Title: Re: MAPVIEW upgrade
Post by: Nord on October 17, 2021, 06:07:54 pm
@Nord I don't have TftD myself and so can't check the Maps... is there an error? or is it silent... what happens?
Here is error message:
System.OverflowException: Array dimensions exceeded supported range.
   at XCom.SpriteCollection..ctor(String label, Palette pal, Int32 tabwordLength, Byte[] bytesPck, Byte[] bytesTab)
   at XCom.SpritesetsManager.LoadSpriteset(String label, String dir, Int32 tabwordLength, Palette pal, Boolean preserveStaticSpritesets)
   at XCom.Descriptor.CreateTerrain(Int32 id)
   at XCom.MapFileService.LoadDescriptor(Descriptor descriptor, Boolean& treechanged, Boolean browseMapfile, Boolean ignoreRecordsExceeded, RouteNodeCollection routes)
   at MapView.MainViewF.LoadSelectedDescriptor(Boolean browseMapfile, Boolean keepRoutes)
   at MapView.MainViewF.OnMapTreeAfterSelect(Object sender, TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 18, 2021, 04:56:14 am
Here is error message:
System.OverflowException: Array dimensions exceeded supported range.
   at XCom.SpriteCollection..ctor(String label, Palette pal, Int32 tabwordLength, Byte[] bytesPck, Byte[] bytesTab)
   at XCom.SpritesetsManager.LoadSpriteset(String label, String dir, Int32 tabwordLength, Palette pal, Boolean preserveStaticSpritesets)
   at XCom.Descriptor.CreateTerrain(Int32 id)
   at XCom.MapFileService.LoadDescriptor(Descriptor descriptor, Boolean& treechanged, Boolean browseMapfile, Boolean ignoreRecordsExceeded, RouteNodeCollection routes)
   at MapView.MainViewF.LoadSelectedDescriptor(Boolean browseMapfile, Boolean keepRoutes)
   at MapView.MainViewF.OnMapTreeAfterSelect(Object sender, TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

@Nord you seem to be using an old version of MapView2. The functs in the stacktrace no longer exist in that form ...pls upgrade and try it again -- let me know if it still borks out,
Title: Re: MAPVIEW upgrade
Post by: Nord on October 18, 2021, 09:39:28 am
@Nord you seem to be using an old version of MapView2. The functs in the stacktrace no longer exist in that form ...pls upgrade and try it again -- let me know if it still borks out,
Downloaded version fro 4 october. Still got this:
System.OverflowException: Array dimensions exceeded supported range.
   at XCom.Spriteset..ctor(String label, Palette pal, Byte[] bytesPck, Byte[] bytesTab, Int32 spritewidth, Int32 spriteheight, Int32 tabwordLength, Boolean createToned)
   at XCom.SpritesetManager.CreateSpriteset(String label, String dir, Palette pal, Boolean createToned, Int32 spritewidth, Int32 spriteheight)
   at XCom.Descriptor.CreateTerrain(Int32 terid)
   at XCom.MapFileService.LoadDescriptor(Descriptor descriptor, Boolean& browseMapfile, Boolean ignoreRecordsExceeded, RouteNodes routes, TreeNode selected)
   at MapView.MainViewF.LoadSelectedDescriptor(Boolean browseMapfile, Boolean keepRoutes)
   at MapView.MainViewF.OnMapTreeAfterSelect(Object sender, TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Title: Re: MAPVIEW upgrade
Post by: kevL on October 18, 2021, 08:10:28 pm
vanilla tftd map of alien base level 1

hi Nord, could you link me to a MAP and the terrain files req'd to load

#----- Alien Base Level 1 -----------------------------------------------------#
  - type: ENTRY00
    terrains:
      - SAND
      - UEXT2
      - UEXT3
      - ORGANIC1
      - ENTRY

?
Title: Re: MAPVIEW upgrade
Post by: kevL on October 19, 2021, 06:16:20 am
The release build of Mapview2 was well behaved on my machine, when loading Maps in the tftdSeascapes|Alien Base Level 1 category. I get this error:

Quote
In the MCD file ENTRY part #6 has an invalid death part (id #47 of 12 records).

in the debug build, however, this also gets thrown:

System.ArgumentNullException: Value cannot be null.
Parameter name: image
   at System.Drawing.Graphics.DrawImage(Image image, Rectangle destRect, Int32 srcX, Int32 srcY, Int32 srcWidth, Int32 srcHeight, GraphicsUnit srcUnit, ImageAttributes imageAttrs, DrawImageAbort callback, IntPtr callbackData)
   at System.Drawing.Graphics.DrawImage(Image image, Rectangle destRect, Int32 srcX, Int32 srcY, Int32 srcWidth, Int32 srcHeight, GraphicsUnit srcUnit, ImageAttributes imageAttr)
   at MapView.Forms.MainView.MainViewOverlay.DrawSprite(Image sprite, Rectangle rect) in c:\GIT\OpenXCOM.Tools\MapView\Forms\MainView\MainViewPanel\MainViewOverlay.cs:line 2031
   at MapView.Forms.MainView.MainViewOverlay.DrawTile(MapTile tile, Int32 x, Int32 y, Boolean toned) in c:\GIT\OpenXCOM.Tools\MapView\Forms\MainView\MainViewPanel\MainViewOverlay.cs:line 1975
   at MapView.Forms.MainView.MainViewOverlay.DrawRembrandt() in c:\GIT\OpenXCOM.Tools\MapView\Forms\MainView\MainViewPanel\MainViewOverlay.cs:line 1440
   at MapView.Forms.MainView.MainViewOverlay.OnPaint(PaintEventArgs e) in c:\GIT\OpenXCOM.Tools\MapView\Forms\MainView\MainViewPanel\MainViewOverlay.cs:line 1321
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

investigating further, found that Alien Base Level 2 does the same thing with the ORGANIC2 terrain, which is almost identical to the ENTRY terrain (but has 2 less tileparts).

Quote
In the MCD file ORGANIC2 part #6 has an invalid death part (id #47 of 10 records).

potential fix :
Open ENTRY.MCD in McdView (or MCDEdit) and change the deathtile of id #6 from 47 to 7. save ...
Open ORGANIC2.MCD in McdView (or MCDEdit) and change the deathtile of id #6 from 47 to 7. save ...

try it ...,
Title: Re: MAPVIEW upgrade
Post by: Nord on October 19, 2021, 11:42:20 am
I have open MCD's. And no, they are valid.
MCD part 6 have deathId 7 in ENTRY. ORGANIC2 is fine too.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 19, 2021, 04:04:41 pm
I have open MCD's. And no, they are valid.
MCD part 6 have deathId 7 in ENTRY. ORGANIC2 is fine too.

then pls send me the Map and terrain files for the tileset you are trying to load. The ones you sent me are different ... (and they load, btw).

@robin sry this is taking longer than expected

[edit]
@Nord

Quote
System.OverflowException: Array dimensions exceeded supported range.

at first i thought the error was the usual "index exceeds bounds of the array" but then looked into it ... it looks like, for whatever whacky reason, one or more of the terrains you're trying to load is causing c# to attempt to create an array with indices for > 65000 sprites
Title: Re: MAPVIEW upgrade
Post by: kevL on October 20, 2021, 09:06:06 am
2021 October 20
MapView2_211020.7z
https://drive.google.com/file/d/1CLaCLZu_Y_YMfmWaeSMYrfKsUCyeJTMx/view?usp=sharing

fix Copy/Paste tiles from one Map to another.
rework About boxes
+ assorted tweaks
Title: Re: MAPVIEW upgrade
Post by: Nord on October 20, 2021, 09:30:36 am
Ok, i have tryed an full-clean install. And it is working. Sorry, looks like problems are on my side. Too many modding, confused with all these maps and terrains.
Once again, sorry.
 :-[
Title: Re: MAPVIEW upgrade
Post by: kevL on October 20, 2021, 10:04:57 am
kk

nothin wrong with pushing the limits..
Title: Re: MAPVIEW upgrade
Post by: Finnik on October 26, 2021, 09:29:06 pm
Can I make a few requests for PckView?

1) Add empty frame. Current version AFAIK can only add frame from file, but id like to draw in directly in your software.

2) Make SpriteEditor window bigger, with greater scaling. On my monitor its too small, that makes it hard to work with.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 27, 2021, 02:10:52 am
2) Make SpriteEditor window bigger, with greater scaling. On my monitor its too small, that makes it hard to work with.

done. not uploaded yet ... ( 1x .. 2x in increments of 10% )

will have a look at create blank sprite soon ...


there'll be a few minor upgrades to Mapview2 also ...

/cheers

[edit]
put in a small user-config file for PckView (autosaves on quit)

Code: [Select]
PckConfig:
  transparent: True
  spriteshade: True
  palette: 0
  grid: 0
  scale: 0

[edit2]
1) Add empty frame. Current version AFAIK can only add frame from file, but id like to draw in directly in your software.

done. RMB contextmenu will have create and clear ops

lookin pretty good, just wanna sleep on it ...
Title: Re: MAPVIEW upgrade
Post by: kevL on October 29, 2021, 11:49:31 pm
https://github.com/kevL/OpenXCOM.Tools/releases/tag/211029-real

let me know if anything borks, pls
Title: Re: MAPVIEW upgrade
Post by: Finnik on October 30, 2021, 02:38:09 pm
Works fine, at +10 it looks ok to me to work with, thank you!

Another possible improvement - not disable SpriteEditor window when Palette is opened. It is essential to have them both under hand in order to draw sprites.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 30, 2021, 03:19:39 pm
Another possible improvement - not disable SpriteEditor window when Palette is opened. It is essential to have them both under hand in order to draw sprites.

disable? i don't get what ya mean. There's the SpriteEditor (window) and the Palette (window) side by side ... the editor has two modes: Locked or Enabled (click text to toggle mode)

Do you mean you'd like the SpriteEditor to start in Enabled mode by default ? i can save the mode to the config file ... (kinda forgot to do that tbh)
Title: Re: MAPVIEW upgrade
Post by: Finnik on October 31, 2021, 04:44:08 pm
Yes, it would be nice too.

I mean that once I opened Palette window, I can't edit sprite in SpriteEditor before I close Palette window. That leads to frustration, when i need to open and close it over and over again in order to draw a sprite.
Title: Re: MAPVIEW upgrade
Post by: kevL on October 31, 2021, 04:47:58 pm
I mean that once I opened Palette window, I can't edit sprite in SpriteEditor before I close Palette window.

hmmmmmmmm sounds like the win10 anomaly ... will need time to investigate ... (read: that should not happen)

[edit]
i think I have something, will upload later,
Title: Re: MAPVIEW upgrade
Post by: kevL on November 04, 2021, 01:58:11 am
@Finnik - try this one

There should be a new item under Options in PckView's menu: _Bring editor/palette to front_

It is turned off by default. Turning it on allows the SpriteEditor and Palette windows to pop to the front of other app-windows that might be covering those windows, such that focusing the PckView window shall bring both the SpriteEditor and Palette to front, and focusing the SpriteEditor shall bring the Palette to front. But this is a finicky (no pun intended) business in .net ... it behaves differently in win7 and win10, eg.

I haven't found a way, in win10, that allows focus to return properly to the window that initiates the routine. So the _Bring editor/palette to front_ option just turns the routine on/off (ie. bypasses it when OFF).

if you turn the option on and focus does not return properly to the parent window, you'll have to close the child window(s) and turn the option off again.


note that whether the option is on or off, all windows of PckView can be brought to front by minimizing and then restoring PckView per the taskbar ...


Also, the option is saved to PckConfig.yml in the /settings folder


https://github.com/kevL/OpenXCOM.Tools/releases/tag/211103
Title: Re: MAPVIEW upgrade
Post by: Finnik on November 07, 2021, 03:47:19 pm
@Finnik - try this one

There should be a new item under Options in PckView's menu: _Bring editor/palette to front_

It is turned off by default. Turning it on allows the SpriteEditor and Palette windows to pop to the front of other app-windows that might be covering those windows, such that focusing the PckView window shall bring both the SpriteEditor and Palette to front, and focusing the SpriteEditor shall bring the Palette to front. But this is a finicky (no pun intended) business in .net ... it behaves differently in win7 and win10, eg.

I haven't found a way, in win10, that allows focus to return properly to the window that initiates the routine. So the _Bring editor/palette to front_ option just turns the routine on/off (ie. bypasses it when OFF).

if you turn the option on and focus does not return properly to the parent window, you'll have to close the child window(s) and turn the option off again.


note that whether the option is on or off, all windows of PckView can be brought to front by minimizing and then restoring PckView per the taskbar ...


Also, the option is saved to PckConfig.yml in the /settings folder


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

Works great with default setting you made! Thank you so much!
Title: Re: MAPVIEW upgrade
Post by: kevL on November 07, 2021, 05:33:55 pm
Works great with default setting you made! Thank you so much!

oky doke
Title: Re: MAPVIEW upgrade
Post by: Nord on January 07, 2022, 07:37:59 pm
Sorry if i bothering, but i have one user-question.
Operating this version, i want to place an object to the map. First i chose item to place. Then i move mouse to the desired plot and need to press mouse button THREE TIMES to place item. First to activate window, second to choose map square, and third to place an object. It is really annoying. Is it possible to reduce this quantity?
Thanks.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 08, 2022, 02:19:23 am
hi Nord,

for me it's 2 clicks : with the part to place already selected in TileView, RMB in TopView (or LMB) activates the TopView window* then RMB on a tile should both select that tile and place the part in the currently seleted quadrant/slot (west, north, etc.)


* i don't like that behavior either :\ Some apps (like MapView2) discard the mouse-click when a window is inactive, others don't iirc. It may be a function of the .net framework but i really don't know. Stackoverflow.com has suggested workarounds ... (but i can't say with conviction if/when i might try to implement them)

?
Title: Re: MAPVIEW upgrade
Post by: Nord on January 11, 2022, 10:38:37 am
Sad.
Anyway, mapview 2 is indispensable tool, than you.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 11, 2022, 10:45:48 am
Anyway, mapview 2 is indispensable tool, than you.

yes i know Mv2 is more indispensable than me ;p

regardless, ill look into bypassing .net's first-click activation ... i got an idea it might not be as difficult as id thought ...
Title: Re: MAPVIEW upgrade
Post by: Nord on January 11, 2022, 07:08:01 pm
wait... this topic is not about mapview 2? I am confused...
Title: Re: MAPVIEW upgrade
Post by: kevL on January 11, 2022, 07:10:42 pm
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 ...
Title: Re: MAPVIEW upgrade
Post by: kevL on January 18, 2022, 09:33:39 am
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,
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 21, 2022, 08:41:42 am
Hello,
  Just working on a little something something and getting this exception.... Good to see your still maintaining this  :P

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.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 21, 2022, 09:26:28 am
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.
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 23, 2022, 12:07:43 am
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.
Title: Re: MAPVIEW upgrade
Post by: kevL on January 23, 2022, 01:55:34 am
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.
Title: Re: MAPVIEW upgrade
Post by: kevL on March 16, 2022, 08:52:07 am
MapView 4.3.0.0
- x2 scale button for RouteView

https://github.com/kevL/OpenXCOM.Tools/releases/tag/220315
Title: Re: MAPVIEW upgrade
Post by: kevL on March 26, 2022, 08:59:15 pm
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
Title: Re: MAPVIEW upgrade
Post by: Delian on April 29, 2022, 03:35:19 pm
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.
Title: Re: MAPVIEW upgrade
Post by: kevL on April 29, 2022, 03:42:45 pm
does it have a .TAB file? If so pls link it also

PckView doesn't open .PCK files unless they have a .TAB file ...
Title: Re: MAPVIEW upgrade
Post by: Delian on April 29, 2022, 03:56:50 pm
It has a TAB file.
Title: Re: MAPVIEW upgrade
Post by: kevL on April 29, 2022, 05:03:21 pm
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.
Title: Re: MAPVIEW upgrade
Post by: Delian on April 29, 2022, 07:39:03 pm
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?
Title: Re: MAPVIEW upgrade
Post by: kevL on April 29, 2022, 08:45:41 pm
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,
Title: Re: MAPVIEW upgrade
Post by: kevL on May 02, 2022, 12:25:15 am
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 ...
Title: Re: MAPVIEW upgrade
Post by: kevL on May 06, 2022, 11:41:17 pm
https://github.com/kevL/OpenXCOM.Tools/releases/tag/220506
Title: Re: MAPVIEW upgrade
Post by: thusky on August 08, 2022, 11:13:23 pm
Heya! Sorry to revive this old thread but I suppose I can ask here for one tiny extra feature to MapView?

- Dark mode !

My eyes are literally bleeding after spending so many hours on map editing/making, not mapview's fault though I should see the sun more but I found that dark mode strains my eyes a lot less, maybe that's the case for you guys as well?

Anyways, thanks for maintaining that tool after so long, eager to see if it's already in the plans or not too hard to implement!  8)

Cheers!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 09, 2022, 03:23:31 am
hey thusky,

im okay with lightmode so no plans for dark, but you *might* be able to get some relief by tweaking your OS-color settings ... (change white controls to silver, for example)


ps. creating color-schemes = surprisingly nontrivial ...

pps. I might be able to add a 'dark' option for some areas without causing color conflicts, if you want to post a screenshot or two pointing out what bothers most, (no guarantees)
Title: Re: MAPVIEW upgrade
Post by: thusky on August 09, 2022, 12:39:56 pm
Alright I'll see what I can tweak in windows already!

Here are a few modified screenshots to show roughly what I had in mind just in case!

No worries though I can work in mapview already, if it's too much work might not be worth it if I'm the only one asking.
Title: Re: MAPVIEW upgrade
Post by: kevL on August 10, 2022, 03:24:31 am
ok i see

basically backgrounds of panels, and the MapTree

am trying to finish a big update on another project atm - ill take a closer look sometime, maybe implement user-options for those ...


thanks for the headsup



ps. Is the font in your MapTree really that borky... ?
Title: Re: MAPVIEW upgrade
Post by: The Reaver of Darkness on August 10, 2022, 05:06:34 am
Relevant image I produced a few years back:
(https://i.imgur.com/DHkLvj3.png)
(source material is Dumbing of Age webcomic)

Dark theme should always be the default, just putting that out there for future reference.
Title: Re: MAPVIEW upgrade
Post by: thusky on August 10, 2022, 10:16:32 am
am trying to finish a big update on another project atm - ill take a closer look sometime, maybe implement user-options for those ...
Awesome!


Quote
ps. Is the font in your MapTree really that borky... ?
You mean the front of the top view being that big? It's because I increase the size to see more clearly or did you refer to something else?
Title: Re: MAPVIEW upgrade
Post by: kevL on August 10, 2022, 12:08:37 pm
You mean the front of the top view being that big? It's because I increase the size to see more clearly or did you refer to something else?

well, i was kinda wondering about that (screenshot 1) but more about 2

did you increase fontsize in Win OS ?
Title: Re: MAPVIEW upgrade
Post by: thusky on August 10, 2022, 01:33:22 pm
well, i was kinda wondering about that (screenshot 1) but more about 2

did you increase fontsize in Win OS ?

I did actually! I also tweaked the font in pixel art to make some part more readable to you as a ref, even though the text on the left is pretty unreadable I'll admit!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 10, 2022, 03:26:08 pm
I did actually!

hm, not sure what to say ... i never 'trusted' changing fontsize globally and am 'scared' to even try it (for myself). I mean, .net gives the programmer all sorts of control over the layout of his/her app, but then respects an OS setting that essentially says "Here, put this 15" tire on a fiat rim ..."

i mean, I see the user-side of the argument: monitor resolutions are getting huge these days (im running 1920x1080 and fortunately i like small fonts - but im also farsighted and have to wear reading glasses)

so ... How much space should a programmer allocate among controls to account for an arbitrary change of the fontsize in a label? Why doesn't .net TreeView handle the OS change better than that? If I change font-scaling on my OS and open some apps, are the locations and sizes of the apps going to change in the Registry?

and a change like that has the potential to crash the OS, which can be an absolute nightmare (been there)

... just some rhetorical questions, i guess. I'd have to take the deep dive and be prepared to bite the snake before venturing into that particular jungle, if you know what i mean :)


Anyway, backcolor and forecolor changes should be easier,
Title: Re: MAPVIEW upgrade
Post by: thusky on August 10, 2022, 08:16:15 pm
Yeah background/foreground color is what dark mode is all about, font size wasn't my request it was to make things more readable to me and you ahah.

Thank you so much for your time!
Title: Re: MAPVIEW upgrade
Post by: bulletdesigner on August 11, 2022, 08:18:54 pm
is it possible to do a LOFTEM view on mapview? dunno if already was discussed but that would be gold!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 12, 2022, 04:08:40 am
haha yeah, uh no

(not by me anyway)
Title: Re: MAPVIEW upgrade
Post by: kevL on August 12, 2022, 06:52:24 am
@thusky so far so good ...

[edit] oh its beginning to look lovely (screenshot2)
Title: Re: MAPVIEW upgrade
Post by: thusky on August 12, 2022, 02:30:01 pm
Quote
oh its beginning to look lovely (screenshot2)

It's awesome! I'm sure your work will benefit many other modders as well, big thanks KevL!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 17, 2022, 11:50:17 pm
color schemes ... surprisingly nontrivial

but gettin there
Title: Re: MAPVIEW upgrade
Post by: Solarius Scorch on August 18, 2022, 11:22:37 am
Next step: skins with custom textures and cursors. ;D
Title: Re: MAPVIEW upgrade
Post by: thusky on August 18, 2022, 12:58:06 pm
color schemes ... surprisingly nontrivial

but gettin there
Thank you for your hard work! I already hyped both discord servers about your color schemes upgrade!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 18, 2022, 07:32:18 pm
everytime i think hm, Presets: Save/Load/Reset

I shuffle outside and water the tomato plants.
Title: Re: MAPVIEW upgrade
Post by: kevL on August 24, 2022, 02:43:44 pm
2022 aug 24

MapView.exe 4.4.0.0
XCom.dll 4.1.3.0
DSShared.dll 4.2.1.0


IMPORTANT: The MapTree has been overhauled. Navigating away from a treenode
(whether by leftclick or keyboard) for which a tileset is currently loaded shall
close that tileset (a save confirmation should appear if the tileset has been
changed). Further, when navigating the tree by keyboard arrows, a selected
tileset node will appear with a border only; pressing [Enter] (or clicking on
the node) will fill the border with color if the tileset loads successfully.
Also, the MapTree's context menu (rightclick or spacebar) is disabled when the
treenode of an invalid tileset is currently selected.

The changes are intended to resolve any ambiguity that could result from the
fact that a selected treenode did not necessarily correspond to a loaded
tileset.

WARNING: That involved many technical changes and a partial rethink of the way
that the MapTree functions. So BACKUP YOUR STUFF before taking this version of
Mapview2 out for a spin ... if you aren't comfortable using beta software then
it's best to wait a couple weeks for possible bugs/glitches to be found and get
fixed.

Please report bugs/glitches ASAP. Tks. And ... Pls BACKUP yer STUFF


- fix: do not attempt to draw blobs for crippled tileparts (in TopView and
  RouteView). Crippled parts have ids beyond the currently allocated terrainset
  and have no records, hence no blobs.
- fix: deter enabled state of levelup/down arrows in MainView and TopView when
  using the Go/Og buttons or when raising/lowering a routenode in RouteView.
- fix: do not show infinite SaveAlerts when deleting a Changed tileset from the
  MapTree (just close it - no confirmation is given).
- fix: deleting a tileset in the Maptree closes the tileset

- add File|Close (closes a currently loaded tileset)
- refactor and tweak the Maptree's context routines
- show highest invalid setId in TilepartSubstitution dialog (if a placed
  tilepart id is greater than the current Max terrainset id)
- Options dialogs: when minimized, clicking a dialog's respective Option-button
  [Ctrl+o] shall restore instead of close the dialog

- add lots of Color choices to each viewer's Options (allows user to reduce
  gravitational x-rays emitted by his/her monitor and could lead to watching
  Neil Breen movies). Requested by thusky


https://github.com/kevL/OpenXCOM.Tools/releases/tag/220824
Title: Re: MAPVIEW upgrade
Post by: thusky on August 24, 2022, 09:50:47 pm
Just shared your update on the discord servers! I'll be sure to report anything unusual/buggy so you know what's up, again big thanks for your work, it's a big help for my eyes ahah!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 24, 2022, 11:05:16 pm
cool cool :^)


ps. when I stress backup, backup settings/MapTilesets.yml (also)

note that the MV_Backup folders that appear here and there are ONE SHOT only. That is, when MapView2 writes pretty much any file it makes a back up in MV_Backup -- but those files get overwritten the very next time another write happens. So the folder is for users who notice immediately that something bad may have happened: don't go pressing savesavesave why isn't this working? Because that defeats automated Mv2 backups ...
Title: Re: MAPVIEW upgrade
Post by: thusky on August 24, 2022, 11:10:55 pm
I just duplicated my whole mapview working folder personally, no errors so far so I kept working, the ability to change colors is a boon for sure, I feel much better working with Mapview now, I can't stress how much this will help me on the long run!

it's things like this that makes me want to boot the software more often!
Title: Re: MAPVIEW upgrade
Post by: kevL on August 24, 2022, 11:27:20 pm
nice. I wish i had more time to put it through its paces ...
Title: Re: MAPVIEW upgrade
Post by: kevL on October 05, 2022, 10:31:26 pm
RouteView gets Highlights menu

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

+ minor fixes and tweaks
Title: Re: MAPVIEW upgrade
Post by: kevL on October 11, 2022, 03:11:03 am
MapView 4.4.4.0

- enhancement to RouteView's noderank highlights: depressing [Ctrl] when
  clicking items in the Highlights menu or on the noderank color-panels will add
  or subtract the rank without affecting the current state of other ranks.


https://github.com/kevL/OpenXCOM.Tools/releases/tag/221011
Title: Re: MAPVIEW upgrade
Post by: kevL on May 23, 2023, 01:38:07 am
2023 May 22

MapView.exe 4.4.6.0
McdView.exe 4.1.2.1
PckView.exe 4.3.0.1
XCom.dll 4.2.0.0
DSShared.dll 4.2.1.1
YamlDotNet.dll 0.0.1.0 (c) Antoine Aubry and contributors

ConfigConverter.exe 2.2.2.1
RulesetConverter.exe 1.3.0.1

RouteView

    hardcap Link destinations to MaxDestId=250. The value is stored as a byte in
    the Routefile but the top 5 values are reserved for the compass points and the
    NotUsed value. Note that Routenode IDs are not limited to Byte.MaxValue but
    they can't be linked to if their ID is greater than 250.

    support more than 256 routenodes in a Routefile.

    TftD NodeRanks: change "Leader/Commander" string to "Navigator/Commander".

    SpawnInfo dialog: rework layout mechanics to account for the longer
    "Navigator/Commander" string.

    add (textbox) Goto #id on the menubar.

    rewrite the embedded MonotoneSpriteset (TopView's quadrant and TileView's
    eraser sprites).

MapResize

    restrict cols/rows/levels to Max 255 (these values are stored in a Mapfile as
    bytes).

    bugfix: when removing levels from the bottom of a Map that has routenodes that
    go out of bounds at the currently displayed level an exception was thrown by
    RouteView's Paint routine. fixed ...


https://github.com/kevL/OpenXCOM.Tools/releases/tag/230522
Title: Re: MAPVIEW upgrade
Post by: The Martian on June 02, 2023, 10:41:18 am
Thank you for updating MapView2 your program is great. (https://openxcom.org/forum/Themes/InsidiousV1-k/images/post/thumbup.gif)
Title: Re: MAPVIEW upgrade
Post by: kevL on June 03, 2023, 01:13:08 am
Thank you for updating MapView2 your program is great. (https://openxcom.org/forum/Themes/InsidiousV1-k/images/post/thumbup.gif)

i pass it on in spirit to Ben, and anyone who's contributed in any way: code, reports, requests

/salut
Title: Re: MAPVIEW upgrade
Post by: GumChewer on January 16, 2024, 07:57:28 pm
I request an option for directly reading a OXC(E) terrain .rul file in MapView.
Instead of having to use the RulesetConverter initally and re-convert whenever something in the .rul file changes.

I'm fine with, and it is seemingly easy to implement by glancing the source code,
1) Store the corresponding input (path of the .rul file, optional basepath, type) of the corresponding RulesetConverter call in the options of MapView. Or in the MapTileset.yml file which then acts only as a proxy.
2) Do the conversion at every startup of MapView
3) Do not write changes back to the .rul file

Anyway, thanks for the work so far!
Title: Re: MAPVIEW upgrade
Post by: kevL on January 17, 2024, 10:09:50 am
I request an option for directly reading a OXC(E) terrain .rul file in MapView.
Instead of having to use the RulesetConverter initally and re-convert whenever something in the .rul file changes.

hiya, good idea,

unfortunately my flagging health is putting me behind on a bunch of stuff (already) ...

imo, Mapview should get a means of loading (user choice) "MapTilesets" -- if that were done, it'd be a good time to also put in loading a Terrain.rul file. One thing that strikes me right away is disabling a bunch of maptree stuff (so a maptree that's based on a .rul file can't be changed, as you note).

automagically changing the Mapview (global) Basepath is also something to consider (though this can already be done with the Configurator it would be a nice feature, which however necessitates a mechanism to automagically change it back ...) etc.


Personally im glad that Mv2 seems to be stable in its current state, but (for me) this would be a fairly big new feature to implement,
Title: Re: MAPVIEW upgrade
Post by: luke83 on January 26, 2024, 06:14:10 am
Good to see your still keeping this dream alive  @kevL i grabbed the newest version last night and shes working great :)
Title: Re: MAPVIEW upgrade
Post by: kevL on January 26, 2024, 04:05:59 pm
luuuuuuuuke !
Title: Re: MAPVIEW upgrade
Post by: GumChewer on January 29, 2024, 08:29:36 pm
unfortunately my flagging health is putting me behind on a bunch of stuff (already) ...
Hey,

good luck with the health!

I will see what I can code myself and open a pull request. But I'm very short on spare time, so this will not happen soon, sadly.
Title: Re: MAPVIEW upgrade
Post by: GumChewer on March 02, 2024, 12:25:14 pm
MapView cannot open the options menu for me, on Linux/Mono6/libgdiplus.
Stacktrace attached, but the error seems to be too complicated for me.
It works without the options window too, but I'd love if you find the time to have a look (Sorry for the work...).

Code: [Select]
System.NullReferenceException: Object reference not set to an instance of an object
  at MapView.OptionsF..ctor (System.Object o, MapView.Options options, MapView.OptionableType oType) [0x0006d] in <0a0656103b894489b35d71dc5339306a>:0
  at (wrapper remoting-invoke-with-check) MapView.OptionsF..ctor(object,MapView.Options,MapView.OptionableType)
  at MapView.MainViewF.OnOptionsClick (System.Object sender, System.EventArgs e) [0x00063] in <0a0656103b894489b35d71dc5339306a>:0
  at System.Windows.Forms.MenuItem.OnClick (System.EventArgs e) [0x00019] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.MenuItem.PerformClick () [0x00000] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.MenuItem.PerformClick()
  at System.Windows.Forms.MenuTracker.OnMouseUp (System.Windows.Forms.MouseEventArgs args) [0x000bf] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Control.ProcessActiveTracker (System.Windows.Forms.Message& m) [0x00091] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00015] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x001b4] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.ScrollableControl.WndProc (System.Windows.Forms.Message& m) [0x00000] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.ContainerControl.WndProc (System.Windows.Forms.Message& m) [0x00027] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Form.WndProc (System.Windows.Forms.Message& m) [0x00166] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x0000b] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.NativeWindow.WndProc (System.IntPtr hWnd, System.Windows.Forms.Msg msg, System.IntPtr wParam, System.IntPtr lParam) [0x00085] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
#
Title: Re: MAPVIEW upgrade
Post by: GumChewer on March 02, 2024, 12:27:36 pm
And ...  ;D ... it also crashes when I use the mouse wheel.

Code: [Select]
Unhandled Exception:
System.EntryPointNotFoundException: WindowFromPoint assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) MapView.MainViewF.WindowFromPoint(System.Drawing.Point)
  at MapView.MainViewF.PreFilterMessage (System.Windows.Forms.Message& m) [0x00020] in <0a0656103b894489b35d71dc5339306a>:0
  at System.Windows.Forms.Application.FilterMessage (System.Windows.Forms.Message& message) [0x0001f] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.RunLoop (System.Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x000e9] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00011] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00006] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at MapView.Start.Start_init () [0x00021] in <0a0656103b894489b35d71dc5339306a>:0
  at MapView.Program.Main (System.String[] args) [0x00033] in <0a0656103b894489b35d71dc5339306a>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: WindowFromPoint assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) MapView.MainViewF.WindowFromPoint(System.Drawing.Point)
  at MapView.MainViewF.PreFilterMessage (System.Windows.Forms.Message& m) [0x00020] in <0a0656103b894489b35d71dc5339306a>:0
  at System.Windows.Forms.Application.FilterMessage (System.Windows.Forms.Message& message) [0x0001f] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.RunLoop (System.Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x000e9] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00011] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00006] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at MapView.Start.Start_init () [0x00021] in <0a0656103b894489b35d71dc5339306a>:0
  at MapView.Program.Main (System.String[] args) [0x00033] in <0a0656103b894489b35d71dc5339306a>:0
Title: Re: MAPVIEW upgrade
Post by: kevL on March 02, 2024, 12:56:18 pm
sorry i don't warantee Mono, but if you find a solution ...
Title: Re: MAPVIEW upgrade
Post by: kevL on March 02, 2024, 01:08:22 pm
And ...  ;D ... it also crashes when I use the mouse wheel.

Code: [Select]
Unhandled Exception:
System.EntryPointNotFoundException: WindowFromPoint assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) MapView.MainViewF.WindowFromPoint(System.Drawing.Point)
  at MapView.MainViewF.PreFilterMessage (System.Windows.Forms.Message& m) [0x00020] in <0a0656103b894489b35d71dc5339306a>:0
  at System.Windows.Forms.Application.FilterMessage (System.Windows.Forms.Message& message) [0x0001f] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.RunLoop (System.Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x000e9] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00011] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00006] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at MapView.Start.Start_init () [0x00021] in <0a0656103b894489b35d71dc5339306a>:0
  at MapView.Program.Main (System.String[] args) [0x00033] in <0a0656103b894489b35d71dc5339306a>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: WindowFromPoint assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) MapView.MainViewF.WindowFromPoint(System.Drawing.Point)
  at MapView.MainViewF.PreFilterMessage (System.Windows.Forms.Message& m) [0x00020] in <0a0656103b894489b35d71dc5339306a>:0
  at System.Windows.Forms.Application.FilterMessage (System.Windows.Forms.Message& message) [0x0001f] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.RunLoop (System.Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x000e9] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.ApplicationContext context) [0x00011] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at System.Windows.Forms.Application.Run (System.Windows.Forms.Form mainForm) [0x00006] in <b2f5ba339bd244a2a072fe9fd5539e2f>:0
  at MapView.Start.Start_init () [0x00021] in <0a0656103b894489b35d71dc5339306a>:0
  at MapView.Program.Main (System.String[] args) [0x00033] in <0a0656103b894489b35d71dc5339306a>:0

The mousewheel issue likely has to do with Forms/MainView/MainViewF (near the top). I don't have Mono and I'm not absolutely positive about the __MonoCS__ flag. This bit of code (and associated stuff perhaps) allows windows to capture the mousewheel even if a control is not currently focused. Did you build against mono yourself, because if you're relying on a build against .NET well ... this is the kind of stuff that would throw ... or so it seems to me

Code: [Select]
#if !__MonoCS__
#region P/Invoke declarations
[DllImport("user32.dll")]
static extern IntPtr WindowFromPoint(Point pt);

[DllImport("user32.dll")]
static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wp, IntPtr lp);
#endregion P/Invoke declarations

#region IMessageFilter
/// <summary>
/// Sends mousewheel messages to the control that the mouse-cursor is
/// hovering over.
/// </summary>
/// <param name="m">the message</param>
/// <returns>true if a mousewheel message was handled successfully</returns>
/// <remarks>https://stackoverflow.com/questions/4769854/windows-forms-capturing-mousewheel#4769961</remarks>
public bool PreFilterMessage(ref Message m)
{
if (m.Msg == 0x20a)
{
// WM_MOUSEWHEEL - find the control at screen position m.LParam
var pos = new Point(m.LParam.ToInt32());

IntPtr hWnd = WindowFromPoint(pos);
if (hWnd != IntPtr.Zero && hWnd != m.HWnd && Control.FromHandle(hWnd) != null)
{
SendMessage(hWnd, m.Msg, m.WParam, m.LParam);
return true;
}
}
return false;
}
#endregion IMessageFilter
#endif
Title: Re: MAPVIEW upgrade
Post by: GumChewer on March 02, 2024, 06:08:24 pm
sorry i don't warantee Mono, but if you find a solution ...

Thanks for the fast answer and sorry for forgetting about the warranty!
Title: Re: MAPVIEW upgrade
Post by: GumChewer on March 02, 2024, 06:11:40 pm
The mousewheel issue likely has to do with Forms/MainView/MainViewF (near the top). I don't have Mono and I'm not absolutely positive about the __MonoCS__ flag. This bit of code (and associated stuff perhaps) allows windows to capture the mousewheel even if a control is not currently focused. Did you build against mono yourself, because if you're relying on a build against .NET well ... this is the kind of stuff that would throw ... or so it seems to me

Code: [Select]
#if !__MonoCS__
#region P/Invoke declarations
[DllImport("user32.dll")]
static extern IntPtr WindowFromPoint(Point pt);

[DllImport("user32.dll")]
static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wp, IntPtr lp);
#endregion P/Invoke declarations

#region IMessageFilter
/// <summary>
/// Sends mousewheel messages to the control that the mouse-cursor is
/// hovering over.
/// </summary>
/// <param name="m">the message</param>
/// <returns>true if a mousewheel message was handled successfully</returns>
/// <remarks>https://stackoverflow.com/questions/4769854/windows-forms-capturing-mousewheel#4769961</remarks>
public bool PreFilterMessage(ref Message m)
{
if (m.Msg == 0x20a)
{
// WM_MOUSEWHEEL - find the control at screen position m.LParam
var pos = new Point(m.LParam.ToInt32());

IntPtr hWnd = WindowFromPoint(pos);
if (hWnd != IntPtr.Zero && hWnd != m.HWnd && Control.FromHandle(hWnd) != null)
{
SendMessage(hWnd, m.Msg, m.WParam, m.LParam);
return true;
}
}
return false;
}
#endregion IMessageFilter
#endif
__MonoCS__ is no longer defined, by the default compiler, since Mono version 5.
Even if, as you already noted, compiler and runtime might differ.

I have opened a pull-request which checks for Mono at runtime. If, it does not activate the mouse wheel filtering and prints a message to the console.

This needs reconsidering if ever WindowFromPoint, and maybe sendMessage, gets to works with Mono.
It would be safer to runtime-check if that function exists or implement the mouse wheeling differently.
But that is totally out of my league/time at the moment.

It should work flawlessly on Windows / .Net, but I cannot test that.

Anyway, have a nice weekend!
Title: Re: MAPVIEW upgrade
Post by: kevL on March 02, 2024, 11:13:36 pm
Thanks, you too.

ps. good luck with the other one (i cant make heads or tails of it)

if u really can't access options, the config files can be edited ... I suspect that the problem is not with Options per se, but with instantiating the propertypanel for user input
Title: Re: MAPVIEW upgrade
Post by: mikKoi on April 05, 2024, 03:51:00 pm
Hello
I have been using MCDView because of my custom LoFTs, but it seems to have thingies missing compared to MCDEdit
So, am I missing something? Great tools otherwise, btw :)

(Currently I start with MCDEdit and go to MCDView for the LoFTs, but then I must go back to set BigWalls and never can come back)

...edit
OK, figured out how to use custom LoFTs in MCDEdit 👍 but the defined BigWall digit(s) is still blocking me editing data files with MCDView afterwards
Title: Re: MAPVIEW upgrade
Post by: kevL on April 06, 2024, 02:32:14 am
ok, looking into it ... It's gona take me days or even weeks to get back into it (the code) ... esp. the idea of "editing multiple ID's bytes at once"

am not in the best of health,
Title: Re: MAPVIEW upgrade
Post by: mikKoi on April 06, 2024, 09:16:32 am
No problem, no more rush because I found a workaround for custom LoFTs. The main thing is that the MapView itself works great (although I can't get the Top view to show symbols from my LoFTs, but I can live with that)

Thx and take care!
Title: Re: MAPVIEW upgrade
Post by: kevL on April 06, 2024, 10:38:13 am
although I can't get the Top view to show symbols from my LoFTs

hm, interesting issue ... the blobs (as i call them) are determined somewhat arbitrarily after examining all parts in a tile ... ill have a look later to see if a default blob is feasible.