Eh, you seem to have misread me in a couple of places -
The issue of trust, was trust that you wouldn't shift definitions on me, or backtrack, etc.
I see. Well, there's no backtracking being done by me. I take pride in consistency. So if there is anything that you feel I've backtracked on, please feel free to point it out; because you can't just throw that out there and not elaborate (which is precisely why we're still having this discussion btw). For your quick reference, the entire thread of our discussion is
preserved here for posterity; complete with links.
1a, you still have wrong, is not that some systems weren't converted, is that some parts of those systems don't need to run slow. So on a line by line basis, it's been considered how much precision is needed.
Oh c'mon! Seriously? How can I be "wrong"? I indicated that there is no way in hell that StarEngine (built on custom CE3.x) had been converted to handle 64-Bit size scenes, and the complimentary 64-Bit positioning within them. Sean Tracy went on the record and indicated that only some modules were in fact converted. So, what exactly is it that I'm
wrong about? So yeah, it
is that some systems (e.g. AI, Physics etc)
weren't converted (because they didn't need to be).
1b, vi, The tube isn't there to hide anything, it's just for style.
Yes, I gathered that. But even if it's a style thing, it's still
hiding something: the transition through space. My guess is that you guys compress the transit so much that, even with motion blur, it would probably look rubbish. So it makes sense to hide it. It's even more suspicious that it's being done in intra-system travel, where it makes less sense, given the shorter travel distances. As seen in my games and others, any such long distance transit is done with such "styling", but still sped up so you see world space (and all the POIs) race past. If you haven't yet, watch the UCCE video again and you'll see what I mean.
2b, the concept of internal spaces is just a matter of visibility culling boxes, which are just another entity type. The ability to host objects within objects is also generic.
That's the point I was making; and the reason for that question in the first place. So basically, in keeping with "generic" convention; you guys have a box (Port Olisar) inside a box (Stanton) - just as I stated/asked.
Also, you're wrong about physics grids- most solvers start to come apart when object masses are too different, so trying to naively handle a person riding in an aircraft carrier will not only be inefficient, it'll explode.
Actually, no, I'm not wrong. Solvers (all types) come apart for a variety of reasons - most of those are quite evident in the current SC alpha. And having different "physics grids" (e.g. box in a box) embedded - especially depending on the object type, distance from world origin etc - is one of those bugs that you simply can't fix, but just have to live with. This is evidenced by the currently janky nature of multi-crew ships, in which, for a year now, those sort of issues still
aren't resolved. But backers are still theory-crafting about 100 player crew ships. I can't wait to see how they get to attach/connect one ship to another (e.g. the Prowler). But seeing as I don't believe it's ever going to get that far, it's pointless speculating.
The only time you will change boxes is when you change star systems (once they are in-game), which will use some kind of stylised hyperspace jump to mask the loading (like the other game...)
This is my understanding, yes.
So zoned (stitched) then.
If you make up a term and immediately explain what you're trying to represent with it, you've got a good chance of being understood. Especially by programmers, since ~90% of programming (if you don't count bug hunts) consists of making up terms and then rigorously defining them.
Nice. You're doing it again. Thus far, in our discourse, you have displayed
complete ignorance of some widely used technical terminology - which I didn't make up; and which one trip to Google confirms.
I have tried to be polite and respectful in our banter, out of respect for our profession. But yet, you keep making these jabs for no apparent reason other than to display your own arrogance and insecurities. God forbid, the old guy dumping on your project knows more - or has more experience - than you do. We can't have that. Because after all, we have to keep up appearances. But that's your lot. The difference between you and me is that for over 30 years, I've called my own shots. So very little is of any consequence to my well-being; and I don't have to put up airs in order to impress anyone. I'm just me - faults and all. Meanwhile, at this point in your short career, you have the dubious distinction of being attached to and associated with what is turning out be the largest videogame project collapse in gaming history. You should be proud.
You're young; I get it; but arrogance diminishes wisdom; while killing curiosity and passion.
I'm done.