Default cycle model/textures/cockpit competition for 0.4?

[Lucifer]

While we're at it, do we have any sort of flexible moviepack selection system in the game? If we do, then it would be worthwhile to consider including some of the runners up in the contest as part of the game, just not the default setting.

[compguygene]

Isn't it possible to ship the game with a the default textures and a moviepack installed? Then toggling the moviepack could switch between the two.

[Z-Man]

While we're at it, do we have any sort of flexible moviepack selection system in the game? If we do, then it would be worthwhile to consider including some of the runners up in the contest as part of the game, just not the default setting.

No, we don't. The system used by tr2n is very half-assed and won't be ported. We can build a three quarter assed system no problem for 0.4, but not a proper solution where users can select their preferred graphics and server admins can select theirs with priorities and automatic download of missing content (the automatic download bit would be missing, as well as some flexibility). I'd rather not.

compguy: that would only work if the secondary content was in moviepack format, which it won't be if it wants to be the primary content. The cycle will be no problem, but four texture rim wall split.

[Phytotron]

Isn't it possible to ship the game with a the default textures and a moviepack installed? Then toggling the moviepack could switch between the two.

compguy: that would only work if the secondary content was in moviepack format, which it won't be if it wants to be the primary content. The cycle will be no problem, but four texture rim wall split.

You're referring to if it were the runner-up that was made the moviepack (or vice-versa, really; they're co-equal, I reckon)? Pretty easy to convert a single rim texture to four (copy 3 times, rename). Dir_wall would differ in dimensions but, depending on what it was, could probably be easily converted. And if the top two winners happen to use differing cycle model types, well then, the one with the .mod becomes default textures and the one with .ase becomes default moviepack. All that is to say, we'd want to wait to see what the eventual winner and runner-up look like.

All that said, if there were going to be any kind of moviepack included, I think my personal vote would be for that old classic one that used to be included in older versions—the one that, you know, mimics the movie. Umm...this one, I think it is.

And with this as well, since it's meant to be the default, shouldn't the values in there be non-custom as well? For example, I'd think floor_r/g/b all set to 1. And here I can recall an actual incidence. I remember back when I was totally naive to this stuff, Fonkay and I having an issue with a green grass floor texture I made being tinted blue on her computer. Hey, found it, heh. (There was some other issue there, but the point remains.)

That's a tradeoff between easy customization of the floor color and easy complete change of the floor texture. The way it is, grey texture plus non-white color setting, makes adjusting the color easier. If we'd go with your suggestion, you'd need to make a new texture for that.

I don't quite follow what you're saying here. Isn't the point that there may be a new floor texture?


And speaking of the floor, I can't recall (and the forum search declines the phrase "just grid" for being too-common words), is there a particular reason why the "just grid" doesn't (or can't) extend to infinity (or at least all the way to the rim)?

[Z-Man]

Pretty easy to convert a single rim texture to four (copy 3 times, rename).

Easy, yes, but horrible for performance. Plus, including both a moviepack and regular data makes installing a custom moviepack harder or the results more confusing. I'd feel less bad about it than hacking together a graphics selection system, but it still doesn't feel right.

And with this as well, since it's meant to be the default, shouldn't the values in there be non-custom as well? For example, I'd think floor_r/g/b all set to 1. And here I can recall an actual incidence. I remember back when I was totally naive to this stuff, Fonkay and I having an issue with a green grass floor texture I made being tinted blue on her computer. Hey, found it, heh. (There was some other issue there, but the point remains.)

That's a tradeoff between easy customization of the floor color and easy complete change of the floor texture. The way it is, grey texture plus non-white color setting, makes adjusting the color easier. If we'd go with your suggestion, you'd need to make a new texture for that.

I don't quite follow what you're saying here. Isn't the point that there may be a new floor texture?

I'm saying that the right way to do an even just mostly monochromatic floor is to keep the texture gray and adjust the floor color settings. I won't mandate white color settings because it makes changing the texture easier, it's up to the artist to decide.

And speaking of the floor, I can't recall (and the forum search declines the phrase "just grid" for being too-common words), is there a particular reason why the "just grid" doesn't (or can't) extend to infinity (or at least all the way to the rim)?

Yes. Incredibly off topic. That option is only there for very low end machines, especially ones without hardware accelerated OpenGL, and every line uses up CPU power. It'd be relatively cheap to extend the lines to practically infinity, but then the grid would be just a cross.

[Lucifer]

I was thinking of a resource wrapper that lightly wraps the existing moviepack format, and just changing the hardcoded directories to use a variable pulled from the currently selected moviepack resource. Maybe not worry about letting servers pick moviepacks right away? And, of course, also taking the 0.2.8 default graphics and making a new legacy moviepack, just like we have for 0.2.7 and below.

I know, sounds easy, but I've been in there to do it, too.

[compguygene]

Lucifer, if it is practical for that to be done, that sounds like a great step forward, that would be a nice incremental change towards proper moviepack selection. Right now there is a very tiny group of people that change their moviepack. Perhaps with this small step, the community of people changing moviepacks would grow, which would encourage more moviepacks to be made. I found when playing TR2NOrigins that I really liked to use different moviepacks for different servers. Even if there was no previewer, etc. I would love to see this done right instead of the hacky way that Manta did it. Before TR2NOrigins died, they started getting some bug reports related to the ugly hacks that were done. I am very grateful that the devs here are trying to do this stuff right, and fix the platform a piece at a time.

[Lucifer]

It's practical, sort of. Some of it depends on how much purity is required for the solution to be accepted. Most of it is how much existing code has to be adapted to meet the level of purity, and right there where we're talking is the most broken part of the rendering code (that I remember). It's the two rendering paths depending on if you're using a moviepack or not, and the way models and textures and stuff get loaded. The resource system provides the long term solution to all of this, but the renderer, last I looked at it, is in no shape to be adapted at this point.

So, hrm. It was "easy" for TR2N to adapt, but like z-man says, what they did was a huge hack. Almost as bad as their hack to play ingame music. These little hacks are like lines of cocaine. One or two every couple of months isn't dangerous (even if it's still stupid) for most people, but doing it every time you turn around is a serious problem.

[Phytotron]

Cocaine is a hell of a drug.

[compguygene]

So, hrm. It was "easy" for TR2N to adapt, but like z-man says, what they did was a huge hack. Almost as bad as their hack to play ingame music. These little hacks are like lines of cocaine. One or two every couple of months isn't dangerous (even if it's still stupid) for most people, but doing it every time you turn around is a serious problem.

