Messages

16

Tools / Re: MAPVIEW upgrade

« on: October 07, 2019, 07:30:08 pm »

That looks like... different from your screenshot.
Looks like good!

17

Tools / Re: MAPVIEW upgrade

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

18

Tools / Re: MAPVIEW upgrade

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

19

Tools / Re: MAPVIEW upgrade

« 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!

20

Tools / Re: MAPVIEW upgrade

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

21

Tools / Re: MAPVIEW upgrade

« 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

22

Tools / Re: MAPVIEW upgrade

« 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 
Moreover, it made Mono builds much stable.

23

Tools / Re: MAPVIEW upgrade

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

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

24

Tools / Re: MAPVIEW upgrade

« 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 

25

Tools / Re: MAPVIEW upgrade

« 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

26

Tools / Re: MAPVIEW upgrade

« 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

27

Tools / Re: MAPVIEW upgrade

« 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 

Waiting for your solution, then

28

Tools / Re: MAPVIEW upgrade

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

29

Tools / Re: MAPVIEW upgrade

« 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 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


30

Tools / Re: MAPVIEW upgrade

« 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!