Key words come to mind "Interpolation" and "Dead Reckoning" which are the technical terms that describe fluid, smooth multiplayer experiences. Well,  based on a video I have seen on Microsoft flight simulator 2020.

Case in point, it has been 10 years that Shores of Hazeron has been open to the public, and I believe it is time to drill this functionality into the game before an aspirational steam release.

Refer to the video's below to see my usual experience of the game's AI, animals and other players movement when observing from my own perspective (they all look the same)

https://youtu.be/Zddbo1-yn0c?t=44

Note that, that video is from 2015 and is still relevant to the issue at hand.

https://www.youtube.com/watch?v=6o7n6reHqLo

Crew movement; video as of this week. Same for troops etc and other players appear to slide show as well as they run - you can imagine what PVP is like...

https://www.youtube.com/watch?v=YyfguFib11E

Nature's animals, same as crew etc, video taken as of this week.

A good article on the topic as well: https://www.gamasutra.com/view/feature/1...g_for_.php

Now i'm not going to pretend to be an expert on the field, but i'm pretty sure a lot of other multiplayer, and even more faster paced games employ some form of this methodology in their design, and hopefully, we see the same being employed in Hazeron.

Similar to Elite: Dangerous, perhaps a method for preventing atmo-diving/sundiving would be to upgrade the grav drive mechanism into a semi-warp style drive, where the AI will travel towards its targets in a fluid fashion as the same before, and then designate all celestial objects with an invisible 'exclusion' zone around it, upon an accidental AI malfunction, the ship will collide first with this 'exclusion' zone instead of the planet itself, rendering the occupants unharmed as the grav drive 'cools down'.

Grav drive wouldn't be as fast as the warp drive, but it has a distinct bonus compared to rocket driven space craft. So this is an idea to change the mechanics of how a grav drive behaves in relation to its surroundings rather than its arbitrary speed.

It would be useful when upgrading to a new manufacturing building if there was some way to transfer all the processes configured in an existing building, maybe by allowing copying the configuration to storage media. It is particularly tedious to copy the production lines of an airport repair shop, which typically have many production lines to cover every type of module.

EDIT: Also useful when you just want to move a building somewhere else.

In addition to the dedicated sell button in the F11 menu one should be able to hail a building on  the voice channel while standing on its plot.
IMO, the benefit of this would be consistent with how overall trade works and help to establish a vague sense of "comms range" for various building types

Even on the highest grid brightness setting, the grid is very hard to see:


I wish there was an option to make the grid thicker; it seems that with just 1-pixel thick lines there's a limit to how visible the grid can be.

Halt, Citizen! Soviet Empire announces the creation of the Noncommercial Intergalactic Imperial News Agency "Red Star".

 It is a neutral platform (like Galnet from Elite Dangerous) where news from all over the universe is posted, as a diplomatic messages, information or announcments. If you want to contact - write on the I.N.A. Red Star Forum (this thread) or email at imperialnewsagency@gmail.com - our contact person Joseph Goebbels will answer you as soon as possible.

 We will also post Hazeron development news if Haxus agrees. We will not search for news throughout the forum or discord (although if we find out about them, we will of course publish), if you want to publish a message in the news feed - write here or by mail, the message will be published in news format.
 This agency was created not only for the RP purpose, but also for the centralization of the diplomatic and informational space of Hazeron. News will be added whenever possible, probably 2-3 times a week. News site still WIP, but already functional any necessary help welcomed. Also, we need someone who help with English part because it's not native language of creators.

 We will also open to all suggestions and wishes.

https://imperialnewsagency.blogspot.com/

Howdy folks,

I brought this up in galactic chat the other day, but I think it could be useful for city builders!

Basically, for anyone who's played Factorio, I'm talking about the production charts, where you get information on the rate of production of components and commodities, so you know if you have bottlenecks or if you're making a gain or loss of product. I.E: Metal +5k, Fruit +500, Gas -25 etc. Not just the change from one report to the next, but what the trend currently is. Then you could decide if you needed to up production or cut back to redirect labour elsewhere.

I'm not skilled or knowledgeable enough to write code, and the reports seem to occur often enough that you could compile some relatively accurate data out of the storage reports themselves, but I would imagine that the calculations of all of the data for every city in the universe might end up being hard on the servers. Maybe it could be a localized script that could be run on command? Or a third party program if someones brave enough to write one up.

Before I go too far into this though, this was just an idea and suggestion I had at random when I noticed I had massive stockpiles of some products and barely any for others.

Anyways, let me know what you think!

Cheers,
SJ

A couple of new tools added to the designer would help tremendously with usability.

The first is an automatic room void tool.

Now I know a room void "button" has been debated against and makes good sense as to why it will never be added.

Which is why I think a tool would be best instead. The method of implementation I am thinking is a polygon based extrusion tool. Simply put, the user would draw a polygon on the grid extrude it to height and a hull void would generate 0.1 smaller than the room relative to each face. This room would have simple square walls be a pure polygon, all convex sides, on the floor and ceiling, and could even have a fixed number of edges for the source polygon and subsequent walls as decided based on the necessary limitations of the pathfinding mechanics. This tool call it room+room void extrusion would allow people to draw full corridors and rooms using the current designer quickly and easily.

The next idea, Doors, two tools air tight and not airtight. 

Not airtight doors could be added by drawing a line from one room wall to the other and setting a wall thickness this auto generated door would be a three piece mesh with three barriers. Two static and one barrier/mesh tied with the door state. This door would exist within the room void meaning it would not isolate them when opened or closed.

The next tool should be the air tight door. This would be a simple auto door tool that would require one to draw a polygon on one wall like the door jig and then have it cut the door with some simple checks in place both walls need to be squares, parallel and be less then 0.5 meters away. This auto door tool would automatically add the door and associated walk path and room void.

It should project a breathable atmo around the hull, akin to a fancy skinned biodome.
It all should protect against all environment damage, Corrosion, Pressure, and excess speed. Making entering corrosive and Insidious atmospheres easier as well as helping with aerobraking all at the expanse of sweet sweet power.

Hello,
I was wondering if you could supply a basic spec on how the SoH format is constructed. The spec doesn't need to be super detailed, but information about if it's compressed (and what algorithm is used), general structure of the file like vertex data, then uvs, then index array, then normals, etc.

I tried reverse engineering the format myself but the furthest I got was figuring out that the first 2 bytes were likely a version identifier, next 4 bytes are an int denoting the size of a data blob, and then the rest of the data blob is mostly unknown. There's a good chance that the first 4 bytes of the data blob are also a version identifier but there's no way to really tell. All of the data seems to be strewn about in a way I can't really glean from trial and error, and even something as simple as changing a single vertex changes a ton of the data.

I tried using the designer multiple times but i'm just over it not working the way i want it to, and having to deal with manually texture mapping every individual face since everything is bugged, and it is actually far easier for me to bypass it entirely by creating tools to export/convert from other editors. I would really like to be able to contribute nice looking buildings/ships that other people could use but unfortunately it's just an absolute pain to do anything other than an untextured blob at present.

Ideally it would be nice if you could implement gltf/glb importing as well, since STL is an ancient format that isn't particularly useful for anything, and/or fix the 3DS import to actually properly respect UVs instead of shoving them off way into the corner randomly (although i'd still have to use an external converter to go from GLB->3DS), that would also be great.

Thanks