Hey, I've been trying to solve the "SVB mystery" and here's a screenshot from the ToEEWB visual sector painter that sheds some light on why SVB'ed areas show in places where they are not supposed to show! It seems like the SVB stuff is rotated 90 degs compared to everything else, *in addition* to the fact that it's 3-layer. At the screenshot we can see a room in the middle (with a quite defined configuration so you can see all the details), AND we can see the brown SVB definition squares for the room that looks rotated 90 degs compared to the room configuration itself. Note that the fact that ToEEWB draws them inverted is not the fault of ToEEWB. In fact, the SVB sector layout appears to be rotated and that is how it is interpreted in the game. Maybe the sector code and the SVB code were made by different people??... I'll try to modify the support for SVB in ToEEWB to make sure that SVB things are drawn in a 90-degs-reverted way so that they overlap the objects they are defined for. It could take some time, though, but I'll work on that. - Agetian
Now why didn't I notice that? Just slow, I guess... Do u notice the 3 sets are not absolutely identical? Hmmmmm...
That's actually something I noticed quite long ago. The three layers can be different, of course... I think they actually correspond to three different layers on the Z axis (though I may be different). Most of the time they'll be the same, but sometimes it may be worthy to draw them differently (?) That's another point, I'll get to it after my experiments with Ed.py (that are undergoing right now ) - Agetian
I've been trying to improve the way SVBs are handled in 'Ed' in any reasonable way for a few hours by now, and to no avail at all. It seems that the original ("90-degs-turned") way of representing the SVB data is so far the best. I tried all possible rotations, but none of them makes the SVB and sector blocking data overlap "exactly". And all other rotations except for the default one cause more problems than the default one... Well, I don't know what to do with this :censored: SVB stuff yet - I can't improve the way SVBs are handled in any meaningful way (without causing even more problems), yet I understand that it's already weird enough (3-layer, 90 degs-turned :yikes: ) to be handled the way it is handled now (although technically speaking, it is handled in the right way right now, at least from the point of view of ToEE engine!). Well, I will keep thinking about it. - Agetian
Depends what u mean by overlapping - if u turn it 90 degrees, does it show the tiles that are svb'd? It may not overlap precisely what is there because, well, this or that wall might have a couple 9ths that are walk-onable that need svbing, or whatever. I am not expressing this well but I wouldn't expect the svb's to match up exactly with the blocked floor-plan because as u say they go into the z axis of an isometric view so they are going to be different in parts (mainly around the edges). As long as they show which bits svb when u walk on them, we don't have to go berserk - anything is better than nothing at this point! <sigh> Here I am telling the perfectionist to get it sorta right ;-)
The trick is - they are too far away to make sense. In fact, wherever I turn it, it turns out that most of the SVBed tiles get out into the impassable area (or area which can't be reached at all), which makes little sense. As I said, I'm working on it. - Agetian
I've got another crazy idea about implementing more-or-less correct SVBs, so I'll test it today and tomorrow. No promises here though, but I'll try it out and see if it does the trick or not (I won't open up what exactly I'm up to for now ) - Agetian
Nope, didn't work. Gosh, how crazy this SVB thing is! I've tried out so many things, and nothing has worked (and the result is always FAR from perfect). No matter how you rotate the SVB field, it still ends up very far away. If you try to implement certain offsets so that you "force" the SVB field to come onto the related objects, the SVBed area turns out not to match the configuration of the objects it was built for (and, therefore, there is still a lot of flickering, especially in the areas where there's supposed to be no SVB at all). Of course, I will keep thinking about all of this... But so far it all makes very little sense. All contributions are welcome. - Agetian
So if you svb FIRST, find out where it is 'working', then put walls there to walk behind, it doesn't work? Is that what you are saying? So it seems to b influenced by the block it is attached to as well? crikey...
I don't really think that the blocking affects SVB, nor that SVB affects blocking... I just mean that forced overlapping (more-or-less) of SVBed and blocking areas does not give any positive effect. Anyway, will keep testing today. Will make one very fun test - create an area and add three loooooong, but thin SVB layers to it, with easy coordinates, like (500,500) through (550,505). Then I'll see what it corresponds to in the game, and if any rule can be made out of it. I'll keep you posted. - Agetian
Sorry for a long time of silence, been busy all this time... So, my latest experiments with SVBs show that actually the SVBs are not turned 90 degs anywhere (at least it looks that way), since creating a SVBed area from (300,500) to (305,520) covers about the same map area in practice as well. It *seems* to me that smaller areas (1-tile, 2-tile, etc.) usually don't work correctly, while larger areas (more than 5x5 tiles for sure) always work 1:1 when SVBed in the ToEEWB (including all the +21/-21 extra layers). Hmm, for the most time stuff in the SVB remains a mystery... Does anyone have anything to add here? Ted?... - Agetian
Well the only ones I got 'working' were larger areas now you mention it yes. And there was the dang flickering. Maybe they have large chunks of non-playing areas SVBed to create an artifically large area to get it to work?
Yeah, that could make sense. As I said, SVB seems to work in a different coordinate space (at least it may not always correspond to the sector tiles in a 1:1 manner, so it'd make sense if a bigger area should be covered in order to make the SVBs work or to avoid flickering). I think I'll test it soon. - Agetian
Should elaborate: the ones i got working were long lines of svb'ed bits beside long walls, maybe only a single tile wide but more than 5 long, both in x and y axes. Small ones, as you say, didn't work.