OP2 Game Flow Redesign (PhaseShift v0.5.0 released!)

[Vagabond]

Crow!,

We are discussing adding the ability to query which mods are active on GitHub. I would like to start coding it this weekend so you have it available. Feel free to comment if you have any suggestions. The query must be c compliant sense we try to honor the C ABI for cross-dll communication.

https://github.com/OutpostUniverse/op2ext/issues/69

You could probably bring up a dialog telling the player they need to load the phase shift module and then exit the scenario instead of just disabling if you want.

I'm no help on the beacons, but that sounds like something that would belong in HFL if it existed. We added 3 functions to OP2Helper to improve posting messages if you are interested in using them. They have been pushed into the current master OP2MisionSDK repo.

-Brett

[Hooman]

I believe you can use a building enumerator to find the unit record for the mine. I'm not sure if you want the mine building, or the mining beacon. Try either of:

Code: [Select]

PlayerBuildingEnum(Player6, mapMiningBeacon); // Gaia

PlayerBuildingEnum(playerNum, mapCommonOreMine);
PlayerBuildingEnum(playerNum, mapRareOreMine);

From there, you could use a bit of HFL style memory hacking to access the value at the offset you want.

[TechCor]

I don't think I found beacons through PlayerBuildingEnum, but I could be wrong.

Try it with PlayerUnitEnum(Player6, mapMiningBeacon)


For getting beacon data, there is a solution I use in my own HFL library that you can find on my GitHub.

Here's the key parts:

Code: [Select]

struct BeaconData
{
	int numTruckLoadsSoFar;
	int barYield;
	int variant;
	char oreType; // [0 = common, 1 = rare]
	char unknown1;
	char unknown2;
	char surveyedBy; // [player bit vector]
};

and to get the data for the struct:

Code: [Select]

BeaconData* p = (BeaconData*)((int)(*unitArray) + (unitID*120) + 0x58);

Credit goes to some awesome poster from 2011 or so.

[Hooman]

Yes, that should work, provided you have a way of finding the correct unitID / unitIndex.

If you really need to, you can implement your own enumerator class. A few people have done that before. If you can't use an existing enumerator as a base, then you can always try looping over the unit array manually and determine the unit type. The game usually determines the unit type in a bit of a roundabout way:

Code: [Select]

unitRecord.GetUnitTypeInfo().unitType;  // enum map_id

The GetUnitTypeInfo() method is the first method in the virtual function table. The unitType field is at offset 0x4 in the UnitTypeInfo class (the first field after the virtual function table pointer).

[Crow!]

I think I'm following all this unit record navigation stuff except for the (*unitArray) part.  Is that one array global to the game, or something created by our enumeration, or what's the deal?  And, more to the point, where will I find it?

[TechCor]

unitArray is in UnitEx of HFL.

Here is an implementation of beacon data with accessor methods:

https://github.com/TechCor8/OP2DotNetMissionSDK/tree/master/NativeMissionSDK/NativeSDK/HFL/Source

The two important files are UnitEx.h and UnitEx.cpp.

[Vagabond]

Crow!,

I've partially implemented the changes required by op2ext for detecting which module(s) are loaded. Hooman is providing code reviews and technical guidance on how to implement, which will really improve the final product.

I'm hoping to be far enough along to provide you a test build this coming weekend. The code will be partially unit tested, but would be looking for feedback from you on usability and any bugs you might find.

While you are testing, I may continue to rewrite the backend of op2ext to allow more through unit tests.

-Brett

[Crow!]

Phase Shift v0.4.0 is done, and is attached to this post!  A summary of the changes is here, too.

A couple outstanding coding issues remain, both regarding the hookup with op2ext:
- op2ext did not replace savnt213.wav, even though it was in the mod folder.  I might be misunderstanding how a .wav file replacement is done.  I want the mine depletion alert to say "Mining location diminishing," but instead it will just make the smelter selection noise.
- As noted by Vagabond above, there is some new functionality I'm waiting on; once it is ready, there should not need to be the separate vanilla vs phase shift versions of Ohana.  (For now, the PhaseShift download only contains the PhaseShift version of the map.)


