If this is a set-up Coop-Server for the Vanilla Game I would follow @Escarli herewith and file a Bag Report
Young lad is looking into it to see what's going on and will file bug report for it. He is the computer expert. I am just the switch on computer and switch on game person. Too old to know how computers work lol
I suspect that it’s related to the addition of the backup for player.dat. Seen issues before like this when the file is corrupted, but I need to get around to characterising the issue properly.
I'm in the same situation mate. Stopped playing because I can hardly see the cross hair. I've gone back to Minecraft. Making an automated ice farm at the moment.
I think perhaps we're talking at cross purposes here, I'm talking about Cargo Mass, sorry, I thought that was clear, but maybe not as I do ramble when I'm tired...and in general to be fair. All I'm trying to get at is that a vessel's top speed being limited when loaded with cargo vs. not loaded with cargo isn't something I think makes for good gameplay. I'm aware there are other potential factors, but it's not those I'm talking about. I.e. My vessel - be it HV, SV or CV - can reach its class-limited max speed on a planet. I fill one of the cargo boxes / controllers (cargo mass) and now it can't, and said speed may be severely impacted. The only variable that's changed is the added mass of the Cargo. Lifting said cargo mass has been the design bias of the vessel - lots of lifting thrust - but once in the air / hovering (HV) the forward thrust that allowed it to hit its top speed before, should still manage that, but just take a little longer in my view. Like it did before. It's just this part of the overall equation I think is a bad design choice. Sure, it's been improved - the devs reduce the impact of cargo mass on top speed by, IIRC, 50% in an earlier update - which helped a lot. But it's still really easy for a vessel to be crippled when loaded with cargo. This has a particularly high impact during the early-game, and slow vessels are frustrating to use. My original reply about not being able to reach the speed of light, but 70m.s should be possible was meant to be tongue in cheek of course. I do actually know a little bit about real world physics, or I could google and fake it if I didn't lol. Or speak to one of my physicist friends as I'm sure they'd coach me. The primary thing here is the "not fun" aspect, something I notice particularly significantly during the early-game. There has been a lot of chat about this and I think the general consensus is that people don't enjoy this particular feature much. Hence, at least in part, why Eleon made some changes to it, which, while of course welcome, still don't go quite far enough in my view. Anyway, I didn't really intend to bring this all up again, just to reply to a post in an amusing fashion. However, I then waffled a bit about a change I'm really not fond of, evidently conveying my issues with it poorly. Scoob.
I just wanted to give a "gamey" explanation that was not too far fetched, but honestly it is the least of my concerns with the game. I have a clear idea of what I want to do, pieces are slowly falling into place, and with new features like decals and dialog/ scenario capabilities it only opens doors to get even further from the "vanilla" setup. So in a way I don't even care if Eleon completely botches the vanilla game's balance because we can practically reverse-mod it from the ground up. The only usage I would see for that cargo thing could be to use it to simulate effect of a EMP weapon against a ship, slowing it down by putting some very heavy item in there via scenario reward or something similar. If I enable CPU it will probably be used in a similar way, only having high values in 1 or 2 specific devices, and insignificant for everything else. And that's how I view almost all aspects of the game that irritate many players : some "working mechanics" that we can use as we want, provided we know how to mod them, and they can become something completely different than what they were created for. Where some players may see "hindrance" I see another tool to help diversify events in game, and not necessarily how they were intended.
Probably not the place for complaining about current state of end game HVs as I dont think anything changed. That said... Having just made a 165t T4,L20 HV (and cardboard at that according to your definition as 1-2 layer combat steel for PvE only of course) I have to say they do kind of suck compared to SVs. To get reasonable non RSI inducing turning I ended up with 72(!!!) RCS on it - the huge number of side thrusters just wouldnt turn the damn thing much unless I doubled its length and gave it an ideal brick shape. The end result I think as far as such HVs go is one that is actually quite agile (nearly 40m/s^2 sideways acceleration and nearly 40deg/s yaw). The irony, I have a companion T4 assault SV that can pick up it resulting in a combined mass of over 270t (well over that when you add ammo in both) and despite the very non-ideal mass distribution for the SV when carrying the HV it can still run rings around the HV while carrying an identical HV.
We needed wheels. They should have ditched the whole HV category and replaced it with proper wheels, keeping the hover engines for CV/ SV as anti-ground-collision safety, but have vehicles that rest on their wheels without all this mass balancing and terrain navigation problems. I like challenges. If I was making a game with vehicles, I could not simply skip "wheels" and I would surely develop a whole palette of specialized devices and blocks to make wheeled vehicles. This is one big missed opportunity, and the very faint line between HV and SV with artificial limits would simply not exist with proper wheel vehicle class ; they would be complementary. So it looks that by not wanting to tackle the "difficulty" to implement even a half-baked, low- quality wheel vehicle class, the developers have been struggling from the start trying to get the wonky HV to fly/ accelerate correctly, not sink in water, get stuck in mining holes and on small trees, get flipped over when strafing, put restrictions in devices code so can't fly in space, etc. Why not just make wheels. These vehicles don't challenge the rendering engine by speeding through deco like HVs, they can't go on water (use a SV), they can't fly in space, they don't strafe. I just don't understand.
I would agree if wheels can be done right. OTOH I have nightmares about wheels from space engineers where I have lost count of the number of time my vessel has inexplicably face planted and exploded despite being on perfectly flat ground (ice lake for eg - you dont get much flatter in SE). I think the problem in this game is the nature of the way the play-school physics and collision stuff feels like it is done - by sampling a point rather than projecting a path - I guess that is why thing get tangled in trees and each other so easily. I just dont think wheel can work well under those conditions - part the reason why the existing motor bike is such a pain I guess. I also have a suspicion they would just hack it perhaps - pretend the wheels are actual wheels with a suspension when in fact they end up being short range hover engines and the 'wheels' just end up cosmetic with no collider followed by 6 months of clueless hacks with terrible performance to pretend that they appear to act more like wheels. In the end of course they will probably try to avoid the perf issue by making each wheel need 10k cpu...
Well that's the positive aspect of Empyrion : it's not striving for realism like Space Engineers, we would only have problems with terrain like we already have with HV - but they don't explode... But at least we would have much less device duplication, a much slower progression from hard survival on foot to flying into space after a few hours of gameplay. Also less devices flavors (how many jet thrusters we have...) but more focus on ship function de facto. They don't have to make F1FA - quality wheel system : a fixed distance to ground, some "buffer" space to ignore small obstacles and bumps, and wheels are just animated props anyway. They show how to do wheel vehicles in tutorials for beginners. I can't accept that seasoned developers can't even make a mock-up wheel system.
I think progression is a separate and much more complex discussion. I agree current progression is a mess but I dont think changing the nature of land vehicles will impact that at all. Instead the only effort they throw at progression is skills based weapon effects including this nonsense damage FFS when instead the whole thing needs a massive rethink.
Quite the contrary. Players new to the game don't have a clue about what to do, because what has been proposed to model "progression" has been based on suggestions and complaints from experienced players that find the game boring once they get their end-game CV. If Eleon tries to slow thes players down from having their big warp-capable CV in the starter system players will complain again. If they make it too easy then hardcore survivalists will say that the real "survival" part of the game is the only short moment before they get the capacity to fly off the planet, which comes quite quickly. We can't build a shack from rocks and wood, it need a core, we have no fire, no basic melee weapon, etc. In fact it's like they never intended to have us stranded anywhere, it's just a way to follow-up from the arrival in the shuttle, because it has been like that from the start and they never intended to make it any different. Just like the motorbike in fact. But having the player to be able to make basic equipment, then have a normal "low tech" vehicle at some point to be protected from elements ans have better carry capacity, maybe one turret as the top-of-the-line defence at that stage. Enemies and POIs can then all be scaled down on the starter world, and players can't build their castle with chain production and artillery and whatnot. But instead we get all this capacity after rising quite fast in levels, unlocking end game tech while still facing the very first enemies the game has to offer, mixed with unbeatable POIs that have no business on the starter world, apart from scaring the player into staying far and getting on his way to get better tech elsewhere. But just making that end-game tech hard to get by forcing grind for hours is not "progression" : it's grind. Unimaginative, boring, repetitive. I want my wheels.
The game may have lots of bugs and ill thought out ideas..... but at least we have pretty rings round planets now...
I like the game. A lot. I have 10x as many hours played in it as in my next most-played game. As far as making a wood shack, you start with a core, and plastic bricks (or whatever they're called) are made out of wood. So, you can already make a low-tech plastic shack out of wood. But why wheels? A starter SV can be had at level 5, a starter HV so early in the game, that picking a few plants will get you the required levels. Who needs wheels? Who needs another motorbike? For experienced players wanting new "stuff" and a greater challenge, there's Reforged Eden. Or just Reforged for a greater challenge, Eden for new stuff. And I still don't see any use for wheels. HV's can go over any terrain, including water. Wheels cannot. I have a micro-SV that cost very little and was available at lvl5. It beats the heck out of any wheeled vehicles. I wish they would fix a few of the bugs, and amp up the graphics quality, but I do not wish for wheels. And I still really like the game. A lot.
OP UPDATED https://empyriononline.com/threads/experimental-v1-3.96371/ Patch 2020-12-07 v1.3 B3187 Changes: Decals: - Decals on structures: you can now specify a web url to download the image from there. - Decals on structures: you can now specify '-Video=' to show a mp4 video instead of a texture. Please use responsible as this can affect performance! - Decals on structures: added '-Color=r,g,b,a', '-ColliderMode=NoCollision|Collision|Off' to set tint color/transparency and optional colliders to the decal. - Decals on structures get now saved into <gamename>/Shared/<structid>/decals.txt to be able to change existing decals manually using a text editor. - Decals with video: warning message 'AudioSampleProvider buffer overflow. 1024 sample frames discarded.' should now occur less often. - Console cmd 'decals reload' will now prefer the 'decals.txt' in the 'Shared' for reloading. With this also player created structures can be adjusted during runtime. - ClientUpload system: added 'mp4' to the file extensions that get uploaded to clients. - Adjusted position of SantaClauseHat + SnowmanHead a bit to not clip into armor too much. - If RangeAU/RangeLY is modded with Mod.RangeAU/Mod.RangeLY, it is displayed correctly now in info texts PDA/Story: - Added the Journey Book as new Empyriopedia element for tracking the story progress (currently all visible;will change later) and re-read all important info, logs and dialogues - Changed: Starting the Journey Apollon logs now available in Journey Book (removed from dialogue, because considered as too long) - Updated Ilmarinen (Ancient Revelations) with new Infected Legacy creatures - Updated UCH Heidelberg, Sigma Fulcrum - Updated Loca texts Misc: - Modded item properties via player skills: added BlastDamage - Modded item properties via player skills: added RangeAU, RangeLY from BlocksConfig - Updated: Starter planet description texts (random default scenario) - Updated: XenuFuelDepot (thx to sulusdacor) - Updated: added commodity traders welcome texts - Added Pirates OPV 'Quin Merac' (thx to sulusdacor) - Added Station Services for Ambassador Vessel and GLaD Outpost - Added Commodity Traders to several orbital stations (thx to Kaeser) - Item Icons can now be modded in SharedData/Content/Bundles/ItemIcons - Item Icons are now loaded from asset bundle (to prepare allowing to mod them, modding not active yet!). Please watch out for missing item icons! - Improved: Color Tool Configure window can now be closed with ESC key (behaves like clicking on 'Cancel') - Changed: Creative Scenario: Moved position of White Canvas moon further out - Added proper names for new NPC enemies and civilians to loca file (only EN; Translations will follow) - Added first draft of suit props: SantaClauseHat, SnowmanHead. Use console cmd 'psp SnowmanHead' or 'psp SantaClauseHat' for now. - TokenConfig.ecf: added example how to set an icon for a token Fixes: - Fixed: CoQ when skill values get saved to DB - Fixed: UCH Heidelberg wreckage too far away from starting point on Snow Starter (random default scenario) - Fixed: Ok'Y medical had 2x Stomach Pills entries - Fixed: BUDS entry in Empyriopedia showing/naming the wrong plant - Fixed: Motorbike exception spam on pf server - Fixed: CoQ in Color Tool - Fixed: Color Tool not updating RGB/HSV sliders when selecting another palette - Fixed: Self destruct timer for AI vessel triggering incorrectly - Fixed: Item Icons: fix for MP when first time connecting to a server and getting the icons, no icons were displayed - Fixed: Gas Refinery (Traders Guild) Power trader leading to CoQ - Fixed: SuitProps: fix for other player's prop was not visible when entering a MP game. - Fixed: [MP] Legacy base turrets will not shoot - Fixed: Ticks become broken after sleeping in space after multiple warps EAH: - Updated EAH https://empyriononline.com/threads/tool-eah-empyrion-admin-helper-v1-52-x.5771/page-70#post-424576
Guys, Thanks for the trader fix and for all your efforts! I see that you replace the trader in Polaris Gas Refineries and added a new one in the same room. They both look cool of course and commodities are now a reality (I'm so excited for that). But I'm able to buy some items real cheap from trader #1 like Robotics, for instance... And sell it for 10 times the value to trader #2 who's in the same room. Is it supposed to be like that? EDIT 1: I think the problem here is the 80% discount modifier which applies for both sides of the negotiation. EDIT 2: I edited Factory and Powerplant traders to offer 20% discount and now it seems more reasonably balanced. Again, thanks a lot, Eleon, for all your dedication! I loved the changes.