Outpost Universe Forums

Projects & Development => Projects => Topic started by: TechCor on November 13, 2019, 07:05:26 AM

Title: OP2 Mission Editor
Post by: TechCor on November 13, 2019, 07:05:26 AM
Hey there!

Welcome to another episode of TechCor's OP2 Projects!

Today, we are going to focus on the Outpost 2 Mission Editor.

This top post will be edited as development progresses - just like the C# Mission SDK.

https://github.com/TechCor8/OP2MissionEditor/releases (https://github.com/TechCor8/OP2MissionEditor/releases)

Mission Editor: https://github.com/TechCor8/OP2MissionEditor (https://github.com/TechCor8/OP2MissionEditor)
OP2Utility.NET: https://github.com/TechCor8/OP2UtilityDotNet (https://github.com/TechCor8/OP2UtilityDotNet)

Currently designing the feature set for this project. Additional details in the following post.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 13, 2019, 07:07:34 AM
This project is going to be built with Unity since I have a lot of experience working with it. It will make long-term maintenance a pain (annual upgrades), but it shouldn't take more than a few hours each year to update. It will be very important not to let the project rot to the point of being unsalvagable.

The editor's missions will work exclusively with the C# Mission SDK through the use of its JSON data files. There will be an extra feature to export the MAP portion through OP2 Utility, but for the most part, data will be saved in JSON. For devs that prefer to work in C++, don't forget you can link to the C# SDK and continue working in C++.

Feature Specification:
Code: [Select]
Menu bar
Import Map...
Save As...
Export Map...

Map Properties
Mission Properties
Player Properties

Map Properties

Mission Properties
MissionType (DropDown)
MaxTechLevel (DropDown)
UnitOnlyMission (Checkbox)

DaylightEverywhere (Checkbox)
DaylightMoves (Require DaylightEverywhere=false, Checkbox)
InitialLightLevel (int inputfield)

Music Playlist
Scroll list of tracks
Add track (dropdown)
Remove track
Move up/down
Repeat start index

Player Properties
Scroll list of players
Add Player
Remove Player

ColonyType (dropdown: Eden, Plymouth)
IsHuman (checkbox)
BotType (dropdown)
Color (dropdown)
Allies: Togglable scroll list of players
Center View X
Center View Y


Scroll list of completed research
Add topic (dropdown: Data pulled from tech file)
Remove topic

Paint Pane
Dropdown (Terrain, CellTypes, Resources, Walls and Tubes, Disasters, Units, Structures, Locations)

Tiles (Extract BMP)

CellType (dropdown)

Prebaked Icon
Common Mining Beacon
Rare Mining Beacon
- Yield (dropdown)
- Variant (dropdown)
- *Spawn Area (width/height)

- *Spawn Area

Magma Vent
- *Spawn Area

Circle Marker
DNA Marker
- *Spawn Area

- Type (dropdown: spaceship parts)
- IsVisible (checkbox)
- *Spawn Area

Walls and Tubes:
Prebaked Icon
Lava Wall
Microbe Wall

DisasterType (dropdown)
(If disaster has both src and dest areas, must place both for disaster area to appear)

*Areas are painted by clicking and dragging to create the size

Colony (dropdown: Eden, Plymouth)
Prebaked Icon
CargoType (dropdown: Convec=StructureKit, Truck=TruckCargo) Must be convec or truck
CargoAmount (int inputfield, cargo truck only)

Locations: (Used for triggers)
ID (alphanumeric?)
*Spawn Area


AI Base Preplanning

Please let me know if you have any feature requests or changes you would like to see, and also if you see any problems with the current list.
Title: Re: OP2 Mission Editor
Post by: Hooman on November 13, 2019, 10:11:06 AM
Slightly related, I had a project I was working on a while back that converted the Outpost 2 map file to JSON format. Not sure it would be useful to you though. It mostly just made use of OP2Utility, which you can use directly.

Would be good to have extra map data stored in JSON format, rather than forcing people to write executable DLL code.
Title: Re: OP2 Mission Editor
Post by: Vagabond on November 15, 2019, 08:31:26 PM

This sounds ambitious. Good Luck! I would be willing to do some light testing for you if it gets far enough along.

We should talk about your use cases for the sprites contained in Outpost 2. Currently, OP2Utility will just extract individual frames. You will probably want to show composite frames of structures. I wanted to program this, but wasn't good enough at the bitmap format at the time. I could take another look at it though if you think it would be helpful.

At any rate, please report any bugs are wanted features in OP2Utility. I'll see what I can do to accommodate the changes.


Hooman, if your ideas are fairly well fleshed out, maybe it would be good to get it in the repo so techcor can use it?

Title: Re: OP2 Mission Editor
Post by: Hooman on November 15, 2019, 10:26:23 PM
I'll have to dig up the project and upload it to GitHub.

Actually, I was just thinking, a C# project that could run with Mono would work on Linux. That would be wonderful. The current OP2 editor doesn't run on Linux, and trying to update it so it does sounds like a rather difficult undertaking.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 16, 2019, 11:48:37 AM
Just committed OP2Utility.NET's source to GitHub.

Unity can build to Linux, so the editor will work there as long as an ".so" can be built from the OP2UtilityForC project in OP2Utility.NET. Someone will need to check that source out and see if they can make an .so. No rush though, OP2UtilityForC has not been tested yet.


The editor has the menu options set up. Going to add the code behind them later tonight now that I have OP2 Utility for C#.
Title: Re: OP2 Mission Editor
Post by: Hooman on November 17, 2019, 07:26:45 AM
For those who are curious, the link to the project is:
https://github.com/TechCor8/OP2UtilityDotNet (https://github.com/TechCor8/OP2UtilityDotNet)

Edit: Ahh, I see now. You edited your first post and added a link.

Interesting how it converts the C++ API interface to a C compatible one, and then wraps C# classes around the C interface.

I gave the project a try from Linux. I needed to first get some Nuget packages with dotnet restore. The Microsoft build tools don't really know how to build C++ projects from Linux, but I was able to specifically build the C# project with either msbuild OP2UtilityDotNet or dotnet build OP2UtilityDotNet.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 17, 2019, 04:24:23 PM
Yes, the C compatible interface is what needs to compile on Linux. I suppose it needs a CMake file or something. I'm not familiar with it.

Since C# compiles to IL code, the DLL from Windows will work on Linux. The JIT compiler on the user machine should take care of it.

Although, I will need a special DLL anyway to change DllImport to point to the Linux C library. That is something I can prepare easily.


Looks like I am able to load and save maps and missions (File Menu). Going to look at rendering tiles to the tile map.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 17, 2019, 11:41:50 PM
EDIT: I fixed it! Turns out the map was upside down and the tile graphic indexes needed to be inverted.



Submitted editor source. It's currently just a "Map Viewer" where you can import and scroll around maps, adjust grid overlay color and alpha, and export the map. Not going to bother with a release build yet.
Title: Re: OP2 Mission Editor
Post by: Hooman on November 18, 2019, 01:44:51 PM
I tried checking out the project. There didn't seem to be a project file. I saw some DLL files, but no EXE. Not really sure how to run it.