Change log:
PhaseShift specific maps will now alert the player when a mine is running out.
A map specially designed for PhaseShift, Ohana, is now included with the mod!  (Bundled map version is 0.3)
Minor edits to Mine.txt to make it work better with the way the above mentioned alert is implemented.
Slight increase to mine "trickle" output after it has been depleted.
Initial maximum morale reduced; Medical Centers and the colony-specific morale topic effect on max morale increased.
   The important thing to know is that you must get something other than just Nursery and University tech to get beyond Poor morale.
Guard Post base price reduced.
Scorpion armor class is now None instead of Light.
Reduction of some buffs to Scorpion-related research rates.
EMP missile research cost and maximum scientist count increased.
Observatory's Scientist cost lowered.
Meteor Defense common metal, worker, and research costs lowered.

[EDIT] Replaced attachment with PhaseShift v0.4.1, which updates the Ohana map to version 0.4, which fixes an issue where Ohana's SE base's N wall wasn't solid.

[Vagabond]

Crow!,

Could you post your new sound effect for troubleshooting? I've never attempted to replace a sound effect before so would need to look at it to give advice. Unsure if op2ext will pickup the new sound effect without testing.

Thanks,
Brett

[Crow!]

Sure.  Here's the file.  I placed it in with the other files in the PhaseShift folder, and I told the mission to play sound sample 167 along with the message, but I got "Struture Lost", the unmodified version of the sound sample, instead.

[Crow!]

I wasn't able to do any multiplayer tests of PhaseShift this weekend, but I did get some vanilla games in, and earlier today, I did an offline test of PhaseShift.  I found a couple things that needed changed, so here we go:

-----------

Phase Shift v0.4.2 updates:

Fixed a bug that prevented the Diode Lasers upgrade from being researched.
Structure Factory cost reduced to 1600, and building time reduced to 2000 "points" (was 2500 for each).
   This is for the same reason, and to about the same degree, as the Command Center change.

[Hooman]

Hmm, seeing as how you've got evolving versions, have you thought about putting this work up on GitHub? Have you used Git before?

[Crow!]

Sure, why not.  I usually avoid using git for releases of my work because it scares off the not-technically-inclined, but I think the OP2 community can handle it.

https://github.com/iICrowIi/OP2PhaseShift

[leeor_net]

So I see that there's no actual source code for the mission itself.

[Hooman]

Oh yeah, you've got the compiled DLL, but no source for it. And a zip file, which I assume is mostly just the contents of the repository?

That stuff could be packaged as a Release on GitHub:
https://github.com/iICrowIi/OP2PhaseShift/releases

Admittedly I still haven't figured out how the Release section works, though Brett has been making good use of it with his projects.

As you've said, it might also make sense to repost the release package on the forums for the less technically inclined. It's much harder to sort through old releases on the forums though. GitHub is a bit more organized in that regards. Same if anyone wants to use a prior version of the tech tree edits or something.

Anyway, thanks for putting it on GitHub.

[leeor_net]

Release on GitHub is pretty simple. Create a tag, then make a release based on the tag. If you don't provide binaries it'll still provide a tar and zip of the repository sans binaries. You can then add release notes (markdown style) and it's good to go.

[Crow!]

SirBomber and I had a game yesterday.  After some thoughts on how it played out, here's the result:
https://github.com/iICrowIi/OP2PhaseShift/releases/tag/v0.5.0

