Messages

Very unfortunately, no. It was rushed and hardcoded...
As you can see in every skill xml file, they all have entry like this:

<page>3</page>

It determines the skill category in which the skill will be displayed.

Unfortunately, we didn't implement any solution for this problem. You need to override the whole file.

[Acuru]

Acuru, you're right. We will update wiki page to clearly describe that CPK/MPK are just a ZIP archive with no compression and they should contain files directly, not in an extra subfolder.

Regarding the mod bundles - we have plans for this in CryoFall. Perhaps, we will port this feature back to VoidExpanse (core engine part of the games are shared, but VoidExpanse will require several non-trivial engine/UI modifications to support this feature).
Basically, the idea is to have our own mods repository at AtomicTorch.com with fast CDN (Azure or Amazon) where anyone will be able to upload their mods with our Mod Uploader tool (the same tool as our Steam Mod Uploader, but modified to work with AtomicTorch.com CDN instead and, perhaps, ported to Linux/Mac to smooth out the process for everyone).
The game will be able to download a mod by its ID and version number and install/activate automatically accordingly to the game server configuration. This is necessary as there will be many modded servers and manual installation/updating of mods on the client is something we want to avoid.
With this architecture, the mods bundle is trivial to implement - it will contain just a single XML manifest file with the bundle information (id, version, title, author, description, date) and the list of mods (with their versions) in the order of activation (plus an icon for the bundle, but nothing more). So the game client and server will be able to automatically download all the required mods from the list and install/activate them.

What are your thoughts guys?
Oh by the way the pieces are ordered except the heatsinks.

I'm sad to hear you ordered the hardware mostly for VE hosting.
The VoidExpanse game server is 99% single-threaded. It means it practically cannot utilize more than one core. So you can have a motherboard with 4 CPUs and each one is 12 cores, but the game server will use only a single core, 1/48 of total power. The only way to utilize these much cores is to run multiple servers (48 total), but it doesn't make sense for you as you wanted to host a single huge galaxy - like a MMO.
There is a known problem in programming (not only in gamedev) - if an application/game was not designed to be multi-threaded from beginning, it's almost impossible to rewrite it to be multi-threaded anytime later - especially after tons and tons of code were written in a ~2 years by a programmer who suddenly left the team before the release of the game.
So, we thought a lot about paralleling processing of the star systems (so each one could take a dedicated core and we could utilize multiple processors) but it's impossible without rewriting the game server completely. And this is impossible for multiple reasons.
Also, VE modding is very limited - many important things are hardcoded in the game engine and API is very limited. Adding new content (ships, weapons of existing types, skills) is trivial, adding new quests/topics/AI is hard, everything else is almost impossible and often will require our very limited time to modify the game engine to expose new API methods...

Currently, we're working hard on CryoFall and the modding will be much simpler and enjoyable as described there
http://wiki.atomictorch.com/Renkei_Engine It will have much better modding features (C#, hot-reloading of assets and code, powerful debugging and logging tools) and allow absolute freedom for modders. It will be possible to host a server with custom mods, connect to it, automatically download the required mods - and play in a total conversion of the game, with completely different UI and (almost) everything else.

[Acuru]

Acuru, I guess you forgot to set "no compression" setting in 7-zip.

Yes, it makes sense. Recently all the anti-virus software companies rushed ransomware protection into their products.
Good to hear you've found a way to resolve the issue. We will recommend it to other players and also update the game troubleshooting wiki.

Regards!

I see. It seems they're performing some kind of sandboxing to isolate it from accessing the file system outside of the application location.
I would recommend reporting this issue to the Avast support.

If you added the exe file into the anti-virus software, it should be enough and you need to try a workaround:

Setting the compatibility settings in VoidExpanse.Server.exe and VoidExpanse to run in admin mode fixed it.

[addiktion]

Hello, addiktion!

Thanks for reporting. I've checked the logs and found the crash issue (in the end of the server log file):

CRITICAL ERROR at VoidExpanse.Server.exe! Unhandled exception. Terminating process!
System.UnauthorizedAccessException: Access to the path 'C:\Users\James\Documents\AtomicTorchStudio\VoidExpanse\Saves\backup_slot_2\screenshot.jpg' is denied.

It seems the game cannot access folder "Documents\AtomicTorchStudio\VoidExpanse" (to write the savegame). This could be related to the anti-virus protection.
Please ensure you have added the game server executable (located at "<game folder>/Server_dotNET/VoidExpanse.Server.exe") to the anti-virus whitelist.
If you don't have any anti-virus software or the game server executable is already whitelisted, please try the workaround described in this topic http://steamcommunity.com/app/324260/discussions/0/1457328927830385121/

Regards!

Hello,

I'm not sure if we promised support for Linux at the release time - I cannot find any mention of it. But right, we would like to provide support for Linux as soon as possible.

There are multiple problems this time. First, we're a smaller team now (only one programmer, actually). Secondly, we've changed our client engine of choice to MonoGame (well, actually it's a in-house tech - Renkei engine - built on top of MonoGame, and we could switch MonoGame to something else if feels necessary to do so). MonoGame itself is cross-platform, but we decided to use DirectX for Windows as the easiest way to develop our game, so adding OpenGL support (as required for Linux) will take a considerable effort. Ideally, we would like to switch on Vulkan - it's a modern cross-platform library, but it's not supported well enough yet (I mean drivers, C# wrappers, cross-platform shader compilers).

Thirdly, we lifted the bar of modding capabilities of the game by providing completely open source gameplay assets and code. It means all the assets are come with the game (Core.cpk) in their raw form (no pre-cooked texture atlases, no custom file formats) and baked into the required format by the game engine itself when needed (with caches for faster loading next time). It also allows the game to listen to the file system changes and hot-reload changed files (all of file formats are already supported). It means that we're shipping the C# (.cs) and shader (.fx) code compilers together with the game. The bad news is that currently MGFX (MonoGame FX shader compiler) is working with two different formats for shaders - one uses HLSL and another GLSL (for DirectX and OpenGL, respectively). It means there is no single compiler which will work with .FX files supplied currently with the game on both Windows and Linux. Duplicating shaders on both shader languages is something we need to avoid at any cost (it will complicate development and modding), so we have only a few options - wait until MonoGame team implement support for HLSL shaders compilation on non-Windows platforms or switch to Vulkan, rewrite our current shaders and use the Vulkan shader compiler (which is cross-platform). The MonoGame team also have plans for adding Vulkan support to MonoGame so maybe this is a way to go.

The good news is that Microsoft will ship .NET Core 2.0 very soon which is an absolutely amazing re-implementation of .NET Framework - with better performance, completely open source and cross-platform. In theory, it might allow us to make a single build of the game which will run everywhere (if we include .NET Core runtime with the game for all the OSes we're going to support). And it's much faster and more stable than Mono, with the best ever support from Microsoft and community.

Also, NoesisGUI much improved over last years so we can expect great stability and performance this time (with VoidExpanse it was very rough for a few months after release).

Regards!

Looks interesting!

That galaxy looking very dense. 759 stars, 88037 asteroids, 9486 ships, 114 stations, 1617 jumpgates. That's really a lot and the game was not designed for this amount of objects. Use on your own risk :-).

You can upload your image on http://tinypic.com/
then you need to copy-paste the text from "IMG Code for Forums & Message Boards".

Hi,

no, it's not possible to inline the script code into XML. The script files should be separate from XML.

Regards!

Press F12 key to make a screenshot.

Unfortunately, there is no way to modify galaxy map without hacking of DLL and it's really hard work as it will require a lot of changes. And you will be unable to distribute it as a mod (MPK-file).