Happy 2022! Now, about those save times...

This forum is the ideal place for all discussion relating to X4. You will also find additional information from developers here.

Moderator: Moderators for English X Forum

dmk
Posts: 682
Joined: Fri, 25. Nov 05, 00:59
x4

Re: Happy 2022! Now, about those save times...

Post by dmk » Thu, 6. Jan 22, 20:15

Panos wrote:
Thu, 6. Jan 22, 17:17
4.20 had a general optimization on game perf including saving. On a 5900X with MP600 nvme drive now takes around 5 seconds to save on Windows 10, compressed, even a 70 hours campaign. That wasn't the case pre 4.20 which needed much more time.

Can clearly see this time 100% of the CPU been used to serialize and save the file.
on my old rig (still 4 real cores, 8 hyperthread one) it takes 1m30sec,
and hibernation is faster, hdd, but during save it is not used more than on 10%,
i.e. no multi-thread usage, and it was fast only in early game, still in late game uncompressed save 800 mb, compressed 95mb

xixas
Posts: 40
Joined: Sat, 1. Jan 22, 22:47

Re: Happy 2022! Now, about those save times...

Post by xixas » Thu, 6. Jan 22, 21:39

Panos wrote:
Thu, 6. Jan 22, 17:17
4.20 had a general optimization on game perf including saving. On a 5900X with MP600 nvme drive now takes around 5 seconds to save on Windows 10, compressed, even a 70 hours campaign. That wasn't the case pre 4.20 which needed much more time.
I'm mainly playing on a 5900HS linux laptop these days, and I've encountered no such improvements.
The 49 second average I quoted was on 4.20, ~200 hrs on the current playthrough, ~90 MB compressed saves.
Looks like the last couple saves are in the realm of 5-8 MB smaller than 4.10 saves, but save duration's about the same.

I've got X4 saving to an external SSD atm, but disk I/O certainly doesn't seem to be the bottleneck.
Ehli wrote:
Thu, 6. Jan 22, 13:42
Sorry for sounding harsh...
S'ok, no kid gloves requested.
Glad you got the indignity out on the first shot :)

But hey, it's not about me, and it's apparent I'm not insulting anyone or trivializing the effort involved.
I'm just making a good-faith effort here on behalf of the player base to get some tangible answers after 3 years and, hopefully, some eventual results.
Ehli wrote:
Thu, 6. Jan 22, 13:42
  1. IMO the OP has way too little information of the X4 code to be giving out advise like that.
  2. You can't assume ECS, it's a custom in-house made engine.
  3. The suggested solution/github code is, IMO, a way too simplistic / is a blue-eyed approach and only shows a lack of understanding their core issue.
  4. ...a mutex eating well over 200 CPU cycles on a fine-grained level. Especially the getValue - even if you use a spinlock instead of a mutex you're performance is now guaranteed abysmal!
  5. The problem isn't serialization, the problem is consistency.
That's a nice list of things we already covered in this thread.
Appreciate the recap, so I won't bother addressing most of it again, save to say about #3 and #4:
  • It was intentionally simplistic for a novice-to-intermediate audience -- it's a general example designed to use as a talking point... and it doesn't mention X4 anywhere in it
  • Sounds like in your haste to post you skipped the second code sample
But no matter.
It's common in every passionate forum that no example is ever good enough.
It's either too generic -- and apparently insulting to some -- or it's hyper-specific and shot down for not being reusable.

I believe the rest of your post could be summarized as "I'd rather feign indignation on behalf of EgoSoft than allow any code-oriented discussion," to which I'll simply say that no one's twisting your arm to talk.
You're more than welcome to snap those big boy suspenders you seem to be so proud of and tell us how it's done if you'd like to contribute.
Reiterating how it's not done, however, is not constructive without counter-suggestion.

Point is, the issue keeps coming up.
Maybe you don't like it. Maybe Imperial Good doesn't like it. Maybe EgoSoft doesn't like it.
Like it or not, the issue is still a problem to a lot of players -- and, frankly, most of them don't care how hard it is to fix.
Most also won't bother making yet another forum account to air their grievance -- they'll just stop playing and casually bash the game to their friends in private when asked why they gave up on it.

