Working on Hl2Parse: Learning Git, working with Preon

December 8th, 2010 Comments off

Working on Hl2Parse this week. I want to release it at some point, but I don’t really want to stick with my own hodgepodge of code for reading binary files. Sure, it works, it’s customizable, but I still think something could be better. Preon caught my eye a while back, and I’m going to try to rewrite my code to use it.

As a bonus, this offers me an opportunity to experiment with Git, which I’ve been meaning to learn for a while after being used to Subversion. It also offers some interesting possibilities when it comes to synchronizing work I might do on different computers.

Once I get existing binary file functionality (BSP, MDL, PHY, Clientregistry.blob, etc.) translated into Preon annotations, I can see about adding more detail to the MDLs and parsing PCF dependencies.

Tags: , ,

Friendly Enums in Java with JNA

November 30th, 2010 2 comments

Well, it's a slow week so I think I might as well share some old code to apologize for not making new code. In jHllib, which allows Java programs to inter-operate with a certain C/C++ DLL, I found myself needing to refer to certain integer values that were defined in C. All the documentation and examples for JNA (the Java< ->native bridging platform) tell you to use non-type-safe integer constants in your program, but this just didn't sit well with me.

After some experimentation, I found a way around to use Java's type-safe enums with JNA. First I'll show you what the final product looks like, and then look at the guts that make it possible.

Read more...
Tags: ,

Crunch Time: Google AI contest

November 26th, 2010 Comments off

Sorry for the lack of updates: I’m working in last-minute-scramble mode for the University of Waterloo’s AI contest. (Marketed as “Google” since they have some sort of sponsorship going on.)

After it’s done I may do a bit of a postmortem on it.

Edit: Wasted a bunch of time on the JfuzzyLogic library from Sourceforge… unfortunately the author has completely intermixed the “demo display” logic and the “to/from file representation” logic with the actual math, so it’s a big ball of mud with lots of dependencies that I’d rather not use.

Tags:

Minecraft monster spawning ideas

November 7th, 2010 2 comments

With the recent 2010 Halloween update to Minecraft, players are complaining about some of the changes to monster-spawning code which causes them to appear in otherwise-safe areas. After kicking some ideas around, I figured they might be worth a blog-post or two.

I’d like to present three ideas that should make the lighting-based monsters spawning system more viable. While it may seem to make players safer in their bases, it actually means that the game can place a greater emphasis on spawning lots of monsters because it reduces the chance of “weird” or “unfair” monster appearances.

Suggestion 1: Bright ceilings also deter monster spawns.

The order in which cells are checked before spawning a creeper

Currently, monsters will spawn based on the brightness of the bottommost “floor” tiles. While this makes some sense from a technical standpoint, it neglects to consider how players prefer to light their buildings, and leads to cases where an area that seems properly lit can still be vulnerable.

To fix this: When deciding whether to spawn a monster, check any empty-space around the spot and make sure the surroundings (especially upwards) are either “solid” or else are also dark enough.

Blocks checked for light when obstructions are present

On the left you can see that for a 2×1 creeper (side-view) the spawning system checks each of the blocks in the order shown. If a block on the path is “solid”, the checking on that line stops. If any “open” block visited has a light-level that is too high, the creeper cannot spawn.

In conclusion, monsters can–as before–spawn in very small dark places. However, if the area is larger, some of the extra space is checked to make sure it is also dark-enough.

Suggestion 2: Player “scent” trails.

Some people may be familiar with this as “breadcrumbs” from AI terminology. Basically, the player leaves behind a “smell” in the world as they move around. This smell goes a small distance from them, and then hangs around areas they’ve been for a while before fading. A given area will have a smell that depends on how close the player was, and how long ago they were nearby.

Technical details: Each block (or perhaps each “floor” surface) has a special counter. Counters which are above zero will decrease with time (and are zeroed when the chunk is unloaded.) If the player is near a block, that block’s counter cannot be lower than an a certain amount based on how close the player is. This means that the “smell” of a block depends both on how long ago the player was nearby, and how close the player was to to that block before they moved away.

