Topic: Exercise with oof files

[Thomas]

To know and understand what a lot of the mods components are about, it helps to read the story it is based upon.

This mod is very dangerous. It is a rar archive that extracts the files, and it suggests to extract all of them into D3's main folder. It further suggests that if you'd like to remove it again you go through 10 000 000 files manually and delete them.

The file TABLE.GAM included in the mod will override your original Descent 3 TABLE.GAM file, and so will others when they create other mods. Very convenient. 

It is like placing a file README.TXT in one of the zips for automatic downloads. Good that the next one with a new README.TXT will wipe out the previous one - very smart. 

I've got to admit that I have no clue how this can be done the right way. I know what Aenn did with Pyromania and BPJustice. He copied the file MAIN.EXE and edited it to point to different folders. That way they don't interfere with the original versions. I'm not really sure if this is a better approach.

[-<WillyP>-]

If you can edit d3.exe to do so, perhaps it could look in a folder with the same name as the mn3 to find customs. So if you made, say xyz.mn3, in the zip you would also include all the custom stuff in a folder called xyz. You could also put screenshots, readme's, etc there too, to keep them associated with the correct mission.

[Thomas]

In the oldest tutorials, that have not been updated, it was not told to put the oof in the mn3, you had to name them after an existing object, then  place them in the main d3 directory. So then they would 'over-rule' that same named file in the main d3 hog.

This is definitely wrong, because these objects take precedance over the ones in the mission files, including Descent 3's original objects. If you extract all objects from Arrilen Po into your main folder amd leave them there, you will always get the Hellion's head as a bright-green and shiny alien.

Dang! Power went out! When it came back on and I opened Firefox, here is my half typed message... Woo Hoo!

Is that an excuse to have your supper earlier? 

[Thomas]

If you can edit d3.exe to do so, perhaps it could look in a folder with the same name as the mn3 to find customs. So if you made, say xyz.mn3, in the zip you would also include all the custom stuff in a folder called xyz. You could also put screenshots, readme's, etc there too, to keep them associated with the correct mission.

That'd probably work, but why would you want to do that?
The custom stuff goes in the mn3 file. This works in SP.

It also works in MP for everything apart from object files (oof). This is obviously a bug in Descent 3. If the objects cannot be found in the main folder, the game (-> the server) crashes at some point.

[-<WillyP>-]

In the oldest tutorials, that have not been updated, it was not told to put the oof in the mn3, you had to name them after an existing object, then  place them in the main d3 directory. So then they would 'over-rule' that same named file in the main d3 hog.

This is definitely wrong, because these objects take precedance over the ones in the mission files, including Descent 3's original objects. If you extract all objects from Arrilen Po into your main folder amd leave them there, you will always get the Hellion's head as a bright-green and shiny alien.

Dang! Power went out! When it came back on and I opened Firefox, here is my half typed message... Woo Hoo!

Is that an excuse to have your supper earlier?  

No, but I lost my train of thought when the power went out for a while.   They had to turn it off to re-connect people who had had it out since Thursday night. Over a million customers lost power. Some are expected to be out for much longer.

but, yeah, when you were playing a mission, you were supposed to put your custom oof in the main directory, then take it back out when done playing that mission. Those were the early days. But then somebody found out how to make doors and stuff have their own names and pack them into the mn3.

[TechPro]

This mod is very dangerous. It is a rar archive that extracts the files, and it suggests to extract all of them into D3's main folder. It further suggests that if you'd like to remove it again you go through 10 000 000 files manually and delete them.

The file TABLE.GAM included in the mod will override your original Descent 3 TABLE.GAM file, and so will others when they create other mods. Very convenient. 

Please, let's not exaggerate.