Change summary:
Updated packaged Ohana map and scenario to version 0.5, which fixes some terrain, allows victory via either Starship launching OR Last One Standing conditions, makes the first common and first rare mine always the same variant, and replaces the backdoor 1-bar common with a 1-bar rare, and increases the initial metals for Medium and Low starting resources.
GitHub release now features Ohana's source code.
Common Ore Smelter, Rare Ore Smelter, and Robot Command Center costs reduced slightly.
Robot-Assist Mechanic tech removed.  Garage is now available with Cybernetic Teleoperation.
Advanced Robot Manipulator Arm's prerequisite is now Advanced Vehicle Power Plant.
Scout-Class Drive Train Refit research time slower and now requires Advanced Vehicle Power Plant.
All starship components (including the cargoes) cost 25% less common and rare metals.

-----

I had been dragging my feet on Ohana because it had some changes that weren't actually working yet.  Now they are, so its source is available now, too.

At some point I'll have to set it up in a way that makes the parts that need to be included in a PhaseShift map more easily portable; for now, the morale and the mine depletion alert repeating triggers and trigger handlers in main.cpp have to be copied.

-----

Outstanding PhaseShift issues:
Scorpions may be too strong in the period of time where Advanced Combat Chassis is blocking the next tier of weapons.
Advanced Armoring Systems messes up the idea that some weapons (especially Acid Cloud and ESG) are supposed to do better vs swarms of light units than against Tigers.  I want to remove it, but am not sure if it should be replaced with something else as that happens.

-----

Oustanding Ohana issues:
Incorporate a way to ask op2ext whether PhaseShift is active or not so it can use a single .dll
Add Disasters when that check box is selected

[Vagabond]

Crow!,

I did some research on your sound issue. Outpost 2 will not pick up individual sounds placed loosely. It looks like you have to bake the sound effect into sound.vol.

I recommend packing your sound effect into sound.vol. Then you can place the modified sound.vol into your mod directory. Outpost 2 will pick up and load your sounds instead of the default when the mod is detected. You can use OP2Archive to do the packaging. Beware that it has outstanding directory selection issues that I still need to clean up. So you might have to get creative and command the package from a relative or absolute directory or something to get it to work. Sorry, but I made some poor decisions on how XFile was coded and have been working other things instead of cleaning it up. If you have too much trouble, I'll focus on fixing it.

op2ext currently has 2 outstanding bugs that are in PRs. If these get merged in, we should be ready for you to take a beta build of it and test the ability to detect the module name. I'd like to continue beefing up the unit tests some more if I find some time.

Let me know how the sound effect integration goes. I suspect it may be coded incorrectly and play as static once you get Outpost 2 to detect it. I tested by overwriting the sound effect Tokamaks play when you click on them.

[Hooman]

Ahh, sweet! Source code


Looks like you're using a slightly outdated level template. Nothing wrong with that. Just wanted to point out there is an updated version at:
https://github.com/OutpostUniverse/LevelTemplate

A few differences with the newer version:
 - A .gitignore file was added, as not all files need to be versioned (*.user, .vs/, Debug/, Release/ ReleaseMinSize/).
 - The old Visual Studio 6 project files were removed. (Version 6 is circa 1996).
 - Main.cpp was split into LevelMain.cpp and DllMain.cpp. Most people only care about LevelMain.cpp. The slow compiling Windows specific stuff usually goes in DllMain.cpp. There was a default HFL init call added to DllMain.cpp.
 - It's pre-setup with an AppVeyor config file for online Continuous Integration builds. (You'd need an AppVeyor account to enable it).
 - Updated APIs with numerous small additions, fixes, and renames.
 - APIs can be updated with a Git submodule update. No need for manual downloading and unpacking.

All of it optional. No need to upgrade, though some changes could potentially make your life a little bit easier.

----

The sound file thing is interesting and unexpected. For game data, I've seen Outpost 2 treat free files the same as stuff packed in VOL files. Not sure why sound would be any different, though this may warrant some investigation. In terms of repacking a VOL file, do you really need to repack the full VOL file, or can you add an additional VOL file?

[Vagabond]

Crow!,

I just posted a beta release of op2ext that allows checking which console modules are loaded.