Meanwhile, the JsonMap (https://github.com/OutpostUniverse/JsonMap) project that was mentioned earlier has been uploaded to GitHub. Probably not directly useful for your editor though.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 24, 2019, 08:13:35 AM
I tried checking out the project. There didn't seem to be a project file. I saw some DLL files, but no EXE. Not really sure how to run it.
The folder itself is the project file. You need Unity to open it.


Next major task is the paint pane.

Now that I have a better understanding of how maps work, it's clear that the mission API can't fully control the graphic in the tilemap. I thought the entire game was using one big atlas.

I'm thinking the two alternatives now are exporting the map and opm files separately (which is how these are currently read), and/or bundling them into a special mission vol file with a different extension that gets read by the C# Mission SDK. Maybe both.

So options in the File menu could be:

Open (omv / Mission Volume)
Import Map
Import Mission (opm)

Save (omv / Mission Volume)
Export Map
Export Mission (opm)
Export Plugin (Native C DLL hook)

Of course this would require modifying OP2 to look for maps from a different vol extension. Probably not worth it.
Title: Re: OP2 Mission Editor
Post by: leeor_net on November 25, 2019, 03:01:30 AM
Suggestion, it would probably be better to use the GitHub Releases feature instead of providing the release directly in the repository. Just FYI. :D
Title: Re: OP2 Mission Editor
Post by: TechCor on November 25, 2019, 03:24:21 AM

Quick brief about how to use the current version:

That's it for now!
Title: Re: OP2 Mission Editor
Post by: leeor_net on November 25, 2019, 09:11:03 AM
It's definitely a great working prototype! I gave it a shot last night and was generally impressed.

I dislike the UI as it's not native but that's truly a minor gripe.

Only thing I noticed is that when importing a map, it kinda hangs for a bit. Or at least, it appears to. If I had to guess I'd say it's doing a lot under the hood to convert to an internal format that the editor can work with. Might be good to add a loading text or change the cursor to a wait cursor, something like that. It's a comment about usability and UI's that are 'responsive' to the user. Granted this is early work so I wouldn't go too far into worrying about issues like that before functionality is in place. :D

Anyway, good work! I'm excited to see where this goes.
Title: Re: OP2 Mission Editor
Post by: TechCor on November 25, 2019, 12:56:08 PM
Yes, I would prefer native UI also, but that's the price to pay to use Unity.

I already profiled the import map. Most of the load is coming from color averaging the tiles for the minimap (about 75%). Maybe there is a faster algorithm. I've thought about skipping pixels, but that might affect image accuracy.

Actually, a loading bar is not a bad idea. I can have the percentage be the number of tiles loaded / total tiles. It would would look pretty smooth.
Title: Re: OP2 Mission Editor
Post by: leeor_net on November 25, 2019, 06:10:18 PM
A faster way to do it would be to average the colors of the tilemap itself, build an index table then build the minimap using the index table. E.g., tile index = color index = pixel or however you're generating the map. It's very fast in the prototype code that I built a couple years ago.

Could even pre-cache the index table, e.g., on first run as part of the set up go through all of the tilesets, determine an average color value and store in an index. Can save it out however you think is appropriate and then just load that if the file is present.
Title: Re: OP2 Mission Editor
Post by: Hooman on November 25, 2019, 11:56:13 PM
That's pretty much how the MapImager (https://github.com/OutpostUniverse/OP2MapImager) works. It loads the tilesets, then precomputes scaled tiles for the given scale factor. When it renders the maps, it uses the scaled tileset rather than the original one.
Title: Re: OP2 Mission Editor
Post by: pente on December 09, 2019, 03:52:12 AM
Likewise my python map code precomputes the scaled tiles for the desired scale. I put the code here https://forum.outpost2.net/index.php/topic,6275.0.html (https://forum.outpost2.net/index.php/topic,6275.0.html), it is pretty short and fast thanks to numpy magic.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 13, 2019, 08:41:04 AM
I finally have some time to work on this again.

I now cache a minimap tileset texture along with the regular one when they are first loaded, so that has been optimized. Thanks for the idea, Leeor!

Also removed unnecessary tile refresh which was already happening during SetTiles, and added a progress bar for importing.

Still can't get resourceManager working:
Code: [Select]
extern EXPORT unsigned __int64 __stdcall ResourceManager_GetResourceSize(const char* archiveDirectory, const char* filename, bool accessArchives)
ofstream outputFile;

outputFile << "archiveDirectory = " << archiveDirectory << "\n";
outputFile << "filename = " << filename << "\n";
if (accessArchives)
outputFile << "accessArchives = true\n";
outputFile << "accessArchives = false\n";


ResourceManager resourceManager(archiveDirectory);
std::unique_ptr<Stream::BidirectionalReader> stream = resourceManager.GetResourceStream(filename, accessArchives);

if (stream == nullptr)
ofstream outputFile;
outputFile << "hit 0";
return 0;

return stream->Length();

Prints out:
Code: [Select]
archiveDirectory = E:/Business/Freelance/Projects/Outpost2/Outpost2exe
filename = well0008.bmp
accessArchives = true
...and stream is null.

Tried different archive directories - with/without trailing slash, forward vs back slashes... Can't get it to work.

Will probably have to debug the utility itself to figure this one out.
Title: Re: OP2 Mission Editor
Post by: Hooman on December 13, 2019, 02:25:05 PM
I looked into this. From cursory examination, there may be a bug when the archiveDirectory does not match the current working directory. In that case, when scanning the resource folder for .vol and .clm files, all non-existent files (using the current working directory, not the resource folder) are filtered out of the search results. This causes the archives to not be seen and loaded. That would result in no packed files being found and nullptr being returned for the stream.

Edit: To debug, consider using GetArchiveFilenames to see if any archives are loaded.

Despite my earlier comment, I'm not sure a trailing slash is actually needed. For reference though, I would have used the path:
Code: [Select]

The trailing slash makes the name unambiguously a directory name.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 13, 2019, 05:25:58 PM
You are right; it ignores the passed in directory and uses the working directory.

Confirmed by putting art.vol into the current program directory which is NOT the directory being requested.

The working directory should be used when a relative path is specified. Absolute paths should override the working directory.

Can the OP2Utility project owner please fix this?

I will pull the fix as my copy of OP2Utility has not been changed.

Just want to add that I did check the archive count for the absolute path - it was zero. No archives at the specified directory.
Title: Re: OP2 Mission Editor
Post by: Vagabond on December 13, 2019, 07:55:30 PM
Hooman and I co-curate OP2Utility, although pull requests from the general OPU community would be welcome. I see he opened an issue against the described behaviour. We should be able to fix in fairly short order. Maybe best if Hooman picks the solution. My steering on the ResourceManager and XFile seems to have been poor...

TechCor, why don't you pull OP2Utility as a git submodule into your project so you can pull updates from OP2Utility easier into your project? Also might make it easier to push pull requests if you ever felt inclined.

Sorry for the defective code.

Title: Re: OP2 Mission Editor
Post by: TechCor on December 13, 2019, 08:15:58 PM
I've tried looking into submodules before, and couldn't figure it out. Possibly due to a limitation to referring to another user's repositories. I'm not sure.

Sorry for the defective code.
Let him who has not coded bugs cast the first stone. ;)
Title: Re: OP2 Mission Editor
Post by: lordpalandus on December 15, 2019, 02:22:28 AM
I've never coded insects into my code :P.

"Tosses a stone worth of insects at Vagabond."
Title: Re: OP2 Mission Editor
Post by: Hooman on December 16, 2019, 06:51:08 PM
I've tried looking into submodules before, and couldn't figure it out. Possibly due to a limitation to referring to another user's repositories. I'm not sure.

The mechanics of Git submodules can be a bit strange and unintuitive at times. The worst seems to be that recursive cloning is not the default. There are no restrictions on adding someone else's project as a submodule though. The submodule reference is entirely in the host repository, and doesn't require changes to the submodule's repository. Read-only access is sufficient.
Title: Re: OP2 Mission Editor
Post by: Vagabond on December 16, 2019, 07:27:13 PM