After the TR2NOrigins team kicked me out for talking with you guys, I began to fully realize not only how much of a terrible hack t2o was. But, I also realized poorly the t2o team understood Open Source Software and the Software Development Process.

[Z-Man]

Almost as bad as their hack to play ingame music.

Hey! Didn't they just activate the code that was already there?

Edit: What benefits would the resource approach give if it can't be controlled by the server? There still wouldn't be a menu to select them, we'd still have the old rendering code, and we'd have to properly get the resources in as textures and models. We still don't have a very good system in place for binary resources, mind. And we have one special problem: the data loading code checks whether files exists, and falls back to other files if they don't (like, it checks whether cycle.ASE exists, and loads the mods if it doesn't). In the resource system, we'd need to either hit the network every time (bad) or cache the nonexistence of files (not too good either). And whatever we do, we have the problem that we don't know how art assets would be handled in a future system, there probably will be changes required to all today's moviepacks once we switch. If we hack something together now that inevitably requires changes too, those changes need to be done twice. Or we keep compatibility with both legacy formats then, and again, I'd rather not.

[compguygene]

Almost as bad as their hack to play ingame music.

Hey! Didn't they just activate the code that was already there?.

The way manta explained it to me, he pretty much just had to activate code that was there and hack it to make it work.

[Lucifer]

Almost as bad as their hack to play ingame music.

Hey! Didn't they just activate the code that was already there?.

The way manta explained it to me, he pretty much just had to activate code that was there and hack it to make it work.

He used the sound effect object, which causes the entire file to be loaded into RAM and played. Music should be streamed, it's more efficient and provides the most reliable memory/cpu usage. When you load an entire mp3 into memory to play using the sound effect objects we have now, then the entire file must be decoded while it's being loaded. So now your 5MB mp3 takes up 40MB in RAM, and you take a huge CPU hit when the file is loaded. As I recall, he had to later add some code to prevent the CPU hit during a match, resulting in quiet spots in the music while playing.

[Lucifer]

What benefits would the resource approach give if it can't be controlled by the server? There still wouldn't be a menu to select them, we'd still have the old rendering code, and we'd have to properly get the resources in as textures and models. We still don't have a very good system in place for binary resources, mind. And we have one special problem: the data loading code checks whether files exists, and falls back to other files if they don't (like, it checks whether cycle.ASE exists, and loads the mods if it doesn't). In the resource system, we'd need to either hit the network every time (bad) or cache the nonexistence of files (not too good either). And whatever we do, we have the problem that we don't know how art assets would be handled in a future system, there probably will be changes required to all today's moviepacks once we switch. If we hack something together now that inevitably requires changes too, those changes need to be done twice. Or we keep compatibility with both legacy formats then, and again, I'd rather not.

Without the ability to change the moviepack using a menu item of some sort, there is no benefit.

It would also require some significantly impure hacks. Basically, the moviepack xml file would have just one line that says "download this zip file, everything's in there", then it downloads it, and the hack begins seriously by unzipping, and then having manual fallbacks.

Yeah, doing it right takes care of all of that, and is still workable with the existing rendering code, it's just a ton of work. And it has to be done all at once.

Edit: Has anybody looked at how textures managed to get wrapped in the cockpit?

[Z-Man]

Edit: Has anybody looked at how textures managed to get wrapped in the cockpit?

It's quite OK; from the cockpit file, they are referenced like this:

Code: Select all

                <Image>
                    <Graphic author="wrtlprnft" version="1" name="benboisclock" uri="http://wrtlprnft.ath.cx/benboisclock.png" />
                </Image>

The code then builds a filepath ("wrtlprnft/benboisclock-1.aatex.png") from the metadata given there and tries to load the texture with it. Failing that, it downloads from the URI (or constructs one on the default repository).
The kicker are these two source lines from the path construction:

Code: Select all

                cur.HasProp("author") ? cur.GetProp("author") : m_Cockpit->Path().Author(),
                cur.HasProp("category") ? cur.GetProp("category") : m_Cockpit->Path().Category(),

That means that if you omit the author and category values, they're taken from the parent cockpit file. So, should we reuse that code for a moviepack resource metadata xml, we could just provide a sample xml where the data files are referenced without giving author and category, and all the user has to do is adapt those two values in the head of the file.

And rename all the textures because the default texture names are incompatible with this scheme. Dang.

No, really, the good way to do this is to rework the rendering and loading code first so it makes sense, *then* look for a good way to get legacy data loaded again. That approach worked quite well for zones 2.0. Even if we use the above resource wrapping scheme, which is tempting, we'd still have to solve the problem all over again.