Hint about next patch from Egosoft? CBJ just posted this...

[Ericius11]

The fact of the matter is most changelogs won't be that long. Especially right now, where most of their days are probably spend testing and re-testing features. Can you imagine how frustrated certain (nameless) forum goers may be if they looked and saw two weeks in a row of "Feature Testing?"

Honestly, I agree with you. I want to see the updates, and I'm okay with the idea that Egosoft may have accomplished nothing in a week. Because at the very least, they've spent a week finding ways to NOT improve the game. But I know a lot of people wouldn't react well to hearing that.

[Observe]

One thing to realize, is a week, or even a month isn't all that long when it comes to working on software. Hell, a whole week can go by sometimes with barely anything being accomplished in terms of final result. On the other hand, there are times when a lot gets done in one day! It's hard to predict. It's not a linear thing.

One thing we can be sure of (I think), is they are working very hard, and probably long hours, bringing improvements to us. We just have to be patient. There's not much else we can do (aside from complaining).

As far as the discussion re. continuously reading XML files, this as has already been pointed out, is not correct. XML data is read, processed, and sometimes (not always) stored in memory for future use.

[VincentTH]

I have not looked into those posts, nor have I profiled the application myself.

I can tell you however that both internal AND external profilers can be extremely misleading because they get in the way of execution of the threads they're profiling.

[Edit:] In fact I've seen this happen on XML loading processing more than anything else. Turned out that sans profiler the XML loading finished in less than a second and the actual problem was somewhere completely unrelated. [/Edit]

They are meaningless without diving into the code itself and toying with it until the truth unveils itself. Profilers are simply a clue, not the answer.

To say otherwise is to show your ignorance, as is saying CBJ doesn't know what's going on. I guarantee you as a senior developer myself that whatever profilers the gamers are running are a waste of time.

Agree. This is known as the Heisenberg effect. Any profiler always injects some modification that affects performance of the software you want to profile.

[graphicboy]

I think you meant Observer Effect. They're similar, but not the same thing. Either way - yes.

[gbjbaanb]

However, if the profiler shows long amount of time in the libxml library, then its nearly always because... its spending a lot of time there. If a profiler cannot get this right, its useless.

