FO/FO2 Map Viewer

First off, I apologize for taking so long to reply - had some real life stuff that came up.

I'm currently creating a Windows 7 VM, on which I should be able to debug the app, without having to worry about (relatively) trivial matters like visual style support - something that xp doesn't have, which may add complications to rooting out the real cause. In addition, the version of vstudio used to write this, doesn't install in xp.

I do appreciate all the feedback, and help you guys have given me - and apologize for not testing this out fully, on other platforms, before releasing it.

Oh well, I guess those learning experiences just keep on comin' :p

Thanks for your patience :/

Update: The problem with the config file generated by the program, boils down to a simple typo. In the current version, the config file it generates, contains the following line:

Code: 
< supportedRuntime version="v4.0" sku=".NETFramework,Version=4.0" />
<supportedruntime version="v4.0" sku=".NETFramework,Version=4.0">

When it should read:

Code: 
<supportedruntime version="v4.0" sku=".NETFramework,Version=<strong>v</strong>4.0">< supportedRuntime version="v4.0" sku=".NETFramework,Version=[B]v[/B]4.0" />
<supportedruntime version="v4.0" sku=".NETFramework,Version=<strong>v</strong>4.0">

The "v" was missing before the 4.0 in the sku attribute.

However, that only covers the .NET error box, not the reason why the app would crash. That turned out to be nothing more than stupidly using real paths, instead of relative...which is why it worked *perfectly* on my computer...and nobody else's.

So, that's fixed. Even tested it out on a "virgin" Win 7 box (i.e. no Vstudio installed), and loaded up fine.

Now, it's still not working on xp - but that, is likely due to visual styling, and I'll go ahead and work on that, by making it use a "normal" window in that case.</supportedruntime></supportedruntime></supportedruntime>
 
Last edited:
Alright, I figured I'd put this up since it should now be working for all of you.

Fallout MapViewer 0.1.2 Beta

quick rundown of what's changed:

  • Config file now properly (re)generates, without throwing that silly .NET error (remember to delete any existing ones!)
  • Most importantly: Paths have been fixed, so it should actually run now
  • A border has been added around the main window, to help separate it from the background, if Aero isn't enabled
  • Further style changes were made so that it maintained the same appearance across Windows 7, Vista and XP.
  • App will now adjust for xp's lower level of desktop graphics support, by using software rendering and skipping the drop shadow.


As always, please let me know if you run into any issues. :)
 
Last edited:
Still crashes for me saying it needs .NET 4.0 :'( But I'll let others chime in, maybe it's just my computer.
 
Sduibek said:
Still crashes for me saying it needs .NET 4.0 :'( But I'll let others chime in, maybe it's just my computer.
Click to expand...


Grab the latest one (0.1.2)

and make sure you delete whatever exe.config file you may have in that same folder.

The only time you'll see that .NET 4.0 thing is if the typo exists in the generated config file.

alternatively, you can open it up in notepad, and change the line:

supportedRuntime version="v4.0" sku=".NETFramework,Version=4.0"

to

supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"
 
TheEart said:
All files extracted from the .DATs - including critters.
Click to expand...
When there will be a support .DAT files without their unpacking?
Click to expand...

At some point after I get all the Fallout 2 maps working. It's certainly, in my mind, a requirement for it being truly finished - but I want to make sure that everything is working with the unpacked files, before adding the complexity of opening files directly from the .dat file.
 
Is that why it's not working for me, perhaps? I did not read anywhere that unpacked data files were required. So I need to unpack all files from master.dat AND critter.dat or just master.dat?
 
Sduibek said:
Is that why it's not working for me, perhaps? I did not read anywhere that unpacked data files were required. So I need to unpack all files from master.dat AND critter.dat or just master.dat?
Click to expand...

The program will still open regardless, you'll just get errors if you attempt to open a map file. But yes, both critter and master.dat need to be extracted at this point.

If you're seeing this error:

As29eyl.png


the only cause is a bad config file.

1. Delete anything with the name "Fallout MapViewer" in the folder - including the application.

2. Download it again here.

3. Extract the application from the .rar file, to the desired folder

4. Run it.
 
Update: working. It was crashing due to my mistake; I was trying to run it from the desktop prior to this post. I hadn't realized it needed to be in Fallout directory, for some reason I'd just assumed it did some sort of auto-detection or could be configured what directory to search after opening. I apologize, that's my mistake for sending you on a wild goose chase.