This basic idea provides two very useful possibilities in terms of both making players less-frustrated and also making monsters a slightly bigger challenge:

  1. Most immediately-useful: Monsters can be prevented from spawning anywhere the player has very recently been, even if that place is poorly lit. This prevents annoying (and impossible) cases where you walk around a large room, and then a monster appears on the far side of it behind you as you are leaving through the only door.

  2. It provides a way to make monsters smarter! OK, not very much, but smart enough to actually follow you around small corners. If they can’t directly reach you, they can try to follow the path you took by looking at gradients in the smells.

Suggestion 3: Additive lighting

Currently, Minecraft’s lighting model is not additive.  This means that (compared to the real world) adding more torches doesn’t always make certain areas any brighter than they were before. I’ve made a quick animation to illustrate what I mean by “non-additive”. In the real world, you would expect the area between both torches to become brighter, but it does not.

Click to see an animation showing how light is non-additive in Minecraft

This lighting model is partly responsible for the frustration people are having in deep areas of the world: They place torches in a way which seems correct based on real-world lighting, but it doesn’t really work. Every time you see someone make a 1×1 pillar with torches on all four sides, it’s an example of this mistaken belief. The way the minecraft world currently works,  the ideal way to light things is to avoid grouping any torches together, yet players do this all the time because it’s what we “know” works.

Changing to an additive model (with an upper cap on brightness) would add visual realism and reduce the amount of frustration players will feel when trying to make areas safe.

Tags:

PackBSP 2.0.4 Released

November 6th, 2010 Comments off

Please see the project-page for download links.

This release is primarily small bug-fixes. Unfortunately,
screening out non-used static-prop skins is still not working until I
puzzle out more of the MDL format, sorry.

Changes


  • Feature: Tries to auto-detect the Steam directory from the
    Windows Registry.

  • Fix: Issue where if the same file exists in the game
    directory and in the GCFs, it was being unnecessarily packed, even
    if the file content is identical. Now such “harmless duplicates” are ignored and not
    packed. (This is particularly important for TF2 maps using the old
    Swamp Pack assets became officially adopted.)

  • Fix: Issue where model-skin paths contained an extra slash
    due to how the QC options where written prior to compile.

  • Fix: VMTs legitimately provided in place of SPR files are now
    parsed correctly to find depended-upon materials/textures.

  • Fix: Clientregistry.blob is no longer directly read, but
    instead copied to a temporary file to avoid conflicts with
    concurrent Steam operations. This can still fail if Steam is in the
    middle of updating or downloading game data, but the error message
    should be much clearer now.

  • Fix: Upgraded to use HlLib 2.4.0, fixing an issue where HlLib
    could not extract from GCFs over 4gb in size.

Known issues:


  • Ensure you have re-run the Source SDK and/or any mods you are working with
    before using this program, because Valve occasionally updates their SDK and everything is in a broken-state
    until their software is re-run.
  • “Locked” variations of TF2 control-point hud
    icons (ending in _locked.vmt) are not discovered for
    team_control_point. This is due to hidden behavior of the TF2
    engine, and will require additional work to add “plug-ins”
    that can solve this in an extensible manner.

  • Textures that are needed for custom particles are not
    detected. This will require more work to parse PCF files.

Tags: ,

Source SDK Errors

November 6th, 2010 Comments off

Just a quick public service announcement. If you are using Source SDK tools (or third-party tools that depend on them) and encounter weird errors about invalid return codes and missing DLLs… Always re-run the game you are modding for as well as the Source SDK. It seems Valve puts a lot of their upgrade/update logic into the launchers rather than in Steam’s game updating features.

In my case, bspzip.exe would fail unless I ran it from a very specific starting directory (complaining about missing tier0.dll) and then would still fail because it couldn’t find filesystem_steam.dll in the right place. Re-running TF2 and the Source SDK launcher fixed both problems.

Tags:

Should have a new version of PackBSP soon…

October 28th, 2010 Comments off

PackBSP 2.0.4 will primarily be a bug-fix release. I delayed it a bit (due to other programming projects and obsessions) and I’m going to delay it just a liiiitle bit more.

With the recent TF2 Halloween update, a bug in HlLib (upon which PackBSP relies) has been discovered involving large (>4gb)  GCF files. So I’m going to wait for that to be fixed, update and check that jHlLib works,  and then ship 2.0.4 with the newer libraries.

Update: HlLib 2.4.0 was released today (Tuesday Nov 2nd), but I have to do things like vote and attend certain festivities, so I’m aiming for PackBSP 2.0.4 (and new version of JHlLib) sometime around Friday.

