Author Topic: MAPVIEW upgrade  (Read 85565 times)

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #435 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]

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #436 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.

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #437 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

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #438 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,

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #439 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.

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #440 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 :)

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #441 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 -- 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.
« Last Edit: October 02, 2019, 01:10:40 am by kevL »

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #442 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
« Last Edit: October 02, 2019, 09:36:33 am by osd_daedalus »

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #443 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

Online Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 5594
  • Aaand we're back!
    • View Profile
    • My Wiki
Re: MAPVIEW upgrade
« Reply #444 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.

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #445 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
« Last Edit: October 03, 2019, 06:06:41 am by kevL »

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #446 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 :)

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #447 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

Offline kevL

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: MAPVIEW upgrade
« Reply #448 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 ;)
« Last Edit: October 03, 2019, 11:10:29 pm by kevL »

Offline osd_daedalus

  • Sergeant
  • **
  • Posts: 17
    • View Profile
Re: MAPVIEW upgrade
« Reply #449 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 :)
« Last Edit: October 04, 2019, 12:43:14 am by osd_daedalus »