In game development, "It's too hard" (usually pronounced "It isn't feasible at this time") is a common delay tactic devs feed their PM to de-prioritize a nagging ticket.
But when Steam, or Apple, or whatever app store your game uses to generate the majority of its revenue says jump... well, impossibilities tend to become possible real quick when it affects the bottom line.

It could be naively argued that this doesn't affect the bottom line because it only affects players after they've made a purchase -- but we all know that's not how it works.
Unhappy players -- especially when they feel they're getting ignored or blown off -- affect sales through the grapevine. That's just the way it is.
But, for the sake of argument, let us say that EgoSoft is perfectly happy with their current quarterlies. That still doesn't change the root of things...

If it's going to keep coming up, we should discuss it constructively.

Panos
Posts: 848
Joined: Sat, 25. Oct 08, 00:48
x4

Re: Happy 2022! Now, about those save times...

Post by Panos » Thu, 6. Jan 22, 21:51

xixas wrote:
Thu, 6. Jan 22, 21:39
Panos wrote:
Thu, 6. Jan 22, 17:17
4.20 had a general optimization on game perf including saving. On a 5900X with MP600 nvme drive now takes around 5 seconds to save on Windows 10, compressed, even a 70 hours campaign. That wasn't the case pre 4.20 which needed much more time.
I'm mainly playing on a 5900HS linux laptop these days, and I've encountered no such improvements.
The 49 second average I quoted was on 4.20, ~200 hrs on the current playthrough, ~90 MB compressed saves.
Looks like the last couple saves are in the realm of 5-8 MB smaller than 4.10 saves, but save duration's about the same.

I've got X4 saving to an external SSD atm, but disk I/O certainly doesn't seem to be the bottleneck.
External SSD cannot be compared with PCIe 4.0 internal NVME drive. The former has 1000MB/s at USB 3.2 connection the other 5000MB/s
Also your laptop ram speed is slower than the desktop one, so is the latency. And RAM speed matters on X4. There is a difference even between 3600C16 to 3800C14.

xixas
Posts: 40
Joined: Sat, 1. Jan 22, 22:47

Re: Happy 2022! Now, about those save times...

Post by xixas » Thu, 6. Jan 22, 22:13

Panos wrote:
Thu, 6. Jan 22, 21:51
External SSD cannot be compared with PCIe 4.0 internal NVME drive. The former has 1000MB/s at USB 3.2 connection the other 5000MB/s
Also your laptop ram speed is slower than the desktop one, so is the latency. And RAM speed matters on X4. There is a difference even between 3600C16 to 3800C14.
Agreed.
The intended point was that disk I/O shouldn't have any real play here (we're talking ~90 MB).
And that if improvements have been made, they may not impact the majority of players.
i.e. most players aren't running a 5900X/5950X

User avatar
Ehli
Posts: 94
Joined: Tue, 10. Apr 18, 18:18
x4

Re: Happy 2022! Now, about those save times...

Post by Ehli » Thu, 6. Jan 22, 23:00

I did see the second code link, but it's not better and I did not want to post two reviews here. People in this thread expressed finding it difficult to judge your code: a latin mass. I happen to earn my living with that kind of latin, so the very least I can do is shed another light on it.

Since you more or less asked about your second code link: still the write cache trashing, still the memory barrier costing you many wasted CPU cycles, still the heap allocation and overall poor memory usage, but this time with a costly vtable and a virtual call.

However, all of that does not matter: it's not solving the issue. It can't even serve as an example, sorry. I tried explaining the consistency issue together with a link with more info. I replied to you containing a technical answer, together with a link to a post (by me) which explains the issue and challenge - technically. It also explains what IS needed, architectually. Maybe you don't like the answer, but it is one: saying I didn't is just poor form.

I'd like to end this by stressing again that Ego already explained (too much and too often even) they seriously tried to make this better, spending quite some man-hours. They even improved it a bit recently. And you are a "game developer" - that's what you insinuated at least. Come on man, be nice: you should know better. Developers doing this for their job know you can't judge a book by its cover.. That's just insulting. Call it "feign indignation on behalf of EgoSoft" if you want - I think it's just bad manners. Especially the bitter last 3 paragaphs you just wrote.. :roll:

iznogood
Posts: 11
Joined: Mon, 17. Dec 18, 14:41

Re: Happy 2022! Now, about those save times...

Post by iznogood » Thu, 6. Jan 22, 23:28

