"Non-fatal error in ReadPrt: Couldn't read OP2_ART files"

[Lugiathan]

So I keep getting this error popup when launching the OP2Mapper:


And then when I try and create a map I get this other error popup that tells me it can't load the tileset:


When I click OK, the client freezes or crashes. I cannot load existing map files or I get a very similar error popup.

I have tried running the mapper from a freshly downloaded copy of OP2 1.3.7 to no avail.

Anybody know how to fix this? I am running Windows 10.

[Lugiathan]

I waited several days to post this and then discovered the solution on my own within 60 seconds of asking for help. Funny how that works.

Anyway, the solution is to go into Options and manually add art.vol to the list of "additional" VOLs to look at.

[Hooman]

Thanks for the post. This is a usability issue that we should address.

[leeor_net]

Two solutions:

1) Find a copy of VB6 just before we burst into flames.
2) Hammer out a new editor that doesn't suck so hard.

As a note, the editor has served its purpose and is about as good as one can expect out of VB6 and the inexperienced developers that we were nearly 20 years ago when this was built... but I think it's really time to retire it and build something a lot better. I know the back end code has dramatically improved between the work that you, Hooman, and Vagabond have put into it.

I put together something in C++ more as a proof of concept than anything else (especially considering our conversations about how painful it is to develop GUI code in C++). It might make more sense to build something new using C# and interop with the vastly improved backend API. Not sure how well managed and unmanaged code works together... perhaps Vagabond can weigh in on that? I've never tried... it seems like it'd be a headache and a half to get working right without exploding in my face but that comes from my lack of experience making C# work with unmanaged native code.

[Arklon]

Not sure how well managed and unmanaged code works together... perhaps Vagabond can weigh in on that? I've never tried... it seems like it'd be a headache and a half to get working right without exploding in my face but that comes from my lack of experience making C# work with unmanaged native code.

This is actually the one very legitimate use case for C++ .NET/CLR: making an interop shim layer between C# and C++ code. In general, C++ .NET is an abomination, but it's actually quite convenient for this purpose since it natively interops with CLR and unmanaged C++.

[leeor_net]

Fair point. I remember once trying to build a .NET application in C++... it was absolute misery and I swore I'd never attempt it again. Ever. Of course I was trying to build a GUI application using .NET/C++ which is probably why it was so flipping painful.

[Vagabond]

Leeor,

I did some research a couple of years ago on how to wrap or decorate C++ functions to allow them to be called from C#. Unfortunately, I never actually implemented any of it so I've forgotten most of it.

I guess the question is which is less painful

 - 1. Calling code between 2 different programming languages
 - 2. Writing a GUI in C++

The nice thing about designing a set of decorated function for OP2Utility is that it would facilitate use of the library in C# for other projects in C# as well as some mapper.

I am proficient in C# though, so might be in a decent spot to work on some sort of C++/C# bridge project if we really want to go that route.

I thought you had a nice start on a C++ version of a new mapper though.

-Brett

[leeor_net]

I guess the question is which is less painful

 - 1. Calling code between 2 different programming languages
 - 2. Writing a GUI in C++

Writing a Windows GUI application in C++ is way more painful unless we use something like wxWidgets/Qt but those have the unfortunate side effect of a learning curve (also I think wxWidgets is probably better in this case purely because it uses native OS calls).

I thought you had a nice start on a C++ version of a new mapper though.

Perhaps? But it uses a custom-built GUI library built on top of NAS2D (which is now out of date and has a lot of usability limitations because I didn't feel like building things like text selection and scrolling among other things) and I'm finding that has a lot of limitations and its own learning curve for other developers. The good thing, at least, is I can probably push the GUI part of it while others work on the lower-level stuff. Basically what I'm saying is I'd like to see a native GUI app over a full-screen game-like application that pretends to be a GUI app though I suppose the only real benefit to the native GUI app is not having to build each and every custom control/widget.