If you are interested in submodules and use TortoiseGit, I can write up a few lines to walk you through it. Hooman could probably write something similar for the Git command line. I understand if you are not interested though. Definitely agree recursive cloning should be default.

Hooman just merged in changes to OP2Utility that should fix the issue you were seeing with the ResourceManager. I think they are changes for the better.

Title: Re: OP2 Mission Editor
Post by: TechCor on December 17, 2019, 04:18:23 AM
I see my mistake. I thought it worked like .gitignore, and specifying a .gitmodules file would automatically work. Looks like it is working now.

Only complaint is that my project settings are different, and now I have a "dirty" submodule. Hmm..

Disappointed with how limited GitHub Desktop is. Doesn't appear possible to update submodules, or pretty much do anything with them.

Oh well.

Just tried out the fixed ResourceManager. Works great!

Thanks, Hooman!
Title: Re: OP2 Mission Editor
Post by: Hooman on December 19, 2019, 01:35:54 AM
Git submodules are version locked and tracked by a Git commit hash. If you modify a submodule, either through uncommitted changes, or by updating it to a new commit (such as checking out a new branch, or pulling new changes to master), it will show up as dirty. If you want to update the version of the submodule you are using, you need to make a new commit in the host repository. This is a bit of extra work, but it's also safer, since it ensures the version of the host repository matches up with a compatible version of the submodule dependency.

Be aware that when switching branches, it may not automatically update the submodule version for you. Hence you can also see the submodule appearing to be dirty when you switch between branches that use two different versions of the submodule. From the command line, you would run git submodule update to switch to the last committed version of the submodule.

Glad the changes are working for you.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 22, 2019, 03:56:29 AM
I've added an Export Plugin menu option that pulls the data from the top of Mission Properties and writes it into a plugin DLL using a template.

This all seems to work. I was able to change maps and descriptions and see the effect of flipping "Unit Only Mission" without any compilation.

The only issue I am running into is Outpost 2 is listing the colony mission twice. I'm unsure of what conditions would cause it to create two missions from one DLL. Clicking either of them opens the mission successfully.

In any case, it is looking very likely that compile-free mission building will be a reality fairly soon. :)


So it appears the problem is related to DLL filename length. Anything over 7 characters causes a second mission to be listed.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 24, 2019, 06:10:56 AM

Terrain painting is in!

The tile images in the paint window are loaded from the TileMappings that are in the map, grouped by tileset. You can't add new tile mappings (or tilesets) yet, so you would need to import an existing map with these set up.

Some other new features:

I'm going to do Cell Type painting next, followed by resources/units/structures.
Probably going to use a special set of overlay tiles to represent Cell Types that are only visible while in Cell Type mode.

Currently, there are 3 files required for a mission, Plugin.dll, map, and mission. Two, if you reuse a map. Not great but... engine limitations. I'm going to add Export/Import Mission file menu options and change Open/Save to perform all 3.

When you save, you will select the mission file name. Then the map will be exported based on what was set in the mission properties dialog. Finally, the DLL will be exported using the mission file name + the type prefix character based on the mission properties dialog.

When you open, you select the mission to open. Then, it will perform a resources search for the map specified in the mission properties dialog, and load it if it can find it.

This seems like the easiest way to handle mission saving/loading for the map designer. If anyone has any better ideas, I'm open to suggestions.

By the way, does anyone know what TerrainType is for? Looks like it is extra data for TileMapping that wasn't included to save space on duplicate data. It's the only explanation for "tileMappingRange". Setting up the editor to modify that looks like a real pain...
Title: Re: OP2 Mission Editor
Post by: Hooman on December 24, 2019, 06:52:30 PM
Hey, nice progress.

For the TerrainType, best I can offer is to look at the struct definitions, or perhaps find the .txt file about the .map file format. It's stored in the SVN repository along with the OllyDbg info.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 25, 2019, 05:03:03 AM
Moving as quickly as possible while I've got the free time:


Goal is to be able to create a multiplayer-type mission and play against the "experimental" AI by end of year (no triggers).
Title: Re: OP2 Mission Editor
Post by: TechCor on December 27, 2019, 10:07:18 AM
Keeping on:


Unit ID
I removed SpawnRects from the SDK and replaced it with Unit ID. Any object of the same type and the same Unit ID will be selected at random. This gives some good flexibility when it comes to placements. Units with zero/no ID are always placed. Eventually, Unit ID will also be used for triggers.

Future Plans / Mission Variants
While Unit ID is good for random placements, I want to have something similar to missions that have randomized start locations. Eventually, I am going to introduce the concept of "mission variants". By default, you will build on the primary variant. When you are ready, you can duplicate the primary variant, and modify all data that belongs to the new variant. Example variant data would include: Starting people and metals, beacon placements, unit and structure placements, and wreckage placements. A mission variant would be selected at mission start.

Up next, going to work on structure placements.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 28, 2019, 06:45:22 PM
Phew! Structures were quite a pain, but it is basically done. Need to tweak the mine text/health bar placement.

Here's what it looks like in the editor:

...And in case anyone thinks it doesn't actually work, I exported the mission and launched the game:

Some notes:

Issue of great importance:

Structures currently do not take on the color of the player. The images are PNGs with the Eden color baked in (these were converted from "art viewer"). I cannot think of an easy way / algorithm to convert the blue player color to another color. If anyone has an idea of what a shader algorithm would look like, let me know!

Otherwise, the only other option appears to be cutting out the player colors by hand for each frame (there are 1000), and making them a gray-scale overlay image that get tinted. The likelihood of me wanting to cut all those frames is extremely low.
Title: Re: OP2 Mission Editor
Post by: Vagabond on December 29, 2019, 01:15:29 PM
The old map editor spits out a source code file containing structure locations. That allowed the dll to properly assign colors once a game was initialized. If you are supporting multiplayer maps, I don't see a way around this since you won't know the color when making the map of each player.

The color is achieved by changing out an indexed bitmap pallet. There are 2 console modules cm1 and cm2 that demonstrate this if you want to check them out. Although I suspect you are looking for a more out of the box solution.

Looks like you have made some great progress.

Title: Re: OP2 Mission Editor
Post by: TechCor on December 29, 2019, 02:01:09 PM
I actually have no idea how the old map editor works. I looked at it about a year ago, but it was throwing exceptions (if that's the one you are talking about).

What I'd really like, is for OP2Utility to be able to read the .prt and art files and break the data into a digestible form. So essentially, I would read through a list of Sprite Groups, assign them to the appropriate map_ids, extract and convert the bitmaps similar to how I did the tiles, and reconstruct the sprites in the editor. I could even have everything animated.

Of course, that would be a lot of work. Too much to ask for, and too much effort for me to figure out the data formats myself compared to converting the bitmap frames to PNGs. Gotta get stuff done! ;)

So, the palette information is lost.

That's OK. I might pay a freelancer to cut up the player colors from the frames, or maybe I'll have time one day to extend OP2Utility. We'll be waiting a long time for the latter though. So many other things to work on.

Absolute worst case, I stick a colored circle on the structures to represent player color.
Title: Re: OP2 Mission Editor
Post by: Vagabond on December 29, 2019, 06:21:54 PM
I don't think the palette information is lost, I'm just not sure if there is an easy way for you to swap palettes real time in the map editor as Outpost 2 would handle it.

Yeah, I feel bad for not finishing the .prt and .bmp parsing for OP2Utility. There is a decent amount of work remaining to complete it, although I'll keep in mind you are looking for it. I think there are other priorities for me right now concerning OP2.

