Classic moviepack

[Lucifer]

Ok, I just put together the classic moviepack, which can be found on the wiki.

http://wiki.armagetronad.net/index.php/Moviepacks_list

Some things (and some questions). Would it be too terrible to have the moviepack support the original model? It would be nice to have the classic moviepack complete with the same model, animated. If not, is there someone willing to remake the original model into .ase form for the moviepack? In the meantime, I stuck ed's reworking of what I think is the original moviepack model in there instead.

For the splash screen, I was thinking it should have either none, or the same as 0.2.8, or keep the 0.2.7.0 splash screen. What do you guys think?

[Z-Man]

No splash at all lets a moviepack crash, so I suggest to stick to the one from 0.2.7.0.

Luckily, the way a cycle is rendered is determined entirely at creation time, it would be just a minimal hack to support the .mod models with animated wheels (at hardcoded positions) in a moviepack or the .ase non-animated model in the regular look.

What did you do about the rim wall? It gets rendered quite differently in a moviepack, and there, the hacks are so bad that I would not dare to touch them for 0.2.8.0. You didn't just replicate it four times, did you?

[Lucifer]

haha. I just replicated it four times.

Edit: I would prefer for the moviepack to just fallback to the original model if no model is provided, but use a texture that is in the moviepack directory to texture the original model if it's there, otherwise fallback to the textures in the textures directory. I looked at it to see how much work *that* would be, and it doesn't look too bad. Not a five minute hack for me, though.

[joda.bot]

About cycle animation...

well, I just looked at the rModel and gCycle code (loading the model and animating it). My goal was to find out how difficult it is to support ase animated models (by using three ase models).

IMHO: Loss of animation (even the default) is bad, I always prefered the default cycle as it's animated.


Problems:
- There are already two separate code paths for moviepack and default.
- different number of textures for Moviepack (1) and default cycle (2)
- one code path uses (hardcoded) animation - the other doesn't
- The animation is hardcoded.
(this could be improved by making it more model dependend).
e.g. use the front wheel's bounding box center as rotation axis.
Conclusion:
- more hacks won't improve the lack of design/structure here

