ElDodgero
3rd June 2008 13:09 UTC

Content, not program installs. Noob. Confused.
Hiya, all.

I'm picking this up because it seems a more practical alternative than writing installers for stuff totally from scratch (which, since I code in Perl, would lead to the annoyance of huge overhead with the whole Perl interpreter and Wx libraries, about 5MB or some crap).

Thing is, while it seems perfectly suited to the installation of software, which is what I imaging 95%+ of people using it would want to do, that's not what I want to do.

I'm trying to build installers for 3D content assets. Basically, see, there's this one company that includes installers for all their content, and everyone else uses ZIP files and tells the users to drag the stuff to their runtime. The thing is, the ZIP approach works fine but looks less pro. The one company that does an installer uses WISE, and their installers have, over the last 5 years, gotten pretty decent. I want to do even better. But since every tut out there seems geared towards software installs rather than content installs, I'm bewildered as to how to go from what's shown to what I need to do, and was hoping someone could point me in the right direction.

Okay, first off, I don't install right into a folder under Program Files. Rather, I install to one of assorted possible locations under program files depending on where the user has their associated program installed. The options I can think of (that I have seen) are:
$PROGRAMFILES\MetaCreations\Poser 4\
$PROGRAMFILES\Curious Labs\Poser4\
$PROGRAMFILES\Curious Labs\Poser Pro Pack\
$PROGRAMFILES\Curious Labs\Poser 4\
$PROGRAMFILES\Curious Labs\Poser 5\
$PROGRAMFILES\Curious Labs\Poser Artist\
$PROGRAMFILES\Curious Labs\Poser 6\
$PROGRAMFILES\Curious Labs\Poser 7\
$PROGRAMFILES\Curious Labs\Poser\
$PROGRAMFILES\DAZ\Studio Alpha\Content\
$PROGRAMFILES\DAZ\Studio Beta\Content\
$PROGRAMFILES\DAZ\Studio\Content\

Any of these and probably things I don't know about could be possibilities. Moreover, Poser got bought recently by Smith Micro, so there'll probably be "$PROGRAMFILES\Smith Micro\Poser 7\" on the way too.

So problem 1 is I need a prompt for where they want it installed and I totally cannot assume any one of these.

Optimally, it would be great if I could actually search their Program Files directory for the existence of poser.exe (DAZ Studio includes a dummy file, so it works in both places) and prompt them with that and a list.

However, that's slow, so I'm thinking this sort of approach is best:
- Install my own registry key upon install that stores the last place they installed to.
- If the key is present, read that and provide it as a radio button option.
- Provide a 'browse to Runtime' browse thingy.
- Provide a 'Search for Runtime' button.

So that's part 1. I don't know how to do this.

Part 2:
Determining what version I'm installing to.
Sometimes this doesnt' much matter. Sometimes the files are all identical. But that's actually rare.

First of all, Between Poser 4 and Poser Pro Pack (which is sort of 4.5, except that 5+ don't do everything PPP did, but do some other things) there was a change in the content library thumbnails used. P4 (and lower, but I don't support lower) used an 'RSR' file, which was basically a bastardised Mac PICT resource (as in the stuff from an old Mac Pre OS X resource fork), stuck in a data file and with some weird (and redundant) format changes. After version 4.2.3 (Pro Pack and beyond), they switched to PNG files instead. While nothing says I can't just drop both an RSR and a PNG in there, it's more professional to install the right thumbnail files, so determining 'Is this Poser 4, or is it higher' is on my list of definite needs, and conditially installing the files based on this, of course.

Aside from that, there was a change to the bumpmap texture files. Poser 4 used 'BUM' files which are a sort of normal map without the blue channel. Poser Pro Pack and up use the same old greyscale height maps that every other 3d app uses. This works out to the same conditional as the above.

Finally, Poser 5 and up use a more complicated materials shader definition format, which includes the old format, of course, but also includes more detail because it has more shader possibilities. However, it's a decent hunk of data, and it would be probably best to not install an extra 10K of data useless to the Poser 4 and Poser Pro Pack users, I think. This isn't always a concern -- things can be made to use the old style and P5+ will read it in without concern and simply make up the extra material details, but it's not always great at it and also it would be nice to have the P5+ stuff explicitly use all the capabilities (like for instance metal and mirrors can actually reflect in P5, in P4 and PPP they cannot and only use fake reflection maps).

