One of the reasons people say they want a reset, is because old empires have a starmap with all systems explored.

This is only an issue because of how "explored systems" are handled. Once you have explored a solar system, simply by visiting it, you can forever and always see the current state of that solar system. If a new city is founded in an explored solar system two years after you were last there, you will instantly know about the new city.

To combat this issue I suggest that this "explored" status should be lost after some time without visiting it. System surveys should not be affected, only your real-time intel about the system.

Think of them as probes left behind from when your ship was there last, after some time those probes break down and need to be replaced. This also brings some interesting counter-intelligence options, for example allow your ship to remove all enemy probes from a solar system if it remains there for a vast amount of time.

In order to not make all space suddenly unexplored, the observatory building could maintain all probes in the neighboring sectors if it has power and a worker. Could even allow the observatory to slowly/randomly send probes to nearby solar systems, allowing you to gain some basic planetary information about nearby solar systems before reaching interstellar travel.

[img]blob:https://imgur.com/1e9f9e2c-e867-4eb1-99c5-1ed6f105bcc6[/img]

left: spacex's spacecraft
right: hazeron's rocket

I'm running Arch Linux and using the Manjaro build of Hazeron, which otherwise works fine, but breaks when I try to save the starmap. No file dialog comes up and the program locks up so that I can't click on anything and am forced to kill the process. I had to run the windows version under WINE to save my starmap  . I will acknowledge that it's entirely possible that this is just another side effect of my messed up arch system, so if you can't replicate it on your end, I wouldn't waste any time on it.

Ubuntu makes a long term support release every two years. Xubuntu is my preferred development environment so I try to stay in sync with the LTS releases. The most recent LTS release was 4/2018. The server version was not ready for installation right away so I waited to do the upgrades, until now.

Upgrading always takes a lot of work and the best ending is to have everything working again when it's over. It is best done when other tasks are not demanding attention. This week has been spent doing that work.

Qt Libraries on Linux
SoH distributions for Linux no longer contain any Qt libraries. This should result in better compatibility. It also makes the SoH distribution for Linux a bit smaller.

The launcher now consists of just three files: the executable, an icon, and a tiny data file. You should remove all lib files from the Shores of Hazeron/Launcher folder or unpack the new launcher into a new folder.

Similarly, the Shores of Hazeron/Programs folder may contain old Qt libraries. They all begin with libQt; remove them. The only lib files remaining in the Programs folder should begin with libAu; those belong to SoH.

UPDATE: Be sure to delete the qt.conf file from the Launcher and Programs folders.

Ubuntu 18
The current Ubuntu LTS release is 18.0.4. The Qt5 package available is 5.9.5 LTS. The apt package name is qt5-default.

Hazeron Commander also requires the qtmultimedia5 package. One of its objects is used to make sounds.

Mint 19
The current Mint release is 19.1. The Qt5 package available is 5.9.5 LTS. The apt package name is qt5-default.

Hazeron Commander also requires the qtmultimedia5 package. One of its objects is used to make sounds.

Debian 9
The current Debian release is 9.6.0. The Qt5 package available is 5.7.1. The apt package name is qt5-default.

Hazeron Commander also requires the libqt5multimedia5 package. One of its objects is used to make sounds.

Manjaro 18
The current Manjaro release is 18.0.2. Qt 5.12.0 LTS is installed with the base system, a pleasant surprise.

This is the first Arch Linux distro for SoH. I found it to be very nice.

openSUSE Tumbleweed
The rolling release version of openSUSE is Tumbleweed. It offers no Qt5 binary package.

If you have Qt5 setup on openSUSE, I will configure my openSUSE with the same Qt version and build SoH for you. Just ask.

Fedora 29
The current Fedora release is 29. The vintage Qt package available is 4.8.7, released December 2011. I will stop building SoH for Fedora, unless someone asks.

Other Linux Distros
For now, our front line support for Linux will rest on those distros that bundle a usable version of Qt5. If your distro is not represented here and it has a Qt5 package, let me know. I will gladly add it to the build list.

To find out what version of Qt you have, enter 'qmake -v' at a command prompt.

If a binary Qt5 package is not available for your Linux distribution, SoH can be built for you, as long as I can set up a virtual machine with that distro. Then you would have to build your own Qt libraries. The process of building Qt is moderately difficult, not always easy. The Qt source code is free for all Linux distros, I think. Let me know if you want to do this.

Windows 64 bits
Windows 64 bit build of SoH will now be built using Qt 5.9.5 LTS. Qt libraries (DLLs) are distributed with SoH. The Qt libraries are the ones distributed by The Qt Company.

Windows 32 bits
Windows 32 bit build of SoH will continue to be built using Qt 5.8.0 for a little longer. Qt libraries (DLLs) are distributed with SoH. The Qt libraries are the ones distributed by The Qt Company.

