Hello all.  I've been a Hazeron player on and off for a number of years and just recently came back to see how things have been progressing. I paid the $5 bucks for 15 days and I like what I see - excited to get back out to the stars.

Anyway, I've started as a new emperor and have managed to build some unincorporated buildings in order to produce raw materials and such. I'm ready to found my first city but I can not find the capitol building anywhere in the build screen. I also don't see the police station as an option.  I took a deep dive into the wiki, tried youtube, briefly searched the forums, and then did all those things again. I just can't seem to find the answer.  I guess I'm missing some information somewhere... 

Could someone please instruct me on what needs to be done to place a capitol and found a city?

After discussing a bit with Dean on Discord, I had an idea to split up empire detection mechanics to be more logical and allow specific forms of detection, allowing an empire to place more deliberate focus into empire detection as an attainable goal. It would utilize Dean's suggestions as posted in his Fog of War and Deep Space Radar threads.


Radar Detection

Airports and Military Radars have different purposes. Airport radar is for tracking and identification while Military Radar should be dedicated toward threat tracking and targeting. I propose that Airports be able to show any vehicles within their range while Military Radar must exist in a city in order for defensive systems to target hostiles that aren't hovering directly above a city. In addition, airports and military radar will have a power consumption rating which determines their range. Airports will have a maximum rating lower than military radar, allowing military radar to be set to a larger potential coverage area. Detecting an alien ship within range would reveal the existence of the empire and its name, but not their planets or claimed systems until they are detected by one of the proposed Observatory types below.

As with Dean's idea, underwater cities would be undetectable by radar and any radar built underwater would have a nearly nonexistent range. This makes it effective for people wanting to hide a city from radar without giving them the unfair advantage of being able to detect others themselves.


Optical Detection & Fog of War

Observatories can detect the basic parameters of solar systems and planets at range, but the fidelity of reports depends upon the tech level of the blueprint for them. To see the status of a solar system, it must be within range of an observatory otherwise the system report reflects only the information available the last time it was in detection range or was last visited. Observatories can detect the optical effects of civilization upon a planet, but it takes time for these signs to become apparent (reflecting the time it takes for light to travel from the source to the observatory). The existing System Emission mechanic can be used for this.

Detecting cities via optical means will only reveal that an empire exists there, but no other details about it.

Unlike Dean's idea, I believe probes should not communicate with an observatory but with a new building type.


Radio Observatory

Radio Observatories detect transmissions coming from empire cities and ships. Detection of cities over long range occurs the same as the System Emission mechanic, but the lower threshold of detection is more relaxed: radio emissions can be detected much earlier (at a lower power rating) than by optical means. This reflects the real world potential of an alien civilization detecting our radio transmissions long before optical evidence of our cities is apparent. The existence of a Mass Media building would increase the time and range at which its planet is detectable. Detecting an empire via radio would reveal its name and any cities in a solar system.

Ships can be detected well outside of radar range, but the detection and ability to track the ship is not immediate and would depend on the ship, its crew, officer or captain communicating via the comm or by hailing. This makes it possible for a player to specialize in stealth by building cities underwater, utilizing mission disks and keeping communications to a minimum.

Wormholes should only appear in remote system reports if they are within range of a Radio Observatory. Considering that wormholes are ship-sized and they show visual radiation, it would make sense that radio emissions may be part of their nature. Perhaps polarities are detectable at higher TL blueprints.

Remote probes communicate via radio signals and would require a radio observatory to receive.

Hails and communications performed between ships and cities within the same system would not contribute to detection.


I believe there would be a more detailed progression to detection types with these ideas, increasing with tech level. As a civilization ramps up, it will gain the ability to use new types of detection while potentially making itself detectable to them and granting the potential to limit their vulnerability as well. Likewise, a civilization will be able to specialize in a specific area to have "optical stealth" or "radio stealth" on an empire level. It also reflects the realities astronomy in all its flavors. Optical astronomy has the longest range but is passive and will not reveal much about any empire detected with it other than the fact that they exist. Radar is short-range, immediate and reveals many characteristics but is not useful for long-range astronomy or remote detection of anything. Radio astronomy balances the middle-ground between Optical and Radar detection by revealing partial details at long range while making it possible for careless empires to reveal themselves from farther away.

People wanting a reset seem to use the presence of the Weltreich empire's massive deep space detection network as a reason. Even if a reset was done, this issue would only return again if nothing is changed.

New-style radar installations can have such a long deep space detection range that you can detect others before they are ever able to detect you.

I suggest that power consumption of radar installations should scale with their size, and maybe even generate extra system emissions for the sole purpose of making such installations easier to detect by anyone that it can detect.
Preferably you should be able to detect anyone that can detect you.

This also mean reducing the deep space range of underwater radar installations. If you want to be undetectable, you shouldn't be allowed to detect others unless they can detect you first.

Related bug report: http://hazeron.com/mybb/showthread.php?tid=295

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