Yeah I deleted my guy before I thought about it and now there's a bunch of blueprints on the exchange that I had wanted to improve upon over time. I'd rather not clutter it up if I could avoid it so if we could pull Kelpi's buildings I'd appreciate it.

I'll just start this thread so we can keep the bug reports on-topic.
See: (Idea thread) Metal EV Helmet doesn't require Cryo Heat Sink

I can't see a reason for having an EV suit be two separate parts, EV Helmet and EV Suit. It doubles the amount of things we need to manufacture without any real benefit.

(03-09-2020, 12:50 AM)Xantheose Wrote: - Having a mix between helmets and armor to mix resistances

(03-09-2020, 12:50 AM)Xantheose Wrote: - Crafting helmets of one material and armor of another one because it's less expansive

(03-09-2020, 12:50 AM)Xantheose Wrote: - 2 different loots from troops then you can't build a full stuff to every troop you kill

(03-09-2020, 12:50 AM)Xantheose Wrote: - You can getting one broken while the other is ok

(03-09-2020, 12:50 AM)Xantheose Wrote: - Elec parts quality is based on an average quality, metal isn't

(03-09-2020, 12:50 AM)Xantheose Wrote: - All armors have helmet and armor but EV only armor? No. That's called consistency.

A number of players mentioned their cities randomly decaying. They didn't know how lands worked or that they manually had to add a system to their avatar's land.

I simply suggest that when you found a new city, it should automatically add the solar system to the avatar's land. Assuming this would produce the same thought message as normal, new players would notice something is wrong on their own if they get a message saying "I can't add more solar systems to my land." when they found a new city.

This would also help us forgetful veteran players.

Wiki page for context: http://hazeron.com/wiki/index.php/Land

Hi!

As the title suggests, I was wondering if you ever thought of implementing scripts to detect when a server stops responding, and bring them back online automatically?

I have been getting 'limbo'd' due to server crashes almost every night since the restart--in fact both of my avatars have been unable to log in since last night--and it's gotten to a point where I think a system like this could be hugely beneficial. Would it be feasible to write some shell scripts to accomplish this? I think it would go a long way towards improving the game experience for everyone.

These are two suggestions wrapped into one thread as they both address FTL Travel Changes. The first suggestion is to move wormholes to the outer edge of the system, instead of orbiting the primary (or secondary star with black hole systems). Intergalactic wormholes around supermassive black holes (and potential future intragalactic wormholes around stellar mass black holes) should remain close to the event horizon of the black hole for added challenge. This suggestion is made as it would reduce the issues associated with Wormhole travel, namely sundiving and wormholes appearing in a close orbiting companion star or planet that results in instant spaceship destruction. This would also create added challenge for system defence requiring multiple stations to blockade the system against wormhole travel. This would also remove the requirement for all black hole systems to have a companion star, which is good as lone systems with just a black hole are spooky and systems with no star but perhaps an asteroid belt / accretion disk and planets are interesting.

The second suggestion is related to how the AI handles warping to another system. Currently the AI will warp until the target system is reached, then drop out right at the system boundary which is often very far away. The ship will then accelerate at sublight speeds until it reaches the 'outer edge' of the system before deciding it has arrived and stopping. My suggestion is that instead the AI will warp to this 'outer edge', or at least a lot closer. This will save players a lot of time.

Rubber Banding
I rode a motor bike for ten seconds and got off. The motor bike disappeared and I couldn't move. Eventually the motor bike came lurching down the street and stopped next to me where I got off of it. Then I could move again. This is super obnoxious.

Fixed the bug. Built this patch update that contains only that one bug fix. I am working on an update with more fixes but it is not ready to be posted. The rubber banding bug was so bad I couldn't stand to let it go through the weekend that way.

Win64 client has been updated.
Other clients will be posted as they finish.

Would be nice if you could automatically (by pressing a GUI button) scrap a whole ship for modules or materials.

Would require it to be moored at station / airport. Or maybe the same conditions than mothball.

Scrapped materials / modules quantity would depend of the current durability of the ship. Maybe have a quantity penalty based on quality, kinda like quality fails when fetching.

Could be scraped by Airport Repair Shops, and should work with ships of other empires (captured).

Scrap should require a fraction of the nominal design build time.

Why ?
Well it's really annoying to waste tons of ressources into a big ship and having to replace it for a random reason (newly found Q255 hull ressource / interior update of a mothership etc)
It's even worst when you think about all the ressources your nearly-pristine ship represent.

I've found it's kinda frustrating placing mines/wells with the new node based system. It's entirely unclear where nodes are since they are near impossible to see, especially at night. It makes it very frustrating to try and place your building on these nodes to maximize output, and since you can't overlap buildings (which is good) you want to get as much as you can under one building.



How many gems are for the first gem icon? 8? 7? is the 8 pulling one from the second gem icon? Getting 11 gems on this mine is nice, but how much is that leaving out on the left or right? Would it be better to do 2 mines? Would you get more? You gotta try all combinations to figure it out. Time consuming, frustrating.

I propose that while you have a building in hand, the nodes should show up as little points color coded. So in this case the red would be gems, and the white is the stone.


This field would not spread far past the building outline, so as to not clutter the screen, but it would show you enough information to inform your decision on where to actually place the building.

On a similar note, a planet tells me it has 1% oil and 1% ore. Ore is everywhere, very abundant. But oil? Well I searched for an hour and couldn't find any in my resource zone. 1% for both? You sure? To ease with this frustration, I suggest allowing ships to scan a planet for resources, and this would then allow a new use for the surface map. After a planet is scanned for resources, the surface map will show a side bar/box with a selection for planetary resources. When selected, it will show a rough estimation for where these resources are. The estimation is a little vague, so it won't be at the exact coordinates, but close. You still need to search, but now you don't need to search the entire planet.

Resource view with Oil selected, shows that there is oil in zone 3, it just happens to be down near the pole!

Hey, so, some parts of a building have specific sizes m^3 per unit of... thing. Like an office needs 34 m^3 or something. As far as I can tell there's no reason to have sliders that lets us pick some fraction of a whole unit, so either having slider increments of the unit's requirements or an field to enter the specific number of units desired would be useful. For example, If I want 8 generators, I could enter '8' and the designer would put the required amount of space in. Or, the slider itself would just move in whatever increment is required.

It would be nice to have an option to flatten the star map for easier wormhole navigation; the Y-value of systems isn't very important when navigating through wormholes except for determining what sector a system is in, but with the ability to flatten and unflatten at will, that issue could be negated. Flattened maps are much easier to read than 3D maps, even if some information is lost in the flattening process.