Testing from 0.199.132a

-validate-
-confirmed-

Latest release has made the mining drones completely non responsive to the "mine this sector" command.

great have fun , closing this now

the sad problem is that their is supposed to be a building limit obove and around planets .. which has been broken.

It isn't happening just on conversion to new chunks.

I follow your instruction. Install manually Java 64 bit, and change my memory settings... The game was running, but still, it was struggling a lot. So I uninstall and re-install it using the Starmade site instead of the Steam one. Now it's running very smoothly. Thank you very much for all the help!

This is true for the Mushrooms T1769

this is wrong on the game bug tracker

The whole permission system needs to be overhauled. Being restricted to placing blocks next to something you want to give access too is just a bad system. I know it's an engine limitation currently but it's still a bad system.

You are running the game on 32 bit java

[2016-08-03 07:32:09] [LIBLOADER] JAVA Oracle Corporation - 1.8.0_101 - C:\Program Files (x86)\Java\jre1.8.0_101
[2016-08-03 07:32:09] [LIBLOADER] ARCHITECTURE x86
[2016-08-03 07:32:09] [LIBLOADER] LOADED WINDOWS 32bit NATIVE LIBRARIES 
[2016-08-03 07:32:09] [LIBLOADER] FastNoiseSIMD Level: 2

please manually install the latest 64 bit version -> https://www.java.com/en/download/manual.jsp

-confirmed-

typo in log.txt

-validated-

closing this as fixed
asteroids do generate quite well

this is a support problem not a bug it seems

-Validated-
-Confirmed-

OK... putting back in queue as it seems that the initial path settup isnt catching the illegal characters in the same way as the input from the options menu does.

linux-i32 launcher (linux64 bit multi-arch) launcher started fine after I chased down a missing i386 library. Game starts fine and joins lan word w/bundled 32bit java

Linux64:
When updating from the first time selection, all characters are accepted and not converted to spaces

Looks like no one has looked at this yet, so heres a example blueprint I slapped together from some random cache files.
Spawn as admin to avoid invalid blueprint issue.

The next build fixes the broken use case of (2048+1024) initial+early not snapping to the 3,072 lower-bound. The math is also easier to read now, and slightly faster.

Its an older vessel. I can submit it in .sment format onto the Dock for you if it is required that this specific vessel is used in testing... But this is an old, closed issue; the other issue contains a Sment version of this ship in attachments I do believe

0 - 20 is numbering of the logs 0 newest 20 oldest ... a new one pushes all other one to 20 .. 21 is deleted. .. afaik

Wouldn't StarMade.#.log be more semantically correct?

This really needs to be two separate tickets.

This is incorrect behavior.
The slider should always snap to the lower bound, the powers of 2 in between, and the upper bound.

According to StormWing0 problem is fixed with .132a

With initial + early generation >= 2GB, the slider will not slide below the next power of two. Below 2 GB, it will slide down to a value equal to initial + early generation. Whichever behavior is intended, something is inconsistent.

-QA Testing-

-QA Testing-

to be able to place them as deco blocks in the first place was a bug.
that wasnt intended at all for gameplay purposes.
unconnected they should always be transparent

-validated-
-confirmed-