What I was trying to get at is that the color of a building is not set until a level is loaded since a player could choose a different color for multiplayer maps. How will your map editor handle this? I don't actually know what happens if you place a blue CC on a map and then start a mission as magenta... Maybe it would all work out?

I could send you a sample of the previous map editor's output. It is basically a .cpp file containing the code to create all the buildings for each player using TethysGame::CreateUnit. You could then include that .cpp file in your source code and have fully constructed starting bases without baking the building tiles into the map the map editor created. This really isn't a great solution, but I'm assuming it was the best that could be done for a reason.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 29, 2019, 07:21:16 PM
Oh, I see. I'm cutting the weapons now, and just thought about how the player color is still there, so if I can just find out what RGB values are used for the player color in the palette, I can pull the pixels and create gray-scale textures at startup, or better, make a shader that swaps on the fly. Just have to get the palette information...

Buildings aren't baked into the map tiles. The images just represent the building's location in the editor. The editor dumps the building locations and other info into a JSON file to be processed by the DotNetMissionSDK. TethysGame::CreateUnit ultimately gets called in the end.

The colors that will display in the editor will be whatever is set in Player Properties. When the game launches, the colors will only be set for single player missions with SetColorNumber().
Title: Re: OP2 Mission Editor
Post by: Hooman on December 29, 2019, 08:24:38 PM
Looks like pretty good progress.

For the player colors, the game does some palette remapping. I'm pretty sure there's something posted to the forums somewhere, and the art_reader utility could handle it. As I remember it, one of the palettes contains all the player colors. If I remember correctly, there are 32 palette entries for each player color, covering all shades of the color. That leaves room in a 256 color palette for 8 player colors, at 32 shades each. For the unit sprites, I believe the bottom 32 colors are remapped according to the player color palette. Just multiply the player number by 32 to get the starting block of the player's color. That block of player colors is used in place of the lower 32 colors of the image's referenced palette. I believe there is some kind of attribute flag bit for sprites, so the game knows what images to do this for.
Title: Re: OP2 Mission Editor
Post by: Vagabond on December 29, 2019, 09:42:22 PM
For an example color palette, see: https://forum.outpost2.net/index.php/topic,3907.msg62442.html#msg62442

For the code to modify the pallet within Outpost 2 see: https://forum.outpost2.net/index.php/topic,4332.msg65267.html#msg65267

The original palette should be contained in art.prt if not somewhere on the forum. OP2Utility may be robust enough to extract it with a little massaging. I could try to help extracting it if you would like to have it available and it isn't somewhere else on the forum already.

Title: Re: OP2 Mission Editor
Post by: TechCor on December 30, 2019, 08:30:25 AM
Thanks. I think I figured it out.

Player color palette is stored in Color.bmp. Popping it open in Gimp, looks like 24 colors per player, Blue, Red, Green, Yellow, Cyan, Magenta, then the rest of the palette is solid black.

I don't have any way to read the bitmap palette, so I'll recreate this in a PNG, and write a shader that takes an offset and count.

Looks like the images I'm using default to the first color, so I'll use that to determine which pixels need to change. Hopefully there aren't any duplicate RGB values in the source images.
Title: Re: OP2 Mission Editor
Post by: Hooman on December 31, 2019, 02:50:26 PM
Glad you figured it out. Thanks for the correct on the color count.

Do you plan to do the color remapping from an 8-bit indexed bitmap, or were you planning on converting images to true color and then somehow recognizing and remapping colors that way? If so, it's possible there could be some color reuse. I'm not aware of any though. Of course, this would be a great opportunity for someone to create a new color mod just to mess with that idea.  ;)
Title: Re: OP2 Mission Editor
Post by: TechCor on December 31, 2019, 08:47:18 PM
All the images are in true color, so yes, it's going to be a bit hacky, and it doesn't work with mods. I see this as a temporary measure until OP2Utility can provide adequate sprite data. I figure it'll be in use for the next year or two.
Title: Re: OP2 Mission Editor
Post by: TechCor on December 31, 2019, 09:40:04 PM
Painstakingly set up all the vehicle offsets. Here it is:

My little "game jam" is coming to an end, so I am going to post a build to all the work that was just completed:

Mission Editor v0.2.0
https://github.com/TechCor8/OP2MissionEditor/releases/tag/v0.2.0 (https://github.com/TechCor8/OP2MissionEditor/releases/tag/v0.2.0)

This is still very much pre-release. However, you can definitely set up a basic mission and play against the DotNet AI! No compilation required!

Unfortunately, no walls/tubes or player colors, but that will get in there eventually. Over the next couple months, I will focus on usability features such as a placement overlay, units on the minimap, player colors, moving and editing existing units, etc.

Editor Tutorial:

BACK UP YOUR OUTPOST 2 DIRECTORY. The editor does not confirm when overwriting files, and things can go very badly if you don't know what it is doing!
Known Issues:

That is it for now. There is still so much more planned! Let's hope 2020 is another productive year for Outpost 2 development!
Title: Re: OP2 Mission Editor
Post by: TechCor on January 05, 2020, 11:46:22 PM
Mission Editor v0.3.0:
https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.3.0 (https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.3.0)

This version focuses on usability improvements for existing functionality.


Note: Guard post crashing has been fixed in the DotNetMissionSDK, which is included in this release.

If anyone knows the lighting algorithm used by the game, please let me know about it. I'd like to emulate the light settings in the editor. Thanks!
Title: Re: OP2 Mission Editor
Post by: Vagabond on January 06, 2020, 09:44:10 PM

The editor is looking great. I downloaded it and give it a try. A couple of thoughts below. I'm overall very impressed, so don't take these as negative. It is a pretty massive project.

A big feature request is to store the cell index associated with a terrain tile and automatically update the cell index when the tile is placed. I spent many hours in the old mapper updating cell indexes to match my terrain types, when I usually just wanted to change the cell index to the default value of the terrain image. It would be nice to maybe disable this feature temporarily if desired, but default to updating the cell index. I know mapping all the cell indexes to tiles could be a pretty big time suck.

1. The initial dialog to change screen resolution and grid color doesn't seem to have an accept or ok button. I just used the top right X, but might be nice to add an OK button as I was a bit confused if it would cancel my settings or not.

2. I tested it on a laptop. The terrain tiles on the right side of the screen are pretty small. I had a difficult time distinguishing the tiles. It would be nice if they could be maybe doubled in size or more.

3. I tried creating a new mission. It just flashed a small dialog box too small for me to see and didn't seem to do anything else. When I tried opening an existing map everything seemed to work.

I appreciate that you allow saving maps in the original format. This would allow people who want to use C++ for mission development to still use your editor for map editing.


Concerning the lighting. Do you mean the shadows on buildings and vehicles or the day night cycle or building/vehicle lights in the dark?

The unit shadows are simply 1 bit bitmaps that are added to each image. They are contained in the .prt/.bmp file like other sprites.

The day night cycle and edge of light is produced by applying a mask over the tiles. The same principle is used for the blight but a different color is used. Hooman wrote a sample program to show how it works and you can find some details here: https://wiki.outpost2.net/doku.php?id=outpost_2:helper_programs:virus_mask. The program is written in Visual Basic and the source is available, so you could inspect it. I have a hard time reading Visual Basic code not being fluent in the language.

Quote from Hooman in how light/dark tiles are completed internally:
When determining which tile to display, it examines 4 tiles in a 22 setup, using 1 bit from each tile to get a 4 bit index. (There are 16 tiles in VirMask.raw). It's probably easiest to think of the actual virus display as being off by half a tile.

