Oolite Bulletins

mcarans wrote: ↑Thu Oct 16, 2025 7:50 pm

As far as I recall, there are currently no further bugs with the modern_build that have been found so far. Please let me know if I've missed anything.

The only thing you had mentioned is the file size of libicudt77.dll. That comes from https://github.com/msys2/MSYS2-packages ... u/PKGBUILD. If it's a big problem, that package can be built with specific locales to reduce file size. The locale specification is here: https://github.com/unicode-org/icu/blob ... le-slicing

If all is well, my next idea is to make a GH Action release of the packages (EDIT: see https://github.com/mcarans/oolite_mingw ... /tag/0.0.1) and in a separate repo, to see if it's possible to make a GH Action that downloads those release packages (latest version), installs them in a fresh MSYS MinGW64, then builds the nsis Oolite package, enabling the automation of a versioned Oolite release with pre-built versioned packages.

another_commander wrote: ↑Fri Oct 17, 2025 5:44 am

Not sure if it is a bug, a feature or something else, but the .GNUstepDefaults file is no longer called .GNUstepDefaults. It is now called $(PRODUCT_BUNDLE_IDENTIFIER).plist, which I believe is actually meant to be the application bundle name. This feels like a bug. Additionally, this file is now in XML format, while in Windows it is expected to be NextStep. The Linux version also has this file in XML format, but that happened only after the GNUstep project decided at some point years ago to switch the defaults file to XML. Before that, all ports had their defaults file in NextStep format and Windows just kept it even after the upstream change occurred because NextStep is more human friendly. This is a strong departure from what we had and, to top it off, any and all references in the wiki or in the forum giving advice about .GNUstepDefaults are now invalid (or at the best case confusing) since this file is no longer present.

Lone_Wolf wrote: ↑Sat Oct 11, 2025 12:08 pm

$(PRODUCT_BUNDLE_IDENTIFIER).plist is also present (and used) on source builds for linux trunk & stable on archlinux.

The generic installer for linux 64-bit does use .GNUstepDefaults .
Maybe the method used to create pre-built binaries makes changes to the sourcecode/config settings before building ?

another_commander wrote: ↑Fri Oct 17, 2025 5:44 am

Go for it.

enum {
  NSPropertyListOpenStepFormat = 1,
  NSPropertyListXMLFormat_v1_0 = 100,
  NSPropertyListBinaryFormat_v1_0 = 200,

  NSPropertyListGNUstepFormat = 1000,
  NSPropertyListGNUstepBinaryFormat
};

mcarans wrote: ↑Fri Oct 17, 2025 7:01 am

Here is a release of Oolite's installer built using the latest packages: https://github.com/mcarans/oolite_windo ... /tag/0.0.1

As for the plist format, I believe it can be set to one of these:

Code: Select all

enum {
  NSPropertyListOpenStepFormat = 1,
  NSPropertyListXMLFormat_v1_0 = 100,
  NSPropertyListBinaryFormat_v1_0 = 200,

  NSPropertyListGNUstepFormat = 1000,
  NSPropertyListGNUstepBinaryFormat
};

https://github.com/gnustep/libs-base/bl ... List.h#L58

another_commander wrote: ↑Fri Oct 17, 2025 7:17 am

Yes, we want the first one in the enum and you need to modify NSUserDefaults.m in the gnustep-base source, writeDictionary function.

cp /mingw64/share/GNUstep/Makefiles/GNUstep.sh /etc/profile.d/

if ! grep -q "# Custom history settings" ~/.bashrc; then
  cat >> ~/.bashrc <<'EOF'

# Custom history settings
WIN_HOME=$(cygpath "$USERPROFILE")
export HISTFILE=$WIN_HOME/.bash_history
export HISTSIZE=5000
export HISTFILESIZE=10000
shopt -s histappend
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
EOF
fi

another_commander wrote: ↑Fri Oct 17, 2025 5:44 am

Not sure if it is a bug, a feature or something else, but the .GNUstepDefaults file is no longer called .GNUstepDefaults. It is now called $(PRODUCT_BUNDLE_IDENTIFIER).plist, which I believe is actually meant to be the application bundle name. This feels like a bug.

	  pd = [[GSPersistentDomain alloc] initWithName: bundleIdentifier
						  owner: self];

another_commander wrote: ↑Sun Oct 19, 2025 5:27 am

I agree. OoliteDefaults.plist doesn't sound bad at all to me.

another_commander wrote: ↑Sun Oct 19, 2025 5:27 am

I agree. OoliteDefaults.plist doesn't sound bad at all to me.

another_commander wrote: ↑Mon Oct 20, 2025 7:05 pm

Latest installer seems to work fine here.

another_commander wrote: ↑Mon Oct 20, 2025 7:46 pm

Whenever you feel ready let me know, I'll add you as a developer in Oolite and you will have write access to the game's repo.

For a few months we need to be running the modern and the "classic" builds in parallel just to be sure.

mcarans wrote: ↑Mon Oct 20, 2025 8:40 pm

EDIT: I couldn't resist trying the system NSPR since it's so easy to switch with everything as pacman packages. The JS library built fine with it as did Oolite. The game seems to work fine too. What are your thoughts on using the standard MSYS2 MinGW64 package instead of building it from my copy of your repo?