RPT file checker idea.

[Synide 0]

yes, .pbo's are essentially like .zip or .rar etc. - you can pretty much put any filetype inside them...

i extract (at least once) every .pbo I've ever downloaded just to check there's nothing suspicious inside them...

and yeah, sometimes I've found very large amounts of 'working' data that people should not have left in their final release pbo's thereby making them alot bigger than necessary... kinda disheartening sometimes...

[Hellop 0]

yes, .pbo's are essentially like .zip or .rar etc. - you can pretty much put any filetype inside them...

i extract (at least once) every .pbo I've ever downloaded just to check there's nothing suspicious inside them...

Part 1.

Well, there's some news.  That explains why BI decided to make Addons downloadable during mission join.  

*EDIT*: Sorry Yoma. Typo. That should read "why BI decided NOT to make Addons downloadable". Regardless, I guess the question is, why did BI decide not to let addons be downloadable when joining a server? *END EDIT*

Question is, WHY are there executable programs inside an addon?  then, HOW, can you make an .exe inside a .pbo run from Arma?  <-- this feature needs to be eliminated.

Part 2.  Yoma, I still don't understand what you want to do.  I think you want to figure out why you are getting errors in your .rpt.  Do, client .pbos give you errors in your server .rpt?   Can you explain your intentions more?  BTW, you seem like a motivated and capable programmer...

Fill this out please:

1. Problem Identification:   e.g. "Client side .pbos generate hard to track errors."

2. Request for Proposals:  "A way to find out which pbo generates the error"

3. Proposals:

Proposal 1:  ".pbo error/quality ratings"

Proposal 2:  "database of .pbos and MD5s"  -doesn't bisign do this?

Proposal 3: "database of unpacked pbo's to search for error output"  -Shouldn't mission makers do this?

Yoma, I'd like to help.  And before you spend too much time...  If you're talking about making some kind of 100MB online database I think you may be on the wrong track.  We/You need to identify the problems better, and then maybe, we will figure out a suggestion that BI needs to put into Arma2 or a patch....  That will help everyone.

Otherwise, I have access to servers and can host PHP/mysql...

[Yoma 0]

yes, .pbo's are essentially like .zip or .rar etc. - you can pretty much put any filetype inside them...

i extract (at least once) every .pbo I've ever downloaded just to check there's nothing suspicious inside them...

Part 1.

Well, there's some news.  That explains why BI decided to make Addons downloadable during mission join.  Question is, WHY are there executable programs inside an addon?  then, HOW, can you make an .exe inside a .pbo run from Arma?  <-- this feature needs to be eliminated.

Part 2.  Yoma, I still don't understand what you want to do.  I think you want to figure out why you are getting errors in your .rpt.  Do, client .pbos give you errors in your server .rpt?   Can you explain your intentions more?  BTW, you seem like a motivated and capable programmer...

Fill this out please:

1. Problem Identification:   e.g. "Client side .pbos generate hard to track errors."

2. Request for Proposals:  "A way to find out which pbo generates the error"

3. Proposals:

Proposal 1:  ".pbo error/quality ratings"

Proposal 2:  "database of .pbos and MD5s"  -doesn't bisign do this?

Proposal 3: "database of unpacked pbo's to search for error output"  -Shouldn't mission makers do this?

Yoma, I'd like to help.  And before you spend too much time...  If you're talking about making some kind of 100MB online database I think you may be on the wrong track.  We/You need to identify the problems better, and then maybe, we will figure out a suggestion that BI needs to put into Arma2 or a patch....  That will help everyone.

Otherwise, I have access to servers and can host PHP/mysql...

Arma2 will have possibility to download addons on the fly?

If they don't provide this, then maybe i'm not talking about making a 100mb db online, i'm talking about making a 100GB addon repositry online ;-) (it will most likely never happen).

The only reason i would do such a thing is because that could reduce loads on gameservers.

(a lot of people host their addons for download on the same server as the gameserver, something tells me this just can't be good performancewise) What we could do is create a repositry online and have the gameservers host a tiny xmlfile describing the mods they need, after that they can dl em from a repositry server.)

Never mind what i'm doing, i'm just toying around. I can allready see that identifying real problems in arma.rpt is not gonna solve a whole lot of problems.

What my db could do however is "verify" an addon for useless crap inside. Other then that it could later also store classes the addons use and stuff like that. Maybe we could figure out what mods can/cannot be used together.

Again i'm not into addonmaking so i don't know any of the inside details.

[Synide 0]

@Hellop...

Quote[/b] ]Part 1...

I think you got the wrong end of the stick there... sorry, stuff that ArmA doesn't know how to use or doesn't need to use that may inadvertently be left in development folders by Addon makers and then .pbo'd up and distributed is very much in the minority...

I was just confirming to Yoma that technically you can have all sorts of different file types inside a .pbo... doesn't mean it's at all useful within the context of ArmA...

Yoma, do you really need a detailed list of filetypes & their possible formats that ArmA can utilize from within a pbo?

[Yoma 0]

Nah i think my db generated it for me

[Yoma 0]

This little db of mine is getting more and more fun to play with.

In its current state it has data on about 7000 UNIQUE addon files (different MD5), about 25000 (non-unique, gonna fix that) sqs, sqf,cpp files.

The nice thing is you can query it pretty quickly.

Generating the db still takes about an hour (have to extract all) on my pc. Its pretty cool for quickly getting REAL scripting examples.

It currently wheighs in at about 80MB, just for fun i compressed it with winrar and it was only 5MB (maybe synchronizing it with an online db could be possible after all...)

Also a first run takes very long, but a second run only inventorizes what's changed, so that takes just seconds to generate (unless you downloaded a really new 1000mb mod of course) (for now it does need the extracted folders to know you extracted it, i'll fix that too)

It might nog be really usefull in its current state, but it's sure fun to play around with, search for a keyword (e.g. _vehicle lol) and the resulting scripts come up real quick.

Once i get some kind of search gui on it, i'll release it, just for fun: don't expect any miracles from it + a lot of stuff can still go wrong generating the db.