Simerge spacegame

Does this mean all existing entities have to be known to the game instance all over the time? Or in other words all segments have to be loaded to memory always? Otherwise there must be a mechanism which describes where an object can be loaded which is currently not in memory.

Hmm. Never thought having said this. Where does it stands? But to answer your question. In this version of Geo files all segments should be loaded. Yes. This version is suitable to describe smaller ships.

What you meant is probably out-of-core paging, right?
This technology is also existing. It allows to reduce the amount of loaded assets to the required ones. There are something like Zones (class TALZone). Each Zone is containing multiple segments and can be switched to loaded state. Then all segments are automatically swapped into the memory and integrated into the world (e.g. by opening new portals or other mechanisms). But in this version multiple Zones shouldn't be supported.

I see this more from the practical site. When always all existing segments are need to be located in memory, this will increase memory consumption directly with the size of the game world. So for example, when you are entering a station it makes no sense to me to have segments in memory that are containing to a station in another system, which are not directly accessible by any portal. Or do I misunderstand something?

You are right, I agree! And this is what happening now. And in the future it will be even better. Not all segments would be loaded also when a station is existing in the same system. There is a little complicated mechanism there, also because not everything is clear for me now. As I said before there are zones containing segments. These are world parts whose "load state" can be switched on or off, depending what zone is required to be loaded (eg. in case of visibility). When triggering a zone as "loaded" it will page in its contents into the memory on the fly, calling also the parser you write. The set of all Zones X visible from any Zone A are called the "Horizont of A". In other words, if the camera is residing at the Zone A, then the engine should make at least sure the whole horizont is loaded into the memory.

The parser you write will be called from the zone loading routines. In the future versions we will have Zones in the Geo Files, too. With predefined horizonts and such things. But these Geo Files are better for large capital ships and stations.

Ok, I can live with that. I only wanna ensure such possible problems are not surprisingly occur in a later design state.

I have updated the definition in the origin topic above

Some more questions:
In your example in portals or doors, there is a position and angle of target (binded) defined, couldn't this be taken directly from the target?

Courrently name of entities is optional, I think this should be mandatory to handle any interaction (example: destroy static objects and save their state).

Maybe a string name is not the best choice for identification of objects related to performance, an integer would be better (there could be 2^32 objects per segment and 2^32 segments if using an 32bit int as ID, defining this for example as "0:1" instead of "seg0:portal1").

How do you imaging a "group" entity?

I notice that I often think about technical usage of this data. Ple interrupt me, when this leads to far away required for this task!

At which line in which source file?


Agreed


Names should be used to make it easier to write the Geo files. Usually there wouldn't be any performance loss if you convert the names into numbers or array indices internally.


A group entity is nothing more than an entity containing sub entities. Because a group entity is a segment itself, the sub entities can be placed into the local space of the parent entity. If you ever worked with Ogre you could compare them with scene nodes.


No problem. The more thoughts and doubts we have the better the game will be. And if a discussion leads away from the current topic, you can make up a new one.

No, not in source. In the xml example above you write:
<bind-direct seg="seg1" pos="x:y:z" orient_angles="r:p:y" />

Thinking deeper, I see you describe a point where no portal is in "seg1", right? Then forget this question, first I was thinking about connecting this portal to another portal using this construction.

Following question: It's possible to:
- link portals to a defined point (the portal is entry only, point is exit only)
- link portals to other portals (both portals are entry and exit)
Consider both variants?

Right.



Portals are currently bidirectional. How do yo mean it with only entry and only exit?
With <bind-direct> tag in my first example the regarded portal could be bound to an arbitrary position in another segment. With an alternativ tag <bind-endian> you could bind a portal to an endian. which would be an answer part of a portal (or nothing more than the exported attribute pair "pos and orient" from <bind-direct>). Portal to portal binding should not be possible, because of different contradictions. One of them is that you could assign any of them a different shape. Endians are a replacement for this situation.

I mean, if you have a portal-portal pair, you can enter one and leave it on the oposite and reverse. If you have a portal-point pair, you can enter the portal to leave at the point, but not reverse. For this pair the portal is entry only. Of course you could bind the portal to another portal too.
But with the things you wrote later in mind, only portal-point is possible, so each portal is only an entry, each bind point is the exit.

It was a misunderstanding The <bind-direct> tag says how the whole portal shape is lying inside the target segment. There you don't have a single point.



Portal-point-pair seems for me not possible, because an object or camera can cross the portal shape at different positions resulting in a displacement at the other endian. So it doesn't spawn exactly on the predefined point at the other segment. But a displacement you get a typical portal-to-portal situation again.