MacOS
MacOS build of SoH will continue to be built using Qt 5.8.0 for a little longer. It requires an OS upgrade on our Mac Pro, planned for later today.

The Qt package available is Qt 5.12.0 LTS. The app store package install downloads the Qt source code and builds it. The build failed on my Mac Pro because the OS version is too old.

I plan to have the MacOS build of SoH updated next week.

UPDATE

The macOS build is updated and ready to go. SoH for macOS includes the Qt 5.12.0 libraries. They are the ones from the app store package, the same ones SoH is built against. After upgrading my macOS, I don't think the package installer had to build the Qt libraries. They may be pre-built binaries, which would be nice.

I am still building an SoH that supports OpenGL 3.2 and one that supports OpenGL 4.1. You have to pick which one you want in the launcher settings. The way OpenGL is handled on the Mac, an app has to target a specific OpenGL standard when it is built and the programmer must not stray a step from the gl functions available under the targeted OpenGL standard. I suppose that is why stuff on the Mac tends to work so well.

Server Upgrades
The game servers run Ubuntu Server operating systems. They will be upgraded to 18.0.4 LTS starting Monday.

After going through the process on the debug servers, I think I can get all of the game servers done in one day. I'll keep the server status page updated as it goes.

The game universe will not be available for game play for parts of the day Monday, possibly most of the day.

One of the servers is currently dead in its rack. I will upgrade the OS on the other servers before going to Denver to revive it, in case more than one of them needs reviving.

(different buildings, joined by photoshop)

Buildings designs are 3026820 'Large Factory' and 3132513 'Industrial 1k H' respectively.

I don't know if we need more morale bonuses, since more bonuses mean we can avoid more morale penalties. But putting that to the side for another day.

Currently there is no real benefits to having large homes at all. They take twice as much volume as a medium home, yet a medium home takes twice the volume of a small home. This means that the keeping the "Small homes <= Medium homes + (Large homes × 2)" ratio is not really an issue and using large homes is simply a waste.

I suggest that a morale bonus gets added when you have "Large homes > Medium homes + (Small homes ÷ 2)" or some such.

Thoughts?

Going to preface this with, it could be entirely due to some quirks of my system and setup. I have not attempted to reinstall hazeron at this time, but this weekend I will go through that process along with ensuring the requirements are satisfied. Regardless, I will post the errors I have noticed so far. I will update if anything changes when I reinstall.

Quote:error: Au3dsGLSLModel::LoadEditorChunk bad chunk size 145 for subchunk 4000 exceeds remaining 103 bytes in chunk
error: Au3dsGLSLObject::LoadChunk bad chunk size 134 for subchunk 4100 exceeds remaining 92 bytes in chunk
libpng warning: iCCP: known incorrect sRGB profile [repeated often]

DaCreature::RxUpdate bad console at console isConPose false conType 0 rxType 0
libpng warning: iCCP: known incorrect sRGB profile
QXcbConnection: XCB error: 3 (BadWindow), sequence: 49905, resource id: 43124854, major code: 40 (TranslateCoords), minor code: 0
libpng warning: iCCP: known incorrect sRGB profile
Au3dsGLSLObject::AverageWeights vertex group "Cube" skipped in file ":data/5FootRight4.3dsN" Was this the intent?

QXcbConnection: XCB error: 3 (BadWindow), sequence: 13597, resource id: 43029451, major code: 40 (TranslateCoords), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 5885, resource id: 43051695, major code: 40 (TranslateCoords), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 4203, resource id: 43060989, major code: 40 (TranslateCoords), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 60116, resource id: 43293463, major code: 40 (TranslateCoords), minor code: 0

DaCreature::RxUpdate bad console at console isConPose false conType 0 rxType 0
DaCreature::RxUpdate bad console at console isConPose false conType 0 rxType 0

DaSolarSystem::FinalizeContents 176111086 "HCZ'WH'B'd" habitability = "Home World" (less of an error and more of just a print log?)


AuZoneResource::ShrubResource - shrubcount == 0
AuZoneResource::ShrubResource - shrubcount == 0
AuZoneResource::ShrubResource - shrubcount == 0 [repeated a lot more]

error: Au3dsGLSLModel::LoadEditorChunk bad chunk size 145 for subchunk 4000 exceeds remaining 103 bytes in chunk
error: Au3dsGLSLObject::LoadChunk bad chunk size 134 for subchunk 4100 exceeds remaining 92 bytes in chunk
WARNING!: Vertex group type=16 was expected to have only 1 vertex; has 2 vertices

The same seems to be happening when done in a university

As seen on System Map. Didnt try to sundive to check. Name of the system is on screenshot
   

make the fact that ur population is missing clothing a - morale factor, pretty simple.