OP2 Mission Editor

[Hooman]

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.

[TechCor]

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.

EDIT:
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.

[TechCor]

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


Changes:

    - 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

Upcoming:

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:

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

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

Action:
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.

[Vagabond]

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.

-Brett

[Hooman]

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.

[TechCor]

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

[Vagabond]

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.

-Brett

[TechCor]

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.

EDIT:
Just want to add that the editor runs on Mono, which takes care of the C# stuff.

[Hooman]

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 build for you. We have that, and AppVeyor, 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.

[TechCor]

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

EDIT:

If you are interested in Unity for Linux:

https://blogs.unity3d.com/2019/05/30/announcing-the-unity-editor-for-linux/

[CaptCrims]

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.

[Hooman]

Hello and welcome 

[Vagabond]

TechCor,

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.

-Brett

[TechCor]

It may be the OP2Utility wrapper DLL. I built it in Debug for testing. Maybe a release build will fix it?

EDIT:
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

The link above comes from here: 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.

[Vagabond]

TechCor,

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.

-Brett

[TechCor]

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.

[Hooman]

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.

[leeor_net]

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!

[Vagabond]

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.

[leeor_net]

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. 

[TechCor]

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:

• DotNetMissionSDK - Disable AI test code (targeting markers).
• DotNetMissionSDK - Make release build.
• DotNetMissionSDK - Update GitHub with release build (used by Hub).
• OP2MissionEditor - Use release build of DotNetMissionSDK.
• OP2MissionHub - Check support on test machine.
• OP2MissionEditor - Check support on test machine.
• DotNetMissionSDK - Check support on test machine.
• OP2MissionEditor - Update GitHub with release build.
• OP2MissionEditor - Remove old releases from GitHub. Clearly marked as developer only.
• DotNetMissionSDK - Test GOG version compatibility.
• OP2MissionHub - Test Linux compatibility.
• OP2MissionEditor - Test Linux compatibility.
• DotNetMissionSDK - Test Linux compatibility.

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.

NOTES:
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.

LINUX:
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.

[TechCor]

New (minor) Release:

v0.5.1
https://github.com/TechCor8/OP2MissionEditor/releases/tag/0.5.1

Linux is now supported.

Updated documentation to make required redistributables clear.

[Hooman]

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?

[TechCor]

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.

[TechCor]

Another minor release:

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