Recent Posts

Pages: [1] 2 3 ... 10
1
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Vagabond on December 09, 2017, 12:20:12 AM »
The first post for this topic has been updated to show which items have been completed vs which are still outstanding.

I reordered the change log to be newest changes at top of file. I also added a 1st draft of Known Bugs to the top of the Changelog. See below for what I wrote. These were all I could think of off the top of my head. If anyone else can think of other bugs to add, please post them/add them yourself.

I'm open to changing the format of the bugs. Less information, different format for list, etc. Also Fractured Alliance isn't in Outpost 2 yet, but since I plan on adding it, I went ahead and listed the bug.


Outpost 2 Changelog & Known Bugs
--------------------------------

Known Bugs
----------

* Menus on title screen occasionally do not appear
  - only a single horizontal red line appears at top of menu with rest of menu nonexistent.
  - Menu is still clickable even though it isn't being drawn.
  - Typically clicking until managing to open a different menu will restore proper behavior.

* Starting building construction without committing the ConVec or structure kit
  - If interrupting the ConVec on the exact right frame, the building will start construction without tying up the ConVec. The structure kit will remain in the ConVec.

* Scenario: 4P, SRV, Forsaken World
  - Some starting colonies begin with buildings intermingled with what should be impassible terrain. One colony cannot access its starting ore deposit.

* Scenario: Plymouth Cold War
  - Attacking the AI base often creates a crashing bug soon after initial engagement.

* Scenario: 5P, SRV, Fractured Alliance
  - Occasionally the scenario will crash on initial load.


Changelog
---------

1.3.7
 . . . MORE TEXT . . .

[/tt]



Quote
Err, no. It's set in stone now.

Subversion doesn't allow rewriting history.

Interesting. There is an easy to find button in TotoiseSVN for editing previous commit messages. Since actually changing the commits is so difficult, I wouldn't have expected them to expose the functionality so nicely in TortoiseSVN.





EDIT
-----------

Using the standard BMP format affects the mapper. The minimap display inside the editor looks a bit weird. Colors are generally correct, but there is some 'darker noise' inside the tiles. Saving the minimap to file via the mapper produces the same results. You can use the mapper otherwise without problem. Bitmap minimaps produced by the mapper are attached to this post for comparison.

New BMP minimap produced by Mapper


Old BMP minimap produced by Mapper


Now that I think about it, Greenworld tilesets were doing this to me earlier when I was playing with them in the Mapper.

Thoughts?



EDIT 2

I found where in Outpost2.exe the version strings are being set. It was actually really easy using HxD. I just searched for the text 1.3 and found them both immediately.

Offset 0xE1A00 - Sets the OPU Ver within the in game menu preferences section. I modded it to 1.36 locally and it didn't crash and showed the new number. I guess now we need to decide if we want to rip it out or start updating it with version changes. I tend towards removing it, but I don't actually know how to remove it, just edit it...

Offset 0xE7F3C - The beginning of the text 1.3.0.4. I'm betting this is the value for checking multiplayer matches. I haven't tested it out yet. Perhaps I'll find some time to mod one copy of Outpost 2 and then try to run up a multiplayer match and see what happens.

Strangely, 0xE7F3C doesn't match the hex address we are using in SetSerialNumber in op2ext.

Code: [Select]
char *verStrAddr = (char*)0x004E973C;

Thanks,
Brett
2
Is there any reason we do not want to post the main music packaged in the same zip file as the CLM music?

I dug out my original Outpost 2 CD and found the music1.wav, which when placed in the same directory as Outpost2.exe restores the music to the main menu. I would like to see this added to the CLM music download zip so when people download the in game music they also get to hear the menu music.

10MB file, zips down to only about 9.25MB. So I cannot attach it to a forum post. If someone with website admin rights is willing to post it with the CLM music, please message me and I can email it to them / figure out a different way to send it if preferred.

In the meantime, if anyone wants the file on an individual basis, message me as well.