Suggestions:
1) Text next to the button icons, instead of just icons. (top-right)

2) Maybe to avoid user stupidity like mine, you could start by informing user it need to run from Fallout directory with data files unpacked (via message box) and if it doesn't find those files. (this to avoid confusiong .NET Framework crash messages)

3) Assume DATA\MAPS subdirectory relative to Fallout directory, if run from valid location (i.e. files needed for #2 above have been located)

Questions:
4) Does it matter if the files are read-only? (The map files and other files your program needs to read) i'm currently running it in an setup where all extracted Fallout files (~25000) are Read-Only.

Also not sure if bug or oversight, but if I have Windows set to not auto-hide Taskbar, mapviewer still goes to bottom of screen if maximized, i.e. it goes under taskbar and can't be seen unless I un-maximize it.

Looks great so far :clap: Official mapper you can hit "i" key to display over objects their scripts, any chance your mapper can do that? Also I assume the X/Y coords and hex numbers is pending, I didn't find an option to enable those.
 
Last edited:
Sduibek said:
Update: working. It was crashing due to my mistake; I was trying to run it from the desktop prior to this post. I hadn't realized it needed to be in Fallout directory, for some reason I'd just assumed it did some sort of auto-detection or could be configured what directory to search after opening. I apologize, that's my mistake for sending you on a wild goose chase.

Suggestions:
1) Text next to the button icons, instead of just icons. (top-right)

2) Maybe to avoid user stupidity like mine, you could start by informing user it need to run from Fallout directory with data files unpacked (via message box) and if it doesn't find those files. (this to avoid confusiong .NET Framework crash messages)

3) Assume DATA\MAPS subdirectory relative to Fallout directory, if run from valid location (i.e. files needed for #2 above have been located)

Questions:
4) Does it matter if the files are read-only? (The map files and other files your program needs to read) i'm currently running it in an setup where all extracted Fallout files (~25000) are Read-Only.

Also not sure if bug or oversight, but if I have Windows set to not auto-hide Taskbar, mapviewer still goes to bottom of screen if maximized, i.e. it goes under taskbar and can't be seen unless I un-maximize it.

Looks great so far :clap: Official mapper you can hit "i" key to display over objects their scripts, any chance your mapper can do that? Also I assume the X/Y coords and hex numbers is pending, I didn't find an option to enable those.
Click to expand...

It should be able to run from anywhere - although I did notice a new issue that seems to have something to do with permissions of some sort, when attempting to run it from the desktop. I'll have to look into this more. If you can, alt+print screen the error message, upload it, and share. Because I think whatever is causing that - is the root of the trouble. Also, please include the path to your fallout folder - just to see if I may have overlooked something. The closest I can get to replicating what you're working with, the better chance i have to track down this pesky little bug :p


1. I think I see, and agree with your reasoning on that; but let me bounce this off of you. I admit that relying on tooltips, and only having certain options available on the toolbar, is bad form. To remedy this, the next release will not only have a View menu, with the filter options - complete with text; but there will also be a status bar that will display what the tooltip does now. While I don't really want to clutter things up by adding text to the toolbar area, I hope that both of these combined will fill that suggestion.

2. This, as I mentioned above, is something I really need to get to the bottom of. Because, regardless of whether you have the files extracted, or where you run the program from, it should at least open. Believe it or not, there are several checks while it's attempting to load the map - although it is still pretty light. The point remains though, that if you're getting crashes before you even attempt to load a map - then my problem is somewhere else.

3. That's something that it *should* do already - but only if the Data path isn't already set. However, *should* and *does* are obviously two different things. I will double check this behavior; but something tells me it's related to the other issue.

4. Read-only shouldn't matter, as long as the config file isn't - as that's the only thing it writes to. Everything else is merely a matter of reading the various files. That being said, while it shouldn't need admin rights, there may be something to that. In fact, for whatever reason, there's certainly a permissions related issue that just showed up for me, while attempting to run from desktop. So yes, I definitely need to look into that.

5. It's a bug and definitely not intended. I assumed that all windows would respect the taskbar, which was obviously wrong. :p This will be fixed on the next release.

After reading your question about the scripts, I went ahead and finally got around to downloading the official map editor. And the answer is...I'm not completely sure where to get that info yet. What I'd like to do, is to parse the MSG files, to get the in-game names/descriptions for the various critters/items; but I have to do some more digging to see how everything is tied together.

