Writing a Pakrat replacement

[Vincent]

Im having the same issue J4CK8 is.

 

[Terr]

HL2Parse is now open-source on github. Might do the same with PackBSP after a while, depending on activity.

 

[Terr]

I have a theory about why some people have problems with PackBSP now...

... I think the third-party library that manages the access to the registry (because people got tired of browsing to their their steam folder) might be asploding on 64-bit OSes.

I may look for a replacement tactic, which might also make the instruction list for "How to build this project" smaller when I open-source things.

 

[Wander]

I have a theory about why some people have problems with PackBSP now...

... I think the third-party library that manages the access to the registry (because people got tired of browsing to their their steam folder) might be asploding on 64-bit OSes.

I may look for a replacement tactic, which might also make the instruction list for "How to build this project" smaller when I open-source things.

Ive got a problem with packbsp as well, it never goes past the Loading splash screen (ive waited an hour)
i got the latest version of java, using win7 64bit

Instead of using the registry to find the steam folder, cant you use the %sourcesdk% system thingy?
typing %sourcesdk% in windows explorer makes it go to C:\Program Files (x86)\Steam\steamapps\<username>\sourcesdk

 

[Terr]

i got the latest version of java, using win7 64bit

Yeah, I strongly suspect it is a 64-bit problem, with a third-party DLL is probably spectacularly exploding in silence. (I don't have any 64-bit copies of Windows to test with, alas. )

I think what happened is that when people said it used to work before, they were actually on an older version of the program and didn't mention it

Yesterday I rewrote things to remove that dependency, now I rely on some kludgy command-line running of reg.exe instead.

Instead of using the registry to find the steam folder, cant you use the %sourcesdk% system thingy?

If I recall correctly, no, the environment variable doesn't always get set correctly, and may depend on when you last launched the Source SDK launcher.

 

[tyler]

I use 64 bit Windows 7 and PackBSP works fine. PM me if you want me to test builds or something.

 

[A Boojum Snark]

But isn't it rather unlikely that packbsp would be ran before SDK on a given boot? What registry key are you go after, specifically?

 

[Terr]

I've started to enter bugs and feature-plans here. I'm still cleaning up the build scripts and adding some dev-documentation so others can build and run it.

I use 64 bit Windows 7 and PackBSP works fine. PM me if you want me to test builds or something.

Thanks, although at least for 2.0.5 I don't anticipate anything "new" 64-bit-wise.

But isn't it rather unlikely that packbsp would be ran before SDK on a given boot?

I just have a general feeling of unease in terms of how much I can depend on the environment variables to be set correctly, especially across usages of the SourceSDK launcher and in such a way that they are correctly exported to the system-at-large instead of the same tree of processes. While I do read from some like VPROJECT, it is more for the purposes of providing users useful click-through defaults than the only way to enter the information.

What registry key are you go after, specifically?

Currently I have it reading from: \\HKCU\Software\Valve\Steam\SteamPath

 

[A Boojum Snark]

I'd never suggest having it be the only way, but wouldn't it be easy enough to look for the env-var, and if not found then just ask the user to find a directory? and, as dumb as some people can be, skins/sounds/hud customization is pretty popular, and I think most people should know how to find a game directory. particularly mappers.

Also, forgive me if I'm missing something as it's been ages since I touched packbsp (and only then out of curiosity rather than usage), but what good does SteamPath do you? Isn't everything you need inside the user directory?

 

[Terr]

SteamPath tells me where to find Steam's clientregistry.blob. Sure, I could possibly infer it from %sourcesdk%, but it seems the "right" way to find it is through the windows-registry in this case. Without the information in steam's registry (binary encoded, zipped, and binary coded again, bleh) I can't know what GCFs a given game uses. The GCFs (and path-prefixes inside them, like tf2/ or hl2/) are not necessarily named anything I can otherwise predict, and vary depending on OS, installed language, and other details like the German players-are-robots censorship.

As far as I can determine, PakRat doesn't do any of that, so it cannot tell when "materials/foo/bar.vmt" is something custom, or something in the GCFs. It just assumes that if it's extracted out, it's custom and needs packing, and if it isn't, then it mayyybe is in the GCFs or missing. (Ex: materials/tools/toolstrigger.vmt)

 

[Terr]

Two requests.

First, if someone is having the "silent failure startup", can you try:

• Opening a command-line window
• Going to the directory PackBSP is in
• Running java -jar app/packbsp.jar
• Post any interesting output

Second, if anybody wants something added to the issues page feel free to post it here if you don't want to sign up for a Github account. After I manage to get everything uploaded into a "Project could live even if I get hit by a meteor" state, I'm not quite sure what's the most pressing priority.

 

[Wander]

First, if someone is having the "silent failure startup", can you try:

• Opening a command-line window
• Going to the directory PackBSP is in
• Running java -jar app/packbsp.jar
• Post any interesting output

while freezing during the loading screen:

java -jar app/packbsp.jar
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: ca.beq.util.win32.registry.RegistryKey.testInitialized()V
        at ca.beq.util.win32.registry.RegistryKey.testInitialized(Native Method)
        at ca.beq.util.win32.registry.RegistryKey.initialize(RegistryKey.java:271)
        at com.technofovea.packbsp.PackbspUtil.<clinit>(PackbspUtil.java:27)
        at com.technofovea.packbsp.gui2.PackbspView.initComponents(PackbspView.java:201)
        at com.technofovea.packbsp.gui2.PackbspView.<init>(PackbspView.java:68)
        at com.technofovea.packbsp.gui2.PackbspApplication.startup(PackbspApplication.java:30)
        at org.jdesktop.application.Application$1.run(Application.java:171)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

 

[Terr]

Thanks, that confirms that it's the jRegistryKey DLL exploding in some nasty manner. I've already ditched it in favor of something homegrown, and it will not be an issue in the next release.

I'll see if I can rig something so that that information is available in a logfile next time.

 

[tyler]

When you make the new version stop asking me if I really want to exit. I always want to exit. Stop asking. Holy shit.

 

[Terr]

Damn, if only I saw your post a few hours earlier... Maybe later there'll be a "never ask if I want to exit" option

I've uploaded 2.0.5, so... oh, wait, one moment:

PackBSP 2.0.5 Released

... and the code is now open-sourced on GitHub. It may not have as many still-working unit tests and sensible comments as I'd like, but I think I've now completed my "If I get hit by a meteor" redundancy goal so that however the project dies it won't die the way Pakrat is doing.

 

[tyler]

Damn, if only I saw your post a few hours earlier... Maybe later there'll be a "never ask if I want to exit" option

I just wish I'd remembered to post it weeks ago.

 

[Terr]

PackBSP Issue Tracker

I can add it myself, but if you think you'll have other things to weigh in on you can make an account

 

[Terr]

Now that the code is more-or-less settled when it comes to open-sourcing and 2.0.5...

What does PackBSP need most right now?

For lack of any other requests, I'm planning for basic L4D2 / Alien Swarm support at the moment. (It'll copy necessary files to the addon folder and then you run VPK yourself.)

 

[Boylee]

What does PackBSP need most right now?

Fancy branding.

Seriously though, thanks for keeping this updated, it's a great tool.

 

[Terr]

Blarg. Not much news. Stuff is moving slowly. Not because it is intrinsically difficult, but because I'm not working too hard on it

Currently focusing on rewriting how it understands the idea of "Choose your game" so that it supports a fixed set of "Development Kits", and the code for those finds "Game Engines" and then "Games" all in-turn. I plan to replace the "Pick an Engine" and "Pick A Game" drop-down combo-boxes with a tree-view (basic idea) instead.

By making it a single step, that way I can sanely show things like: "Found the "Episode 1" game engine, but saw no games under it" or "Couldn't read data for this game" with error icons and tool-tips. The user will just need to select a "Game" from the bunch to continue.

Once that new architecture is hammered out and current functionality is restored, I can start to add "L4D2" (in addition to "Source SDK") as a supported DevKit, and running into whatever new and unpredictable issues that entails.

---------------

I'm also considering making a very basic flash "walkthrough" of PackBSP so that people can see it being used without actually downloading it. I suspect I'm not doing enough PR compared to programming.