Tags: ,

TF2′s 2010 halloween update: Notes on the Headless Horseless Horsemann

October 28th, 2010 Comments off

With the recent update to TF2, a new map, cp_manor_event, is in rotation. And with it, a new and oddball feature: NPC enemies.

The enemy is the Headless Horseless Horsemann, somtiems abbreviated “HHH”, reputed to be the ghost of Silas Mann from the series’ unfolding backstory. Here are some quick facts I learned from painful experience that I wish I had known several hours ago:

Spawning:

  • The Horsemann will respawn at a random interval between 7 and 9 minutes.
  • He will not appear unless there are at least 10 people (not bots)  present on a server.
  • He appears on whatever control-point BLU currently needs to capture.
  • Instead of spawning during map set-up time, the Horsemann will spawn immediately when set-up ends.

Behavior:

  • The Horsemann chases one person who is designated “IT” (with a  skull-and-crossbones icon above their head.)
  • He will still kill anyone who gets too close into his way as he chases.
  • The person who is “IT” can melee-strike an enemy to transfer the “IT” status (and the attention of the Horsemann) to them instead.
  • The Horsemann will destroy sentries and dispensers to get at his target, and cloaking cannot hide you.
  • When the person who is “IT” dies,  gets too far away, or enters a spawn room, or is otherwise impossible to reach, the Horsemann will re-target to the nearest player.
  • If he can’t find anyone remotely nearby to chase, it travels back to the CP it spawned on.

Qualities:

  • The Horsemann will occasionally go “boo” and inflict the “scared” status effect, much like the ghost of Zephreniah Mann in koth_harvest_event.
  • He only has a melee attack, but if he hits you, you’re going to die unless ubered or using some other invulnerability mechanism.
  • His initial health amount is at least 3000, and can be higher by an additional 200 for each player. (Presumably each player beyond the required 10, but I’m not sure.)
  • He generally runs at scout-speed (400u/s), although clever movement and vertical jumps can help a lot to gain breathing room, since he follows fairly mundane paths through the level and does not jump certain gaps.
  • He is not targeted by sentries of either team.
  • He cannot be stunned with the Sandman, Jarate’d, or doused with Mad Milk.
  • Backstabs appear to do no extra damage than other knife strikes.

Achievements:

  • “Sleepy Hollownd” is easy to get by just doing a lot of damage to the HHH, regardless of how he finally dies.
  • “Gored” appears to be only possible by striking the low-health Horsemann with a melee weapon. You will definitely get it if yours is the final strike that finishes him off, but there are reports you can get it as one of the last few living people to melee him before he dies.
  • By the time the Horsemann displays his “dying” animation, it’s too late, so don’t bother hanging back and only hitting him as he convulses and explodes.
  • Upon getting the “Gored” achievement, you will also get a one-time drop of craftable haunted scrap metal.
  • Since you cannot get the achievement or the haunted-metal twice, if you have already gotten the “Owned” achievement the best thing you can do for your friends is to be “IT” and lure the Horsemann around. At the very least, don’t attack him if you think he might be near death.
Tags:

Still alive…

October 10th, 2010 Comments off

Not many updates recently, sorry.

  • PackBsp 2.0.4 is still on the back-burner.
  • I was pretty sick this week.
  • TF2 had their polycount update, so spent some time checking out what new weapons I could get my hands on.
  • I’m playing Minecraft. Way too much. There’s something very satisfying about swiss-cheesing a mountainside and slowly creating a terraced fortress.

Regarding minecraft, I’ve put it onto a USB stick so I can use it in my laptop as well, and I figured I’d share a quick launcher batch file that forces it to store all Minecraft-related data in the same spot as the launcher to create a “portable minecraft”. You still need to be able to log-in, though.

for %%F in (%0) do set dirname=%%~dpF
set APPDATA=%dirname%
minecraft.exe
cmd minecraft.exe /C
exit
Tags:

Art-pass contest done soon…

September 21st, 2010 Comments off

You know how long-term deadlines somehow sneak up on you? Turns out the TF2 Art-pass contest is ending real soon, so I need to scramble a bit to get a newer version of PackBsp out.

Version 2.0.4 should mainly be bug-fixes and stability improvements: I don’t want to gamble too much on new features if people might be using it to submit final contest entries.

Tags: ,