Simerge spacegame

Ah, now I think I understand:
You have a portal, this is connected to a shape at another segment. You wanna bind this portal directly to a shape (definied in the portal definition) or to a shape defined in the target segment.

For understanding: Is it possible that the shape of a portal is identical to a shape of an other portals target? I could imagine there will be curious effects like an endless jumping loop between both portals.

I have created a basic parser that can read the structure defined above - currently filled with lots of dummies as target. The next quesion is where to place the data read from file. I found a "SegmentFile.cpp" in code, where such things are done. I expect to place it there. Some more informations?

Portals aren't really that complicate. For a portal you have exactly one mesh. This mesh is existing in both segments with different translation. I forgot to tell you more about some hidden settings on portals. I thought in the examples used by ship and stations there is everything on them. I was wrong. The ships and stations don't use transformed portal shapes.

For a portal you have the class TSegmentPortal in ScObjects.h at Proto2 project
The members "TSegmentPortalLink links[2]" are the binding endians which are used to bind to both segments at any location. To raise confusion, there are a few functions missing to set transforming parameters at an endian, so you need to assign values directly to the three members:
TSegmentPortalLink::bUseLocation = enables transforms. If disabled, the vertex positions of the shape are regarded as relative to the segment space.
TSegmentPortalLink::myOrient = orientation of the shape in bound segment (valid only if TSegmentPortalLink::bUseLocation is true).
TSegmentPortalLink::myPos = position of the shape in bound segment (valid only if TSegmentPortalLink::bUseLocation is true).

Then you can bind an endian to a segment by using TSegmentPortalLink::linkTo( seg ) alternatively to the function TSegmentPortal::linkTo( segA, segB ) which simply calls the first function.



Didn't understood the question The same portal shape is occuring at both targets.


?? I thought the file was lost. It is not used in the source. There is a part of a parser equal to the one you write. Never tested and never compiled. The file can be ignored.

Ok, another try: When you have a portal and define with bind-direct the position where the shape is located at the target segment, would it be possible, that this point is the point where the opposite portal is located?


Yes, I have seen the functions in this file are not used anywhere. I found it when searching for usages of "TiXmlElement" to look if there are some basic xml routines present, which I could reuse. I was about to ask why creating a new parser when there is already something like this .

Because I thought, that I deleted the file But of course you can reuse everything from there you want.



Ahhh. Alright I think I got what you mean. My English ... Damn!
Well. Such constructions should be possible. And there will be problems. Also the one more harmless case where you place both endians of a portal in opposite resulting in an endless tunnel recursion. I'm sure the rendering routines are protected against your case, because there is maximal recursion depth parameter there (TSegmentScene::buildSegmentList the renderDepth parameter). For collision queries, I think there will be a crash due to stack overflow. We need an equal depth parameter for TSegment::subTestCollisionPortalized. Actually multiple rendering of the same segment with different transformation per frame is not supported, so your example won't be renderable. The portal will remain invisible.

a question relatet to the linkTo() function and xml structure: Wouldn't it be more logical when the portals list is separated from the segments? When you need to define a portal pair only once, this will realize the connection at loading when the parser reach the portal definition in the first segment. But if the portal is a segment member, I expect this is also defined at the second segment, so either the pair will be bind again or it would be necessary to check the portal list for an existing connection before bind a new one (which creates a very high effort).
The idea is to store all portals of the xml file in a single portals list. So an editor doesn't need to take care where he needs to place the portal and put his portal pair only to this list.

for example:

This is more a taste related question. A portal is never exactly a member of one segment. Technically a portal binds to both segments simultaneously. A big advantage of what you propose would be that segments are all already known before the parser sets up the portal pairs. And your system represents more the technical layout of the engine. A disadvantage would be that the person who edits the geo file (as we don't have an editor now) would scroll forward and backward all the time. And a separate portal list appears more detached, so it is harder tha add and remove complete segment clusters, which would be that problem in my proposition. Also the author should take care not to mess anything up and loose oversight.

I leave it to you to decide what system would be implemented. Changing it to another system or support both styles is not a problem afterwards. But if you decide to use your layout, can you take out the <portal-list> container tag out from the <segment-list> container?

Another question. When are you ready with the first working parser?


The portal would be defined only once, not in both segments. In which one it is indifferent, except for the shape vertices order which should be reversed.

Yes, that's the point


When the editor removes a segment and there is anywhere else in a segment a portal connection to there, he is also the looser. And if he doesn't remove this remaining portal, it will be detected as defective by the parser in in both cases, if the target segment is not existing. For a plausibility check of the xml file to verify relations, a small tool is written very fast.


Hard to say. The parser itself is done, but currently everything is read to dummy variables. I need to replace this with the gaming structures now and since I often need to adapt the function calls, this is more effort than I had expect. And unfortunately I have only a few free time at the moment to work on.

Btw: What object is the final target of the data. For example during the ship loading routine, the doors are read to TShipInteriorSegment, other things to TShipObject or direct to TSegment. So it's very confusing for example what is the target for a door? In my opinion I need to create a segment container (named segment list) which represents the xml structure and from where the init routines (for example ship init) get's the data it needs. But here I'm not sure, so I ask better, because this is a relevant design point for the parser.

I totally forgotten this thing Yes there are different types of a segment, all of them are derived from TSegment. E.g. the segment types for a ship are usually TShipInteriorSegment. To make things more complicated, there is also a member variable "TShipObject * shipObj;" which should be necessarily filled out. The different segment types are required to query things like gravity, music set selection and in the future also information about the ship itself to provide the upcomming quickmenu for example.

I would propose to add a few more attributes into <segment> tag:
1. The first one is "segmentClass" pointing at the kind of the segment. If missing the type would be the standard "TSegment".
2. Then there should be one or more parameter attirbutes depending from target segment type. In case of "TShipInteriorSegment" there is only one parameter called "shipObj" where you could give the entity name of the respective ship object.

Next, to realize creation of a segment by its type we need a hardcoded segment class factory database. Each entry would be associated with a key name and would take parameters (received from the <segment> tag). Then a factory would create a segment class instance from these.

Hope it was not too complicated explanation. Dealing with different types always require a few tricking.