AB3D2_LevelED Help required

[abu_the_monkey]

no worries, I know that one only too well

there's no rush

[Karlos]

Speaking of control points, I wonder why the limit was set to 100. I should look more closely into what the engine does with these data. I know it's for alien navigation but how it uses it may have a large bearing on that number, especially if it doesn't scale well in performance terms.

Now that we have C support, it should be easier to try out different algorithms that might be better.

[abu_the_monkey]

the whole zone/control point association tool seems backward to me, why select the zone first and the the control point

[Karlos]

Originally Posted by abu_the_monkey

the whole zone/control point association tool seems backward to me, why select the zone first and the the control point

I am not sure. Maybe it's just the specific circumstances I described that trigger it.

[abu_the_monkey]

selecting the control point first and then the zones to associate with it makes more sense to me, but, in the editor you have to do it the other way round (at least to start with) select a zone and then a control point.
Not sure I follow how it works at the mo

[Karlos]

At some point I am going to have to read the source, because i want to understand how the "clips file" is built. I am sure the data produced is buggy because I have situations where I have followed the stated "rules" for zone placement to the exacting letter and issues with disappearing wall segments, halls of mirrors/void type effects.

I believe the job of the clips file is to hold data about which zones are potentially visible from which other zones, assuming that the connections between them are portals. This is a non trivial task when you are dealing with zones that are not directly connected. For example, just because zone A is directly connected to zone B and zone B is directly connected to zone A, does not imply zone C must be visible from zone A.

Level H is especially glitched, to the extent that several perfectly legal modifications of the design produced a total PVS disaster and I've had to abandon them.

I am contemplating writing an external tool to do this job because I imagine the AMOS code for it is a horrorshow. I just want to understand the data structures and the expectations of them.

[abu_the_monkey]

in the example below viewing from one side (lh) of level H shows obvious pvs issues but viewing from the other side (rh) where I have inserted an extra zone it renders correct (up to a point) prior to adding the extra zone both sides had the same issue.

red arrow is player position and direction
yellow ellipse is the render area in question

is there a bug? probably.

not sure the instructions are 100% accurate either.

[Karlos]

Originally Posted by abu_the_monkey

in the example below viewing from one side (lh) of level H shows obvious pvs issues but viewing from the other side (rh) where I have inserted an extra zone it renders correct (up to a point) prior to adding the extra zone both sides had the same issue.

red arrow is player position and direction
yellow ellipse is the render area in question

is there a bug? probably.

not sure the instructions are 100% accurate either.

It's an interesting result but as far as I can tell, the original zones were not violating any of the rules.

[abu_the_monkey]

yeah I know, but I seem to remember Andy C saying 'you' had to do most of the work in the editor.

maybe the thing just takes shortest path?

[Karlos]

Originally Posted by abu_the_monkey

yeah I know, but I seem to remember Andy C saying 'you' had to do most of the work in the editor.

maybe the thing just takes shortest path?

The one rule that I can think of causing such a problem is when one zone is visible more than once from a given vantage point. This can happen when there's a hole (a void enclosed in external walls) in the map.

Level H does have holes in the central section, but I think the placement is correct.

The PVS glitches I had in H trying to connect the upper gantry to the ground level via a secret door (you can still see the additional points where it was going to go) were extreme, Half the walls became invisible from a vantage point seemingly unrelated to the change area.

[Karlos]

Failing all else, I might segment up those zones in a manner similar to what you have done there, to see if I can fix it that way.

In my Level H, as soon as you are out of the gate, turning around to face the door you exited from and sidestepping right into the slime pool causes the right hand wall section adjacent the door to just disappear, revealing the skybox. It's most perplexing.

[abu_the_monkey]

most likely a bug then.

[Karlos]

Originally Posted by abu_the_monkey

most likely a bug then.

To be fair, it's not a simple task.

[abu_the_monkey]

@Karlos

if you did want to look over the clip file stuff it starts at around line 6290 'Procedure _CLIP_LEVEL' in the LevelED_304.txt and runs on till line 6970 ish. there are a few comments in there.

[Karlos]

Originally Posted by abu_the_monkey

@Karlos

if you did want to look over the clip file stuff it starts at around line 6290 'Procedure _CLIP_LEVEL' in the LevelED_304.txt and runs on till line 6970 ish. there are a few comments in there.

Roger

[Karlos]

@abu_the_monkey

I raised a (hopefully) small feature request issue. The door/lift definition windows limit the raise/lower speed to 16. However, in Level O, there's a lift that falls at speed 200 (the bit that dumps you in the arena with the two wasps), so the 26 limit seems a bit unnecessary. I'm guessing the value is either unsigned 8 bit or a word.

It would be nice if the limit was say 255 rather than 16.

[abu_the_monkey]

Originally Posted by Karlos

@abu_the_monkey

I raised a (hopefully) small feature request issue. The door/lift definition windows limit the raise/lower speed to 16. However, in Level O, there's a lift that falls at speed 200 (the bit that dumps you in the arena with the two wasps), so the 26 limit seems a bit unnecessary. I'm guessing the value is either unsigned 8 bit or a word.

It would be nice if the limit was say 255 rather than 16.

I will have a look when the wife is at work later, should be an easy one (famous last words )

[abu_the_monkey]

yes, simply extending the input value range works as it already loads/saves an 8 bit byte, did you want this for both doors and lifts?

word of warning, don't set the raise and lower speed to 256 for player touch type lifts, the travel is practically instant

[Karlos]

Originally Posted by abu_the_monkey

yes, simply extending the input value range works as it already loads/saves an 8 bit byte, did you want this for both doors and lifts?

word of warning, don't set the raise and lower speed to 256 for player touch type lifts, the travel is practically instant

I think 255 should be the actual limit?

[abu_the_monkey]

@Karlos

here is a build with extended input for door/lift speed values.

values are for 0 to 256