Yes, that mod was not at all "clean" in how it did things (you'd already know that was common knowledge for those it was shared with if you bothered to read more of the conversations in that forum  ) and instructions were given on how to easily enable/disable the mod.

Like WillyP said, there were (in earlier days) different methods commonly used than what you seem to be expecting now.

Which brings me to this question ....  Why are you picking apart (criticizing) the hard work of other people that has been willingly shared with you?  We thought you were simply asking about the .oof files people may have and maybe finding out what their purpose was, not picking apart and tearing down what other people have done.  Pardon my frankness, but if that's what you want to do, please do that somewhere else.

[Scyphi]

Ok, I hope I didn't talk to much or too loud and make not too much spelling faults here. If so.., sorry!

No, that's quite all right, cleared up a few things for me, actually. Like I said, I won't profess to be an expert at this, so it's nice for someone to straighten out my presumptions out a bit.

Which brings me to this question ....  Why are you picking apart (criticizing) the hard work of other people that has been willingly shared with you?  We thought you were simply asking about the .oof files people may have and maybe finding out what their purpose was, not picking apart and tearing down what other people have done.  Pardon my frankness, but if that's what you want to do, please do that somewhere else.

I, too, am wondering what Thomas's ulterior motive is to all of this, as it seems clear to me he's seeking something, but hasn't gotten it yet, and is therefore trying to press for it...without being clear on just what it is that he wants to know.

[Foil]

FYI,

Thomas is working on updates/alterations to the D3Server tool which server-ops use.

In many cases, in order to prevent crashes when games cycle, server-ops have to manually pull .oof files out of the mission, and place them in the \Descent3 folder.  I can tell you from experience that this tends to REALLY clutter that folder.

Thomas is working on a solution to that problem in D3Server.

[Thomas]

but, yeah, when you were playing a mission, you were supposed to put your custom oof in the main directory, then take it back out when done playing that mission. Those were the early days. But then somebody found out how to make doors and stuff have their own names and pack them into the mn3.

If it only worked for object and servers too.

For dedicated servers, I think I found a solution as long as no interferring servers are hosted at the same time.

In-game servers will require a wrapper application, similar to StartSP (or maybe even built into StartSP). That's probably not a bad idea. It would save another wrapper application.

[Thomas]

Which brings me to this question ....  Why are you picking apart (criticizing) the hard work of other people that has been willingly shared with you?

You're right, sorry.

The original oof question was regarding a behaviour in the new server tool D3Server3. It extracts objects from mission files into D3's main folder before the server is started and removes them again when it is stopped. This prevents server crashes with custom objects.

Mzero came up with the suggestion for the server tool to automatically remove all object files from the main folder on startup, because they didn't seem to be required for anything. The same could have been done when no server is running anymore, basically to clean-up the system.

I didn't mean to pick on any mod. I'm trying to collect as many as possible to include them in an automatic installer for new (and old) players. Whenever I find something that sounds like it's a nice-to-have I'm trying to investigate whether it could be included in our Descent 3 installer (http://www.dateiliste.com/en/descent-3/26-descent-3-installation-updates-and-modifications/120-download-the-full-version-of-descent-3.html). For that to happen it's vital to know how it is installed best. A file table.gam in Descent 3's main folder is a no-go, unless it can somehow automatically be moved in and out.

Ideally, I'm after a Descent 3 that runs without issues but includes all possible features.

[Thomas]

I, too, am wondering what Thomas's ulterior motive is to all of this, as it seems clear to me he's seeking something, but hasn't gotten it yet, and is therefore trying to press for it...without being clear on just what it is that he wants to know.

My vision is to get 1000 Descent 3 players online at any given time and to have the game installed on every third gaming PC on this planet. 

The question behind all of this is: What can we do to get as close as possible to this target? 

[TechPro]

FYI,

Thomas is working on updates/alterations to the D3Server tool which server-ops use.

... describes the problem ...

Thomas is working on a solution to that problem in D3Server.

The original oof question was regarding a behaviour in the new server tool D3Server3. It extracts objects from mission files into D3's main folder before the server is started and removes them again when it is stopped. This prevents server crashes with custom objects.

... discusses what Thomas is working on ...

Ideally, I'm after a Descent 3 that runs without issues but includes all possible features.

Now it all makes sense to me.  Sounds like a worthwhile project. 

[Scyphi]

Yes indeed, probably would've helped if we knew this sooner, but hey, we aren't going to hold that against ya.

[Thomas]

FYI,

Thomas is working on updates/alterations to the D3Server tool which server-ops use.

... describes the problem ...

Thomas is working on a solution to that problem in D3Server.

The original oof question was regarding a behaviour in the new server tool D3Server3. It extracts objects from mission files into D3's main folder before the server is started and removes them again when it is stopped. This prevents server crashes with custom objects.

... discusses what Thomas is working on ...

Ideally, I'm after a Descent 3 that runs without issues but includes all possible features.

Now it all makes sense to me.  Sounds like a worthwhile project. 

I wonder how you got all these quotes together in one post. I think I got to play with this a bit more at some point.

Worthwile always sounds good.
Unfortunately, it'd be a full-time job to implement everything, and that wouldn't even include bug-fixing. The more I play with the server tool myself the unhappier I am with it, and that although I consider it as being quite a masterpiece. (DE_)Hunter's put a remarkable amount of effort in this software.

[TechPro]

I wonder how you got all these quotes together in one post. I think I got to play with this a bit more at some point.

Trade secret.    I could tell you but then I'd have to shoot you.