[ARSPR]

Example: take in mind that your media vp patches are supposed to be loaded overriding media vp just because their names (mp_whatever vs. mv_whatever). If FS2 depends on creation date, it could be REALLY tricky and unusable.

VPs themselves are sorted alphabetically, so there is no issue there.  It's just the files under data/ that aren't sorted, and I see no reason to change that behavior.

Well I can see one, although by far, it's not so critical as vp sorting. In fact, only Vp sorting is THE CRITICAL one.

Between releases, Mediavps does usually have a lot of official or unofficial updates (new models, small fixes, or whatever; for example I've got 9 user-patches + 4 HTL models in addition to 3.6.8. zetas+alpha patches). The best way to do this process is packing each "update" in one Vp. In this way you control how these updates are applied and in which order. But, maybe people just copy the additions to mediavps\data folder.

As there can be a lot of "updates" which are not really designed with any of the others in mind, if some kind of cross-effect happens between tables it can be a PITA to track it down. And if you don't know how the tables, which you don't remember what they have, are being loaded, the problem gets worse. With the vp use, at least, you know how they are loaded, but it seems that with just file loading is nearly random or luck.

So, I think that, if it is not too much coding work, adding this alphabetical criterion to file loading could be a good idea. Although you could have always used vps method (the most hygienic one). And OTOH I see no harm in an alphabetical file loading, (apart from your coding homework  ).

[taylor]

So, I think that, if it is not too much coding work, adding this alphabetical criterion to file loading could be a good idea. Although you could have always used vps method (the most hygienic one). And OTOH I see no harm in an alphabetical file loading, (apart from your coding homework  ).

You mean, aside from the massive performance decrease on game load and any time that the game does to disk for file loading?

There is actually a reason that individual files aren't sorted you know.

[ARSPR]

So, I think that, if it is not too much coding work, adding this alphabetical criterion to file loading could be a good idea. Although you could have always used vps method (the most hygienic one). And OTOH I see no harm in an alphabetical file loading, (apart from your coding homework  ).

You mean, aside from the massive performance decrease on game load and any time that the game does to disk for file loading?

There is actually a reason that individual files aren't sorted you know.

OK then 

Unless you, the expert guys, have a different opinion, tomorrow, I'll update Modular tables section in Wiki posting a warning about putting conflictive tbms in the same folder or vp. It will say that there's no easy way to predict which one will be really applied.

(I think earth people, like me, shouldn't be messed up with technical info saying that the loading order will depend on how the vp was built or how your computer OS filesystem works ...)

[ARSPR]

Modular Tables in Wiki is re-updated.

Please check my English and knowledge, again.

(Also, when -str.tbm is fixed, please post here so I re-test again).

[taylor]

(Also, when -str.tbm is fixed, please post here so I re-test again).

It is fixed already, but CVS is down so I can't commit the changes.  If you want to go ahead and test it out then let me know and I'll post an updated Xt build later today.  It's not going to be much different than 0520 though.


EDIT: Oh, and someone probably needs to update the fireballs.tbl entry too.  After "$LOD:" there can be "$Light Color:", which takes 3 values in the 0 to 255 range.  This sets the color of light that is given off when that explosion is created.  And values set at "0 0 0" will not give off any light at all, just FYI.

[ARSPR]

Don't worry, I can wait till your next XT (for example with errors & warnings enabled    ). Don't compile a build just because of this issue.



EDIT -------------

I've decided to make further reorganization in the Modular Tables page. I think now it is clearer.

[ARSPR]

EDIT: Oh, and someone probably needs to update the fireballs.tbl entry too.  After "$LOD:" there can be "$Light Color:", which takes 3 values in the 0 to 255 range.  This sets the color of light that is given off when that explosion is created.  And values set at "0 0 0" will not give off any light at all, just FYI.

I'll do but just several questions:

+ Is it a SCP addition? (Just to paint it in red).
+ Which are the default values if it is not specified?
+ RGB coded? GBR? BRG?
+ I suppose tbm supports it.

[taylor]

+ Is it a SCP addition? (Just to paint it in red).

Yes, added after 3.6.9 was released (ie, in late January).  It will be an official feature starting with 3.6.10, in other words.

+ Which are the default values if it is not specified?

The default values are the ones that used to be hard-coded.  Those being:
255, 127, 31 for the LARGE1, LARGE2, MEDIUM, and ASTEROID explosions
191, 191, 255 for the standard WARP effect
191, 255, 191 for the KNOSSOS WARP effect

+ RGB coded? GBR? BRG?

RGB, to keep it the same as all other tbl color specifications.  There is no alpha component however, so it's only valid to have the 3 values for RGB.

And as stated earilier, values of 0, 0, 0 will give off no light at all when that particular effect occurs.  If you wanted dark/black light you would have to make at least one of the RGB values "1", or simply use 1, 1, 1 for a uniform dark color.

+ I suppose tbm supports it.

Yep.  And it's completely optional in both tbl and tbm.

[ARSPR]

+ Is it a SCP addition? (Just to paint it in red).

Yes, added after 3.6.9 was released (ie, in late January).  It will be an official feature starting with 3.6.10, in other words.

I won't update Wiki yet then.

When 3.6.10 is out, at least in RC version, I'll post it.