My suggestion is to keep everything as it for 0.2.8.
For the next version 0.2.9 this should be fixed by redesign.
All files (like z-man's cycle and the moviepacks) will then be converted to the new format (only one code path then).

The other solution I see is adding animation to the movie pack and converting the default cycle to the enhanced moviepack format. (Feature freeze is active thus this is not an option).

[Lucifer]

Let's see. When the model is loaded, check for the moviepack model. If it's there, use it. If it's not, load the default model. Then check for a texture for the default model in the moviepack directory. If it's there, load it. If it's not, load the default texture. Now set a member variable to gCycle to say what you've done.

Then, during rendering, check the member variable instead of the global mp variable to see if you should render gCycle::customModel or use the others. Since this comes from memory, it shouldn't matter.

Maybe it is a 5 minute hack for me, I just overcomplicated it. Trying to fix something on my computer right now so I can get back to paying work, though.

[joda.bot]

@lucifer: My point of view was ... no more hacks .

[Lucifer]

Right. Ummm, you know, we're only talking bout this in the 0.2.8 version, who's only reason for existing is to provide the classic look for those who want it. I'll be perfectly happy to just use an ASE model, and if people aren't happy having lost animation, too bad.

Anyway, I started working on a rGameObject class, after having a pretty thorough conversation about it with philippe that finally got my head wrapped around it. I had to stop, though, have other things to do. Right now it's just class rGameObject {};. heh. Anyway, I agree with the meaning, and "no more hacks" should be a guiding principle in the trunk.

[Lucifer]

Just some other addition to the moviepack thing: Too complicated... Getting a file from somewhere, overwriting some other dir with it... You can't explain that without losing the match and i dont wannna type long URIs to the arma wiki...

JASI (just another stupid idea): What about multiple moviepacks? Like having a moviepack1 ... moviepack9 dir in /usr/share which all contain a file that somehow contains a description of the moviepack to display in the GUI? Then you could just put the old deault moviepack, the moviepack faking the old graphics and some other nice ones that barely lost the vote in the default package, make it a menu option and the n00bs would be happy...

I think the idea is eventually the moviepack as you know it will cease to exist and will be something more like a grid skin or a grid pack or something like that. Supporting multiple moviepacks is too big for 0.2.8 for all the reasons joda doesn't want to hack in the ability to use the default cycle model in a moviepack now. Other than that, you're on the right track.

Um, just give people the base url for the wiki, and if they say they can't find it, prod them for not using the search feature. It's not that hard to find, and I think it's in the process of getting linked from several areas, so it won't be hard to find for long (if it is now, which is arguable).

[Z-Man]

Let's see. When the model is loaded, check for the moviepack model. If it's there, use it. If it's not, load the default model. Then check for a texture for the default model in the moviepack directory. If it's there, load it. If it's not, load the default texture. Now set a member variable to gCycle to say what you've done.

Then, during rendering, check the member variable instead of the global mp variable to see if you should render gCycle::customModel or use the others. Since this comes from memory, it shouldn't matter.

Coincidentally, that's how it is already done. All that is required to give it the flexibility we need here is to change the loading code, and that should be a small and benign hack. I'm on it.

[Lucifer]

Haha. Break up assume into 2 words and a letter.... I assumed mp was a global variable, but I didn't track it down because it didn't matter for what I was fooling with. The other stuff is what mattered...

[Z-Man]

Unfortunately, because of the way some things work, the flexible loading code will be quite long with lots of pointless conditional statements. I'll finish it, but when I'm done, I may decide its just too messy.

As a fallback, why don't we just supply the old contents of the textures folder? There would be no way to switch between old and new style, but players desperate enough to download the old textures probably won't mind if the new ones are gone for good.

[Lucifer]

um, the moviepack does supply that. They can just unzip it in the textures directory instead. We can even put the model and textures for it, since if you put it in the moviepack directory they'll be ignored, and vice versa for the moviepack model. Then the user needs to adjust the floor color settings, not totally straightforward, but if they don't want to run it as a moviepack, they'll just have to suffer through it.

But come on, if you're going to finish it, it may as well be in artemis (it is technically a bug, at least, in my mind ), even if it's ugly. I promise we'll throw it away sometime before 2007 and it won't be in another stable release. Well, except maybe 0.2.8.1, 0.2.8.2. Throw in a comment to disown it if it'll make you happier.

[k]

Just thought I'd dig up some old links on this subject to add fuel to the fire.

re-structuring the skinnable part
Bike/Wall selection Gui
Cycle Customization

[Z-Man]

Lucifer: Allright, finished it, and it's reasonably non-ugly. I still would recommend it to only go outside with a paper bag over its head, but at least you don't have to vomit if you see it.
Here's what it does. First, it tries to load the model. It starts in the folder the user wants (mp/regular) and with the format the user wants(mp/regular). If that fails, it tries the other format, then the other folder, then the other both.
When a model is loaded, it loads the textures from the folder the user wants (mp/regular) in the format dictated by the model, if that fails, from the other folder. If texture loading fails, the model loading counts as failed, too.
I take it that you're the volunteer tester It's in b0_2_8_0. The system should never fail to display something, unless neither for the moviepack type cycle nor the classic cycle all resources can be found in both the two folders.

K: Appreciated, but we should really first have a GOOD model format and not the current hacks before we do any of that. Sorry that your file selection item is still unused Maybe next version for maps?

[wrtlprnft]

What happens if /usr/share/games/armagetronad/models/ contains *.mod files, but ~/.armagetronad/models only contains a .ASE file?

The thing I would desire would be to use the .ASE file, since in any other way you couldn't get armagetron to use a .ASE file without a moviepack without deleting the .mod files after every upgrade... But if I get that right the ~/.armagetronad dir kinda works as an overlay for the one in /usr/share, so it would take the .mod files.

Can't test it since I have no idea where to get a b_0_8_0 from (isn't on the beta site) and CVS is not even playable.