Quote from Scawen :

I didn't know DDS was so well optimized for RAM, CPU, and GPU. I didn't know that JPG had such a significant impact during decompression. I won't even mention the mipmaps, as that was far beyond my understanding. I believe that DTX1 and DTX3 are currently the best options available.

From what I read:
DTX1 (BC1) was released in 1998 with DirectX 6.
DTX3 (BC2) was released in 1999 with DirectX 7

After acquiring this knowledge, I experimented with all the newer formats up to BC7 (DXGI_FORMAT_BC7 which was released in 2009 with DX11). However, in my experience, all RGB/RGBA tests resulted in the same disk size or even worse outcomes. Although I read that BC7 offers better compression for alphas, I didn't achieve a smaller disk size. In theory, this compression improvement should come at the expense of CPU time and GPU resources. So, the end result is that I didn't manage to find a better solution.

The only thing that worries me is that this format hasn't improved in a significant way over the years, so we cannot benefit from it, but that's life.

Thanks for clearing this. This is a simple example of how we learn something new every day.

Yes, these DXT formats are interesting, as a special kind of compression that can be used directly by the GPU without decompression. Well, that's not quite true - I suppose they are decompressed at the moment they are read into the pixel shader, but not in advance.

Because the compression is only in blocks of 4x4 pixels, which is a completely different type of compression compared with JPG or PNG (which are also very different from each other).

The result of this is that they are even faster than fully decompressed textures because of the memory bandwidth reduction.

maybe something to flag a mod wich doesnt meet publication requirement anymore, has it been changed/updated, or review didnt see the issue.

example here on the "marigus" mod
https://www.lfs.net/files/vehmods/E1BC02

we can see on mod photo that it has magirus insignia on the rear
https://www.lfs.net/attachment/569961

wich is exactly the same as what we see in reality
http://upload.wikimedia.org/wikipedia/commons/6/69/Magirus-Deutz_230.jpg

maybe button in the vehicle mod page, that would open some dialog to write reason of the flagging, and if reason is found valid, mod would be unpublished until issue is fixed

I'm not sure how bike steering currently works, but is it possible to do a minor improvement on the control, while the bike is on its rear wheel? It's very easy on bikes (with traction control: off) to lift the front wheel, but there is no control afterward, is there an easy way to add a bit of driver body weight control? Although I have no idea, that weight might have already been used for the corner steering. Would be great, if we could have a bit more control over the X-axis, left/right weight control, so we can land back the bikes on their front wheels, rather than fall down every time. This is just a question, if it's a long time process, I wouldn't mind it being rejected, it's just something I noticed in multiplayer, so I thought I'd ask.

I'd love the ability to publish a car that is based on a derivative mod, but disallow further derivatives. For example, I have the SLX180 mod, and did the SLX180 TYPEX, which links back to the SLX180 and is fine since I allow derivatives on the TYPEX as well.

When I want to build a private team car based on the SLX180, I can't link to it and have derivatives turned off, so when I look at the new how many derivatives I have for the SLX180 now (thanks Scawen for the the update, looks awesome), it isn't accurate since the team cars are set to link back to the original external source so I can have derivatives off.

In short form: allowed to base mod off a derivative, with the new mod having the option to turn derivatives off (it should be on by default I think).

FYI: before you could do that but it has been changed (don't know the context as to why)

I did think you could do that before, except in the case of a "ShareAlike" license.

I could have a look into this, to see if I can understand if it has gone wrong somehow. It's not my code, by the way, and that license stuff is in a part of the website code that I am not really familiar with, but maybe I could make some sense of it before asking Victor about it.

OK, I've had a look in the code. I actually think that this hasn't changed, but it is different when the source model is external.

Ideally, when the source mod's grant license is:
CC Attribution-NonCommercial (BY-NC)
Then it should be possible for the creator of the derived mod, to decide if derivatives are allowed. If they say "NO" then the derived mod's grant license would become:
CC Attribution-NonCommercial-NoDerivs (BY-NC-ND)

Similarly if the source mod's grant license is:
CC Attribution (BY)
Then the creator of the derived mod should be able to decide if derivatives are allowed. If they say "NO" then the derived mod's grant license would become:
CC Attribution-NoDerivs (BY-ND)

It seems in the license selector wizard, this is not possible when deriving from another mod (as described by OpenClutch above). But is IS possible when deriving from an external source, so I think that may be what we remembering.

I think that it would be best if the same logic for external sources was available for when deriving from an existing LFS mod. I don't actually know how to change this type of code but I will ask Victor if he can have a look.

Thanks Scawen, I agree that if linking to a lfs deriv acted the same as an external resource, this would solve the issue.

If fixed, I'll go chase down the derivs that I know of and get them to link back to my SLX180 for full transparency.