I believe VirMask.raw is contained in Art.vol.

EDIT: It appears the SVN repository is down again, so you might not be able to pull the source code. Someone might have a copy of it though if you want to inspect.
Title: Re: OP2 Mission Editor
Post by: TechCor on January 07, 2020, 12:52:43 PM
Thanks for the feedback.

I can have some code pull the most commonly used cell types for a tileset + graphic index from a bunch standard OP2 maps and  write it to a config file. Those can then be painted at the same time as the terrain graphics.

I haven't been focusing too much on the map capabilities since map editors already exist, so mission work is taking priority. Eventually, I want to add the ability to edit tilesets, mappings, terrain types, and create and paint tile groups.

- I will increase the size of terrain buttons to match structures/vehicles.

- When you start up, you are already looking at a new mission (no map loaded). If you import a map and then create a new mission, you will notice that you are taken back to this screen. I would have liked to select a blank map of some size, but starting from scratch looks complicated (no tilesets, mappings, or terrain types), and OP2Utility does not seem to support it anyway.

I was actually looking for how the big window/column of light is calculated. I assume it is some multiplier like "1 is daylight" and "0.25 is night" with some X sized column width, and Y amount of falloff. Also important is how the "initial light level" is applied, and perhaps the movement rate when daylight moves.

Knowing the other stuff will be helpful later, since I could have vehicle lights and paint blight.
Title: Re: OP2 Mission Editor
Post by: Hooman on January 13, 2020, 07:58:18 AM
It's been a while since I looked at the day/night cycle code. I don't think it was ever understood in great detail, though there were a number of calculations that were noted down. Well, the integer math was noted down. This is one of the few places in the code where floating point was used.

In OllyDbg, there was an object marked as DayNight. Internally, there is a daylightPosition field, which ranges from 0..65535. There is also another associated field actualDaylightPosition, which is set to daylightPosition * Map.tileWidth / 65536. Despite the name, it's possible that point actually represents the darkest point on the map.

During the update cycle, daylightPosition is incremented by 4. I'm not certain, but I suspect this update cycle is called every 4 ticks, so that may be why. The actualDaylightPosition is then updated according to the formula. The game engine doesn't have any other global references to the daylightPosition field, though does have a number of references to the actualDaylightPosition field.

When drawing unit graphics, the internal graphics API has a lightLevel parameter. It is calculated as Unit.tileX - actualDaylightPosition. There is some code that artificially bumps up the lightLevel by 512 when bDaylightEverywhere is not set. I had to check that a few times to make sure I was reading it right. From the looks of it, it might actually be a darkness level rather than a light level. In other places, if bDaylightEverywhere is not set, it bumps up the lightLevel by Map.widthInTiles.

There is also a Map.lightLevelBrightnessAdjustment array, which is an array of bytes (char). I believe that array somehow maps on to the bands of day/night across the map, though I don't think that area is well understood. In particular, I've never been too certain on how it determines the width of day/night regions.
Title: Re: OP2 Mission Editor
Post by: TechCor on January 14, 2020, 12:50:54 AM
Very cool. I want to expand HFL to include some of these items so I can view the contents, and maybe add the ability to control the day/night cycle speed. :)

I assume "Map.lightLevelBrightnessAdjustment" is referring to "54F854   0x5C   char[] lightLevel". What size is this array? numTiles?

Trying to understand this:
actualDaylightPosition is the current tileX daylight is on which wraps at map.tileWidth i.e. if the map is 256 wide, actualDaylightPosition is 0-256. Kind of a clever way to avoid a conditional wrap.

It looks like the "lightLevel" is the distance from the "actualDaylightPosition". To avoid a negative value, it adds 512 to it (max map width).
tileX - actualDaylightPosition + 512 = lightLevel:
0 - 512 + 512 = 0 (dist = -512, lightLevel = 0)
511 - 512 + 512 = 511 (dist = -1, lightLevel = 511)
511 - 256 + 512 = 767 (dist = 255, lightLevel = 767)
511 - 0 + 512 = 1023 (dist = 511, lightLevel = 1023)

Trying to envision what this would look like, but it seems like something is off. Maybe actualDaylightPosition/lightLevel is not related to the actual daylight, but instead lightLevel is an index into the "lightLevelBrightnessAdjustment" array (size 1024). Then the value returned from that array is used as a multiplier. This would give you "bands of light".

Total speculation, of course. :D
Title: Re: OP2 Mission Editor
Post by: TechCor on January 20, 2020, 03:26:54 AM
Doing a somewhat light (pre)release because of a breaking change, as I will not be available for a couple weeks. I don't anticipate any other breaking changes in the future, but can't guarantee that there won't be.

This introduces "Mission Variants" which allows for fairly good randomization of mission startup parameters without the need for code (or triggers in the future).

https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.4.1 (https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.4.1)

v0.4.1 - Added difficulty settings for "Gaia" units. Changed difficulty to use additive-override settings the same way variants were working. The benefit is decreased mission file size, more manageable work flow, and the ability to manipulate beacons and wreckage based on difficulty.

Breaking Change
Mission format (.opm) has changed to support "Mission Variants" and "Player Difficulty". Backwards compatibility is not available for pre-release builds. Mission files are human readable, so you can manually upgrade if you wish by adding the appropriate attributes.

Mission Variants and Player Difficulty are controlled through the new Mission Variants window found in the View menu. Mission Variants allow randomization at the start of a mission to help give it a bit of a unique flavor and prevent things from being too predictable. Player Difficulty settings affect starting resources and settings for single player and multiplayer games.

Mission Variants
Variants affect game settings such as daylight and music, as well as all units such as beacons, markers, wreckage, and all player settings and units. When the game starts, the master variant is always applied, and then a random variant is chosen to be applied as an additive override - the variant's units and resources are added, and non-countable settings like daylight and music override the master variant's settings.

Player Difficulty
Player difficulties affect a specific player's morale, tech, and units (resources) based on their chosen difficulty level. The default player resources will be applied to all difficulties, and then the chosen difficulty's resources will be added on top of those resources. For example, if "all difficulties" is set to 500 food, and "easy" is set to 100, the player will receive 600 food for selecting easy difficulty. Settings such as morale are overridden by the difficulty's settings. If a mission does not contain a difficulty, only the default resources are given. In our example above, it would be 500 food.

In single player, all players use the local player's difficulty settings. This means that AI player resources can be adjusted based on the selected difficulty.

Beacons, markers, and wreckage (gaia units) are only affected by difficulty in single player. These follow the same rules as above based on the local player's difficulty selection. This is useful for controlling beacon placements and whether wreckage is visible in lower difficulties. In multiplayer, only default resources ("all difficulties") will be applied.

By default, you are working on the master variant with "all difficulties" selected. The recommended workflow is to set up all non-variant resources and units for "all difficulties". Then, you create easy mode and add resources and units. Finally, when creating normal and hard, you can duplicate easy mode and remove resources and units.

After the master variant is finished, you can create a new variant which contains duplicate settings and no resource or unit data. Because variants are applied additively to the master variant, you will only need to make changes specific to this variant, such as additional resources and different beacon or player start locations. When adding a variant while another variant is selected, you will duplicate that variant's data.

Player counts and difficulty levels must remain uniform across all variants (enforced), so be careful when deleting those values as you will lose that player or difficulty for all variants.

