1. Make a portable version.
On windows this would be equal to making an installer, installing and grabbing all the files from the installed directory. Not sure how it is for linux and mac, but I would expect a portable version for those os to be one folder full of files that would run without downloading anything from the net.
2. Select the destination of the ‘start’ directory.
“C:\Users<your name>\AppData\Local\Panda3D” is a bit obscure location. On windows the de facto standard is “C:\Users<your name>\Documents\My Games<game title>” but I’d also like the option to store the data in the directory that game was installed (so a prc config option would be a good thing).
3. Pack the icon with the exe.
Pdeploy can make an ico file, but it’s only used by the installer to make a ‘start menu’ shortcut. I’m sure the icon can be packed into the exe, there’s a program out there called Resource Hacker that can pack an icon into a exe… but it also breaks a exe generated by pdeploy
4. Include files and directories.
When making a installer I’d like to include some extra files and directories to be installed alongside the game (like a pdf manual, a directory full of models or even another exe ) I’d also like to add custom ‘start menu’ entires for some of them.
5. Control the log.
By default some things are written to the log that I’m not interested in (like loaded models/shaders/fonts/textures or anything with :display:), errors and warnings are still welcome.
I’d also like a timestamp next to each message and a option to write to the end of a log instead of creating a new log each time… or even better an option to point to a file myself (eg. if the log file is too big I can make a new one).
6. Pack the license.
It would be nice if pdeploy could generate a simple text file with the panda3d license and the license of all the third party libs actually used.
7. Respect the prc.
Maybe I’m doing something wrong, but config options like ‘win-size’ or ‘undecorated’ are ignored when loaded from a prc file, I have to use WindowProperties.getDefault()/setDefault() to have a window with those properties in a deployed game.
These are good points. I agree that these would be nice features to have.
is a pretty commonly-requested feature. It’s definitely on my list.
As for 2, this is a fair enough point, but I do want to point out that there’s nothing preventing you from calling chdir in Python at the beginning of your program and writing to a different directory.
I’ve looked into 3. before, though it’s tricky, because it means I’d have to write a Python class to parse and modify the .exe file itself. It’s possible, though, and would be a useful feature to have.
As for 4; such advanced features would bloat the command-line interface, but I’ve been thinking of maybe extending the .pdef file syntax to allow describing the installer format, which would allow for commands that install extra files, etc.
As for the .pdf manual, as of the 1.9.1 runtime (which is up today) you can pack it into the .p3d by specifying the “-x pdf” extension, which will cause pdeploy to extract it to disk instead of packing it into the .exe. No shortcut will be made, though.
You can control all of this by setting variables like “notify-level”, “notify-output” and “notify-timestamp” in a .prc file in the root of your game directory.
As of the latest 1.9.1, you can pack a license file into your .p3d and on the packp3d command-line, mark the extension with the -x flag. This means that it will be extracted to disk when pdeploy turns it into an installer, rather than embedding it into the .exe.
You can control the initial window width and height with these options to pdeploy: -t width=800 -t height=600 — I don’t believe it is possible to make the window undecorated this way, though. But I’m surprised that setting “undecorated” in a .prc file in the root of the .p3d file does not work.
My apologies for reanimating a months-old thread, but I happened upon this while searching for something else.
I don’t know about the “undecorated” setting–I don’t think that I’ve tried it, myself–but I’d like to confirm the issue of a custom prc file being largely ignored, including the “win-size” variable mentioned by Wezu above: as I recall, I’ve experienced similar issues. A previous post of mine on the topic can be found here, I believe.
(Thus far, my only solution has been to set such things manually, after the program has started.)