xixas wrote:
Wed, 5. Jan 22, 19:05
shovelmonkey wrote:
Wed, 5. Jan 22, 04:55
Most good debates benefit from a devil's advocate. Imperial Good's replies seem to be met with good natured responses from the OP. In fact, from the untrained eye it would seem to be quite the friendly battle. Something lacking these days. Probably why I'm enjoying it.
Hah, and here I thought I was the one playing Devil's Advocate by starting the thread :)
Anyway -- debate yes, battle no. We're on the same side here. We both want to see what's best for the game.
Falcrack wrote:
Wed, 5. Jan 22, 01:33
xixas wrote:
Tue, 4. Jan 22, 22:53
... Imperial Good's doing their best to shoot holes in said proposal :)
Imperial Good does his best to shoot holes in every proposal, no matter how sensible it may be, it's a recurring theme I've noticed, although he seems to prefer shooting holes in proposals that come from me!
This was, indeed, intended as a good-natured ribbing.
Moderators are the team's gatekeepers on the forum. It's their purview to catch and reign in the ridiculous before requests get out of hand or threads go off the rails.
If the conversation requires double Devil's Advocate, so be it :)
iznogood wrote:
Wed, 5. Jan 22, 00:25
I agree creating a world snapshot, and serializing it to xml, while the game is running might be extremely hard BUT:
Currently the world is paused while this happens, and that might be acceptable if the game at least made proper use of the available cores.
So... I start with the big ask, and then you come in with the soft sell?
Suppose I could be on board with that strategy, lol.
Please pardon me if I don't give up just yet, though.
Being a developer myself, I have a pretty good feel for when something is about to get really hard, and we "all" know creating a snapshot of a vast number of objects and serializing them, without making the game stutter to uselessness, is going to be really hard (or really slow).

However would it really be a problem, if the save pause took 3-5 seconds?
While i obviously haven't seen their code, I have certainly made similar improvements in my own daily work. It usually doesn't take more than a couple of days.

You can of course ask for the moon, but when it's pitch black outside, a flash light can be really handy too... and it's so much more obtainable.

xixas
Posts: 40
Joined: Sat, 1. Jan 22, 22:47

Re: Happy 2022! Now, about those save times...

Post by xixas » Fri, 7. Jan 22, 02:35

iznogood wrote:
Thu, 6. Jan 22, 23:28
xixas wrote:
Wed, 5. Jan 22, 19:05
So... I start with the big ask, and then you come in with the soft sell?
Suppose I could be on board with that strategy, lol.
Please pardon me if I don't give up just yet, though.
Being a developer myself, I have a pretty good feel for when something is about to get really hard, and we "all" know creating a snapshot of a vast number of objects and serializing them, without making the game stutter to uselessness, is going to be really hard (or really slow).

However would it really be a problem, if the save pause took 3-5 seconds?
While i obviously haven't seen their code, I have certainly made similar improvements in my own daily work. It usually doesn't take more than a couple of days.

You can of course ask for the moon, but when it's pitch black outside, a flash light can be really handy too... and it's so much more obtainable.
I intended that as a genuine compliment. My apologies if it didn't read that way.
Sometimes the best way to get anything done is is to look at the bigger picture, see the "big ask", and re-frame the sensibility of smaller-scale improvements.

I agree with you whole-heartedly. A 3-5 second across-the-board save window would be fantastic.
That'd bring it on par with X3's save-at-dock.
Ehli wrote:
Thu, 6. Jan 22, 23:00
I did see the second code link, but it's not better and I did not want to post two reviews here. People in this thread expressed finding it difficult to judge your code: a latin mass. I happen to earn my living with that kind of latin, so the very least I can do is shed another light on it.
Since you more or less asked about your second code link: still the write cache trashing, still the memory barrier costing you many wasted CPU cycles, still the heap allocation and overall poor memory usage, but this time with a costly vtable and a virtual call.
Didn't ask. Your critiques just all referred to the initial sample, ignoring subsequent resolutions.

Still, I think you're entirely disregarding the snippet's purpose... on purpose.

The only point intended to be illustrated was that snapshots can be performed at any level you like, even on a per-value basis, by abstracting them behind redirected pointers.
Sure, I could have made it more convoluted by allocating a larger working surface instead of hammering new/delete, but I think the generics alone are enough to confuse casual readers and -the point- was to get the ball rolling with something people -could discuss-.