- Added Mission Variants and Player Difficulty settings.
Title: Re: OP2 Mission Editor
Post by: Hooman on January 25, 2020, 04:22:26 PM
I was just thinking, the OP2Helper library allows defining a ResourceSet, which consists of 3 levels of Resources. A resource level within a set may be selected based on the difficulty setting, and specifies the exact values for each resource. That allows a developer to set starting resources for all difficulty levels, without doing math in their head. That might be a little easier to use than a base resource level plus modifiers.
Title: Re: OP2 Mission Editor
Post by: TechCor on January 25, 2020, 07:04:18 PM
There's an issue where units/structures/tubes/walls are all considered "resources", and obviously those have to have unique positions. That means they must be duplicated per player for each difficulty (and possibly per variant, if we are talking about that, too). This has all sorts of negative side effects for ease of use and file size. Duplication was how I first implemented difficulties.

To put things in perspective, I imagine a typical mission might have 3 variants with 3 difficulties per player. That's 9 different settings per player. 6 players = 54 resource sets to modify if they decide to tweak the numbers (or units!). Consider that standard multiplayer maps aren't the only use-case and resources could be different per player (ex: AI).

By using base + modifiers it becomes easy to quickly adjust multiple settings at one time, especially units. You maintain the flexibility of being able to modify all variants/difficulties individually without sacrificing the ease-of-use of just setting everything at the base level.

I understand it's not intuitive in its current form. I'm thinking that this is more of a presentation issue. Perhaps a label next to the input field with "+500" and/or "1500 total" on modifiers would be acceptable, which solves the "math in the head" issue. Maybe changing the input field color could indicate that you are on a modifier vs the base.

For units, the editor already "grays out" units that will be spawned for a difficulty/variant but belong to "all difficulties/variants" when a specific modifier is selected.

Finally, I will be adding a "help" menu option with documentation at some point that covers important topics like this.

Side note: I appreciate the feedback. This was very helpful even if I don't agree with the specific solution offered.

Here's a diagram if it helps people understand a bit better without reading a wall of text!


NOTE: Disasters and triggers will probably run through this same system.
Title: Re: OP2 Mission Editor
Post by: TechCor on January 29, 2020, 07:29:38 AM
Added ability to paint walls and tubes, and structures now render bulldozed terrain and tubes to more accurately represent the appearance in the game.

Version 0.5.0:
https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.5.0 (https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.5.0)


    - Made terrain pane tiles same size as vehicles/structures
    - Windows will sort to top when clicked
    - Menus will activate on mouse over if another menu is already open
    - Added Help menu with links to Outpost Universe, the forum, and the editor GitHub repository
    - Added About Dialog with version information
    - Added Walls/Tubes pane
    - Added bulldozed tiles and tubes for structures


Slowly rolling towards feature complete. The next major feature is the trigger system. This is going to be set up using an "Event, Condition, Action" style and will be applied per variant/difficulty using the same rules shown in the previous post. Aiming for maximum flexibility while still being easy to use. The intent is to be something like:

On Game Mark [50]
On unit entered region [Name]

[CurrentPlayer] food [less than] [5000]
[CurrentUnit] health [greater than] [50] percent.
Game Mark [greater than] [35]

Kill [CurrentUnit] (Could also be a unit ID)
Kill units in region [Name]
Spawn [UnitType] in region [Name]
Add [1000] food to [CurrentPlayer].
Wait [25] Marks
Repeat Trigger

I'll have to come up with a comprehensive list. DotNetMissionSDK doesn't have this system set up yet, so that will get done first before the editor.
Title: Re: OP2 Mission Editor
Post by: Vagabond on January 30, 2020, 09:43:10 PM
I'll have to try it out again here soon. I like the idea of auto painting walls and tubes. That is something the previous map-maker does not allow.

Title: Re: OP2 Mission Editor
Post by: Hooman on February 02, 2020, 07:57:29 AM
Sounds pretty neat.

I'd sort of like to give this a try, though not really sure how or if it can be done from Linux.
Title: Re: OP2 Mission Editor
Post by: TechCor on February 02, 2020, 09:14:10 AM
I can build the editor to Linux, but the OP2UtilityForC project needs to be built as a Linux library. However, I don't know how to compile to Linux, or if it can be done from Windows. Without it, the editor can't render or modify .map files, which is kind of essential...

Although rumor has it that Linux can run Windows DLLs through some kind of interpreter. WINE or something.

Here's a Linux version of the editor. I dropped the OP2UtilityForC dll in the root directory, but it probably won't work.
https://github.com/TechCor8/OP2MissionEditor/releases/download/0.5.0/OP2MissionEditor_Linux64.zip (https://github.com/TechCor8/OP2MissionEditor/releases/download/0.5.0/OP2MissionEditor_Linux64.zip)
Title: Re: OP2 Mission Editor
Post by: Vagabond on February 02, 2020, 06:12:57 PM
I can't tell if you are serious or joking about the WINE comment! Most Linux users run Outpost 2 using WINE and it seems to do a decent job. You might actually be able to run this in Wine. It would maybe help to target older versions of the .net framework in case WINE lags some from the most recent release...

If you want to formally support Linux, I would recommend adding an automated build using circleci. It would require crafting a makefile first though. Maybe Hooman could help with the initial setup. At the conclusion of a successful post build script you can have circleci save the build artifacts, which would give you access to the Linux build. OP2Utilty has a sample circleci setup you could use as a template if interested.

I'd be curious to see how the .net core Linux build goes. I have some .net core experience, but not with a Linux build.

Title: Re: OP2 Mission Editor
Post by: TechCor on February 03, 2020, 02:16:18 AM
I can't tell if you are serious or joking about the WINE comment!
I'm half-joking. I've met hardcore Linux users before (maybe all Linux users are hardcore?), Wine always comes up as the way to get Windows apps running on Linux. It makes sense for it to be a big deal since the Linux market share is too small to get dedicated development support for major applications. Personally, I've only dabbled with Linux to check some cross-platform applications. Never used Wine.

If you want to formally support Linux, I would recommend adding an automated build using circleci. It would require crafting a makefile first though. Maybe Hooman could help with the initial setup. At the conclusion of a successful post build script you can have circleci save the build artifacts, which would give you access to the Linux build. OP2Utilty has a sample circleci setup you could use as a template if interested.
I have no idea what you are talking about here. Seriously.

I'm sure a Linux expert could get this up and running in about 15 minutes because technically the editor core already builds to Linux, and OP2Utility seems to already build to Linux, so the only thing that needs to be done is build the OP2Utility C wrapper to Linux and drop it into the editor.

The OP2 Utility C# wrapper might need to be tweaked to read .so instead of .dll, but I think I have it set up right.

Just want to add that the editor runs on Mono, which takes care of the C# stuff.
Title: Re: OP2 Mission Editor
Post by: Hooman on February 03, 2020, 07:23:43 PM
I don't know how well Wine works with newer .NET stuff, though that may be a possibility.

I know a lot of C# stuff can be compiled natively for Linux. I would like to go that route if possible. I'm no expert on C# though, so I'm not sure what the process is. I don't even see a project file for OP2MissionEditor.

Any sense of how the project might be built outside of the IDE on Windows?

If I can get it working, I wouldn't mind trying to configure a CircleCI (https://circleci.com/) build for you. We have that, and AppVeyor (https://www.appveyor.com/), setup for other projects. Just push changes to GitHub, and it'll compile the code on all configured platforms, and let you know about any build failures. We even started adding artifact uploading and automatic GitHub releases. Push a git tag, and the Continuous Integration builds will automatically create binaries and upload them as a new GitHub release.
Title: Re: OP2 Mission Editor
Post by: TechCor on February 03, 2020, 09:07:25 PM
The OP2MissionEditor already builds to Linux through Unity. We can come back to this later, but you can't build "outside the IDE". Although I think they have a Linux IDE now. Not 100% certain.