Then last but not least some content creators, including the big one, allow users to create derived works, but require that a user cannot use them without owning the original. To make matters worse, they fiddle around with stupid crap like the way they state a copyright line inside a geometry file (they have three versions of one figure that only differ by the word 'copyright' versus '(c)' versus an actual copyright symbol), and then don't tell anyone, so the thing you want to check against might have niggly little differences of a few bytes, which means both checksums and file size comparisons may not work.

The common approach is to use something that encrypts the installer off a checksum of the file and tell the user to use a program for decrypting it (RTEncoder for instance). Obviously every time that they change something, even something as dumb as how they say 'copyright', it means you have to run and provide a whole new encoded file before the wave of "I have the latest V3 and I can't install your file that I just bought!" comes in.

I'd rather just check some basics, like, "Does this have the right number of lines starting with 'v '?" to determine their file has the right number of vertices and move on.

This in itself comes with a few challenges:

1: Check to see the file exists or, if it can't be found, prompt them to browse to the file
2: If it does, in fact, exist, read it in and make sure it has the right number of vertices.

Sure this might be fooled, but it'll be good enough. The only people who'd know exactly how to make a fake file that would work are the same people making content in the first place, so I'm not that concerned. A vertex count is good enough for me and more than their OWN prereq-installers do (which only check filesize).

So... anyone actually read this far? Anyone want to help?

Thanks,

--
Dodger

Animaether
3rd June 2008 13:51 UTC

Woo... I read that far and, as far as I can tell, this can be summarized as:

1.1 How do I present the user with an installation directory page
1.2 that is pre-filled in with a previous installation's location
1.3 read from the registry?

2.1 How do I determine the version of the host application I am installing data / plugin software for
2.2 and install only the appropriate files for that version?

3.1 How can I find a particular file
3.2 Or prompt the user for a particular file
3.3 read that file's contents
3.4 and only install a given file if that file's contents satisfy a particular condition.

Sound about right?

1.1 Is easy.. Include a "Page directory".
http://nsis.sourceforge.net/Docs/Chapter4.html#4.5.4

1.2 and 1.3 Are also easy, and are one step; Use "InstallDirRegKey".
http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.1

2.1 if the Poser executable has version information, try "GetDLLVersion".
http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.3

If it does not, you'll have to get the version from a different reliable source. I'm familiar with the Poser program but haven't used it in years, so I'm afraid I have no idea where else you may find version information. You may wish to check the registry keys for the various versions you're familiar with, including uninstall keys, and see if any of those have version information.

2.2 Then becomes pretty easy as well. You simply check if the version is either "4" or "5" or, etc. and only issue the "File <filespec>" commands for that particular version. If you use LogicLic, this is very easily done as, say...

${If} $0 == "4" ; check the actual version number, of course
  File Poser4File1
  File Poser4File2
  File Poser4File3
${Else}
  File Poser5File1
  File Poser5File2
  File Poser5File3
${EndIf}

ElDodgero
3rd June 2008 14:20 UTC

Wow, thanks!

As stupid as it sounds, it's as relief to be a noob sometimes, like being able to ask stupid questions and get responses. (As a really high end Perl programmer, I have gotten used to posting questions and either never getting any reply, or getting a "wow, good question... no one knows" so a reply that fast brought a smile to my face even at 6:20am! Big thanks!)

I'm going through things step by step... so I'm going to reply step by step as I get questions.

Thus question #1 is:
Seems the regkey thing would work like so:

InstallDirRegKey HKLM Software\XFX\Content PoserRuntime

The thing is, the docs don't say at all that it's stored automagically upon install. Does that mean I have to specifically write that reg key myself, or is it just that the docs skimmed over that bit?

ElDodgero
3rd June 2008 14:33 UTC

Actually, ahead of myself on one thing, I checked Poser.exe for vanilla Poser 4 (which I develop for first, and add fancy P5+ stuff later). Checking properties, it says: 4.0.3.126 as File Version on the Version tab in XP. I assume that means it has version information?