Seems that attempt was successful -- even if you are trying so very hard to derail said discussion -- so mission accomplished.
On both fronts I suppose.... so... kudos (?)

Down the rabbit hole...

The only thing noted as particularly vague was the the (canPerformSave) parm getting set with (i+1 == threadCount), relegating it to the last thread.
That (temporarily) made it less-than-clear that the intent was to multi-thread the snapshot, not the serialization.
The miscommunication was resolved.

There's a note about template-type-grouped static variable registration in the first sample's documentation to avoid the vtable overhead... but again, not exactly novice friendly.
If you want to skip that all together and store everything in a (void**) and static_cast it all back, more power to you. I'm sure that example will be tons of fun to read and maintain for a general audience.

--Regarding heap allocation and write cache trashing--
We're going to be working on the heap one way or another -- unless you're proposing trying to snapshot an unknown quantity of data on the stack (I presume not) -- so we either pre-allocate an estimated scratch space and expand as necessary (outside of the sample scope, because it wasn't the point) ...or the sample remains simple and easy to follow.
Can't say I regret opting for the latter.
Ehli wrote:
Thu, 6. Jan 22, 23:00
However, all of that does not matter: it's not solving the issue. It can't even serve as an example, sorry. I tried explaining the consistency issue together with a link with more info. I replied to you containing a technical answer, together with a link to a post (by me) which explains the issue and challenge - technically. It also explains what IS needed, architectually. Maybe you don't like the answer, but it is one: saying I didn't is just poor form.
Indeed, said post (by you):
  • begins with a bit of self aggrandizing
  • follows up by rehashing the traversal/serialization issue
  • mentions that the only way to fix it is with a snapshot... i.e. --the very thing we're discussing here--
  • makes your own assumptions about the code base and what's needed
  • asks the reader to look up MVCC on Wikipedia
  • says none of it's worth the trouble
  • ...and then you just trail off to talk a bit more about yourself -- apparently a popular theme in your neck of the ivory tower
That's not an answer. That's an apologist's self-flagellating cop out.
All you established is that -the discussion we're having here- is the one that needs to be had with a few technically minded people who believe it is worth the trouble.

The entire exercise is to brainstorm ways around a generic problem in a code base we can't see in hopes of sparking something useful.
...not to bug (or insult) the developers with monthly "it doesn't work the way I want it to" nags, but instead to attempt to generate a coherent list of potential strategies and/or acceptable alternatives.

I find the best way to do that is by spending a few minutes writing small examples that compile and can be discussed on their merits (something with which you're perhaps unfamiliar).
Fail-fast experiments are part of the process of elimination... one we can do here... without wasting developer time.

In any case, if you don't want to join in... don't. No offense taken.

P.S. -- I know. I know. Don't feed the trolls. As much is paraphrased in the forum rules. Mea culpa. Won't happen again :)
Last edited by xixas on Fri, 7. Jan 22, 03:26, edited 1 time in total.

Skeeter
Posts: 3665
Joined: Thu, 9. Jan 03, 19:47
x3

Re: Happy 2022! Now, about those save times...

Post by Skeeter » Fri, 7. Jan 22, 02:44

Maybe CBJ can pop in and explain the issues from their end then that way coders can brainstorm around what cbj says is the fundamental issues in the code.

Btw i love code talk even tho im not versed in it other than a bit of coding with script in a mission for a game many years ago but i find it intriguing.
[ external image ]
7600x cpu 5.4ghz 32gb DDR5 5600mhz 6700XT 32" 1440p mon

iznogood
Posts: 11
Joined: Mon, 17. Dec 18, 14:41

Re: Happy 2022! Now, about those save times...

Post by iznogood » Fri, 7. Jan 22, 03:10

xixas wrote:
Fri, 7. Jan 22, 02:35
iznogood wrote:
Thu, 6. Jan 22, 23:28
xixas wrote:
Wed, 5. Jan 22, 19:05
So... I start with the big ask, and then you come in with the soft sell?
Suppose I could be on board with that strategy, lol.
Please pardon me if I don't give up just yet, though.
Being a developer myself, I have a pretty good feel for when something is about to get really hard, and we "all" know creating a snapshot of a vast number of objects and serializing them, without making the game stutter to uselessness, is going to be really hard (or really slow).

However would it really be a problem, if the save pause took 3-5 seconds?
While i obviously haven't seen their code, I have certainly made similar improvements in my own daily work. It usually doesn't take more than a couple of days.

You can of course ask for the moon, but when it's pitch black outside, a flash light can be really handy too... and it's so much more obtainable.
I intended that as a genuine compliment. My apologies if it didn't read that way.
Sometimes the best way to get anything done is is to look at the bigger picture, see the "big ask", and re-frame the sensibility of smaller-scale improvements.

I agree with you whole-heartedly. A 3-5 second across-the-board save window would be fantastic.
That'd bring it on par with X3's save-at-dock.
No insult was understood nor implied be me either. I truly think that an overhaul to their saving mechanism would be a much needed boon to the game.

It's more that when you ask for something complex and costly, you typically get nothing, in particular when it's from a company of a limited size.
If however you ask for something almost as good with a limited cost, that's a much easier sell.

Panos
Posts: 848
Joined: Sat, 25. Oct 08, 00:48
x4

Re: Happy 2022! Now, about those save times...

Post by Panos » Fri, 7. Jan 22, 08:40

Guys all of you above asking for shorter saves you need to realize that it will come down to Egosoft removing objects from the game which will destroy the realistic simulator. We need more objects not less.

In my 25y career have done a lot of serialization to pack objects into XML and send it. Especially one of the businesses worked with, is responsible for 50% of the trade at the North Sea and dozen ports. At any moment in time hundreds of ships, tens of thousands of trucks, car parts , food, cars and cargo are moving around and each object needs to be serialized, transformed and send to a dozen destinations for it to be picked up by several authorities per country and various systems at real time.

At any moment there is a view where each of the millions of cargo objects are including all their properties, logs and photographs from entry-exit.


Egosoft has done a damn fine job to keep track of the objects and improve perf with 4.20 and make the game run on 7 year old quad cores with ancient storage media.

xixas
Posts: 40
Joined: Sat, 1. Jan 22, 22:47

Re: Happy 2022! Now, about those save times...

Post by xixas » Sat, 8. Jan 22, 01:00

Panos wrote:
Fri, 7. Jan 22, 08:40
Guys all of you above asking for shorter saves you need to realize that it will come down to Egosoft removing objects from the game which will destroy the realistic simulator. We need more objects not less.
Well, I don't see that happening :)

I have to say, I noticed uncompressed save files dropped about 6 million lines (down from ~20 to ~14 million) in my current save set between 4.10 and 4.20, which is a marked improvement.
Not seeing much change in terms of save time, though, so I wonder if there was any sort of performance penalty taken to attain that reduction.
Haven't had any time to analyze what was cut/regrouped/optimized yet.
Panos wrote:
Fri, 7. Jan 22, 08:40
Egosoft has done a damn fine job to keep track of the objects and improve perf with 4.20 and make the game run on 7 year old quad cores with ancient storage media.
On the keeping track of objects bit, indeed they have, no complaints there.
I also don't have any specific critique on either the previous or current save performance -- I'd just still like to see further improvement :)

