Howdy. I've been testing this one since the beginning but along the way almost everything I could say was said by others, regarding technical notes, shortcuts, playability, and everything. Well done testers!
Great work on the new version mumhra, it's so much better it's almost a different track, and I don't miss anything from the old one.
It's a very creative track and nicely constructed!
Also, even before Jumper said it
I was going to suggest you use the stone walls and buildings, palm trees and the farmroad textures to create a short circuit, using what you already have as base or creating an all new work, because the look and feel of that village section is great, as Jumper noted.
Now, at this point I must also point out that the crowd models have the same problem as the fencing - the flat bin pull-through effect. I think you should inspect all of them and rotate them as necessary. It's a very frustrating effect.
>> Is there a possibility to see in traxx when they are facing in the correct direction ?
Going from memory here... when you are facing North and you insert a model in Traxx, the front and left (and top) sides of any flat model will be the solid side (the positive axis side).
Quote:
I don't think anybody has made a study of the problem. Does it happen along a particular axis or direction, does it happen on all flat models or only on some facing a certain direction (ie, the bin oriented on a given plane), would adding a single vert solve it if it was off the flat plane, do face types affect what happens, and like that.
<i>In the past I have noted that the pull-through occurs on the negative x/y/z axis of the model (binedit axes), while in-track orientation has nothing to do with it. An extra vert would solve the problem, but offsetting the vertices might work too, so that one end of flat bin is on the positive side on an axis and the other on the negative (picture a shallow angle).</i>
>> nothing worse for a racer than something you cant see
The "SMPHOTL4.BIN" (gray mtm hotel) has this problem, it is a bad model, it needs to be centered in binedit, re-saved and then repositioned, or else made non-collide in the case where it overlaps the road (along course segment two). As it is the collision properties are all wrong. I assume this smp-renamed version is an unchanged version of the original mtm1 bin. [fix-it pod alert]
Now there is an issue regarding the number of model textures used, it was a problem in the first beta and got worse in the second, but even with that I wasn't going to say anything -- until I read Jumper's latest comments about lag. In the first beta there were 412 kb of terrain textures and 4.29 mb of model textures. That is a heavy load of model textures. In the second beta there was 488 kb of terrain textures and 6.88mb of model textures! The model textures alone amount to 104 large (256x256) textures and 97 small ones (the equivilent of about six large ones). These account for the large download and the lag that Jumper has noted. I suspect I've preached about texture efficiency more than anything else over the years, but in my opinion you've used an insane number of textures (due to the large selection of models), which would surely make the track almost unplayable with an old 4mb video card (such as I had when the game was new). With that said, I'm not one to suggest you un-make your track, my only advice is to never repeat this pattern in the future. The problem is that when a bunch of models suddenly come into view, which collectively use a boatload of textures, the game must load them all at once, which causes the pause/chugging/lag effect.
It seems you've collected all sorts of models to use without considering their texture weight, you have many models that use large textures, and in some cases I suspect they aren't worth their weight.
As an example of the way models can be texture heavy - the OLD truck alone uses 8 large textures, which is quite a lot. The single building "SMPBD153.BIN" uses four large textures, no other models in the track use those textures and the building is simply a hotel/courthouse kind of thing, yet there is a whole city's worth of textures assigned to it (chicago) that are never seen! This bulding should be taken out and shot. Also, the single building "SMPHOUS7.BIN" uses four large textures, no other model in the track uses these textures and the building itself is a simple gray building, yet it uses a whole city's worth of textures (san fransico) that are never seen.
I'm not suggesting you remove anything, the OLD truck is mentioned simply as an example of how models need to be considered before use, but "I" would remove the two buildings due to the incredible waste of texture memory. The thing is that most of the buildings you've used are from "Fly!", you've selected only a few buildings from each city - while the ideal is to use many buildings from one city - since the set of models all share the same textures. I realize your track demanded a large variety of models, but normally one should avoid using dozens of different large texture models from many different sources in a single track.
You can reduce texture induced lag by setting models to normal or complex, to give racers a clean run when running in sparse. Billboards, pagan gods, trucks, aircraft and other unnecessary eye-candy would be the ideal target for this option.
Note: the number of textures I counted up above doesn't tell the full story, what I counted is what was in the pod but not used in the track (the large texture count is closer to 70, not 100). If you purge unused models and textures in Traxx you will reduce the download by more than a megabyte, so don't forget to do that.
Finally, if you switch to wire frame only view in Traxx, and fly around looking at models, you will find at least two old checkpoint markers you can delete to free up space for two more objects.
![[nyuk]](./images/smilies/smilie_nyuk.gif "Nyuk")
![[(-:]](./images/smilies/smilie_uppydown.gif "Uppy Downy")
![[uhoh]](./images/smilies/smilie_worry.gif "Worry")
pictures lol.
