compressed transfert files...

[bOrIuM]

I talked about it few months ago.. but I'd like to have an autocompressor integrated in the exchange files. Sometimes they weight up to 4mo and can be compressed down to 120ko with winrar or other file compressor. Would be nice if the game does it by itself, producing light .pbm files with no need to compress/decompress manually and to send big big files over email !

[MarshallEllis]

I will be looking at ways to do this past 1.08!

[DCWhitworth]

I guess licencing might be an issue here. There are plenty of 'free' compressors out there but most will want money if a commercial company uses them.

[MarshallEllis]

Yea, but I have written custom compression routines before and if I must bring them into play then I might just do this. Don't get me wrong, I have nothing revolutionary or new and probably not as efficient as ZIP BUT I can do something here if it comes to it BUT I will look around for some public stuff to see what is out there. If anybody knows of anything then let me know...

[DCWhitworth]

I use 7Zip (http://www.7zip.com/) pretty good, free and allows use of batch commands. Distributed under the GNU LGPL but I don't know how this would affect commercial use.

[NeverMan]

ORIGINAL: DCWhitworth

I use 7Zip (http://www.7zip.com/) pretty good, free and allows use of batch commands. Distributed under the GNU LGPL but I don't know how this would affect commercial use.

I've pointed this (7-zip) out before and Jimmer (and I assume Marshall) told me that it was IMPOSSIBLE without support... LOL!!!!

[NeverMan]

ORIGINAL: Marshall Ellis

Yea, but I have written custom compression routines before and if I must bring them into play then I might just do this. Don't get me wrong, I have nothing revolutionary or new and probably not as efficient as ZIP BUT I can do something here if it comes to it BUT I will look around for some public stuff to see what is out there. If anybody knows of anything then let me know...

It's amazing how you totally blow off my posts, yet someone else comes on here and posts the EXACT same thing and all of a sudden they are taken seriously.... freaking amazing!! LOLOL!!!

[NeverMan]

I posted about 7-zip here and was shot down by the all knowing Jimmer (who apparently had a few years experience writing coding scripts, which I guess makes him an expert programmer..... does anyone actually consider scripts real languages?):

tm.asp?m=2197298

[MarshallEllis]

ORIGINAL: NeverMan

ORIGINAL: Marshall Ellis

Yea, but I have written custom compression routines before and if I must bring them into play then I might just do this. Don't get me wrong, I have nothing revolutionary or new and probably not as efficient as ZIP BUT I can do something here if it comes to it BUT I will look around for some public stuff to see what is out there. If anybody knows of anything then let me know...

It's amazing how you totally blow off my posts, yet someone else comes on here and posts the EXACT same thing and all of a sudden they are taken seriously.... freaking amazing!! LOLOL!!!

Now, now, now!
I'm not blowing off your posts! I do remember you orignally bringing this up but I cannot remember if you recommended a product? IF anything it's simply a memory issue with me so don't take it wrong if I run in a few circles!

[DCWhitworth]

ORIGINAL: NeverMan

I posted about 7-zip here and was shot down by the all knowing Jimmer (who apparently had a few years experience writing coding scripts, which I guess makes him an expert programmer..... does anyone actually considering scripts real languages?):

tm.asp?m=2197298

I have to disagree with you. Just re-read the thread and Jimmer makes some perfectly valid points about the idea, points that would have to be considered should it be implemented.

[NeverMan]

ORIGINAL: DCWhitworth

ORIGINAL: NeverMan

I posted about 7-zip here and was shot down by the all knowing Jimmer (who apparently had a few years experience writing coding scripts, which I guess makes him an expert programmer..... does anyone actually considering scripts real languages?):

tm.asp?m=2197298

I have to disagree with you. Just re-read the thread and Jimmer makes some perfectly valid points about the idea, points that would have to be considered should it be implemented.

I have to disagree with you. It's open source.... what more do you want? It's basicall like writing your own code and then using it...except someone else has already done the hard part for you.

There's no reason to re-invent the wheel.

[Jimmer]

ORIGINAL: Marshall Ellis
Now, now, now!
I'm not blowing off your posts! I do remember you orignally bringing this up but I cannot remember if you recommended a product? IF anything it's simply a memory issue with me so don't take it wrong if I run in a few circles!

Yes, he posted a product (the same one, I think). The biggest issue is what he disparagingly mentioned here: A commercial product (EiANW, in this case) cannot use an unsupported product inside of itself (7zip, in this case). If 7zip is ever found to have a serious security hole, and the coders of 7zip could have left for greener pastures, Matrix would then be placed in an extremely precarious position: They would have to either remove the code or write/purchase other code to replace it.

Either one would be unacceptable (to Matrix) in an already-delivered product. The former would require removing a critical feature. The latter would require that Matrix spend money without any possibility of recovering that cost from their customer base.

Note that the problem is SUPPORT, not initial cost. Support ALWAYS costs something. Boiled down to the simplest possibilities, it either costs money (frequently referred to as "maintenance"), or it costs time (internal coder time spent fixing bugs in the external product), or it costs customers (customers who leave because a feature has been removed).

End-users (such as the laughing-out-loud Neverman, for example) do not have this problem except in unusual circumstances. But, companies must factor in either money or risk.

Since Neverman is still laughing despite the original logic I presented, perhaps an example would explain things:

Let's say Microsoft decided that it wasn't making money on Office any more. So, they decide to make it public domain freeware. Naturally, since they would no longer be earning money off of sales of Office, they would not longer support the product.

Now, as a typical consumer, this would be great for me: Office no longer costs anything. I'm not going to think about the future, because I can always download OpenOffice if Office craps out.

But, a business looking at available office productivity suites would be hard-pressed to continue using Office. They may for a while, but eventually they would have to give it up.

Now, go one step further and consider businesses who have used Office as a product vehicle. In other words, the company has created a product using Office inside that product (or as the runtime vehicle, etc), and they sell it. Can THIS company continue to use Office as their vehicle (unsupported)?

Obviously, the answer is no. This last part of the example shows the heart of the problem from Matrix's perspective: Support on vendor-supplied products in saleable products is absolutely mandatory.

[Jimmer]

ORIGINAL: NeverMan
I have to disagree with you. It's open source.... what more do you want? It's basicall like writing your own code and then using it...except someone else has already done the hard part for you.

There's no reason to re-invent the wheel.

Read the license agreement. GNU code (and all other open-source code that I'm aware of) always requires that if you build a derivative work, it also must abide by the GNU license agreement. So, in effect, it's not your code.

The jury is still out on whether a programmer can re-write open-source (GNU-type) code himself and then sell it as part of a product without including the GNU license. There are a number of court cases winding their way through the judicial system now testing this very question (in various venues).

The courts may decide that making code open-source (public domain) makes it also fully released from licensing restrictions as well. The logic behind this would be that there was no purchase, so therefore there is no contract, on the hoped-for principle that contract law cannot be unilateral. But, who knows for sure?

Large companies don't take the risk. If they need the code, they have the programming team use clean-room practices to create the code that does the same thing as the open-source code. Smaller companies usually don't have the resources for this, so they tend to just use the open-source code (as you are proposing). Then, they hope that nobody notices. Or, they are ignorant of what could happen to them should they be caught. But, ignorance of the law is not a valid defense.

[DCWhitworth]

ORIGINAL: NeverMan

ORIGINAL: DCWhitworth

ORIGINAL: NeverMan

I posted about 7-zip here and was shot down by the all knowing Jimmer (who apparently had a few years experience writing coding scripts, which I guess makes him an expert programmer..... does anyone actually considering scripts real languages?):

tm.asp?m=2197298

I have to disagree with you. Just re-read the thread and Jimmer makes some perfectly valid points about the idea, points that would have to be considered should it be implemented.

I have to disagree with you. It's open source.... what more do you want? It's basicall like writing your own code and then using it...except someone else has already done the hard part for you.

There's no reason to re-invent the wheel.

I disagree that writing the software is the hard part, the majority of cost in commercial software is in the support not the development. And it's even worse if you're having to support software you haven't written, probably hasn't been documented and may have been written to uncertain standards (if any)

Open source is only free if you don't value your time.

[NeverMan]

ORIGINAL: DCWhitworth

ORIGINAL: NeverMan

ORIGINAL: DCWhitworth



I have to disagree with you. Just re-read the thread and Jimmer makes some perfectly valid points about the idea, points that would have to be considered should it be implemented.

I have to disagree with you. It's open source.... what more do you want? It's basicall like writing your own code and then using it...except someone else has already done the hard part for you.

There's no reason to re-invent the wheel.

I disagree that writing the software is the hard part, the majority of cost in commercial software is in the support not the development. And it's even worse if you're having to support software you haven't written, probably hasn't been documented and may have been written to uncertain standards (if any)

Open source is only free if you don't value your time.

This might be true for large companies selling software but it is NOT true for Matrix. The hardest part is writing the code, this is so painfully evident. As far as support... it's usually the same person who is writing the code, so they go hand in hand there.

[NeverMan]

ORIGINAL: Jimmer

ORIGINAL: NeverMan
I have to disagree with you. It's open source.... what more do you want? It's basicall like writing your own code and then using it...except someone else has already done the hard part for you.

There's no reason to re-invent the wheel.

Read the license agreement. GNU code (and all other open-source code that I'm aware of) always requires that if you build a derivative work, it also must abide by the GNU license agreement. So, in effect, it's not your code.

The jury is still out on whether a programmer can re-write open-source (GNU-type) code himself and then sell it as part of a product without including the GNU license. There are a number of court cases winding their way through the judicial system now testing this very question (in various venues).

The courts may decide that making code open-source (public domain) makes it also fully released from licensing restrictions as well. The logic behind this would be that there was no purchase, so therefore there is no contract, on the hoped-for principle that contract law cannot be unilateral. But, who knows for sure?

Large companies don't take the risk. If they need the code, they have the programming team use clean-room practices to create the code that does the same thing as the open-source code. Smaller companies usually don't have the resources for this, so they tend to just use the open-source code (as you are proposing). Then, they hope that nobody notices. Or, they are ignorant of what could happen to them should they be caught. But, ignorance of the law is not a valid defense.

The derivative work can be shipped with the GNU license, there's no reason it can't. In fact, there's no reason these two programs (EiANW and the Compressor) can't be shipped as two separate executables, therefore, there's no reason Matrix can't use the open sourced code (GNU license and all) with EiANW and still protect everything that is EiANW.

[NeverMan]

ORIGINAL: Jimmer

ORIGINAL: Marshall Ellis
Now, now, now!
I'm not blowing off your posts! I do remember you orignally bringing this up but I cannot remember if you recommended a product? IF anything it's simply a memory issue with me so don't take it wrong if I run in a few circles!

Yes, he posted a product (the same one, I think). The biggest issue is what he disparagingly mentioned here: A commercial product (EiANW, in this case) cannot use an unsupported product inside of itself (7zip, in this case). If 7zip is ever found to have a serious security hole, and the coders of 7zip could have left for greener pastures, Matrix would then be placed in an extremely precarious position: They would have to either remove the code or write/purchase other code to replace it.

Either one would be unacceptable (to Matrix) in an already-delivered product. The former would require removing a critical feature. The latter would require that Matrix spend money without any possibility of recovering that cost from their customer base.

Note that the problem is SUPPORT, not initial cost. Support ALWAYS costs something. Boiled down to the simplest possibilities, it either costs money (frequently referred to as "maintenance"), or it costs time (internal coder time spent fixing bugs in the external product), or it costs customers (customers who leave because a feature has been removed).

End-users (such as the laughing-out-loud Neverman, for example) do not have this problem except in unusual circumstances. But, companies must factor in either money or risk.

Since Neverman is still laughing despite the original logic I presented, perhaps an example would explain things:

Let's say Microsoft decided that it wasn't making money on Office any more. So, they decide to make it public domain freeware. Naturally, since they would no longer be earning money off of sales of Office, they would not longer support the product.

Now, as a typical consumer, this would be great for me: Office no longer costs anything. I'm not going to think about the future, because I can always download OpenOffice if Office craps out.

But, a business looking at available office productivity suites would be hard-pressed to continue using Office. They may for a while, but eventually they would have to give it up.

Now, go one step further and consider businesses who have used Office as a product vehicle. In other words, the company has created a product using Office inside that product (or as the runtime vehicle, etc), and they sell it. Can THIS company continue to use Office as their vehicle (unsupported)?

Obviously, the answer is no. This last part of the example shows the heart of the problem from Matrix's perspective: Support on vendor-supplied products in saleable products is absolutely mandatory.

AGAIN, why does the code have to go 'inside" the other code??? That's just ABSURD!!

If the zip fails then a pbm file is produced... worse case scenario we are RIGHT back to where we started, worse case scenario.

[NeverMan]

In fact, why can't Matrix just use some script to call the compressor program with the pbm file name?

There are a TON of very reasonable solutions that are very simple, though I know Jimmer always likes to do things the hard way.

[Jimmer]

ORIGINAL: NeverMan
..., though I know Jimmer always likes to do things the hard way.

Nope: The right way. Or, as in this case, one of several right ways.

You are correct, though, in one of your entries above: The term "inside" was a very poor use of the language.

What I meant was having the zip product bundled with the game. If the game is dependent (even to a small degree) upon the zip product, then Matrix has to be careful how they handle it. It is not so trivial as you make it out to be.

[NeverMan]

ORIGINAL: Jimmer

ORIGINAL: NeverMan
..., though I know Jimmer always likes to do things the hard way.

Nope: The right way. Or, as in this case, one of several right ways.

You are correct, though, in one of your entries above: The term "inside" was a very poor use of the language.

What I meant was having the zip product bundled with the game. If the game is dependent (even to a small degree) upon the zip product, then Matrix has to be careful how they handle it. It is not so trivial as you make it out to be.

We can agree to disagree on that matter.

However, the point still stands that a compressor can be used as an "outside" tool while not effecting the game one bit, even if it "breaks". Worst case scenario: the game outputs a .pbm file JUST LIKE IT IS DOING NOW ANYWAYS!!