While there may be minimal gains to be made, as mentioned in other threads, in serializing to JSON or even a binary format, XML is still a game industry standard, particularly for Design teams, and I'm not sure there's much value in choosing another format aside from the actual compression/write times. Though perhaps it'd be worth pondering if there's a binary format that could be easily converted to/from XML for manual debugging purposes.

I'd also be curious to know what XML lib(s) is/are used for serialization.
  • These days a lot of smaller games (particularly mobile) are using the tinyxml2 header implementation -- but it's way too slow to consider for a job this size
  • rapidxml and pugixml are quite fast, but they require reading the entire file into memory -- I suppose up to around 1GB isn't a terrible bump if assets are unloaded first for reads, but by default they can take 2-3x file size once meta-data's included -- though the XPath support is nice if entity lookups are for whatever reason necessary at the XML level
  • libxml2 is fairly common practice on larger datasets, being a SAX parser (can stream directly from file) -- so either that or Xerces (a little heavy-handed for this job) would be my first guess, particularly for reading
  • Maybe they went old-school and used Expat for the reads :)
I'm just kind of thinking out loud here, wondering if there are any small gains to be made purely around XML translation bottlenecks.

Is asmxml still a thing? I haven't looked into it in ages. Think it was only x86, but it was fast.

Probably running down the wrong path here... usually thinking in terms of parse performance, but XML generation would be more on topic for this thread.

