That's my job.On the internet everyone's a developer.![]()
That's my job.
Just a sec, I thought iCache was just a layer to speed up querying and updating of whatever the underlying storage is. There is so much communication and yet everything is so confusing. A single presentation of the underlying topology would help. Like a typical bunch of slides from an IT conference. What are the storage mechanisms used overall? DynamoDB? Redis? Custom something? What is stored where? What are the paths for the data? What is the transport for the messages? Which requests are queued and which are synchronous? Etc.Icache will maintain sessions between instances, objects positions, etc but doesn't manage instances. It's the server meshing work to manage instances.
Icache alone will not permit to add Pyro.
This I understand, hence I mentioned jump points. If SQ42 is not vapourware at this moment, we have at least two systems - Stanton and Odin. I hope.And Icache alone can't add more entities in actual Stanton, Stanton is at max capacity. It needs SM to divide the actual instance in multiple smaller ones, afterthat, CIG should be able to add more entities in Stanton.
I don't remember exactly when they said they switched to 64 bits position, but it was quite late into the project - a few years (actually not late in the overall picture - still way too late). It was one of the first major facepalm moments for me (space big! who would've thought?), and when I started to realise that they will probably not be able to make good on their word for the project I backed. (The other early facepalm was the claim that they would not use procgen for their planets but would handcraft all of them, only to return to procgen later ... planets big! who would've thought?)You are correct. For some patches, icache will have no visible effects. CIG can do nothing and lie about it if they want.
It's like when they said they switched to 64bits position. Perhaps it's a lie and the alpha still use 32bits positions.
Given the nature of everyone walking around in the back of the ship, doing their own thing, Loadscreens will not be possible.X tech will solve all problems. Just wait. Be prepared to eat your words, non-believers.
Meanwhile Turbulent is adding regular CryEngine levels withloading screensjump points that are totally not loading screens.
You said CIG lied about 64bits while quoting a phrase saying SC use 64bits![]()
the alpha still use 32bits positions.
INDUSTRIALIZATION OF THE CREATION OF WORLDS
There are many signs that CIG is designing its tools with industrialization in mind.
CIG often talk about simplifying workflow for the creative teams and bypassing dev for a lot of tasks. Their tools, when they show them, are pretty impressives from the usability aspect. For instance, the Building Block tech integrate HTML+CSS for the rendering part and they have stated that you can create missions without specific knowledge with it. And finally a lot of powerful proc generator are developped for the base elements of planets, moons, caves, stations and outposts.
But the main sign is that Turbulent recruit atm a whole team dedicated only to create systems. CIG wants to outsource (at least for a part) the creation of systems and it seems their tools are ready to start this phase. So to the question "how long will it take CIG to finish the 2nd system or the 3rd, etc ?" I will say it can be pretty 'fast' when all prototypes and assets will be finished by CIG. The number of people in the Turbulent and CIG teams assigned to the system creation will purely define the rate of delivery. How many people will be assigned ? 10, 50, 100 people ? Except SOL, every other systems will be much easier to do than Stanton. Pyro has 10 stellar objects. They made the 3 Microtech's moons in 3 months by two people. A quick and not very useful little calculation can give us a 0.5 stellar object/person/month. So with 50 persons, you can achieve 25 stellar objects/month = 2.5 systems/month like Pyro = 30 systems/year. But this calculations does not take into account the specificities of some systems like the Elysium one or the creation of new assets from time to time. The rate will be much slower because a lot of elements will be unique and hand made.
iCache is here. I have 20 bottles of water in a corner of the freelancer's hold since 3 weeks. I was not possible to keep them before.
They need icache working ingame to add server meshing and CIG is just at the beginning of adding it to the alpha (I was wrongly thinking last year that CIG had started to add it).
The alpha still lacks 2 main techs (not 'random' ones), icache and server meshing.
It's perhaps a more important tech than server meshing.
... planets big! who would've thought?)
You can have the player move around on their own ship while in an interactive loading screen. Games do it all the time. They won't see or interact with anyone else while in that "zone". It's still a loading screen, just an interactive one.Given the nature of everyone walking around in the back of the ship, doing their own thing
Given the nature of everyone walking around in the back of the ship, doing their own thing, Loadscreens will not be possible.
Its why you can't have that in EDO while moving from loadscreen to loadscreen.
Honestly there is a point and a reason to it.
You can have the player move around on their own ship while in an interactive loading screen. Games do it all the time. They won't see or interact with anyone else while in that "zone". It's still a loading screen, just an interactive one.
But if there’s a server handover, they won’t be walking around, there’ll be a pause during the handshake. (Or it will be designed around, via enforced seating for Jump points or whatever).
ED’s current system has hitching between space & planetary surface for this reason. The instancing transition. (Technically you can fly directly from space to surface 'seamlessly')
Probably best to wait and see what CIG actually achieve when finally using more than one server per session![]()
You could do it if the game locks you out of interaction for the duration of the loadscreen, but then it obviously a loadscreen, not "Seemless"
64bits was not needed before 2015. It was after the change of scope.I don't remember exactly when they said they switched to 64 bits position, but it was quite late into the project - a few years (actually not late in the overall picture - still way too late). It was one of the first major facepalm moments for me (space big! who would've thought?),
You're interacting with a physicalized object, with its own physics grid, the ship with all its systems and other players.
They won't see or interact with anyone else while in that "zone".
It isn't seemless in EDO, its meant to be, but it isn't, its in a poor state and i can see the loadscreen happening, and i'm still only sitting fixed in place.Yep
Don’t assume that just because you can currently walk around now during asset load you’ll be able to do so during server handovers. Which is what you were doing. (CIG talk a lot of talk about a seamless game world transitions. But walking the walk is a different matter...)
PS it’s definitely 'seamless'![]()