Writing a Pakrat replacement

[Terr]

Hokay. So I'm thinking of redoing the GUI and making it a Back/Continue-style tool. You know, like when you're installing software and it's a series of steps. Does that style sound reasonable to folks?

I may be able to bunch certain steps together into a single "page" in the GUI.

• Page 1
  • Confirm Steam directory.
  • Confirm Source SDK directory.
• Page 2
  • Choose engine (ep1/orangebox)
  • Choose game (draws from the same data the SDK launcher does)
• Page 3
  • Choose map file. (Maybe later it'll remember the last few things you chose.)
  • Confirm output directory
  • Choose logging verbosity
• Page 4
  • Shows scrolling log.
  • Optional button to save log data to specified file.
• Page 5
  • GUI table display with buttons to add/edit/remove from packing-list.
  • Optional button to save packing-list for manual use with bspzip
  • Package" button. Goes ahead and does it.
  • Option to re-start at Page 2 or to exit.
  
  

 

[Freyja]

I don't know if its needed. It works pretty well the way it is now.

 

[Terr]

Ah, but I'm being a selfish and un-customer-focused developer...

I need to brush up on my crusty GUI skills, I have features to integrate, bugs to fix, and Guilder to frame for it. I'm swamped.

The GUI stuff is turning out to be a bit more difficult than I had anticipated, I'm having some mismatches between my vision of an MVC system, Swing's capabilities, and Netbeans' design conventions... I've been doing web/web-service stuff for too long.

My ultimate goal is to get this thing to a place where I can feel good about open-sourcing it, but where it's useful for people in other contexts--like CS mapping, or L4D mapping--and it doesn't have the kind of lingering death-spiral Pakrat does.

 

[Terr]

Turns out already-packed files override ones in directories. (Among other headaches.) This lessens a bit of the "added value" PackBSP can offer, but also makes things easier.

So: If you've already packed something into the BSP, PackBSP will just assume it's the right copy and won't replace it. If you packed the wrong thing and are trying to recover... too bad. Go find the copy of the BSP that has nothing packed in it (you did keep a backup copy, right?) and pack-from-scratch.

Is that too draconian or an acceptable stance?

 

[Ravidge]

Turns out already-packed files override ones in directories. (Among other headaches.) This lessens a bit of the "added value" PackBSP can offer, but also makes things easier.

So: If you've already packed something into the BSP, PackBSP will just assume it's the right copy and won't replace it. If you packed the wrong thing and are trying to recover... too bad. Go find the copy of the BSP that has nothing packed in it (you did keep a backup copy, right?) and pack-from-scratch.

Is that too draconian or an acceptable stance?

I see no issue with that. I always keep a backup and IF I really needed a empty bsp I could just recompile it.

 

[A Boojum Snark]

...I don't get it, frankly. If you are writing this search stuff yourself why can't you just not look inside the bsp?

 

[Terr]

...I don't get it, frankly. If you are writing this search stuff yourself why can't you just not look inside the bsp?

One of the guidelines I was trying to follow was this: "Make whatever the tester sees be what everyone sees after it gets packed and released."

Supposing this type of conflict exists, when you're running/noclipping around your candidate priot to release, the already-packed files (in cases of conflict) are the ones that you are seeing. So from that perspective I can't "replace" things inside the BSP because I could actually be altering what you just QA'ed.

Perhaps more pressingly, support for "replacing" an already-packed file is (last I checked) only supported by the "orangebox" edition of bspzip, and neither edition does outright removals. So in order to "clean" a BSP I'd need to write something custom :/

 

[Terr]

I put a blog post about this kind of collision issue with a diagram of the decision tree.

http://technofovea.com/blog/archives/379

 

[A Boojum Snark]

Unfortunately, these materials are cached, so players arriving from another map may have already loaded the normal skins and see nothing different. Only players who started up the game fresh on your map will see the new effects.

Wrong. Embedded content will always be loaded regardless of what the client has done or played beforehand. The only problem is it is not cleared after the fact.

And about your previous reply to my question, I understand now, but I still don't get why you chose to do that. The chances of somebody having compiled a map with custom content, embedded it, then edited their custom stuff, and re-run the map without a recompile before releasing is... extremely low.

 

[Terr]

Huh. Fixed.

The chances of somebody having compiled a map with custom content, embedded it, then edited their custom stuff, and re-run the map

It's unlikely, but since I have to collect all this data anyway I may as well detect it and fail gracefully rather than create "wtf" moments for people down the line.

 

[A Boojum Snark]

But you are really just trading one moment of confusion for another, and the one you are choosing is a rarer occurrence. There is the one I mentioned, and there is the one where someone actually did edit a custom file and wants to re-embed it, but then... your program won't?

 

[Terr]

There is the one I mentioned, and there is the one where someone actually did edit a custom file and wants to re-embed it, but then... your program won't?

On some further testing, it turns out one of my original justifications (limitations of bspzip) has a workaround, so that's the big thing gone.

The smaller problem is that I wanted it to be a WYSIWYG tool: Whatever you see when testing the map is what you get in the end. Altering something on-disk that was already-packed is certainly a possible use-case, but it sort of goes against that.

Barring some sort of "content lock" choose-able option, y'think wanting to re-embed is more likely than accidental re-embedding?

And of course, all this comes on the heels of me doing a rewrite into the opposite direction Development whiplash!

 

[Terr]

This one's a bit less confusing, because it uses the abstraction of the "search paths" a mod uses. "Archive" is a broad term for anything relating to GCFs or which comes with the game for all players.



Under this model, newer changes on the disk will always replace what was inside the BSP before. (Unless you put on something which matches or hides an "archive" (GCF'ed) file, in which case I don't know how it got into the BSP in the first place.)

It should also handle the WVT-patch case.

Not shown: The "entirely missing" case.

 

[A Boojum Snark]

y'think wanting to re-embed is more likely than accidental re-embedding?

Yes. Of course. Both situations require the exact same sequence of things to happen (packbsp > view > files changed > packbsp > release) except for one important thing. In one situation the files are changed on purpose, and in the other they magically change by themselves through some means unintended by the user. Computers don't just do stuff by their own will, so I believe that would be a much rarer situation.

(and for the record, I have often rembedded content, because I did whatever incorrect and knew what I needed to do to fix it didn't need a recompile)

 

[Terr]

It wouldn't be so much about "recompile" as about "run the packing process again vs. the mapsrc copy of the BSP".

There doesn't seem to be any jargon (and probably doesn't need to be) to distinguish:

• BSP fresh from Hammer (next to .vmf file)
• BSP with packed content
• BSP with cubemaps
• BSP with cubemaps and packed content

 

[A Boojum Snark]

Well see I wasn't even thinking about that. If I'm packing content I don't HAVE a non-packed copy afterward, because I currently use a hand-made bspzip list that is auto-embedded at the end of the compile process before the map gets sent to my tf\maps folder.

However, the mention of recompiling was an anecdote about my own experiences, and has nothing to do with my main point, which was that both issues require the same sequence of events but one is nearly never going to happen because it involves an "accident".

 

[Terr]

Minor progress update on the rewrite...

• Back-end behavior is ~98% complete, from "Confirm your Steam directory" to "Press to package".
• The main chunk of work now is wiring up the front-end GUI wizard panels, and the interface for altering the list of items to insert.
• I still want to do the eye-popping dynamic node graph stuff, but that can be pushed until a later release.
• Workflow will support repeatedly running it in order to tweak packing without having to start all the way over. (Note: Does not support in-place overwriting, and I doubt bspzip does either.)

Unresolved stuff:

• If you didn't already build cubemaps, it will see them and complain about them being missing required files. Shouldn't be a big deal to suppress those warnings. I'm going to assume "Don't forget to build cubemaps!" is something people don't want the app nagging them about.

 

[Terr]

Question to potential users:

If you manually choose to insert/replace a VMT / MDL file, should it automatically inspect at that file and try to add the associated VTF / PHY / etc. file? ... Or at that point, are you probably going: "God damnit stop getting in my way and just do exactly what I say"?

 

[Prestige]

don't look now, but you have 1337 posts on interlopers. DONT POST EVER AGAIN!

 

[Terr]

Goddamnit, if I only had 1336 I could make a post about it... I wonder if deleting a post...

But srsly, it's just a rank, not a count