I'd still rather talk snapshots, but iznogood is right that smaller wins with less effort are more likely, and certainly worth discussing.

Falcrack
Posts: 4927
Joined: Wed, 29. Jul 09, 00:46
x4

Re: Happy 2022! Now, about those save times...

Post by Falcrack » Sat, 8. Jan 22, 06:33

Skeeter wrote:
Fri, 7. Jan 22, 02:44
Maybe CBJ can pop in and explain the issues from their end then that way coders can brainstorm around what cbj says is the fundamental issues in the code.

Btw i love code talk even tho im not versed in it other than a bit of coding with script in a mission for a game many years ago but i find it intriguing.
I predict CBJ or any other Egosoft dev would not touch this thread with a 10 foot pole, though I am pretty sure they are aware of it.

vmo
Posts: 8
Joined: Sat, 8. Jan 22, 10:51

Re: Happy 2022! Now, about those save times...

Post by vmo » Sat, 8. Jan 22, 11:35

Hi! This thread (and many like it) are full of well intentioned people with a great amount of passion for X4. Not only that, but many folks even have software engineering experience they're eager to apply to our shared pain point of long save times. Many of the Egosoft employees have likewise spent many patient years trying to explain why save times are not likely to be reduced dramatically. Sometimes they even go into significant technical depth. (Thanks, Imperial Good!)

Feel free to theorize and puzzle about the problem, because as engineers, isn't that what we love to do most? But I would urge us all to be cautious about thinking that we may have a solution where Egosoft hasn't been able to find one.

I've led the development of software that most of the people on this forum probably use on a regular basis. Someone you know almost certainly used something I helped make today. And one of the biggest things I've learned is that software is *always* more complex than it looks from the outside. WAY more complex.

Even an engineer on a neighboring team could drastically underestimate the effort required. A manager of those engineers is, in comparison, nearly clueless. And what information do we have to go on about X4? Only the experience of playing the game. As much as we all think we know software engineering, we do NOT know the engineering behind X4. Unless you have actually worked on the save game system of X4, in which case you're probably the one arguing why it can't be sped up significantly. ;)

Thanks for letting me interject this little thought here, and thanks for keeping the conversation civil and respectful. Just want to afford the Egosoft team their due respect as well and note that with almost 100% certainty, they have already done a way better job of this than we could by pontificating in a forum with almost zero knowledge of the system design of X4. :)

iznogood
Posts: 11
Joined: Mon, 17. Dec 18, 14:41

Re: Happy 2022! Now, about those save times...

Post by iznogood » Sat, 8. Jan 22, 16:50

vmo wrote:
Sat, 8. Jan 22, 11:35
Hi! This thread (and many like it) are full of well intentioned people with a great amount of passion for X4. Not only that, but many folks even have software engineering experience they're eager to apply to our shared pain point of long save times. Many of the Egosoft employees have likewise spent many patient years trying to explain why save times are not likely to be reduced dramatically. Sometimes they even go into significant technical depth. (Thanks, Imperial Good!)

Feel free to theorize and puzzle about the problem, because as engineers, isn't that what we love to do most? But I would urge us all to be cautious about thinking that we may have a solution where Egosoft hasn't been able to find one.

I've led the development of software that most of the people on this forum probably use on a regular basis. Someone you know almost certainly used something I helped make today. And one of the biggest things I've learned is that software is *always* more complex than it looks from the outside. WAY more complex.

Even an engineer on a neighboring team could drastically underestimate the effort required. A manager of those engineers is, in comparison, nearly clueless. And what information do we have to go on about X4? Only the experience of playing the game. As much as we all think we know software engineering, we do NOT know the engineering behind X4. Unless you have actually worked on the save game system of X4, in which case you're probably the one arguing why it can't be sped up significantly. ;)

Thanks for letting me interject this little thought here, and thanks for keeping the conversation civil and respectful. Just want to afford the Egosoft team their due respect as well and note that with almost 100% certainty, they have already done a way better job of this than we could by pontificating in a forum with almost zero knowledge of the system design of X4. :)
That is not necessarily true.

Most IT problems can be solved, given enough resources and time, it is all about prioritization and cost.

Software is sold by it's feature list, and items that add to that list, tends to get prioritized.
Long save pauses does not fit into the feature list, which is why its prioritization must be raised by other means, that is what we are doing here.
We are making noise so egosoft will know that this is important to us customers.