Let's focus on the critical part of why it doesn't work. The project you should be looking at is OP2UtilityDotNet (https://github.com/TechCor8/OP2UtilityDotNet). Specifically, the project in the folder "OP2UtilityForC". This is just a C wrapper for OP2Utility. I need a Linux library (.so) generated from this project.

That library gets dropped into the OP2MissionEditor project as a plugin.


If you are interested in Unity for Linux:

https://blogs.unity3d.com/2019/05/30/announcing-the-unity-editor-for-linux/ (https://blogs.unity3d.com/2019/05/30/announcing-the-unity-editor-for-linux/)
Title: Re: OP2 Mission Editor
Post by: CaptCrims on March 10, 2020, 10:02:37 PM
This is Great. Really excited to check this out.

New here, outpost 2 was my very first pc game. Probably one of my favorite games of all time just found this site though. Install disk I've had doesn't read properly anymore.

Awesome to see people still keeping it alive in anyway.
Title: Re: OP2 Mission Editor
Post by: Hooman on March 10, 2020, 10:24:10 PM
Hello and welcome  :)
Title: Re: OP2 Mission Editor
Post by: Vagabond on April 19, 2020, 07:23:43 PM

I was going to use your mission editor to work on a mostly finished map. But when I downloaded it I got the attached error. I would see the Unity screen flash, then when it faded out, the error message would pop.

I tried pre-release versions 2-5 and got the same results.

I recently uninstalled a bunch of Windows SDKs from my computer, so it is possible that I deleted one that was required since the last time I used the editor.

Is there a way for you to lookup what the library dependencies are when you compile it?

I cloned your repo, but don't see the Visual Studio project file quickly. Then I realized it probably takes Unity to compile, which I uninstalled and would prefer not to reinstall in the short term.

Longer term, it would be nice if the warning provided the actual missing dependency. It may be possible to statically link the code in to prevent the dependency.

Also, small complaint, but all 5 release zip files are named the exact same. It would be nice if you added the version number or release date to the zip filename so I don't have to manually rename them when downloading multiple copies.

Title: Re: OP2 Mission Editor
Post by: TechCor on April 25, 2020, 02:14:03 PM
It may be the OP2Utility wrapper DLL. I built it in Debug for testing. Maybe a release build will fix it?

It just occurred to me that it says "Visual C++", which is probably referring to the CLR used to interop between C#/C++.

Maybe you can try the 64-bit redistributable. The DLL was built with x64.