(Question mark means I'm used to Windows enough to not assume it *really* means that...)

If so, I'll cross my fingers that all later versions of Poser do, too. (Poser 7 beta on the Mac does, but it lies and says it's 6, but that's a beta for you.)

However, the dummy poser.exe inside the Content directory of DAZ|Studio (which exists for their older installers to 'find' poser only) has no Version tab or info at all, and is 0 bytes. On the other hand, I think that means I can safely assume that if I get nothing back (how does NSIS script deal with NULL and falsehood anyway?) that it's D|S (or that the person made their own dummy file for manual installation piece by piece).

BTW I wouldn't have guessed to use GetDLLVersion on an EXE, thanks again for that too.

ElDodgero
3rd June 2008 14:38 UTC

BTW "even if you check that the user has the appropriate original content, you yourself are still distributing those derivatives to -everybody-... even if they can't particularly read them (presuming you encrypted)."

DAZ has specifically given permission, provided the derived works cannot be used without the original. Therefore if it's, for instance, a reshape of the mesh, the user has to already have the original mesh. The main thing is if they can't get the derivation out of the installer without the original's presence verified in some way, they've already said to go ahead and do it (and their merchant agreement requires their brokered merchants to agree to their EULA and rules too). Most individual merchants outside of DAZ work the same way. Some have differed (Like Anton Kisiel, if I recall correctly), and in those cases I wouldn't even make a derived work of that sort (technically, even making clothing for a figure is a derived work in a sense, but you'd have to be an insane content creator to restrict against *that* because you'd be taking careful aim at your foot and pulling the trigger).

ElDodgero
3rd June 2008 14:43 UTC

Just answered my own first question... doesn't seem to automagically write the key.

Animaether
3rd June 2008 15:41 UTC

Originally posted by ElDodgeroThe thing is, the docs don't say at all that it's stored automagically upon install. Does that mean I have to specifically write that reg key myself

Originally posted by ElDodgero
Just answered my own first question... doesn't seem to automagically write the key.

Originally posted by ElDodgero Checking properties, it says: 4.0.3.126 as File Version on the Version tab in XP. I assume that means it has version information?

ElDodgero
3rd June 2008 18:21 UTC

I decided to scrap the concept in #2. Rather than complicate the whole thing, I just made it a user-selectable option, with 'Common Files', 'P4 Files' and "Pro Pack/P5+ Files' as seperate whachacallem, Sections. That way the user has full control, since I, as a user, like to have full control (I personally don't like desktop icons for instance, having been weaned in GUIs on old NeXTs back in the day, so clutter on my desktop bugs the crap out of me, and thus I hate it when an installer messes up my pristine fake Mac desktop with rubbish I'd stick in my YzDock if I wanted it up front like that, and thus I take the approach that the user knows what version of Poser they are running and can make the choice in an attempt to propagate polite installerness B^)

(Also it was waaaay easier)

ElDodgero
3rd June 2008 18:29 UTC

And the other thing I learned today is that while the GIMP can save out a .ico file after opening a PNG, attempting to use ImageMagick's otherwise much easier command-line convert program on a PNG saved by Photoshop is futile.

Makes me want to go hop on the VTA train just so I can kick the Adobe building.

(Nice thing about being in San Jose... any drive up the 101 or 280 gives you opportunity to shout obscenities directly at most of the software companies that have annoyed you. Drawback, it's not Redmond. Possible compromise in the near future: yelling at Yahoo by proxy.)

ElDodgero
3rd June 2008 18:56 UTC

Whoah... I think I just found what I need, because it lands in my forte...

http://nsis.sourceforge.net/Perl_plugin

See, what I'm specifically trying to do... I have these figures that use the same basic mesh as DAZ's Victoria 3 and Michael 3 figures. They are identical except that the actual vertex positions are different (if that makes sense). As in, they have the same vertices, but in different positions, but the same polygons and mateirals and groups defined.

The best thing I could do, actually, would be, rather than encrypting for instance, Anna the Aeon Teen Girl off all or part of Victoria 3, would be to only include the actual differences. As in, I include a file of deltas (vertex offsets, rather than absolute positions) and then read in the original figure. Those deltas, once applied to the figure, morph the figure into the shape.

Advantages:
1) I'd not be distributing ANYTHING DAZ owns. ONLY the differences.
2) If the user were to try hacking a fake file with 72,712 vertices together to fake it out, they'd just get a mess.

Moreover, while the Perl plugin dll has to be included in the installer, and that adds 800k to the file, not including any facet information pretty much balances that out. Let me check...

Yeah, more than compensates. While OBJ files compress up pretty nice, still, uncompressed verts versus full-file saves 5.51 megabytes on Victoria 3.

Using RAR Best compression I got a difference of 1.33MB, but I don't know how RAR compares to LZwhatsis. LZMA. I'd imagine they're probably comparable. With the 800K stated, I'd still get a savings of 559.44k-ish by including only vertex deltas (I am of course comparing using absolute vertices, not offset deltas, but then that might just give me more, and of course my internal file format doesn't need things like 'v ' in front, so I need only provide raw data, one vertex offset per line).