-Brett
3
Outpost 2 Update / Re: Allowing Outpost2 to load any vol file (*.vol)
« Last post by Vagabond on December 07, 2017, 01:36:13 PM »
leeor,

Sorry I forgot to address your comment earlier. I'm split about the use of markdown syntax. While I like the nice formatting when reviewing the ReadMe on GitHub, when I download the repo onto my computer, there isn't a standard program to open a .md file. So I end up having to manually tell Windows 10 to use Notepad/Wordpad or something. These programs open the file in raw format (without the markdown formatting applied). So now I have to review the readme in raw form or hunt around the internet for a program that shows the markdown formatted. Fortunately, the markdown is fairly clear to read even in raw form, but this is really annoying to me. Just using a .txt file seems to be most compatible.



Quote
Often macros like this are conditionally defined for a shared import/export header. If nothing special is done, the default is typically dllimport. If a project specific define is set, it can use dllexport. Another option is to try moving the dllexport part to the implementation file, which may actually make more sense if you can get it to work.

I'm not exactly following you here. Maybe a short example would be helpful. Are you saying that instead of EXPORT, we should use OP2EXT_API for the macro in op2ext.h?

Code: [Select]
#define OP2EXT_API extern "C" __declspec(dllimport)

None of the functions marked for EXPORT are used within op2ext.



When commenting out SubExt, I get the dialog box with the following error and the game does not load:

Entry Point Not Found
The procedure entry point StubExt could not be located in the DLL Outpost2.exe.


I added the following comment, and StubExt was already in the .cpp file.

Code: [Select]
//Dummy export for linking requirements from Outpost2.exe and OP2Shell.dll. Forces Outpost2.exe to load op2ext.dll.
EXPORT int StubExt = 0;

Please update the comment if I worded it wrong.



Quote
You can potentially use a master internal header file. Perhaps op2ext-internal.h, which includes op2ext.h, and then adds additional declarations for project private methods.

op2ext.h is not used anywhere in the rest of the application, so it wouldn't need to be included in op2ext-internal.h. op2ext.h is currently strictly for consumption by external modules, not within op2ext.

Both dllMain.cpp and op2ext.cpp would #include op2ext-internal.h. Then the declarations for the static instances of the following variable and classes would exist inside op2ext-internal.h instead.

op2ext-internal.h
Code: [Select]
#include "ConsoleModuleLoader.h"
#include "VolList.h"

extern ConsoleModuleLoader consoleModLoader;
extern VolList volList;
extern bool modStarting;

Moving the declaration of volList from VolList.h to op2-internal.h and consoleModLoader from ConsoleModLeader.h to op2ext-internal.h seems like a good idea to me. I think we are getting there...

-Brett
4
Computers & Programming General / Re: SVN -> Git Conversions
« Last post by Vagabond on December 07, 2017, 12:46:08 PM »
https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/LevelsAndMods/trunk/API/Outpost2Dialog

I'm not sure either way about combining the projects. op2ext depends on Outpost2DLL but doesn't need any code from OP2Helper. Reducing the number of projects could be a good thing though.

-Brett
5
Computers & Programming General / Re: SVN -> Git Conversions
« Last post by Hooman on December 07, 2017, 03:19:52 AM »
Quote
The number of projects included on GitHub is starting to grow quite a bit. :)

Yes. I think BlackBox once suggested the Outpost2DLL, Outpost2App, and possibly even OP2Helper projects should be merged. I think I'm starting to see the light on that one. I've been considering lately they can all be separate folders within one project, with one master header file that includes sub-master header files for each section.


Where is Outpost2Dialog?
6
Outpost 2 Update / Re: Allowing Outpost2 to load any vol file (*.vol)
« Last post by Hooman on December 07, 2017, 03:10:56 AM »
Quote
Namespaces are a tool for preventing naming collisions and organizing code into logical sections. Classes are for grouping code with a similar responsibility into an object that has a clearly defined public interface and hidden internal workings.

