Official T3ED FM Distribution Document:

New Horizon on 20/6/2005 at 14:59

Okay, we've had a lot of talk over the last few months but since we're getting so close to having some cool FM's released, lets try to nail down exactly how we're going to do this and then get to work on preparing the foundation. :)

In my opinion, the simplest route is to distribute the FM's via the gmp files/ custom resources and have potential FM players download a one time resources package, as others have suggested. I'm willing to help coordinate this and make an installer for it since I'm also working on an updated T3Ed installer. It would be nice to see the community have a stable working foundation for FM's so that we don't have a huge conflicting mess.

By using the gmp's, it will mean that FM players will not be downloading the same content over and over again. They will only have to download the custom content.

As for custom content, I've been experimenting with ways we could make this work similar to T1 and 2 where the FM is a subset of the core files.

Unfortunately, I'm not sure T3 will allow us to assign multiple resource paths within the default.ini so that we can tell it to search in the main folders first and then in the custom folders second.

For example:

Quote:

Something to that extent, so the engine searches in multiple areas. Some experimentation will be needed.

At any rate, I would like to see further proposals and results of experimentation in this thread. Lets get this up and running. I definately think the gmp approach is the most flexible way to go.

Ziemanskye on 20/6/2005 at 17:10

How well does it handle reskinned Smeshes? There's only one .tim per mesh, so what happens when it thinks the resource is missing because the tim is there but the skin name isn't, and it's not looking elsewhere because it's already found the "correct" file? Or how about when you twiddle the material or physics options on your (editing with) version - that wont be transmitted either.

And that is going to get hideous with triggerscripts.

And that's before we get to real custom content.

As for having to modify the default.ini for every FM, well, I'm biased against messing with the default.ini anyway but I think that bit is order sensitive so you can't just do it on the user.ini.

(Sorry - at this point I'm still in favour of ibt files)

Dark Arrow on 20/6/2005 at 17:20

I agree with your plan. For your plan to work, the community will require the assistance of all the different people who are building a loader program to T3.

I think we could work with this way even if T3 doesn't support multible search paths. Perhaps a cleanup/backup system in the loader to allow FM designers to restore their installation to default one.

I am wondering, could the loader programs be used to locate and package all the custom resources used in an FM? Not really required, as we could do it the old way again.

Edit:

Quote:

Posted By Ziemanskye:
(Sorry - at this point I'm still in favour of ibt files)

Could you explain why you favor them, so we see the issue from another point?

Ziemanskye on 20/6/2005 at 19:37

Mostly I think ibts are just easier and neater, and they definately load quicker once the level size is up.
The file size thing doesn't bother me much though, because I'm not on dialup. And if possible I don't want to have to rely on a loader to play these, so drag-and-drop zipped ibts are easier for me. Stupid maybe, but it's been a long time since I tried to pretend I wasn't arrogant and hypicritical.

That and I'm not entirely convinced that sending the gmp and resources (even just the custom ones) will always work or be a smaller download. Consider it simple arrogance - all I need is someone to convince me the alternatives are better, but until then I'll stick with my answer.

I'll shut up now, and let people get on with the science bit. I'll just keep making missions, someone else can argue the distribution, and I'll play by what people want.

New Horizon on 20/6/2005 at 22:42

Quote Posted by Ziemanskye

It's not just a matter of filesize, it's also a matter of waste and repetition. T3Editing doesn't seem to have been thought out beyond the commercial product by ION.

Quote:

That and I'm not entirely convinced that sending the gmp and resources (even just the custom ones) will always work or be a smaller download. Consider it simple arrogance - all I need is someone to convince me the alternatives are better, but until then I'll stick with my answer.

They will definately be smaller. IBT files package ALL the content used in a level....original and custom. That means downloading the same models, textures, sounds, and scripts, over and over again. Considering our FM's are going to have the capability of being, at the very least, twice the size of a TDS ibt, I think the outcome is pretty clear. :) They work for a commercial release but they're really not important for FM releases.

As for loading times, I think within another year and a half we'll probably see those drop as our systems get faster again and we probably won't start seeing FM's that push the engine to its full potential until then.

Shadowspawn on 21/6/2005 at 03:15

I've been dumping and analyzing some IBT files. This doesn't look too hard to figure out. I could be in trouble if the engine expects content to be at given indexes, but if it actually searches for it or checks for named objects, we should be able to create a "compiler" which would only need the custom content and pointers / names of the objects.

I'll keep looking into this and see what's possible. We can decide once we know what we can and cannot do.

Komag on 21/6/2005 at 04:13

Sounds good. Looks like at this point we just need a bit more info, and then we see if this plan is not just possible, but very very easy for the end user. I'm all for this plan, but in end I would say ease of use is more important than efficient downloading. If we can have both, great, but if it's going to be cumbersome and possibly confusing, let's just go with bulky ibts :thumb:

potterr on 21/6/2005 at 06:50

One thing is for sure though, a basic requirement is to use the exes from the editor to run the FM's otherwise custom objectives do not show. Possibly other things would not work correctly either using the original ones.

Durinda D'Bry on 21/6/2005 at 10:05

Shadowspawn Good news that somebody starts with IBT! I would join you but I'm still very busy and even haven't got access to TDS installation :( Probably I'll have more time in July.

I could be in trouble if the engine expects content to be at given indexes - I'm sure it doesn't. For example, GMP file is unchanged when IBT is created. I think only resource type and name is lookup criterion.

Ziemanskye on 21/6/2005 at 10:47

I know I said I'd shut up on this thread, but it's just occured to me this is relevant:

I had a broken ibt I sent a friend to try - any missing resources it can't find in the ibt, which I assume the gmp tells the game that it needs, it can find in DynamicallyLoaded subfolders of the content.
Since most of the folders don't have DynamicallyLoaded subfolders the FM loader or whatever can just swap it in and out as a whole folder. I'm not sure if it can find things in the normal folders or if it's just the DLs, because he uses a normal+edT3+edT3Main to run and so doesn't have the rest of the editor.
It does however mean that on some level you should be able to strip all of the regular content out of an ibt file (though I'd still say keep it for the TriggerScripts - but by that stage it should be pretty small again)

You maybe already knew that, but I've (had that) tested.