PDA

View Full Version : Accessing the .pak files



Ahoggya
August 14th, 2014, 22:19
I've read through the wiki, especially the on about creating a RQ rules set from D20. The only files I find are .pak files in the rulesests folder. I assume the Lua and other files I need are located in these. How do you access them? Or am I looking around the tree trying to find the tree?

Zeus
August 14th, 2014, 23:42
.PAK files are renamed ZIP archives. Try opening one with WinZIP or a similar tool, you should be able to extract the XML/LUA files to a folder.

Ahoggya
August 15th, 2014, 03:51
Thanks Zeus

damned
August 15th, 2014, 04:11
what I strongly suggest you do is expand your source ruleset into a new folder, store this folder elsewhere - eg in My Docs.
do the same with 3.5E or 4E or another CoreRPG ruleset - for example C&C or CoC or ToC. Find one that has elements you want. Stick this stuff in new folder in My Docs.

Create a new folder in \rulesets called \RQ
Copy base.xml into your new folder.
<!-- --> most of it out.
Start with the character sheet \campaign\record_char_main.xml
and start adding the dependancies back in.
This way you end up with as little unneccesary stuf as possible.
Then start looking between your source rulesets and your new one and start building.
If you are not a great coder prepare to be baffled.... but you can get there... but it will take some real patience...

Im going thru this right now and Im getting some great help from some folks here. cscase who did the Trail Of Cthulhu community ruleset sent me this which is worth reading:



The experience you are describing sounds familiar. I won't pretend even for a moment to be very knowledgeable in this area! I really only figured out just enough to do what I wanted to do and there are tons of things I see done in other rulesets that I wouldn't have a clue how to do. But maybe that makes me better qualified to give advice on getting started, as I'm only slightly less confused than you :P With that preamble, here's what I got for you:

1. What you are seeing is normal (at least in my experience).
It's confusing dropping right into the middle of large set of pre-existing code. If you feel overwhelmed and drowning, it's not because you are missing some magical crucial piece of information that programmers have and you don't. An experienced programmer would have the benefit of confidence and experience, but he would still have to go through the confusing stage of trying to figure out what the heck all these pieces do, just like you. So don't despair. Which leads to the next item.

2. The most important thing you can be is persistent.
So, okay, it's going to be confusing and you have to forge ahead for a ways before the fog starts to lift. That means the main key to success is persistence. If you keep at it, it will inexorably come. You will get it if you don't quit first. (Dakadin told me this when I was where you are, and he was right.)

3. The "Find in files" feature: Use it!
Okay, what does persistence look like? Start picking through code looking for things you think might be relevant, and when you find something that looks interesting, bust out your secret weapon: Notepad++ has a feature called "Find in files." (Henceforth dubbed FIF.) You can use it to search for things not just in the file your in, but anywhere in a whole directory, including sub-directories. In other words, you can search the whole ruleset for references to a particular thing. So, if you're not sure which file in a ruleset's hundreds of files has the part you need, search for related terms, variables, function names etc. This is your way to pick up a piece that you think might be relevant and inquire, "Okay, what are you?" If you figure out what it is, put a comment in that explains it to you, so you'll remember, or make a note.

4. The second most important thing you can be is willing to ask for help.
But sometimes you'll get stuck and even FIF is not bringing any clarity to a situation, so instead of asking the code itself, be willing to go to the forums and ask for help. You already know this, but the forums are full of people who are ridiculously helpful. But when you ask, be specific and post code excerpts showing exactly what you are talking about. Define the problem thoroughly. The cool thing about this is that maybe 25% of the time, in the process of describing the problem fully and logically, you'll figure out the answer before you even finish typing your post up.

5. XML objects and scope
This is a little more abstract, but when I started getting my head around this was when some of the fog started to lift for me. When you're looking at an .xml file - which is most of the files in a ruleset - be aware of the fact that you aren't just looking at a long string of linear code. It's not a story that reads from beginning to end. It's not a rambling linear set of instructions to be performed one after another. It is a set of objects. Use Notepad++'s code-folding features (the little collapsing + signs on the left margin) and the scope highlighting (the red highlights on the left that highlight which block of code you're in) to build an awareness of where you are within the file. Keep in mind the fact that for every tag, there will be a closing tag, and everything within those is a single object. Sometimes there might be sub-objects within that, but they're still part of the parent. Thinking about this makes it a LOT less intimidating to approach a file. Try this: When you first open a file, first fold all of the nodes of code (Alt-0), then just crack open the ones you are interested in. Start poking around. This will force you to think about the sections of the file as objects arranged hierarchically, helping you to understand how the pieces work, and it will also hide a lot of irrelevant junk, making it easier to navigate. This is analogous to looking under the hood of a car. You don't look at every nut and bolt and piece; you lump them together into collections: That over there is the brake stuff, here's the power steering pump, here's the tensioner, this is the AC compressor. You group the pieces by function. So, if you're not working on the compressor, you don't need to be worried about all of the individual parts that make it up. You group them together and call them a name and move past them to whatever it is that you are concerned with. FG's XML files are broken out into pieces in the same way, and code-folding helps you to grab hold of that fact and use it. As you get a little further along, this understanding will be BIG.