Sounds like you've said the same thing twice. What's the difference? "organizing code into logical sections" versus "grouping code with similar responsibliity". Having a clearly defined public interface and hidden internal workings could also be said of namespaces: Wrap the private stuff in a nested anonymous namespace.

To me, the main difference is instance data being tied to functions.

Quote
Additionally, I wrote bool GetGameDir_s(char* buffer, unsigned int bufferSize). It returns false if the provided buffer size is too small for the path, but still fills the buffer with as much of the path as possible. Looking for feedback if the bool return is a good addition or not...

Yes, this is a proper way to handle this. Personally, I've come to detest success/failure return values of methods that are supposed to do something (as opposed to true/false return values of methods designed to check something). Having to always check success/failure at the point of call quickly leads to messy code. The cleaner way is to use exceptions. However, due to C interface restrictions on the exported functions, an exception is not possible here. Hence you have to fall back to the more C way of doing things with a success/failure return value.

Code: [Select]
#define EXPORT extern "C" __declspec(dllexport)

Careful about putting this in the header used for importing. ;)

Often macros like this are conditionally defined for a shared import/export header. If nothing special is done, the default is typically dllimport. If a project specific define is set, it can use dllexport. Another option is to try moving the dllexport part to the implementation file, which may actually make more sense if you can get it to work.

Quote
The one area I'm not sure about here is that I had to include 3 extern calls in op2ext.cpp to bring in the mod loader, and volList, and one bool variable. It doesn't seem too clean, but in order to give EXPORT functions access to the different functions like adding vol files, getting the game directory, and the mod directory, op2ext.cpp will need access to this code.

You can potentially use a master internal header file. Perhaps op2ext-internal.h, which includes op2ext.h, and then adds additional declarations for project private methods. Though that is mostly useful if those same extra methods are used among multiple files. If they're only used in one file (while possibly being defined in another), writing a declaration once in a header versus once in the only source file they are used is still the same amount of typing. Having to create tiny headers to export 1 item often doesn't feel worth it. A declaration versus an include is still one line. If you're declaring 3 items all from the same external file, maybe it's time to consider a header file for those methods, or perhaps consider if the functionality is well encapsulated.

Quote
Also, can anyone shed light on what EXPORT int StubExt = 0 does? It is available externally, but only declared and defined in op2ext.cpp. It should probably be declared in op2ext.h if it is truly meant for consumption outside of the op2ext dll...

Hmm, curious indeed. This probably need to be documented better. I grepped the source and found no uses of it. I also checked git blame, and it was never modified since the project's initial checkin. With no documentation, and no use, I initially assumed it was dead code that had accidentally been left in and should be removed. Though being external, it could be used by another project. With no documentation, you can't much expect a mod to use it. Though a quick check of Outpost 2:
Code: [Select]
grep -rn "StubExt" *
Binary file op2ext.dll matches
Binary file OP2Shell.dll matches
Binary file Outpost2.exe matches

It's likely a dummy export to satisfy a linking requirement from Outpost2.exe and OP2Shell.dll. Try removing it and see if the op2ext DLL fails to load at runtime. This is also likely why it's just defined as an int which is set to 0. There is no type information nor type checks with exported symbols. It's just a name and an address. Declaring an int, would be an easy way to generate an export with the required name.

I've also verified there are no "StubExt" matches with an original CD install. I think BlackBox added a dummy entry to the import table of Outpost2.exe to force loading op2ext.dll. Likely no other reason for that entry.

In which case, it doesn't need to be public, so doesn't need to be in op2ext.h. You can move it to the .cpp file.

Quote
Listing of recent commits. Maybe I need to take what Hooman said to heart and try to reduce the number of commits that I make a little by combining them locally first before pushing to the remote repository...

I don't really object to lots of small commits. They are easy to verify that way. Though once you push, you can't really amend things easily. Hence, my suggestion is more to not push your changes right away after each commit. Wait until the end of your programming session to push. Plus, you'll have a better sense of how you should have done the work by then, so you can repackage your commits nicer if you realize any were botched or out of order.
7
Computers & Programming General / Re: SVN -> Git Conversions
« Last post by Vagabond on December 07, 2017, 01:13:34 AM »
Hooman,

