Plan for Outpost 2 1.3.9

[Vagabond]

Now that Outpost 2 1.3.8 has been out for a while, I thought it would be worth pinging what people were interested in including in the next release.

Currently lined up changes:

• op2ext improvements
• Multiple console module loading
• Run function hook for ini modules
• Concept of Built in Modules within op2ext
• Ability to toggle Built in Modules on and off with the Outpost2.ini file
• Repackage of IPDropDown as a Built in Module
• Plymouth Cold War bug fix and rebalance
• Garage save load bug patch as a Built in Module (currently partially implemented)

Some other Possibilities

• Update to Net Fix Client (some work was completed months ago, but it really didn't finalize and needs much more work)
• Colony game Mesa Missions (partially designed)
• Multiplayer coop Mission Out of the Frying Pan (partially designed)
• Add a built in module to patch gaining free resources by manipulation of the spaceport dock (would require diagnosis first with ollydbg)
• Add a built in module to patch placing buildings without comitting ConVec to construction (would require diagnosis first with ollydbg)

Open to other ideas. Also open to discuss what we think the right timeline is to draw the line and make a release. Perhaps a good stopping point would be the Garage Bug Patch Built In Module implementation. Might be nice to bring in a couple more Built In Modules to show off the new feature better. If people are looking for new content, I could focus on finishing Mesa Missions. I'm happy to help bring to closure whatever the plan is.

-Brett

[steev]

Looking forward to it. Wish i could help out in anyway possible but been so busy.

[Hooman]

For short term priorities, I would list the Garage save load bug patch, and getting a new version of op2ext packaged. There's been a lot of good work on that project, though most of it won't be visible to end users. The changes are perhaps more valuable to maintainers, and maybe to some developers working on game modules. The main benefit seems to be that we'll be able to more easily write new patches. That is maybe something we should focus on for the next little while going forward, though not necessarily all for the next release.

I'm quite happy about the fixes for Plymouth Cold War. The crash bug had been long outstanding, so I'm glad that was finally diagnosed and fixed. New missions would always be good. I often feel we had a disappointing lack of new content, so it would be good to increase the variety of levels to choose from. The lack of new content is something we probably need to focus more on. I believe we need to reduce the barriers to creating new content.

I agree about patching the resource duplication bugs. Though that's going to hurt the speed runs that were posted a little while back. I guess they'll need to be redone. I'd be fine if that got bumped to a future release though.

NetFix needs a bit of attention. I'm not sure how to estimate the level of work required, nor the time it would take.


I think we may need to put a bit of effort into more general areas not directly tied to a release. In particular, we could make some updates to the site to make it a bit more engaging. To get a bit meta, we may also want to produce more content about producing more content. There seems to be some curiosity about producing new content for the game, but because of the steep learning curve, many people get scared off after dabbling a little bit and then running into some sort of difficulty. Perhaps we could produce some walkthrough articles or videos that show how stuff is done. In particular, workflows for downloading projects from GitHub, or creating new levels from the template projects on there.

Related to that, we need a new map editor. The old one is unmaintainable. There is no legal free Visual Basic compiler for people who want to update the front-end. Even going the paid route, the Visual Basic compiler and IDE hasn't been updated in about 20 years. The back-end is written with legacy COM code, and old style C/C++ idioms with raw pointers. Most of the backend code has been rewritten into modern C++ style in the OP2Utility project, but there is no map editor front-end that uses it.

[leeor_net]

A decent map editor would be a huge leap forward. There was my experimental code which is still hosted on GitHub -- it's literally just experimental to see if it could be done. Since I adapted the landlord code, a lot of work was done on the back end that could be used to provide a superior implementation to what I have here. There are also limits to the code, specifically in loading the tileset assets -- they would need to be 24-bit and the original assets are 8-bit. Because it's based on NAS2D as its middle-ware, it will barf with 8-bit assets.

I played around with an SDL2 version that cuts out the NAS2D middle-ware -- it would be less fragile and lighter weight but it suffers from the problem of not having a native GUI. It's also in C++ which is painful to use when developing a GUI application.

TechCor is working on something as well though it looks like it's a Unity application? I like the idea of using C# to build a GUI version of an editor... and I suppose Unity is a reasonable choice, I just personally hate developing on Unity because I found it extremely painful to work with. Granted, it's a visual editor for the most part and surprisingly enough I don't do well with visual development environments... definitely prefer to mingle down on the code level of things.

Still though, it would probably be faster to develop that way and C# is very well suited to GUI applications. I'm finding that Windows Forms are hard to work with when you need them to do more than native Controls... probably can do something using OpenGL or DirectX but I'd need to do more research into that.

[Hooman]

I would like to see a bit of work put into the landlord project. I was able to compile it on Linux, though when I tried to load it the GUI appeared to be missing image and text assets so the user interface was pretty unusable. I guess there is some assumption about resources, such as those tilesets, which isn't well documented.

On a side note, I run the Linux command line tool cppcheck over a number of OPU projects, and it picked up a problem in this one.

Code: [Select]

Checking src/Map/TileSetManager.cpp ...
[src/Map/TileSetManager.cpp:13]: (error) Using 'memset' on struct that contains a 'std::string'.

This seems to result from some old code that I wrote for OP2Editor which got reused here, but with a field type change from char* to std::string.

I was going to open an issue for the above, but it seems there's no issue page on that project link. I assume because it's been forked from elsewhere. I checked the original repository, but it seemed to be far out of date from the forked copy.


Having a C# map editor sounds interesting. Sounds like it may be easier to develop a map editor using C#. I have no idea how to run it on Linux though. It would be kind of interesting to see what might happen if there were 2 competing projects.


A number of the OPU projects on GitHub have been getting ReadMe files added and updated. Hopefully this will make the projects easier to use for people who want to dabble. (It might still be a couple days before the changes are merged in to master. Some of it needs a bit of proofreading and editing).

[leeor_net]

There are some assets that I left out of the repository as they 'infringe' on copyrights and wanted to avoid that problem on GitHub. I attached a ZIP file to this post with the assets that are expected.

It is very much prototype code and if you dig around in it you'll see that I pulled the COM based code you wrote and adapted it (read removed COM). This was before OP2Editor code had been updated so one major change would be to pull the frankenstein code out and instead link to the much better OP2Editor code -- could even be done as a submodule since it doesn't need to necessarily be a compiled binary. Should eliminate that warning/error you're seeing.


I'm less inclined to create a 'competing' project so much as a 'sister' project -- one that runs on and generates native C++ code and one that runs on and generates .Net code. I'm not convinced which is the better approach. Anyway, aside from that, I see a big benefit in code sharing and co-development of features.

[Vagabond]

Work on Outpost 2 1.3.9 has stalled for various reasons. While I suppose there will not be an official release for this posted, I'd like to complete a release of op2ext at a minimum as lots of work was put into it. I think it will be version 3.0.0 as we made a couple of breaking changes to the public interface. Although to my knowledge, no one had publicly posted any content utilizing the changed areas, so practically speaking, it should break anyone else's binaries.

I would really like to see the Garage save/load patch added into op2ext. Hooman, you haven't by chance taken another pass on that before I try to button op2ext up?

We played through some multiplayer matches using a compiled copy of op2ext from the master branch on GitHub without any glitches. It hasn't been thoroughly tested, but between that and the unit tests, hopefully it is fairly stable.

-Brett

[Arklon]

I would really like to see the Garage save/load patch added into op2ext.

Is the patch actually written? All I've found is discussion on reproducing the bug.

[Vagabond]

Correct, the patch was never finished. Code here faithfully reproduces the bug every time: https://github.com/OutpostUniverse/GarageSaveLoadBugModule/blob/master/GarageSaveLoadBugModule.cpp

There is another repo that can be compiled into a mission to assist with quick testing when paired with the op2ext module above.

We never translated that into an actual fix unfortunately. Hooman was looking into rewriting a function from assembly into C but I don't think it was ever done.

-Brett

[Hooman]

Yeah, no, I never got around to finishing that.

Most of my effort in recent months has gone towards OPHD stuff.