A small update that includes some fixes for common issues is a good thing, right? I mean, what do you want them to do, wait a month before fixing those problems?
What I want is irrelevant. But seeing as you asked and I respect you enough to respond...I want them to try harder. If Eleon thinks their game is good enough for prime time they might want to put their big boy pants on and get cracking.
Isn't the "log writer" an integral part of the WAL protocol ? "The WAL protocol asserts that the log records representing changes to some data must already be in stable storage before the changed data is allowed to replace the previous version of the data in nonvolatile storage. That is, the system is not allowed to write an updated page to the nonvolatile storage version of the page until at least the undo portions of the log records which describe the updates to the page have been written to stable storage." I'm more puzzled by this wording here: "- DB: Sqlite setting journal_mode to WAL now (only for new savegames) " Does it mean that the WAL mode will only affect games started after the patch, or that it will only apply when making a new savegame ?
I guess this is not what you were referring to as "size glitch". Is this the "toilet spamming" referred to previously? WC height is approx. 66 cm or nearly 26". Good height for a bar stool, not so good for leaving a "stool".
I'm thinking that either the delete or WAL methods use logging. Delete mode writes to the database file first and then write the previous state in the journal (undo log) while WAL keeps the database intact and writes the changes to journal ("redo"). I'm probably oversimplifying things. Haha. What I meant for things screwing up is because write is now in memory first. I'm not sure how that is handled during a power loss. EDIT: Actually "journal_modes" can't be combined so I guess they first tried using MEMORY which is something risky and then changed it to WAL. According to documentation: "The MEMORY journaling mode stores the rollback journal in volatile RAM. This saves disk I/O but at the expense of database safety and integrity. If the application using SQLite crashes in the middle of a transaction when the MEMORY journaling mode is set, then the database file will very likely go corrupt." So I misunderstood the two update notes: - DB: setting journal_mode to MEMORY in the hope of increasing write performance and - DB: Sqlite setting journal_mode to WAL now (only for new savegames) I thought they were combining both but it's not possible. Thankfully. Yes, because the DB file is in delete mode which is the default mode. If you want to change your save game to WAL, you'll need to use an SQL Editor (like DBeaver, SQuirreL, etc.), connect to the file in autocommit and then issue the command "PRAGMA journal_mode=WAL;". I did it in my current save game and it should be safe but a backup is never too much.
Not sure I follow you. My question was to know if the WAL mode applies when making a savegame, or for games started after (so either one or the other, can't be "yes") as from what I understand, all other transactions unrelated to a savegame are in MEMORY mode. Am I wrong ? >> Because the game constantly updates the database during gameplay, but only saves the gamestate at specific intervals automatically (active game).
Only new savegames are in WAL mode, yes. Existing savegames are in DELETE mode. More here about all existing modes: https://www.sqlite.org/pragma.html#pragma_journal_mode It seems they tried using MEMORY and then chose WAL instead from the patch notes.
Not sure. I'm thinking it should prevent lags when you see those "update" commands in the console. I play SP here but I used to notice the game slowing down while the database was being written, updating entities, player data and stuff. It seems they improved a lot since A12, at least in my system.
These mini "lag" spikes may be the results of many things, and in demanding games databases are not the recommended way to boost performance overall. They're good for some aspects of asset and data management, but they can't feed the render / physics parts of the engine at adequate speed. In fact since you had a look inside the "savegame" database you know what's in there, and surely you don't see all performance-related assets (models/mips/ textures/ sounds/ scripts etc). There's also the "garbage collector" that makes his regular scan and clean that is notorious for causing these mini lag spikes.
Well, I'm not discarding asset rendering and other stuff. I have a capable system and every time I sensed a slow down there were multiple writes with long duration to database and I saw that it took several milliseconds each. In my case, my suspicion is still IO related. Maybe they optimized elsewhere, I dunno. But I noticed a big improvement without having to change any configuration.
I saw a noticeable change in exp 10, not so much in exp 11, and exp 12 was very similar. The only major difference I see is much faster game start (from desktop), and the game also shuts down faster, although this is variable from one session to another. Edit : almost forgot that space/planet/space transition is a thousand times smoother now.
So, gentlemen, in whom to spit in the impudent face for the alteration of Zirax patrol ships? ... which fly at the speed of players in the starting system ... It's just not normal when you fly off the planet and grab 10 volleys of missiles. No, I would understand if I was an enemy and crossed the border of my country ... but this is a game, okay, smarter drones, it's even funny when you try to get away from drones that fly faster on the hover ... But what you can't normally to fly off the planet ... this is already too much and actually out of balance.
Been there. Spiral runaway into asteroid belt and maneuvers among rocks is the only option. AI's flight track is a disaster so single asteroid can sometimes make them defenceless (If such word exist)
I started a fresh vanilla game this afternoon, just a kill a bit of time - I'd been watching a Flipsie and Capac video which inspired me to jump in, seeing them re-learning the game having not played since A7. I've abandoned this game now as I was getting frustrated at some long-standing issues. Picture this, I'm standing on a Base block and there's an Assassin approaching. As he reaches the foot of the block I'm standing on he cannot be seen, meaning there is ZERO LoS between us. I cannot shoot him with my Assault Rifle. However, he's standing there hitting me just fine. Time and time and time again, I'm getting hit when I shouldn't be. Best case I loose a little health, worst case I ultimately die (I role-play that dying is significant) or I suffer the frustration of some sort of infection for which no cure exists outside of a lucky loot find. Frustrating. This really does need addressing, it's been a thing for far too long now. Everyone must have experienced it at some point or another, you're "safe" out of reach and shielded by a solid block of Concrete or Steel. You cannot shoot (or see) your foe, yet they can Melee away through the block to hit you. I used to consider Nightmares the worst culprit for this, in part due to their height. They cannot visually fit in a one block high space, yet they can still move through such spaces. This results in them clipping into the block above them which, as we know, is what can allow hitting / shooting through that block due to how the hit boxes seem to work. However, seeing the Assassin NPC so good at hitting through blocks too means there's more than one issue at play here. The Assassin is relatively short, due to a some what hunched stance - this should make you safer when higher up. The Assassin also doesn't appear to clip much horizontally, other than it's hands / claws - which might be significant - yet it still has the ability to hit the player when both out of range - if no block were present - and of course through any block that is present. Basically, I'm finding this more and more frustrating. I love a genuine challenge, but invalidly taking damage etc. during encounters is a real pain. I play cautiously, tactically scouting out enemy locations, being vigilant when out and about, taking care of my positioning but the game's combat system isn't robust enough to support this. In essence, the "cover" system doesn't work. The player can be perfectly under cover, be it a block, rock etc. yet still take damage. With things like this not working well currently, I can understand why the game isn't ready for crouching yet. As Eleon are working on polishing things now, I really hope these kinds of issues with the basic game-mechanics can be sorted. I know I'm likely seeming a bit grumpy lately, but these issues are really taking the fun out of things in this released title. What do others think about this? Scoob.
database ship "bungee" is worse than ever after resetting game. Ships keep jumping back in time to a earlier position. Seems like the in memory db and commit doesnt work to well. No errors in any logs at all. Plenty of ram on server
I noticed that too while attacking a frigate but I thought it maybe was an old bug. Enemy ship started changing position in small jumps.
It's sad, over the last year or two I've seen many longer-term forum members take a semi-permanent hiatus from the game due to frustration with the lack of improvement of many features, including many basic game functions. All with good reason too as these issues are often game breaking for each individual. Immersion is lost when you dig on a beach and see the water floating, combat is ruined when you try to play tactically but it doesn't matter as it turns into a "who has more HP" game (I was hoping that implementation of crouching would force the team to overhaul the "cover" system), the awe of being lost in the galaxy doesn't exist when every planet is populated with the local rendition of a convenience store. I personally have stopped playing for over a year now as I realized nothing that I feel passionate about in this game is being taken seriously enough to improve for the sake of gameplay, all with the hope and longing to return one day when I feel these issues are addressed. I am giving it a final chance by watching what the team does from this point on, being "the release" and all. I understand the team doesn't agree that 1.0 is considered "full release" but they can't deny the fact that everyone else sees it as such. And being perceived as such they have some very high expectations to meet without their security blanket that was called Early Access. Let's hope, for this project that we all love, that Eleon has some tricks up their sleeves or the dedication to truly listen to their community and unlock raw potential this game holds. Empyrion can be extremely great. It just depends on how the team handles it from here on out.