As far as the X/Y stuff for the tiles/hexes there has been some progress with that. While I'm still working on an efficient way of actually displaying the grids with numbers, the status bar has a section for both hex and tile info based on where the mouse pointer is.

http://i.imgur.com/hCfdno1.png

I'm happy you like it so far, and especially, that you were able to get it running. But I'd be a lot happier when I can get these bugs squashed :p
 
Fallout MapViewer v0.2.0 Beta

Notes
Just some things to be aware of...
  • All files still need to be extracted from the DAT files (work on reading from DATs will continue once I'm sure the program itself is working properly for everybody)
  • Fallout 2 Maps are still not supported entirely

Changes

Fixes:
  • Application will now properly respect the taskbar when maximized
  • Due to possible permissions related issues, settings are now stored in a local application data/appdata folder.
  • DATA path checking/discovery has been rewritten, and will now verify the path, even if it's set in Preferences.
  • Application would crash upon opening the preferences window more than once - this has been fixed.

Additions/Improvements:
  • A View menu has been added, containing redundant filter options with icons/text.
  • A Status Bar has been added, which will describe icons/menu choices with more detail
  • Hex/Tile information will now appear in the status bar for the location under the mouse pointer.
 
Hello,
I would like to use the program, but none of the download links work any more.
 
I will look in my repository, it is possible that I still have a file.
but it’s bad that this has not been brought to release and it does not work with .dat files.
 
So...uh I guess I got distracted. 6 1/2 years. I really wasn't intending to bump this thread, but as JDFRG did the honors already this year, I might as well give an update.

I finally got around to revisiting this project - and decided I needed to go back to the start. I have a habit of rushing towards a goal when it's in sight, which makes expanding on things a lot tougher down the road. So this time around, I've done things the right way. LST,PRO,MSG,MAP,FRM,and PAL formats. Maps are parsed via using the related PRO files, allowing for exact object parsing, and better yet, it's all taken directly from the DAT files, instead of having to use loose files like some savage.

MAP parser has successfully parsed every Fallout & Fallout 2 map - only hiccups were not realizing that the PRO LST files are 1-based, and I may have to adjust the FRM LST files for this as well, but I'll take a look when I get to that point. When I start generating a map, and it spits out a picture of stairs instead of a door, well, I guess I'll know :lol:

I started writing the parsing in C/C++ again, with the intention of just using C# for the UI, but in the end, I decided to just keep it simple and do it entirely in .NET. For a moment I thought I was still going to have to use some C/C++ for the compression, but Decompress works great for Fallout 2's zlib compression, and I was successfully able to port a c-based LZSS class to C# for Fallout. I still plan on using the original UI, with some minor changes due to it getting data directly from the DAT files. You'll be asked to pick the Master.DAT, which it will then use to detect the game, and provide a list of maps to pick from.

I'm currently finishing up porting what I finished in C++ to C#, which includes the parsers, game detection, and a resource manager. The latter essentially stores loaded FRM/PRO files in memory, as they're needed, to avoid having to load them from disk again. That way, when the map needs 50 of the same file, the other 49 can be grabbed straight from memory, instead of having to access the DAT file 50 times. Memory overhead should be minor, in exchange for speed.

So anyway, that's where I'm at right now. /shrug
 
Mr.Stalin said:
Lib in C# to extract resources from DAT. https://github.com/FakelsHub/DatLib
I think you can figure out how to apply it.
Click to expand...
Thanks, but already did it the hard way

Truth be told, parsing the two formats was the easy part - and thanks to .NET adding Deflate support, decompressing files from the FO2 DAT, was as simple as removing the two byte zlib header from the beginning of the data.

LZSS decompression for Fallout was the most time consuming- after falling to find a suitable class, I just ported the c/c++ implementation I was using. Most of that just entailed replacing the pointer math with indexing and converting the types to c# equivalents

I just need to figure out how to track down how to display NPC's real names, and then do the work to hook up my original UI to the new backend.
 
If you disappear for a long time again, don't forget to upload the source code, because I recently had to decompile your exe with the ILSpy utility.
I wanted to rebuild it, but your app has some third-party stuff in the form of WindowChrome, which had problems during the build.
 
You must log in or register to reply here.
Back
Top