Quite often i have looked at a piece of software and thought "how can the customers not be furious about this", to which my boss has answered "they are not complaining about it, so we are not spending time on fixing it".

vmo
Posts: 8
Joined: Sat, 8. Jan 22, 10:51

Re: Happy 2022! Now, about those save times...

Post by vmo » Sat, 8. Jan 22, 18:23

I don't disagree with making noise. Just with the idea that we can come up with a technical solution from the outside.

You're right. Solutions are about tradeoffs. I've been in the role of making these decisions along technical, customer, and business dimensions. Sometimes it's just one feature vs another, but sometimes technical feasibility does actually become a monumental factor, to the point that you're not trading one feature against another - you're trading an entire release or even a near rewrite against the one feature. From the outside, we're not in the position to make these technical judgements.
Last edited by vmo on Sat, 8. Jan 22, 18:49, edited 1 time in total.

iznogood
Posts: 11
Joined: Mon, 17. Dec 18, 14:41

Re: Happy 2022! Now, about those save times...

Post by iznogood » Sat, 8. Jan 22, 18:44

vmo wrote:
Sat, 8. Jan 22, 18:23
I don't disagree with making noise. Just with the idea that we can come up with a technical solution from the outside.
Heh, let's call that qualified noise :)

I think you get qualified noise when the ordinary noise gets shutdown with "no that's impossible, you have no idea of the cost it would incur".
Fact is, nothing much is truly impossible, and if a bit of noise here can allocate an egosoft dev for a week or two, who knows what might happen.

Personally what i object to is waiting, while my computer is barely doing anything. If i am to look at a pause screen, i expect my cpu, disk or some other part of the system, to be maxed out, to keep that pause to a minimum.
Last edited by iznogood on Sat, 8. Jan 22, 18:53, edited 1 time in total.

vmo
Posts: 8
Joined: Sat, 8. Jan 22, 10:51

Re: Happy 2022! Now, about those save times...

Post by vmo » Sat, 8. Jan 22, 18:50

See that's what I mean. I think there's been enough noise already that if all it took was a week or two of one engineer, they would have done it years ago. :)

vmo
Posts: 8
Joined: Sat, 8. Jan 22, 10:51

Re: Happy 2022! Now, about those save times...

Post by vmo » Sat, 8. Jan 22, 18:54

Anyway. I'm not here to tell anyone what they should or should not ask Egosoft for. Products absolutely get better with feedback, including the ones I've led.

Just pointing out that the technical "advice" we have from the outside almost certainly won't solve the actual problem because the problem is almost certainly way harder than we can imagine without understanding the system design of the software.

iznogood
Posts: 11
Joined: Mon, 17. Dec 18, 14:41

Re: Happy 2022! Now, about those save times...

Post by iznogood » Sat, 8. Jan 22, 19:23

vmo wrote:
Sat, 8. Jan 22, 18:54
Anyway. I'm not here to tell anyone what they should or should not ask Egosoft for. Products absolutely get better with feedback, including the ones I've led.

Just pointing out that the technical "advice" we have from the outside almost certainly won't solve the actual problem because the problem is almost certainly way harder than we can imagine without understanding the system design of the software.
It could if they made the save system pluggable. How cool would that be, if they gave us a config option and an interface, so we could create our own.

Rei Ayanami
Posts: 3333
Joined: Wed, 6. Nov 02, 20:31
x4

Re: Happy 2022! Now, about those save times...

Post by Rei Ayanami » Sun, 9. Jan 22, 19:54

iznogood wrote:
Sat, 8. Jan 22, 19:23
vmo wrote:
Sat, 8. Jan 22, 18:54
Anyway. I'm not here to tell anyone what they should or should not ask Egosoft for. Products absolutely get better with feedback, including the ones I've led.

Just pointing out that the technical "advice" we have from the outside almost certainly won't solve the actual problem because the problem is almost certainly way harder than we can imagine without understanding the system design of the software.
It could if they made the save system pluggable. How cool would that be, if they gave us a config option and an interface, so we could create our own.
True, but at the same time it would greatly compromise the current high savegame compatibility between game versions, especially when the savegame format changes in subtle ways and you didn't update your custom savegame-plugin yet.

Locked

Return to “X4: Foundations”