https://github.com/OutpostUniverse/op2ext/releases/tag/ver2.2.0-beta

You should be able to check if your module is present by calling the following from within the mission's InitProc function:

Code: [Select]

if (!IsModuleLoaded("TestModule")) {
	... WARN USER / CLOSE MAP / CHANGE MAP BEHAVIOUR ...
}

Let me know if you need any help setting up.

Thanks,
Brett

[Crow!]

To be clear, if I implement this, will the map crash for anyone who hasn't downloaded this version of op2ext?

[Vagabond]

Crow!,

You should not mix versions of op2ext when playing multiplayer scenarios. I would recommend making a dev copy of Outpost 2 and a regulary play copy of Outpost 2.

Since the function only exists in this new build of op2ext, if you call the new function from a mission DLL with the old op2ext DLL, the game will crash (As it should because it cannot find the function and the application must abort).

Hope that answers your question.

Also, if you return false from initProc, the mission will abort with the attached message. It would be better if a more descriptive dialog popped up saying the given module wasn't present. I have only used modal dialogs on mission startup with colony games. If you want me to play with a multiplayer modal dialog, let me know.

[Crow!]

OK, the module loaded check in that build of op2ext seems to be working how I want it to for Ohana - the mission already had two different initial setups coded in, depending on a single bool I had been setting to a different value depending on whether I was building the vanilla or PhaseShift version.  So, initializing it with:

Code: [Select]

bool isPhaseShift = IsModuleLoaded("PhaseShift");

Is, in my local tests, correctly building the bases and applying new morale and mining rules according to whether the PhaseShift module is loaded.

It is possible I'd like to have a more understandable error message given to the player for a colony game if I have it refuse to load due to not having PhaseShift active, but I'm not sure if that necessarily has to involve op2ext.


As for the audio issue, I have confirmed that packing the replacement sound into voices.vol placed in the mod's directory causes static when the game attempts to play the sound.

[Vagabond]

Crow!,

I just tested and you can load a modal dialog box into Outpost 2 before passing false back from InitProc. This would allow you to give a custom message. Rising from the Ashes contains a dialog box at the start of the mission that you can use as a template. You can check out Rising From the Ashes here: https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/LevelsAndMods/trunk/Levels/RisingFromTheAshes. In the same repository is Plymouth Cold War, by Black Box, which would be another implementation to check out.

Also, you should read https://wiki.outpost2.net/doku.php?id=op2_sdk:textdialogbox. This article will spell out the basics on getting a dialog box to work (unfortunately, it is fairly complex if you are unfamiliar with resources and the rich text format (RTF).)

see the attached screenshots for examples. The downside is it would produce 2 dialogs. Not sure if you could suppress the second dialog, but I think it would be okay either way?

The quote below is pulled from OP2Archive's Readme. It explains how specific music tracks must be encoded to get working with Outpost 2. I wouldn't be surprised if there were similarly complicated rules for Sound Effects. Unfortunately, I'm not aware of anywhere that the information is stored about the exact format. Maybe you could reverse engineer the settings from an existing sound or maybe someone else could help. Sorry. I do know that Outcasters used custom sound effects, so it is possible.

Outpost 2 audio tracks must be formatted as WAV files with the following settings:
 * Frequency = 22050 Hz
 * Channels = 1 (Mono)
 * BitsPerSample = 16

The file size of each WAV audio track (the actual wav data) must be zero padded to a multiple of 32768 bytes (0x8000).
Output 2 fills the music buffer in 0x8000 size chunks and will not zero fill if a chunk at the end of a file is too short.
If the file is not a multiple of 32768 bytes (0x8000), some garbage data will be played in Outpost 2 before switches to the next track.

Hope this helps,
Brett

[Crow!]

Hey guys, just wanted to give an update since I vanished for a while here.  RL stuff has been pretty wild for me in the past month, but the light at the end of the tunnel is in sight.  I'll probably get back to this project and start thinking about single player scenarios for it in two weeks or so.