Hey guys, any progress on this?
Announcement
Collapse
No announcement yet.
Utility for level information?
Collapse
X
-
It's going to be built into my engine, so it'll be out when my new engine release is out (maybe a week or so). I guess though that it wouldn't be difficult to extract the code for a standalone utility.
Still no acceptable solution for level size so I'm just leaving that out.IT LIVES! http://directq.blogspot.com/
Comment
-
OK, here's most of the items on your list which I believe can be usefully extracted:Code:Map name: Introduction File name: maps/start.bsp Skill Modes: Yes CD Track: 4 Surfaces: 5556 Entities: 385 Models: 55 +------+------+------+------+ | EASY | NORM | HARD | DM | +------+------+------+------+ ambient_drip | 1 | 1 | 1 | 1 | ambient_drone | 4 | 4 | 4 | 4 | +------+------+------+------+ func_bossgate | 1 | 1 | 1 | 1 | func_door | 5 | 5 | 5 | 5 | func_episodegate | 4 | 4 | 4 | 0 | func_wall | 2 | 2 | 2 | 7 | +------+------+------+------+ info_intermission | 4 | 4 | 4 | 4 | info_null | 1 | 1 | 1 | 1 | info_player_coop | 4 | 4 | 4 | 4 | info_player_deathmatch | 2 | 2 | 2 | 6 | info_player_start | 1 | 1 | 1 | 1 | info_player_start2 | 1 | 1 | 1 | 1 | info_teleport_destination | 2 | 2 | 2 | 4 | +------+------+------+------+ item_armor2 | 0 | 0 | 0 | 1 | item_armorInv | 0 | 0 | 0 | 1 | item_artifact_super_damage | 0 | 0 | 0 | 1 | item_cells | 0 | 0 | 0 | 3 | item_health | 0 | 0 | 0 | 4 | item_rockets | 0 | 0 | 0 | 4 | item_shells | 0 | 0 | 0 | 2 | item_spikes | 0 | 0 | 0 | 3 | +------+------+------+------+ light | 224 | 224 | 224 | 224 | light_flame_large_yellow | 10 | 10 | 10 | 10 | light_fluoro | 1 | 1 | 1 | 1 | light_fluorospark | 1 | 1 | 1 | 1 | light_torch_small_walltorch | 31 | 31 | 31 | 31 | +------+------+------+------+ misc_fireball | 3 | 3 | 3 | 3 | +------+------+------+------+ monster_zombie | 9 | 9 | 9 | 8 | +------+------+------+------+ trigger_changelevel | 5 | 5 | 5 | 5 | trigger_multiple | 12 | 12 | 12 | 2 | trigger_onlyregistered | 5 | 5 | 5 | 5 | trigger_setskill | 4 | 4 | 4 | 3 | trigger_teleport | 7 | 7 | 7 | 8 | +------+------+------+------+ weapon_grenadelauncher | 0 | 0 | 0 | 1 | weapon_lightning | 0 | 0 | 0 | 1 | weapon_nailgun | 0 | 0 | 0 | 1 | weapon_rocketlauncher | 0 | 0 | 0 | 1 | weapon_supernailgun | 0 | 0 | 0 | 1 | weapon_supershotgun | 0 | 0 | 0 | 1 | +------+------+------+------+ worldspawn | 1 | 1 | 1 | 1 | +------+------+------+------+ Totals | 345 | 345 | 0 | 711 | +------+------+------+------+
For various reasons I don't believe the others are possible or practical. I'd love to be proven wrong but for now I don't see any way.
Specific examples:
Brushes don't even exist in a BSP file - brushes are cut into BSP surfaces and then discarded so we have no way of getting a count. I've replaced them with a surfaces count.
Anything that depends on an entity name is right out. Nothing in the engine mandates any entity naming convention. A mod author could create an entity classname of "elephant" that functions as a player start position. This covers switches, teleporters, secrets, spawn points, as well as the specific entity types you listed in your original post.
It would be possible (but messy) to get the classname of the spawnpoint that the player entered the map on (assuming that this is run in the engine) but that's useless for the other spawnpoint types.
The entity counts by classname I provide here should give you much the same info, but whether or not it's meaningful depends on the classnames that the mod author has chosen.
New graphics are possible but impractical. We'd need to hard-code a list of all old textures in the engine (or in a hypothetical utility) and even that wouldn't be enough. Quake allows different textures to have the same name, so we'd also need checksums for them all. Furthermore, any graphics that are not stored in the BSP (skins, menu graphics, etc) are flat out impossible to pull info on from the BSP. Not going to be done.
Sounds aren't stored in the BSP at all. A sound classname for certain types is, but the actual sound file name isn't; it comes from QC. Other sounds are associated with types of entity. Even if it was practical we'd have to assume that the BSP info was extracted from a game directory where we could backtrack up the filesystem tree to get the sounds directory, then go through the same checksum nightmare as for new graphics. Also not going to be done.
Whether or not SP or DM modes are available can't be inferred from the counts per mode as the mapper may have just neglected to set spawnflags.
Coop mode depends entirely on the coop spawn point being present, and as the modder could have called that anything we can't assume. Same goes for DM and SP spawn points.
Now, maybe I could test for the well-known names on the assumption that a modder won't actually change them, and display the info if a count is present, but I can never definitively say "no". Anyway the entity counts will give you the same, so it doesn't really seem necessary.
I'm dubious about including skills here as there will nearly always be at least two skills available in an SP map - even if the mapper hasn't set the correct spawnflags. One of those is nightmare, which has different behaviour coming from the QC (you'd need a full-blown QC interpreter and a test suite to determine if the QC contains code to support that, by the way).
Amazing what you find when you turn over stones, isn't it?Last edited by MH; 03-23-2010, 07:38 PM.IT LIVES! http://directq.blogspot.com/
Comment
Comment