Hi there!

I need some help to get these qt5 libraries installed.

I'm running Linux mint 19.1 Cinnamon. It's based on Ubuntu, so I used the Ubuntu Launcher Download.

But the game didn't start. It wrote an error, that it couldn't find the qt 5.15 libraries.
I found out, that I have installed qt 5.09 only.

I already tried to get the qt5-default and the other two libraries (given on the dowlnoad page) via synaptic. But they are not listed there.

How I can get the fitting libraries and from where?

When I tried to get qt5.15 from the developer website (qt.io), I didn't understand, how I could download anything from there and what exactly I needed.

I used an (maybe outdated) installer from this company. It installed the libraries and other stuff in one of the linux system folders.
But the game didn't start after that.

Somehow I messed with the qt5 libraries, by manually copying some of them between system folders.
Then it found the qt 5.15 libraries, but now stating this error:

qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

./HazeronLauncherLauncher: Zeile 3 {Line 3}:  2795 Abgebrochen {Aborted}            (Speicherabzug geschrieben) {(Memory leakage written)}./HazeronLauncher

{my Translations}

Hope, someone can help me.

Would like to be able to play Hazeron again :-)

Greetings,

Falkenkopf

I have been trying to figure out how to set the color of window lights on buildings. I have changed opacity, Light-Lense color to the different presets, and even textures. But the windows seem to randomly pick a color from red to orange to bright white. I am trying to get them to be the mercury vapor color. Any advice would be most welcome.

It looks like missile size is scaled on every dimension by the number of missiles launched.  This has unfortunate side effects, such as the following with large launchers:



This isn't really a bug per se, since it seems to work fine, but I suggest scaling the missile by the cube root of the number of missiles launched, as that is more mathematically/volumetrically correct and will limit how often this kind of thing happens.

Feature Request: 

Add the ability to request what transporter station should complete the request when asking to beam up. 

Either pull the group name of the station or the ID, group name is a bit more friendly but either would work.

Account Activation
Abandonment decay depends on accounts becoming inactive. The switch to free-to-play is preventing anything from decaying.

Account activation time is now reset to 30 days whenever you login. If the account was inactive, it becomes active.

You can login using Shores of Hazeron, Hazeron Commander, Hazeron Mail, or the accounts page on this web site. You don't have to enter the game universe with an avatar. Simply logging in refreshes the account's activation status.

Accounts become inactive after you have not logged in for 30 days.

The lands that belong to avatars in an inactive account stop being immune to decay. Buildings will begin to disappear.

The process that deactivates accounts is not currently being run, to give people a chance to activate their accounts. That process will start running in a few days. It will deactivate accounts that have not logged in since the update today.

Server Crash
A bug was fixed that caused three servers to crash since the last update.

In the old days the size of spacecraft you could manufacture was limited by the quality of the materials available (specifically the old TL value) and some research time, finding better quality resources was required to manufacture bigger and bigger spacecraft. Since its removal people have floated some ideas around about if or how the size of spacecraft manufacturing should be limited again.

Issues

I doubt we can expect a whole rebalancing of spacecraft combat. So I won't expect anything fancy like ship size classes or whatever else is normally being suggested by people. Best I imagine is limits that are easy to implement and understand.

Quality of spacecraft manufacturing materials can be annoying to keep track of. Anyone that remember the old TL technology system might be able to remember having to figure out their current size limit and then design their spacecraft blueprint out from that. This is what I would say is one thing I don't miss about the old system, having 32 different spacecraft size categories. This might not be an issue right now, but I think it is good to keep in mind.

Technology has no baring on spacecraft manufacturing, it only affect which modules can be manufactured and the end result quality level of the subsystems on the spacecraft. The research time on some of the more advanced modules (FTL drives) are very very long though, and I doubt we want more of those boring time sinks.

There are no special infrastructure requirements to manufacture the biggest of warships. You just need a spacecraft factory, warehouses filled with the materials and a tiny space station in orbit. Yes you need to actually have harvesting operations and materials manufactured, but that doesn't have to be in the same solar system at all and can just be shipped to the spacecraft factory's city. You can have a tiny city with a population of 10 manufacturing gigantic spacecraft, and this can be thrown down anywhere in just a few minutes.

Ideas

Advanced metal resources (Magmium, Vulcium and Adamantine) don't play any role in spacecraft manufacturing aside from a stronger hull module. This could be one simple way to limit the size you can manufacture a spacecraft at, simply have the hull module type limit it. It has the added advantage of being easy to understand by players and designers alike. For example the metal hull module could limit the size to spacecraft that can normally spawn on the ground. Converting existing spacecraft blueprints to a system like this should also be simple for Haxus to do, or simply allow us to do at the time of manufacturing.

What we don't want is a meaningless research wait timer. So making it a patent research seems like it would be a bad idea and wouldn't solve the issues above.

Limiting spacecraft manufacturing size by city infrastructure could be done by having it require a spacecraft factory of increasingly bigger size with a lot of citizen jobs to operate, so a tiny city with a population of 10 can't make a gigantic spacecraft. Or it could require special buildings like a space elevator and more orbital infrastructure, as long as it requires the city to actually have workers. It would give reason to have larger cities for a shipyard, rather than just a tiny city with lots of warehouses.

Conclusion

There are plenty of options for limiting spacecraft manufacturing size. The ideas I mentioned above can't be the only good ideas, so do share your ideas and give feedback. I assume a mixes of ideas to limit spacecraft manufacturing size by multiple factors would be best, such as all the ideas I mentions or something like that.

Lets brainstorm!

Here is my proposed format change:

It seems that the accounts brought back are now expiring.
is there plans to extend the initial play time or bring back the payment system?

curious to know since if im not mistaken things start melting/decaying when accounts aren't active.

EDIT:

ahh here we go


EDIT 2:
logging into the hazeron client or hazeron commander does not reactivate the account.
only logging into the website does so.

I noticed that when creating new characters off of a .CHR file they dont appear to all be the same species.  I also noticed the file is only 32 bytes.  I would suggest that these 32 bytes be used as a database key to look up what species you are, or something akin to that.

A way to break ties for existing redundant named species and to move existing data to the new scheme would be for the oldest one to win.

It seems possible it was already intended to work this way, however it does appear to me that the species names do not stick across new characters so I'm fairly sure im creating a new identical species every time I do this.

Servers started reporting deadlocks a lot when making SQL updates. I've seen the occasional deadlock happen in the past without knowing the cause. The frequency of deadlocks seemed to increase a lot recently.

When a deadlock happens during an SQL transaction, the entire transaction fails.

The negative consequences of this event are many. One negative consequence is leaving players in limbo when they travel from one server to another, like when going through a wormhole.

A little research revealed the root cause of deadlocks during SQL UPDATE operations in PostgreSQL. The solution was trivial. It simply required a consistency of order when updating records by multiple processes. Updates are now performed in atom id order.

This requires a little time monitoring the server logs to be sure the problem is gone. So far so good. Logs are blissfully quiet.