Thank you for uploading HFL.

I think the last prerequsitie my scenarios take is Outpost2Dialog. This project is basically odasl and a sample of how to create a dialog box at the beginning of a scenario. It also shows how to set/fetch resources to feed the dialog box a message.

I'm not sure how I feel about this project. odasl is used in a lot of scenarios, so it shouldn't be included separately in them all. But, maybe it makes more sense to place it in Outpost2DLL or somewhere else as opposed to being a separate project. I don't know?

The number of projects included on GitHub is starting to grow quite a bit. :)

-Brett
8
Outpost 2 Update / Re: Allowing Outpost2 to load any vol file (*.vol)
« Last post by Vagabond on December 07, 2017, 01:03:47 AM »
After saying there would be no time for major updates until January, I found some time. Life is funny like that. :)

First up, function declarations in IpDropDown not meant for public consumption were moved from IpDropDown.h to IpDropDown.cpp.

Full content of IpDropDown.h
Code: [Select]
#pragma once

void InstallIpDropDown();

Quote
Ok, now how do classes differ from namespaces?
(A question I didn't think to ask for many years)

Namespaces are a tool for preventing naming collisions and organizing code into logical sections. Classes are for grouping code with a similar responsibility into an object that has a clearly defined public interface and hidden internal workings. Well, that is the answer from my C# hobby perspective anyways... (I didn't look that up, just came out of my brain so it is probably a bit off).



The public interface has been moved from public.h to op2ext.h.

Additionally, I wrote bool GetGameDir_s(char* buffer, unsigned int bufferSize). It returns false if the provided buffer size is too small for the path, but still fills the buffer with as much of the path as possible. Looking for feedback if the bool return is a good addition or not...

op2ext.h's new contents
Code: [Select]
// Outpost 2 Extensions (op2ext) external interface. 
// Exposes functions for use when applying modules to Outpost 2 via the C ABI.
// See ReadMe for specific use instructions. For help, post on the Outpost Universe Forum (https://www.outpost2.net/).

#pragma once

#define EXPORT extern "C" __declspec(dllexport)

// Retrieves the current absolute directory of the Outpost 2 executable with a trailing slash.
// If bufferSize is smaller than required to copy entire path, buffer is provided as much of path as possible and false is returned.
EXPORT bool GetGameDir_s(char* buffer, unsigned int bufferSize);


// DEPRECATED as of version 2.0.0. Use GetGameDir_s instead.
// Retrieves the current absolute directory of the Outpost 2 executable with a trailing slash.
// @buffer Pass a buffer of size MAX_PATH length.
EXPORT||deprecated("GetGameDir was deprecated in op2ext ver2.0.0. Use GetGameDir_s instead.")||
void GetGameDir(char* buffer);


// Returns a pointer to a buffer of [MAX_PATH+1] representing the parameter(s) passed into Outpost 2 after the /loadmod argument.
// The consumer must free the buffer when finished with it.
EXPORT char* GetCurrentModDir();


// Allows loading a vol file into Outpost 2. volFilename must be passed before Outpost 2
// initializes by passing by calling this function from mod_init.
// @param volFilename The vol filename ending in a null terminated string.
//                    Must be a relative path from the directory containing the Outpost 2 executable.
EXPORT void AddVolToList(char* volFilename);


// Overwrites the default Outpost 2 version string.
// Required if the module affects multiplayer to detect incompatibilities between different copies of Outpost 2.
// See the ReadMe for detailed usage. Each variable must be a numeric value between 0-9 and not an ASCII character.
EXPORT void SetSerialNumber(char num1, char num2, char num3);

The one area I'm not sure about here is that I had to include 3 extern calls in op2ext.cpp to bring in the mod loader, and volList, and one bool variable. It doesn't seem too clean, but in order to give EXPORT functions access to the different functions like adding vol files, getting the game directory, and the mod directory, op2ext.cpp will need access to this code.

Also, can anyone shed light on what EXPORT int StubExt = 0 does? It is available externally, but only declared and defined in op2ext.cpp. It should probably be declared in op2ext.h if it is truly meant for consumption outside of the op2ext dll...

op2ext.cpp
Code: [Select]
. . . Includes . . .

extern ConsoleModuleLoader consoleModLoader;
extern VolList volList;
extern bool modStarting;

EXPORT int StubExt = 0;

EXPORT bool GetGameDir_s(char* buffer, unsigned int bufferSize)
{
    . . .
}

EXPORT void GetGameDir(char* buffer)
{
    . . .
}

EXPORT char* GetCurrentModDir()
{
    . . .
}

EXPORT void AddVolToList(char* volFilename)
{
    . . .
}

char *verStrAddr = (char*)0x004E973C;
EXPORT void SetSerialNumber(char num1, char num2, char num3)
{
    . . .
}



Listing of recent commits. Maybe I need to take what Hooman said to heart and try to reduce the number of commits that I make a little by combining them locally first before pushing to the remote repository...

* Improve encapsulation of IpDropDown

 - Moved function declarations not meant for public consumption to .cpp file.
 - Moved includes to .cpp file since they are no longer required in IpDropDown.h.

* Move all non EXPORT declares from op2ext.h into op2ext.cpp

 - Preparation work for moving all EXPORT function declarations into op2ext.h

* Move non-EXPORT code from op2ext.cpp into DllMain.cpp

In preparation for moving all EXPORT functions into op2ext.h/op2ext.cpp.

* Move public interface for op2ext from public.h to op2ext.h

 - Added EXPORT bool GetGameDir_s(char* buffer, unsigned int bufferSize)
    - Allows for a safer version of GetGameDir that is compatible with the C ABI
 - Moved definitions of all EXPORT functions to op2ext.cpp
 - Improved comments on EXPORT functions

* Rename ModMgr to ConsoleModuleLoader

* Remove dllexport from GetGameDirectory function

It returns a string and is not compatible with the C ABI. See GetGameDir_s for new EXPORT function.

* Remove unnecessary extern call for a modManager in op2ext.cpp

* Rename class CommandLineModuleLoader to ConsoleModuleLoader

Lines up with new filename ConsoleModuleLoader.h/ConsoleModuleLoader.cpp and is a little shorter in length when typing class name.

9
Game Discussion General / Re: Cataclysm of Chaos V8
« Last post by Hooman on December 06, 2017, 09:56:58 PM »
Agreed on the lore. That is important for an immersive setting.
10
Computers & Programming General / Re: SVN -> Git Conversions
« Last post by Hooman on December 06, 2017, 09:10:30 PM »
HFL and HFL-IUnit projects have been converted and uploaded to GitHub.

Conversion steps:
Code: [Select]
git svn clone -T LevelsAndMods/trunk/API/HFL/ https://svn.outpostuniverse.org:8443/svn/outpost2/ HFL
git svn clone -T LevelsAndMods/trunk/API/HFL-IUnit/ https://svn.outpostuniverse.org:8443/svn/outpost2/ HFL-IUnit

Both projects had history filtered to remove empty commits, and .lib files.

For HFL:
Code: [Select]
git rebase -i --root
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r Lib' --prune-empty --tag-name-filter cat -f -- --all

For HFL-IUnit:
Code: [Select]
git rebase -i --root
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r op2extra.lib' --prune-empty --tag-name-filter cat -f -- --all



After that, projects were uploaded to GitHub.
For HFL:
Code: [Select]
git remote add origin https://github.com/OutpostUniverse/HFL.git
git push -u origin master

For HFL-IUnit:
Code: [Select]
git remote add origin https://github.com/OutpostUniverse/HFL-IUnit.git
git push -u origin master
Pages: [1] 2 3 ... 10