64-bit: vc_redist.x64.exe (https://aka.ms/vs/16/release/vc_redist.x64.exe)

The link above comes from here: The latest supported Visual C++ downloads (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)

If this works, then I will need to set the Hub up to be able to install this since the Mission SDK relies on interop as well. I'll also link these in the GitHub pages.
Title: Re: OP2 Mission Editor
Post by: Vagabond on April 26, 2020, 09:43:30 PM

Thanks for looking into this. After trying your solution and it not working, I did a restore install of Windows 10 and everything was fine. I was also getting an error when Windows was trying to download a security patch for .net 3.5 and 4.8 which clued me into having a larger problem. Not sure if I uninstalled something I shouldn't have or if Windows messed up on its own.

On the clean reinstall, your program worked out of the box, so I don't think bundling the redistributable is mandatory. Someone would likely be doing odd things to their system for it not to work.

The individual sprites on the tile-picker are a bit blurry. Also, they are a bit small. It is really hard to match up terrain transition tiles in this format. I'll probably have to stick with the older editor for working on maps for now. The white border around each tile in the picker may also be making it a bit harder to examine how the transitions go together.

Making an auto-transition tool would be nice. Not all transitions exist for each terrain type though so it would involve adding some custom sprites. Outpost 2 can only support a finite number of tiles. We haven't reached the limit and I never counted to see how many new tiles would need to be added to complete a set of rational transition tiles. Since tile ranges exist, you would probably have to create an alternate well set that a newer map would draw from. Just for thought as I don't know if you were interested in pursuing it or not.

Overall it is looking nice and was fairly intuitive in how it loaded.

Title: Re: OP2 Mission Editor
Post by: TechCor on May 06, 2020, 09:43:57 PM
Someone else was having the same issue, so I finally commandeered a non-dev, non-gaming machine for testing.

I don't quite get the same error. It instead shows as an exception in the editor's console about OP2UtilityForC. Installing the vc_redist.x64.exe solves the problem, but I also changed the DLL to a release version which uses the release dependencies. I'm not sure if the debug version also works with the redist.

I've updated the 5.0 Windows release to use the release DLL, and added the redist to the ReadMe.

Vagabond probably restored to a version with the Windows 10 SDK, which seems to also fix the problem, and is more likely to support debug builds.
Title: Re: OP2 Mission Editor
Post by: Hooman on May 21, 2020, 08:34:44 PM
I don't believe Debug builds have a redistributable. According to the licence terms, the debug builds are not distributable. Essentially, people need a dev machine to be running debug builds.
Title: Re: OP2 Mission Editor
Post by: leeor_net on May 22, 2020, 10:30:39 AM
Debug builds are not redistributable, MS is pretty adamant about that. I'll pass this along on IRC as there were a few questions about it. Thanks!
Title: Re: OP2 Mission Editor
Post by: Vagabond on May 22, 2020, 04:10:47 PM
Correct that compiling to depend on the C++ runtimes needs to be in release mode as debug builds will fail to find a proper dll outside of machines setup for development. To make matters worse the failure message doesn't clearly state that it is looking for debug dlls when failing.

Hooman is right that Microsoft does not condone distributing code complied against the debug dlls. I don't think there is a reason to compile in debug mode for a release though. I think it is typically just forgetting to switch to release mode before final compilation and not noticing until moving out of a development environment.
Title: Re: OP2 Mission Editor
Post by: leeor_net on May 23, 2020, 08:58:53 PM
There's also the whole debug builds are considerably slower than release. I have a demo app I developed that runs at like 14 frames per second or so in debug build but runs at over 1000 frames per second (or at least frames drawn per second) in release builds. Not all applications will get the same sort of speed boost but suffice it to say that debug is not designed for high performance.  :o
Title: Re: OP2 Mission Editor
Post by: TechCor on May 30, 2020, 12:59:33 PM
Yes, everything has been considered "prerelease" up to this point as everything was still in development. I left it in debug so that other developers could give useful stack info if they ran into problems.

I work full-time now, so development has slowed considerably. I'm going to create a user-friendly prerelease, since the full release may be quite some time away.

Here's my checklist to get done this weekend:

I'll have to figure out how people have been running OP2 on Linux and what the limitations are. I assume whether or not it works comes down to dependencies on Windows system calls.

DotNetMissionSDK requires .Net Framework 4.6.1 or higher to run. I tested with 4.7.2. Going to link this...

Outpost2.exe seems to require VC++ redist x86 to run. Going to switch editor to use x86. Editor now uses x86.

There is a crash bug in the mission editor if the game directory specified is deleted or moved. The editor becomes completely inaccessible, and the directory would have to be deleted with "regedit". This will be fixed in the patch release. Fixed.

Added 6 player FFA Bot Match - Pie Chart to Mission Hub.

DotNetMissionSDK - Quite the hassle getting setup, but once Outpost 2 is working with wine tricks, launching a .NET mission appears to work after installing the .NET Framework through Wine Tricks. Took me a couple hours to figure out.

I used VirtualBox with Ubuntu Desktop v20.04.
Title: Re: OP2 Mission Editor
Post by: TechCor on June 01, 2020, 02:53:24 PM
New (minor) Release:


Linux is now supported.

Updated documentation to make required redistributables clear.
Title: Re: OP2 Mission Editor
Post by: Hooman on June 09, 2020, 08:40:38 AM
For Linux, are you doing a Windows build with Visual Studio, and then running under Wine on Linux? Have you tried building natively on Linux?
Title: Re: OP2 Mission Editor
Post by: TechCor on June 10, 2020, 04:27:23 PM
The editor is built with Unity which compiles into Linux native w/ Mono. You don't need Wine for the editor or hub.

Outpost 2 runs with Wine, so DotNetMissionSDK is running through that with .NET 4.6.1 or higher installed via Wine Tricks. The editor creates missions that run using the DotNetMissionSDK.
Title: Re: OP2 Mission Editor
Post by: TechCor on July 18, 2020, 06:48:11 AM
Another minor release:

https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.5.2 (https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.5.2)

The Visual C++ Redistributable is no longer required to run the editor.

Fixed an issue where dragging windows would not move at the same speed as the cursor for certain resolutions.
Title: Re: OP2 Mission Editor
Post by: Vagabond on February 27, 2021, 08:05:35 PM

I was trying to use your mission editor to import a map (v0.5.2). When I click import, the bottom of the window shows NullReferenceException: Object reference not set to an instance of an object.

Then the top ribbon becomes unresponsive, I cannot flick on 'File', 'Edit', etc.

The rest of the editor remains responsive.

I'm using the GoG version of Outpost 2, and pointed to C:/games of gold/Outpost2 as the working directory for the mission editor.

The map works properly when used in Outpost 2, so I don't think it is being caused by a corrupt .map file. I tried a second map with same results.

Using Windows 10 64 bit.

Title: Re: OP2 Mission Editor
Post by: TechCor on March 03, 2021, 06:40:26 PM
The editor was built against the old OPU release. Seems to work fine on there.

I'm not clear on why GOG is different.

Logs say that well0000.bmp is found in the GOG directory.
2120 bytes are loaded.
The BMP library then tries to parse the BMP data, but immediately runs into an issue:
The first two bytes (header) does not match an expected BMP format:
Code: [Select]
Read: 16976
Expected: 19778
It then rejects parsing, and later code throws an exception when it tries to use the missing texture.

If I try to skip the header, it just fails later:

Code: [Select]
Unsupported image format: 524288
The GOG format must be different. Perhaps it is compressed and OPU was not? What was different about OPU?

I used the editor to extract well0000.bmp to a file and it can't be viewed (GOG version. OPU-OK). Further investigation shows that this file is stored in different .vol archives. OPU had it in art.vol at size 2102, while GOG has it in maps.vol at 2120. Both are marked as uncompressed. I'm not sure what is going on here.
Title: Re: OP2 Mission Editor
Post by: Vagabond on March 04, 2021, 06:05:28 PM
Oh, funny I was just working on this in OP2Utility. Outpost 2 is capable of reading tilessts as 8 bit Windows bmps or a custom bmp-like format. The original game shipped with the custom format you are encountering. We had been shipping with the standard format pre GOG posting. Check Tileset.h in OP2Utility for how to load the custom format. I added after your original port of OP2Utility.
Title: Re: OP2 Mission Editor
Post by: TechCor on March 05, 2021, 06:58:48 AM
I have this working and will submit a fixed version soon, but I have a question about OP2Utility.

Code: [Select]
// Read tileset represented by Outpost 2 specific format into memory
// After Reading into memory, reformats into standard 8 bit indexed bitmap before returning results
BitmapFile ReadCustomTileset(Stream::Reader& reader);
This seems to imply that the resulting BitmapFile will be in a standard format.

I used this and then wrote the data back out to a byte array to pass to a third-party library.
While the image would load, it was upside-down due to inverted scan lines.

I see some other manipulation in that function, notably bitmapFile.SwapRedAndBlue(), but it does not call bitmapFile.InvertScanLines()

So the question is: Are inverted scan lines considered "standard format"?

It seems strange to me that I have to check for inverted scan lines before writing out a standard bmp, but it could be a deficiency in the library I'm using.
Title: Re: OP2 Mission Editor
Post by: Vagabond on March 05, 2021, 10:55:41 AM
That may be a bug in OP2Utility. It should have presented scan lines correctly after loading and translating into Windows Bitmap file. You probably need to just set the height value to negative to invert. There is sample code in OP2TilesetConverter that I thought was proving it wasn't inverting incorrectly but I probably need to check my assumptions.
Title: Re: OP2 Mission Editor
Post by: TechCor on March 05, 2021, 07:08:10 PM
The output looks correct through Windows viewer. The other lib just doesn't invert when the height is negative, so I will just need to check for this.

GOG works correctly. All unit tests are passing.

I am having an issue with BitmapFile.ReadIndexed on OPU 1.3.7 for well0001.bmp in art.vol.

Code: [Select]
The size of pixels does not match the image's height time pitch.

If I remove the exception, the image loads fine.

These are the passed in parameters:
Code: [Select]
VerifyPixelSizeMatchesImageDimensionsWithPitch(bitCount = 8, width = 32, height = 8608, pixelsWithPitchSize = 275458)

The first three parameters look correct based on the file property dialog in file explorer. I am not sure how to verify the last one.

I'm curious if this affects OP2Utility C++. The ported code looks to be identical for this function.

I studied the bitmap format a bit. This looks like a case where the BMP file is not formatted to spec. Windows/OP2 ignore this as there is enough information to correctly parse the file.

The BMP pixel container size is 2 bytes more than what it should be. It has two extra bytes of padding at the end that put it out of the 4-byte alignment specification. It is awkward, but it appears this just gets trimmed by most apps/libraries for rendering since the width/height properties will not use the full container.

For OP2UtilityDotNet, I am going to change the exception to only throw when the file's container size is too small for the width/height/bitCount. If there is extra fat at the end, it will pass validation. This appears to work successfully.

It may be worth considering doing this for OP2Utility C++ as well.

Commit for this change:
Fix for bmp files with excess padding. (https://github.com/TechCor8/OP2UtilityDotNet/commit/d6651f666acbcdaa5f35d2320310ae3cdeb7da2b)
Title: Re: OP2 Mission Editor
Post by: Vagabond on March 06, 2021, 07:26:09 AM

Interesting that the third party library you are using doesn't understand negative height. I thought that was a pretty important part of the bitmap specification.

I had noticed that whoever did the original conversion of the tilesets in the Outpost Universe release completed the conversion using a non-standard pitch but I never really addressed it.


What do you think about supporting non-4 byte alignment for pitch? I think you had advocated for this before but I may be remembering wrong. I'm not an expert on the format, but I think TechCor is probably correct that several editors support non-bitmap standard pitch settings, although I'm not sure the specifics on why they are doing this. I think I would agree that we should relax this test condition and allow reading the file if OP2Utility is able to determine pitch settings even when out of standards. Actually, I think that branch I started early last year and just deleted a couple of months ago was to geared towards supporting this but we weren't happy with the specific implementations method I was working towards.
Title: Re: OP2 Mission Editor
Post by: Hooman on March 23, 2021, 01:08:58 AM
Oh wow, I'm just seeing this now. I haven't been checking the forums as much recently. I spend much more time over on GitHub these days. Probably doesn't help that I haven't been getting notifications of forum activity.

I don't remember saying anything specific about pitch padding. (I would probably use the term "alignment" for the start address adjustment, and "padding" for size adjustments).

I would recommend to pad to a 4 byte boundary when writing. It might be good to accept any amount of padding when reading.