If everything else fails, bake it in the oven

Three weeks ago, our laptop died. It’s an old Dell Inspiron 1501 we bought in 2007. Typically you’d just get a new one, recover the data from the old one, and be done with it. Thing is, while searching for a possible cause (and remedy), on one of the links Google returned, a bunch of people talked about doing a solder reflow in their ovens. If this sounds strange, just read the following:

http://russell.heistuman.com/2010/04/27/cooking-the-books-or-baking-my-macbook-pro-logic-board/

So the recipe involves removing anything that is not heat resistant (sponges, rubber parts, the battery and so on), leaving the board in question with just the connectors. You then wrap up in aluminum foil the parts of the PCB that holds the more sensitive components, put it on top of a few balls made of the same aluminum foil in a tray, and bake it for 7-8 minutes at 200 degrees Celsius (485 Fahrenheit I think).

Now, the reason why this works (and it worked also for me) is that at 200 degrees the soldering metal becomes liquid again, and fixes the soldering that went bad. This goes for pretty much any PCB with SMD components that tend to heat up – motherboards with the graphics chipset on them, video cards, you name it.

Question is, why does a soldering go bad?

The typical answer is that the graphics chipset heats up a lot, and in case of poor ventilation (like when using the laptop on a soft surface) the temperatures go high enough to break some of the soldering. This is aggravated by the fact that PCBs end up with some mechanical stress in them, so as soon as the solder goes liquid, there’s a good chance that the PCB will try to go back to its original shape – at the expense of the soldered components, which might end up with some terminals loose.

So, there you go … if everything else fails, just stick it in the oven for 8 minutes, at 200 degrees Celsius.

Ib – Play it!

If you haven’t played it, do that:

http://vgboy.dabomstew.com/other/ib.htm

It’s this kind of game that points out to me that gameplay beats graphics. In this case, even with the pixelated sprites the game uses, it still manages to be fun, creepy and a bit addictive.

Image

Everybody labels it as a horror adventure game; I feel it’s actually the other way around: it’s an adventure game with creepy-borderline-horror-ish elements. The core of the game is solving puzzles (and there are some good ones in it), exploring the area and just avoiding enemies, in order to find your way home.

It’s hard to pinpoint what makes the game good; the music is nice and suits the creepy-art-gallery settings the game takes place in, the puzzles are ok-ish to good and the premise of the game is interesting albeit a bit disturbing.

While not being THE reason why I enjoyed this game, I liked that the author didn’t use too many jump scares; one of them in particular is actually required so that Ib can return and obtain the blue rose. So, a very judicious and conservative use of jump scares – thumbs up from me.

I am now tempted to re-play it to get the other endings …

Changing the character model hitbox for AvP2

The purpose of this tutorial is to illustrate how to change the hitbox for a character model in AVP2. This is a must do, especially since some of the animations of the model will take certain parts (like the head, and sometimes half the torso as well) outside of the hitbox, making multiplayer a sometimes frustrating experience.

The following applies the same for all character models: predators, drones, runners, humans and so on.

Open up ModelEdit. Load an existing model (multi player character models are located in <game_folder>\AvP2\Models\Characters\MP), and select (in the options menu) to make visible the user dimensions:

User Dimensions - another name for hitbox

Now, select an animation, and start working. In our example, we chose to alter the “Crouch – move forward – with a pistol” animation (CF_Ps1):

In the “Animation Edit” box, make sure that the active radio button is ‘User Dimensions’. This will allow us to change the size of the hitbox by pressing the six “+” and “-” buttons located just below the radio button. In our case, we’ll increase the size on the Z (forward-backward) and Y (vertical) axes. So, press the second “+” button (for Y) and the third “+” button (for Z) until reaching an acceptable size:

At this point the hitbox looks OK in terms of size. However, the head is still outside it, and so are the character’s arms. We need to translate the animation so that it fits nice in the hitbox. To do that, change the radio button in the “Animation Edit” box from “User Dimensions” to “Translation”:

Now the six “+” and “-” buttons will work differently: they will shift the animation. In our case we need to move it back on the Z axis (press the third “-” button) and lower it down a bit (negative Y, meaning press the second “-” button), until you get something like:

Now, move the animation slider, or press the play button and watch how the animation and hitbox work together. Make some adjustments if needed, but in most cases even the changes made above will be a good enough step forward.

One thing to be remembered about character hitboxes: they are a trade-off. You will not be able to make it small and have all body parts inside it. But if you have the head, torso and at least half the arms and legs then the hitbox will do just fine.

Innocent changes …

You gotta’ love’m.

It’s the kind of mistake you usually make when you’re overconfident. You know, that little edit in the code that is absolutely safe, right? And then the automated build fails because you didn’t bother to compile the code after that tiny change.

Or when you make that change, the code compiles fine. Then when running the app you face weird crashes, bad file formats and whatnot. All because you didn’t bother to test that said change.

So, here’s the story of such a change.

A few days ago I went on reviving an old piece of software called dirpack. I managed to figure out the issue of O_BINARY flag, and I happily compiled the tool. I did another change though that I didn’t bother to test properly. No, I’m not going to tell you what was the mistake, not yet at least.

I moved on with the development for MapTap, knowing that dirpack is compiled and it works (well, it worked when I tested it, but before making that change). So I clicked on the map I wanted to play, saw the .PAK file getting created, sweet! Now to open it with PakExplorer … and dang, the file is not right! The three BSP files were inside a folder called “maps”, and now they are listed at the top level, with a size of -1 KB ….

