Messages

Hi,
thanks for reporting, I will check it right now.

Yes, it will be possible if we implement some server-to-server (or simply HTTP as it allows connecting with practically anything) networking API, plus API to serialize/deserialize any objects to the network stream. We don't really need this for our current and planned features so it will have to wait for some time.

[kyokei]

kyokei, well, I've already done it for the next version :-).
It will also improve the servers list by displaying the public server domain names instead of IP addresses (if the server domain name is set in the settings file). Will be helpful for CryoFall as well.

[kyokei]

kyokei, sure, I've marked your IP address with the tag.

Can you maybe direct it to kunix.org instead of the IP?

Unfortunately, currently it's not possible - because most IP addresses doesn't have correct PTR record for the reverse DNS lookup. So, in your case:

Code Select Expand

nslookup 83.85.69.80
Name:    53554550.cm-6-6b.dynamic.ziggo.nl
Address:  83.85.69.80

We can improve it in the next builds of VE and Master Server. You will need to specify kunix.org in the config file.
The server will resolve the host name and if the IP address is matched with the IP of the server network connection to Master Server, then the host name from the config file will be used instead of the IP address.

Regards!

EDIT: I looked at the log, it seems that the server app is waiting for a command at script manager step.

It's always listening to the commands, so if you press the Enter key it will print "Please enter command. Enter "help" for commands list.". I'm sure this is not related to the issue.

Thanks for the detailed report! The scripting initialization step is usually the longest one, but should not take much more time than a loading of the savegame - which is in your case happens much faster. I think it maybe related to the disk reading pattern - as the scripting initialization step creates 4 threads to read-parse-compile all the scripts in the game - and if the disk system is not very fast with parallel simultaneous reading, it may cause the stall. Could you run "iotop" in parallel with the game and check if IO is 100% busy during the scripting initialization step?

We've tested the server on desktop OS's - Windows, Mac and Linux (Ubuntu 14 only, but on different configurations, including VMWare with very limited performance; also x86 and x86_64) - and cannot reproduce the issue... Unfortunately, we don't have here any computers with processors on RISC architecture (such as ARM processor in your Raspberry Pi 2). I think this might be related to the issue - not only because of performance, but also because of different Mono implementation for RISC processors...

I understand your energy-efficiency concerns. If you want something ultimate but with reasonable price and similar to Raspberry Pi 2 power consumption, I think you might like an x86-based micro-computer - like UDOO X86. It uses just a few percents more energy, but seems to be several times faster and can run any x86 OS. Personally, I'm looking for something like that for my 24/7 home server.

Regarding the Expansions button - there is an official response http://steamcommunity.com/app/324260/discussions/0/353916584666312753/

Regards!

Hello!

This is very strange... can you reproduce it? If yes, please upload the server log on pastebin.com; if no - well, there are various issues with Mono and I hope with one of the future patches we will be able to switch on CoreCLR (official Microsoft .NET Framework implementation for all desktop operating systems, just released v1.0).

Regards!

Hello!

Thanks for reporting! This is very strange. Looks like a world generation issue. I found the world generation seed in the server log, so we will try to reproduce and fix the issue tomorrow.

Are the stations also absent when you browsing System and Galaxy maps? Or perhaps they're listed, but only in Galaxy Map?

Unfortunately, you need to create a new galaxy as the galaxy generation issues are not fixable with a patch.

Regards!

Hello!
Unfortunately, this is a very hard task as the server implementation is not thread-safe and we cannot do parallel processing of multiple star systems: there are many common subsystems which will be simultaneously utilized by each parallel task and we need to put synchronization/locking code to avoid any race conditions and other multi-threading related issues. Without proper implementation it is not only very hard, but also could degrade the performance. And proper implementation is possible only when supported by server architecture from day zero...

Regards!

Hello!

Thanks for reporting! I see two Unity-related issues and we will try to fix them with the next patch.

Regards!

[ufw]

Hello!

This error is just a warning. The port forwarding is working only for home routers with UPnP technology.
I don't have any experience with Digital Ocean's droplets, but it seems you need to whitelist the game server port in the firewall. I suppose you've done basic setup for Ubuntu 14.04 droplet and have ufw firewall installed and active. If so, you can whitelist the game by executing this command:

sudo ufw allow 5000/udp

(please verify that the game server port is 5000 in the server log file - if not, replace it with your actual server port)

Then you can check the firewall status:

sudo ufw status verbose

If you don't have the firewall installed (all these commands returns some error saying "ufw" is unknown command) than that's not the case... You can try to install a web server and see if it's accessible. There is a good article about initial server setup and installing a web server (nginx) - https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04

Regards!

Hello!

Thanks for reporting. We have one similar report ("sound bugs out (goes all echoey)") and we're investigating it.

Could you upload all the game logs on Google Drive or Dropbox and share the link please? They're located at:
Windows: <User Documents>\AtomicTorchStudio\VoidExpanse\Logs
Linux: ~/.config/AtomicTorchStudio/VoidExpanse/Logs
Maс: ~/Library/Application Support/AtomicTorchStudio/VoidExpanse/Logs

Regards!

The issue is fixed in v1.6.13 (available now, release notes (http://forums.atomictorch.com/index.php?topic=851.msg5581#msg5581)).
The game is not using Unity audio file streaming anymore (it uses in-memory streaming with NVorbis).

Regards!

[=== VoidExpanse v1.6.13 ===]

=== VoidExpanse v1.6.13 ===

• Improvement: (in Singleplayer) savegame backup will be created before writing the new save game files. It will help to avoid cases when a savegame become suddenly corrupted. Backup folders will be created near the savegames folders with names like "backup_slot_0".
  
• Fixed: Savegame corruption when the new savegame file cannot be written in place of current savegame (rare issue related to antivirus and other software).
  
• Improvement: Decreased duration of screen shakes produced by huge explosions.
  
• Fixed: Server crashes in some rare conditions.
  
• Fixed: Client crashes on entering/leaving space station and any other time when the music changes (related to FMOD file streaming issue of Unity Engine).
  
• Change: NVorbis audio library is used now instead of Unity streaming audio. No more disk audio cache needed (reduces required free space amount). The game didn't use NVorbis since v1.1.x because of memory leaks, but now the pool of buffers is implemented.
  
  To the dedicated server hosters: update is recommended, but not required.

Update.

No need for extra logs. It seems the crash happens in the internal Unity subsystem related to audio streaming from disk (FMOD):

Code Select Expand

VoidExpanse.exe!FMOD::UserFile::reallyRead(void * buffer, unsigned int size, unsigned int * rd) Line 119 C++
VoidExpanse.exe!FMOD::UserFile::reallyAsyncRead(FMOD_ASYNCREADINFO * info) Line 207 C++
> VoidExpanse.exe!FMOD::FileThread::threadFunc() Line 185 C++
VoidExpanse.exe!FMOD::Thread::callback(void * data) Line 47 C++
VoidExpanse.exe!_callthreadstartex() Line 314 C
VoidExpanse.exe!_threadstartex(void * ptd) Line 292 C

Will see if we can find a workaround for it...

Regards!