But, whilst I agree with CBJ that they read the XML files into memory data structures (of course they do, really, everyone does this), it doesn't mean that the worker threads aren't repeatedly reading the xml into the data strucctures (due to a bug - it checks, it noticed there's an xml file, it reads it... then it checks.. and sees an xml file and reads it... I have seen bugs where the check is supposed to only process when the file changes, but processes them regardless. this could be one of those occasions I guess)

Then there;'s the other concept that the libxml code is spending a lot of time there because its blocking, this would show up as spending a lot of time in the library, but would not show a large amount of CPU time being used. Whether this is by design or a bug is not for me to say.

[YorrickVander]

The games own debug log might give some clue that this idea of constantly reading XML is complete rubbish. When the game loads the xml, it also checks your extensions folder; this can be validated by any player using mods as your mods would break if the game continued to reload without checking that folder too. So far so good Any mods that modify the original xml via diff patch throw a debug log entry as unrecognised tags upon save game load or new game start; this is also good - we don't want this code to be actually run by the engine after patching. Which brings me to the nub of the evidence - these errors don't show again until another load/new start, and therefore pretty much disproves the idea that the xml is constantly reread in a manner that any player can verify with no need for profilers.

[khartsh]

The games own debug log might give some clue that this idea of constantly reading XML is complete rubbish. When the game loads the xml, it also checks your extensions folder; this can be validated by any player using mods as your mods would break if the game continued to reload without checking that folder too. So far so good Any mods that modify the original xml via diff patch throw a debug log entry as unrecognised tags upon save game load or new game start; this is also good - we don't want this code to be actually run by the engine after patching. Which brings me to the nub of the evidence - these errors don't show again until another load/new start, and therefore pretty much disproves the idea that the xml is constantly reread in a manner that any player can verify with no need for profilers.

Does the game not store objects in xml format? Wouldn't it then be plausible that anytime something is modified, destroyed or created the xml file in question would have to be read, processed, modified, reloaded into memory and validated? Smarter people than I seem to think so.

[YorrickVander]

I don't know how the objects are stored internally, I didn't write it. Nor did the guys making mistakes with profiling tools. Besides, if that was the case then again, mods in the diff patch format could not work.

[Green E.T]

News from Paris / France

A month without release ....

Of course, the game is more stable, and personnaly i do not have major issues with it.


BUT


If a lot of works was done in january and february, i think big walls was forgotten :

IA for Business - Stations made what they want, and not necessary what could be expected. Ex: I have one URV station without Plasma cells , and a cell station full of it : but none of them shell or buy and they are full of credits and vessels.
I have seens Scaldies in Devries comming from Omycron or Albion for business, but i can't asl my stations to make business in others univers ..


Ennemis : Since the beginning fighting is too easy , and now with shunk upgrades, one/two shoots = One ennemy ....
Theyre is clearly no fight game .


Vessels : It's not possible to buy small ships, or repair them. Gigorum could be very usefull for owned station


A way to capture or destroy station could give a significant own strategy

[graphicboy]

Does the game not store objects in xml format? Wouldn't it then be plausible that anytime something is modified, destroyed or created the xml file in question would have to be read, processed, modified, reloaded into memory and validated? Smarter people than I seem to think so.

If the game was written this way you'd know because you'd only be getting 1 FPS or less as the game got permanently bogged down in its own internal processing. No one in their right mind would constantly be hitting XML as you describe. That's not how software is written.

[khartsh]

Does the game not store objects in xml format? Wouldn't it then be plausible that anytime something is modified, destroyed or created the xml file in question would have to be read, processed, modified, reloaded into memory and validated? Smarter people than I seem to think so.

If the game was written this way you'd know because you'd only be getting 1 FPS or less as the game got permanently bogged down in its own internal processing. No one in their right mind would constantly be hitting XML as you describe. That's not how software is written.

Lag from menus and lag during entering and leaving sectors would point to exactly that problem. And you are right it isn't how GOOD software is made.

[graphicboy]

If your measurement is the menu, and sector changes, then yes, I can see that hitting XML. There usually isn't a reason to cache that kind of information since it's not actively being used.

That's not to say that (at least the menu) shouldn't be cached. Maybe it should. Undoubtedly there is simply something being done in the menu that's dumb that hasn't risen high enough on the priority list yet to get tackled.

Compare these issues/questions with the fact that station managers don't work, and trading in general is borked... yeah. We're probably going to have a slow menu for a while.

[Darrosquall]

any news?


..............
.......................

[Sturmhardt]

For me the main problem is station management. There is no point building station or even having them because we don't have any way of controlling them and managers AI is too stupid to do simple tasks. So fixing game and adding new things is all nice, but without fixing the main game features(like economy/trading or mining) there is no point to staring again(for me anyway). Economy and trading is why I like X games without that X games are pointless.....

This. Before the economy and the playability are not improved A LOT, I won't touch it again. Ego can make this right, but they have to commit.

[Trialbyfire]

I can't see myself playing again until they get rid of the highways and the stupid mission icons scattered all over station exteriors. Those two things completely break immersion for me. Yes, mods may eventually do that, but I'm only interested in mods if I'm already interested in vanilla first. Mods should not be for making the game playable. They should only be for improving an already good game. That's only my opinion of course.

[Earth Ultimatum IV.]

any news?


..............
.......................

[Nikola515]

Just like old times

We are waiting for info about patch just like we wore waiting for info about XR release date before

[Alan Phipps]

There is a patch currently in progress as previously said; the system *usually* is as follows:

New patch from devs -> Internal beta test -> Public beta test -> public release.

Of course before each transition stage there can be hotfixes, changes and tweaks. Hence no detailed information is released for general consumption until public release as the content is still 'fluid' until then.

[BigBANGtheory]

I don't doubt that Egosoft and DevNet are working very hard, personally it bothers me not if the next patch is tomorrow or 2 months from now. What does bother me is :
- the quality (does it work well, is it a proper solution)
- the content (did Egosoft listen or do their own thing again)
- the "not knowing" (was it communicated)

[Darrosquall]

There is a patch currently in progress as previously said; the system *usually* is as follows:

New patch from devs -> Internal beta test -> Public beta test -> public release.

Of course before each transition stage there can be hotfixes, changes and tweaks. Hence no detailed information is released for general consumption until public release as the content is still 'fluid' until then.

you are right, but they released a game in an "unfinished state", a lot of people don't give up, want to play, but after one hundred of hours, I want to play the 1.0 version.

This lack of communication is simply not fair. There are few people still interest in this product, well, Devs should care about.

Surely they can say more about a simple beta patch.