And then it hit me.

The innocent change I mentioned was changing throughout the code all uses of ‘/’ as path separator to ‘\\’. And you’d expect it to be ok, right? I mean that’s the path separator for Windows, so no harm done, right?

Wrong.

Because we’re not talking about the Windows operating system anymore and how it handles path separators. We’re talking about .PAK files, which is something slightly different. You have to play by the rules imposed by the people who defined how .PAK files work.

And you should always test your code changes. There’s no such thing as an innocent change.

On MapTap – digging up an old piece of software

One of the features that is scheduled for the next version of MapTap (2.3) is the ability to play Opposing Force maps. This is a feature that we thought it was already working, until tests for 2.0 conducted with members from the Steam community pointed out that it wasn’t.

Phillip did a bit of research, called a guy (who knows a guy – just kidding; the person contacted by Phillip was the expert) who knows a bit more about this game, and it seems that Opposing Force is launched basically as a mod for Half-Life. This spells bad news for us, since MapTap would try to launch the proper game with the “-game” parameter, to specify the folder where we unpack the archives installed.

That expert however provided a solution: create .pak files with our contents!

That posed however some challenges. You see, I wanted to delegate this functionality to an external tool – we do this to extract the .7z archives, by the way. Something like calling an exe and specify the folder and the path to the .pak file to be created as command line parameters.

And that’s how the search started for .PAK file tools. It didn’t end well though: most of them were Windows applications, with no support for command line parameters. Don’t get me wrong, they are probably great tools, it’s just none was easy to interface with from MapTap.

Things turned for the better when finding the dirpack utility; apparently it was part of the QUtils package and then integrated with qcc. I already tried my hand with qcc and failed to convince it to produce a .pak file, so I took the bite, got the code for dirpack and started my attempts to compile it.

Let me tell you one thing: changing compiler specifications is bad. I bet that the code could produce executables, if you compiled it with an old enough compiler. But after an hour of hopelessly trying to put together a decent distribution of djgpp to compile it, I gave up on that approach and went on a different route: adapt the code to the current compilers.

My plan was to build it using CodeBlocks (it runs on MinGW), so the changes in the code went for that direction.

After fixing the obvious (renaming functions already available, finding the right headers to substitute some includes), I faced the first issue: ScanDir.

ScanDir is a function that returns the contents of a directory. You can even specify function pointers to do a bit of filtering and ordering. And it’s not provided for MinGW.

A look at the dirpack code however tells that these features were not used: the function was called with NULL for both function pointer parameters. This meant that even a crippled version of ScanDir would do the job, as long as it returns the complete list of files.

So, roll up the sleeves and start coding.

With that done, I was able to get the dirpack.exe compiled. Next step? Start testing. And see it failed.

Indeed, the .PAK file would not be created. Debugging the code, I found that file reading failed: the number of bytes returned by the read() call was not matching the size of the file. After horribly hacking the code, I finally got my first .PAK file. And surprise – surprise, when unpacking it the files were unusable.

Where could this error come from?

It turned out it was caused by the open() call. You see, a good time ago, all files were opened the same, regardless of their contents. There was no distinction made between text files and binary files. But then, as the open() function was ported to various platforms with their compilers, new rules were added to opening a file. Mainly, the O_BINARY flag, that specifies that for the file to be opened, all bytes from 0 to 255 are fair game.

With that flag in place, file operations ran fine. The .PAK files created could be extracted and the extracted content be used. Dirpack.exe rose from it’s ashes. MapTap support for Opposing Force is now possible.

I will release the code changes done for dirpack: who knows, somebody else might want to integrate it in their app.

Portal 2′s Perpetual Testing Initiative versus map sites

One question Shawn (the chief of modinformer.net) asked during the interview he conducted with Phillip and I (available here) was in the line of: “How do you think the Portal 2′s Perpetual Testing Initiative will affect map sites like PlanetPhillip.com?

I was caught off-guard. I didn’t have a proper look at what P2PI (short for Portal 2′s Perpetual Testing Initiative) means. My answer was more on the line of “not too worried, people looking for quality and for a well reviewed map will end up on PlanetPhillip.com eventually”.

Thing is, there is a threat element, low at the moment, but still, present.

You see, P2PPI is the name for the toolkit that Valve released for Portal 2. It makes it very easy to make maps (a good thing) and it makes it very easy to publish them through Steam Workshop.

And it is the Steam Workshop that is the threat, not the toolkit itself. So I opened up the browser, and looked at the list of maps available for Portal 2, looking for well articulate descriptions and, if any, reviews. Guess what: in my quick search (about 10 maps from the top favorites), none had a description longer than 200 words. As for reviews, let’s be serious, the community is more interested in playing rather than reviewing.

To me this is weird. I mean the tools for writing reviews (a darned editor to post a comment) is there, but nobody bothers writing them. This places PlanetPhillip.com in a privileged position, of still being top dog in terms of reviewing custom maps. For people who like to read a review first then decide to play the map, PlanetPhillip.com is still the place to go.

However, there is still a good number of people who just download maps based on just the rating it has, and they will favor the workshop.

Here’s the thing though: I think that those people would have downloaded maps from filefront ot whatever other file sharing site rather than from PlanetPhillip.com

So the threat, as I see it, does not consist in the Steam Workshop stealing visitors from PlanetPhillip.com, but rather in making it more difficult for Phillip to gain more users. There is always the danger that Steam will hire a couple of people to do reviews for those maps, and publish them alongside the original description of the map. Now THAT would spell bad news for Phillip.