- November 02, 2024, 22:56
- Welcome, Guest
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
1
Releases / The Inferno Module
« on: April 16, 2012, 22:12 »
DoomRL: Inferno
"A difficult module for DoomRL version 0.9.9.6"
download 0.15.1 (raw)
download 0.15.1 (wad)
Old Versions:
Game Hunter's playthrough video on Youtube
This is a full episode module (~25 levels) with new monsters, new items, new special levels, new random levels, etc.
Graphics mode support is still a work in progress both in Inferno and in DoomRL itself (for mods at least), but if you're willing to put up with graphical issues, it should be playable.
Some of the sounds included copyrighted material used without permission. If that makes you uncomfortable, let me know and I'll make a version without sounds available.
Feedback is very welcome. Praise, criticism, bug-reports, balance suggestions, screenshots, YASDs, YAVPs: bring 'em on!
Have fun!
Version History:
FAQ:
Q: Which version should I download? Raw or wad?
A: They are about the same size, and they install the same way. Raw contains the source code. Wad doesn't work on MacOS. If one doesn't work for you, try the other.
Q: DoomRL crashes when I'm done playing your module. What's going on?
A: If you are running DoomRL in console mode, a bug in DoomRL itself will cause the game to crash when returning to the main menu from any module. This is harmless but annoying. The only known workarounds are to run the game in graphics mode or to set MenuReturn to false in config.lua (which is hardly better).
"A difficult module for DoomRL version 0.9.9.6"
download 0.15.1 (raw)
download 0.15.1 (wad)
Old Versions:
Spoiler (click to show/hide)
Game Hunter's playthrough video on Youtube
This is a full episode module (~25 levels) with new monsters, new items, new special levels, new random levels, etc.
Graphics mode support is still a work in progress both in Inferno and in DoomRL itself (for mods at least), but if you're willing to put up with graphical issues, it should be playable.
Some of the sounds included copyrighted material used without permission. If that makes you uncomfortable, let me know and I'll make a version without sounds available.
Feedback is very welcome. Praise, criticism, bug-reports, balance suggestions, screenshots, YASDs, YAVPs: bring 'em on!
Have fun!
Version History:
Spoiler (click to show/hide)
FAQ:
Q: Which version should I download? Raw or wad?
A: They are about the same size, and they install the same way. Raw contains the source code. Wad doesn't work on MacOS. If one doesn't work for you, try the other.
Q: DoomRL crashes when I'm done playing your module. What's going on?
A: If you are running DoomRL in console mode, a bug in DoomRL itself will cause the game to crash when returning to the main menu from any module. This is harmless but annoying. The only known workarounds are to run the game in graphics mode or to set MenuReturn to false in config.lua (which is hardly better).
2
Bug Reports / [Solved][0.9.9.5] Oh no, arachnotrons kill me on AoOC before I even get to move!
« on: January 08, 2012, 13:48 »
Personally, I think this is hilarious. But I've decided to change this (long-standing) issue not giving the player his customary grace period on the first level of the game. In 0.9.9.6 you'll get to have a couple of actions before getting slaughtered by those arachnotrons.
3
Bug Reports / [0.9.9.4] Ballistic armor assembly doesn't quite have the intended resistances
« on: September 01, 2011, 09:38 »
I am sad to provide the first 0.9.9.4 bug report, but this is a very minor issue.
The ballistic armor assembly is intended to gives +30% to melee resistance, but instead it sets it to 0%. It is intended to set acid resistance to 0%, but it doesn't change acid resistance.
The ballistic armor assembly is intended to gives +30% to melee resistance, but instead it sets it to 0%. It is intended to set acid resistance to 0%, but it doesn't change acid resistance.
4
Requests For Features / Inventory management command API proposal
« on: August 02, 2011, 23:49 »
A recent change to Doom RL is the ability to key-bind custom lua scripts. To stop the possibility of using these scripts to cheat, the modding/engine API is not available. This means new safe APIs have to be created to increase scope of customization options.
Currently, there is only a single function in the inventory management API:
What follows is my proposal to expand the inventory management API.
Item Inspection:
A safe api cannot give players references to actual items, as the items could then be modified. I recommend returning instead a pure-lua table (created on-the-fly for each call) that contains item properties that are visible to the player. The names of the properties are generally the same as the name used by the engine so that modders won't have to relearn anything. Quite possibly even more properties could be added, but for now, I'm just including properties that aren't hidden and would be useful in keybindings. Preferably, these values would be case-insensitive.
The downside of the (obvious) implementation of this is that item reference will become invalid after the inventory
changes. This hurts the ease of persistence.
Global properties (for all items):
STRING id -- The sid of the item. (e.g. "smed" for small med packs. A full list is available on the wiki.)
STRING name -- The displayed name of the item (e.g. "modified pistol").
ITEMTYPE itype -- Indicates whether the item is boots, armor, ranged weapon, etc.
Equipment properties:
TABLE mods -- A table mapping mod numbers to quantities for mods that have been applied to the equipment. (e.g. {A = 2, T = 1})
Ranged weapon properties:
STRING ammoid -- The sid of the ammo item used by the weapon.
INTEGER ammo -- The amount of currently loaded ammo.
INTEGER ammomax -- The magazine size of the weapon.
INTEGER acc -- The accuracy bonus of the weapon.
INTEGER damage_dice -- The X of XdY.
INTEGER damage_sides -- The Y of XdY.
INTEGER blastradius -- The explosion size of the weapon. (0 for non-explosive weapons.)
INTEGER shots -- The number of shots fired in a burst (e.g. the Z of (XdY)xZ)
INTEGER shotcost -- The amount of ammo required to fire each shot. (e.g. 40 for the BFG 9000)
INTEGER reloadtime -- The number of 0.1s intervals needed to reload the weapon. (Not including trait bonuses)
INTEGER usetime -- The number of 0.1s intervals needed to fire the weapon. (Not including trait bonuses)
LOCATION location -- [technical] A special table indicating the item's location in the inventory/equipment so that functions will be able to use the table (e.g. {"inventory", index = 5}).
Armor/boots properties:
INTEGER armor -- The amount of protection the armor provides (at full durability).
INTEGER durability -- The current % durability of the armor.
INTEGER maxdurability -- The maximum % durability of the armor.
INTEGER movemod -- The movement speed bonus/penalty of the armor (in %)
INTEGER knockmod -- The knockback bonus/penalty of the armor (in %)
Ammo properties:
INTEGER ammo -- The amount of ammo in the stack.
INTEGER ammomax -- The maximum amount of ammo that would fit in the stack (ignoring Backpack)
Functions:
Equipment management:
There need to be functions to equip items. These functions should interact nicely with the inspection API.
Functions:
Inventory management:
Besides commands to shuffle equipment, there should be commands to manage the inventory slots.
Example usage:
Remarks:
It is possible some of these commands could be metatabled for simpler access. Any comments and suggestions for this API are welcome, but keep in mind that this proposal is focused on inventory and equipment; interacting with the map is an entirely different monster.
Probably the biggest concern would be the inspection design. Creating tables on the fly isn't efficient, but it is reasonably flexible and very safe. Efficiency shouldn't be too much of a concern, since the player interaction part of the code is pretty non-critical for speed purposes. The bigger concern is persistence; it would be nice to be able to save an item reference and have its properties updated seamlessly by the engine (as would be the case with a read-only reference to the real item). However, the engine's representation of items doesn't store their location (at least in terms of equipment/inventory) which would be a problem (or at least source of confusion) with this alternate possibility. Probably this could be worked around, but it would be a pain.
Currently, there is only a single function in the inventory management API:
Code: [Select]
function command.use_item(STRING item_id) -> BOOLEAN
-- Searches the inventory for an item with the given id.
-- If the item is found, it is used and the function returns true.
-- Otherwise, the function returns false.
What follows is my proposal to expand the inventory management API.
Item Inspection:
A safe api cannot give players references to actual items, as the items could then be modified. I recommend returning instead a pure-lua table (created on-the-fly for each call) that contains item properties that are visible to the player. The names of the properties are generally the same as the name used by the engine so that modders won't have to relearn anything. Quite possibly even more properties could be added, but for now, I'm just including properties that aren't hidden and would be useful in keybindings. Preferably, these values would be case-insensitive.
The downside of the (obvious) implementation of this is that item reference will become invalid after the inventory
changes. This hurts the ease of persistence.
Global properties (for all items):
STRING id -- The sid of the item. (e.g. "smed" for small med packs. A full list is available on the wiki.)
STRING name -- The displayed name of the item (e.g. "modified pistol").
ITEMTYPE itype -- Indicates whether the item is boots, armor, ranged weapon, etc.
Equipment properties:
TABLE mods -- A table mapping mod numbers to quantities for mods that have been applied to the equipment. (e.g. {A = 2, T = 1})
Ranged weapon properties:
STRING ammoid -- The sid of the ammo item used by the weapon.
INTEGER ammo -- The amount of currently loaded ammo.
INTEGER ammomax -- The magazine size of the weapon.
INTEGER acc -- The accuracy bonus of the weapon.
INTEGER damage_dice -- The X of XdY.
INTEGER damage_sides -- The Y of XdY.
INTEGER blastradius -- The explosion size of the weapon. (0 for non-explosive weapons.)
INTEGER shots -- The number of shots fired in a burst (e.g. the Z of (XdY)xZ)
INTEGER shotcost -- The amount of ammo required to fire each shot. (e.g. 40 for the BFG 9000)
INTEGER reloadtime -- The number of 0.1s intervals needed to reload the weapon. (Not including trait bonuses)
INTEGER usetime -- The number of 0.1s intervals needed to fire the weapon. (Not including trait bonuses)
LOCATION location -- [technical] A special table indicating the item's location in the inventory/equipment so that functions will be able to use the table (e.g. {"inventory", index = 5}).
Armor/boots properties:
INTEGER armor -- The amount of protection the armor provides (at full durability).
INTEGER durability -- The current % durability of the armor.
INTEGER maxdurability -- The maximum % durability of the armor.
INTEGER movemod -- The movement speed bonus/penalty of the armor (in %)
INTEGER knockmod -- The knockback bonus/penalty of the armor (in %)
Ammo properties:
INTEGER ammo -- The amount of ammo in the stack.
INTEGER ammomax -- The maximum amount of ammo that would fit in the stack (ignoring Backpack)
Functions:
Code: [Select]
command.get_weapon() -> ITEM
-- Returns the player's currently equipped weapon (or nil if none is equipped).
command.get_prepared() -> ITEM
-- Returns the player's prepared item.
command.get_armor() -> ITEM
-- Returns the player's equipped armor.
command.get_boots() -> ITEM
-- Returns the player's equipped boots.
command.get_slot(EQUIP_SLOT slot) -> ITEM
-- Returns one of the player's equipped items depending on the given slot constant.
command.get_inv_item(INTEGER index) -> ITEM
-- Returns the item at the given index in the player's inventory (or nil if the slot is empty).
command.get_inv_item(STRING sid) -> ITEM, ...
-- Returns all the items in the player's inventory with the given sid (or nil if no such items exists).
command.get_inv_size() -> INTEGER
-- Returns the player's maximum inventory size (which can be different in AoLT).
command.inventory() -> ITERATOR of ITEM
-- Returns an iterator over the player's inventory items.
command.inv_is_full() -> BOOLEAN
-- Returns whether the player's inventory is full.
command.count_ammo(STRING sid) -> INTEGER
-- Counts the total amount of ammo of the given type in the player's inventory. Doesn't count ammo that
-- is loaded into weapons.
Equipment management:
There need to be functions to equip items. These functions should interact nicely with the inspection API.
Functions:
Code: [Select]
command.equip(ITEM item, EQUIP_SLOT slot) -> BOOLEAN
-- Equips the given item in the given equipment slot.
-- Slot is optional; if omitted, the default slot for the item is used.
-- The return value is true if the item can be successfully equipped in the slot.
-- An INTEGER or STRING can be used instead of ITEM. In this case, the equipped item
-- will correspond to command.get_inv_item.
command.unequip(EQIUP_SLOT slot) -> BOOLEAN
-- Unequips the item in the given slot and returns true.
-- If the slot was empty or the inventory was full or the item was cursed, returns false.
command.swap()
-- Quickswaps the player's weapon and prepared slots.
Inventory management:
Besides commands to shuffle equipment, there should be commands to manage the inventory slots.
Code: [Select]
command.use_item(ITEM item) -> BOOLEAN
-- Uses the given item; returns true whenever the item could be found and used.
-- An INTEGER or STRING can be used instead of ITEM. In this case, the used item will
-- correspond to command.get_inv_item.
-- (This means that the new version is backwards-compatible.)
-- (Given nil, this will open the use menu.)
command.drop(ITEM item) -> BOOLEAN
-- Drops the given item; returns true if the item can be found and dropped.
-- As command.use_item, an INTEGER or STRING can be used for item.
-- (Given nil, this will open the drop menu.)
command.unload(ITEM item) -> BOOLEAN
-- Unloads the given item; returns true if the item can be found and unloaded.
-- As command.use_item, an INTEGER or STRING can be used for item.
-- (Given nil, this will open the unload menu.)
Example usage:
Code: [Select]
-- This keybinding function equips a green armor from the inventory.
function()
if not command.equip("garmor") then
ui.msg("You don't have any green armor!")
end
end
-- This keybinding function equips the armor with highest protection.
function()
local function calculate_protection(item)
local protection = item.armor
if protection == 0 then
return 0
end
if item.durability == 0 then
return 0
end
if item.durability <= 25 then
protection = math.floor(protection / 4)
elseif item.durability <= 49 then
protection = math.floor(protection / 2)
end
return math.max(1, protection)
end
local best_armor = nil
local best_protection = 0
local current_armor = command.get_armor()
if current_armor then
best_protection = calculate_protection(current_armor)
end
for item in command.inventory() do
if item.itype == ITEMTYPE_ARMOR then
local protection = calculate_protection(item)
if protection > best_protection then
best_armor = item
best_protection = protection
end
end
end
if best_armor then
if not command.equip(best_armor) then
ui.msg("You can't equip your most protective armor!")
end
else
ui.msg("You are already wearing your most protective armor!")
end
end
-- This keybinding function will equip a loaded shotgun from the inventory/prepared slot.
-- (It is designed to help players who use several shotguns to bypass reload time before
-- finding a combat shotty.)
function()
local weapon = command.get_weapon()
if weapon and weapon.sid == "shotgun" and weapon.ammo == 1 then
ui.msg("You are already wielding a loaded shotgun!")
return
end
local prepared = command.get_prepared()
if prepared and prepared.sid == "shotgun" and prepared.ammo == 1 then
command.swap()
return
end
for item in command.inventory() do
if item.sid == "shotgun" and item.ammo == 1 then
command.equip(item)
return
end
end
ui.msg("You don't have any loaded shotguns!")
end
-- As a sister to the above function, this command function will help reload all the shotguns
-- after firing. (Just keep using it until nothing happens.)
function()
local weapon = command.get_weapon()
if weapon and weapon.sid == "shotgun" and weapon.ammo == 0 then
command.reload()
return
end
local prepared = command.get_prepared()
if prepared and prepared.sid == "shotgun" and prepared.ammo == 0 then
command.swap()
return
end
for item in command.inventory() do
if item.sid == "shotgun" and item.ammo == 0 then
command.equip(item)
return
end
end
ui.msg("All of your shotguns are loaded and ready for action!")
end
-- This command is designed to swap in/out ammopacks for the currently equipped weapon.
-- (Ammopacks are a new feature that is currently in beta.)
-- Swapping them out is a bit imperfect, as the command may not swap back in the exact same
-- weapon that was previously prepared if two weapons have the same sid.
do
local last_prepared_sid = nil
function()
local weapon = command.get_weapon()
if not weapon then
ui.msg("You don't have a weapon equipped!")
return
end
local prepared = command.get_prepared()
if prepared and prepared.itype == ITEMTYPE_AMMOPACK and prepared.ammoid == weapon.ammoid then
-- The appropriate ammo pack is already equipped ... swap it out!
if last_prepared_sid then
command.equip(last_prepared_sid, SLOT_PREPARED)
else
if not command.unequip(SLOT_PREPARED) then
ui.msg("You don't have enough inventory space to unequip your ammo pack!")
end
end
else
if prepared then
last_prepared_sid = prepared.sid
end
command.equip("p" .. weapon.ammoid)
end
end
end
Remarks:
It is possible some of these commands could be metatabled for simpler access. Any comments and suggestions for this API are welcome, but keep in mind that this proposal is focused on inventory and equipment; interacting with the map is an entirely different monster.
Probably the biggest concern would be the inspection design. Creating tables on the fly isn't efficient, but it is reasonably flexible and very safe. Efficiency shouldn't be too much of a concern, since the player interaction part of the code is pretty non-critical for speed purposes. The bigger concern is persistence; it would be nice to be able to save an item reference and have its properties updated seamlessly by the engine (as would be the case with a read-only reference to the real item). However, the engine's representation of items doesn't store their location (at least in terms of equipment/inventory) which would be a problem (or at least source of confusion) with this alternate possibility. Probably this could be worked around, but it would be a pain.
5
Bug Reports / [0.9.9.3] Nightmare speed bonus doesn't work
« on: July 29, 2011, 19:19 »
On Nightmare, enemies are supposed to be faster.
The difference in speed is that all beings (including the player) have only 90% of their usual speed rating. The effect of this is pretty much nothing (other than nuking Game Hunter's full win chances :P).
Of course, I can imagine that with all the hubbub about Nightmare being too hard that it may be good not to implement any speed increase at this point.
The difference in speed is that all beings (including the player) have only 90% of their usual speed rating. The effect of this is pretty much nothing (other than nuking Game Hunter's full win chances :P).
Of course, I can imagine that with all the hubbub about Nightmare being too hard that it may be good not to implement any speed increase at this point.
6
Bug Reports / [0.9.9.3] Proposed Aiming/Shotgun Tweaks
« on: July 19, 2011, 03:49 »
Aiming path calculation is open source as a part of FPC Valkyrie. Paths are calculated using the TVisionPath class. Shotgun area-of-effect is calculated using the same algorithm, though multiple rays are cast. I believe there are two minor tweaks that can be made to this class to slightly improve the consistency and usefulness of aiming paths.
Tweak 1:
First, consider a combat shotgun blast. If there are no obstructions, a combat shotgun blast pointed directly right will look like this:
The asymmetry turns out to be relatively easy to fix. Consider lines 388-396 of vvision.pas (from valkyrie version 0.4.5): two checks are made to determine whether shx (or shy) should be positive or negative. In the case of firing into a wall (as above), both checks will succeed. Thus, preference will be given to the second check creating the above asymmetry. To resolve this, I propose that if both checks are successful, then shx (or shy) should be set to zero. As a result, TVisionRay should be completely symmetrical.
In the above comparison, my proposed fix would result in the second shotgun blast being the same as the first shotgun blast, which, although smaller, would be more consistent. This tweak should also reduce the weirdness of the bullet paths that arise when trying to target through walls.
Tweak 2:
Consider a second example: trying to shoot through two doorways (as in Phobos Base Entry). The following path is calculated by the game:
Now, consider the loop in TVisionRay that calculates shx (or shy) (vvision.pas lines 382-397). The loop goes through the entire path, and recalculates shx or shy for each relevant cell. As a result, shx (or shy) is based on the final obstruction.
Recall the example: the game plotted a path through the final obstruction (the second doorway), but ignored the first obstruction (the first doorway). Observe the case if the second obstruction were removed:
I propose that the aiming code should prefer to avoid the first obstacle rather than the last. Generally, neither path will be particularly desirable, but the path avoiding the first obstacle will be slightly more useful, especially when it arises without the player's knowledge as part of tracing out a shotgun blast.
To implement the proposed behavior, the game should break out of the loop immediately after setting shx (or shy) to a non-zero value (respecting the first tweak if it is implemented).
Tweak 1:
First, consider a combat shotgun blast. If there are no obstructions, a combat shotgun blast pointed directly right will look like this:
Code: [Select]
.................
..........******.
....************.
@***************.
....************.
..........******.
.................
This is perfectly fine, but it is not typically observed. Consider now a combat shotgun blast into relatively far-away wall:Code: [Select]
...............#.
..........*****#.
....***********#.
@**************#.
.**************#.
.........******#.
...............#.
Now the area of effect has increased, and it is now asymmetrical. This picture may be more familiar to players, as most Doom RL levels don't have very large open spaces.The asymmetry turns out to be relatively easy to fix. Consider lines 388-396 of vvision.pas (from valkyrie version 0.4.5): two checks are made to determine whether shx (or shy) should be positive or negative. In the case of firing into a wall (as above), both checks will succeed. Thus, preference will be given to the second check creating the above asymmetry. To resolve this, I propose that if both checks are successful, then shx (or shy) should be set to zero. As a result, TVisionRay should be completely symmetrical.
In the above comparison, my proposed fix would result in the second shotgun blast being the same as the first shotgun blast, which, although smaller, would be more consistent. This tweak should also reduce the weirdness of the bullet paths that arise when trying to target through walls.
Tweak 2:
Consider a second example: trying to shoot through two doorways (as in Phobos Base Entry). The following path is calculated by the game:
Code: [Select]
...#######...
...#..****@..
...***.../...
..X#.....#...
...#######...
This path aims immediately into a wall.Now, consider the loop in TVisionRay that calculates shx (or shy) (vvision.pas lines 382-397). The loop goes through the entire path, and recalculates shx or shy for each relevant cell. As a result, shx (or shy) is based on the final obstruction.
Recall the example: the game plotted a path through the final obstruction (the second doorway), but ignored the first obstruction (the first doorway). Observe the case if the second obstruction were removed:
Code: [Select]
...#######...
.........#@..
.......***...
..X****..#...
...#######...
Here, we see that the game is perfectly capable of plotting a path through the first doorway; it simply prefers to plot a path through the second doorway.I propose that the aiming code should prefer to avoid the first obstacle rather than the last. Generally, neither path will be particularly desirable, but the path avoiding the first obstacle will be slightly more useful, especially when it arises without the player's knowledge as part of tracing out a shotgun blast.
To implement the proposed behavior, the game should break out of the loop immediately after setting shx (or shy) to a non-zero value (respecting the first tweak if it is implemented).
7
Discussion / player.wad Viewer
« on: July 15, 2011, 11:12 »
player.wad is the file that contains all the stats that you can look via "View Player" in the game menu.
Some of the contents of player.wad can't be viewed in game. Notably:
* The number of times each enemy has killed you.
* The number of kills you have racked up with each weapon.
So, I present to you playerview.jar (attached), a program designed to display those hidden contents. To use playerview.jar, make sure you have java installed (probably at least 1.6 is needed), then put playerview.jar in your DoomRL directory and run it.
(There are a few things playerview doesn't show: total played time and maximum reached depth for each game type. These can be added by request, but they didn't seem worth the trouble of finding a nice way to show them.)
Edit: Updated for 0.9.9.6
Some of the contents of player.wad can't be viewed in game. Notably:
* The number of times each enemy has killed you.
* The number of kills you have racked up with each weapon.
So, I present to you playerview.jar (attached), a program designed to display those hidden contents. To use playerview.jar, make sure you have java installed (probably at least 1.6 is needed), then put playerview.jar in your DoomRL directory and run it.
(There are a few things playerview doesn't show: total played time and maximum reached depth for each game type. These can be added by request, but they didn't seem worth the trouble of finding a nice way to show them.)
Edit: Updated for 0.9.9.6
8
Bug Reports / [0.9.9.3] Equipment OnRemove hook bug
« on: June 26, 2011, 20:43 »
When armor or boots is destroyed, the OnRemove hook is supposed to be called. In fact, it is called, but the attacking being is passed to the hook instead of the being wearing the armor.
Currently, DoomRL doesn't use this hook very much... I think just for set bonuses. Modders might want it fixed too.
Currently, DoomRL doesn't use this hook very much... I think just for set bonuses. Modders might want it fixed too.
9
Bug Reports / [0.9.9.3] Color ID for cells
« on: June 10, 2011, 20:00 »
Sometimes there are several cells (tiles) that are intended to look alike to the player. The best example is probaly "wall" and "wall2", but also "pwall" (or p versions of anything). By changing color bindings, the player can (intentionally or unintentionally) distinguish between these tiles.
I suggest adding a "color_id" property to cells in the style of levers so that e.g. wall2 will use the color binding for wall.
Modders might also find this useful for e.g. hiding secret doors.
I suggest adding a "color_id" property to cells in the style of levers so that e.g. wall2 will use the color binding for wall.
Modders might also find this useful for e.g. hiding secret doors.
10
Nightmare! / [N!|78%|YAVP] blah nano rocket launcher
« on: June 02, 2011, 06:11 »--------------------------------------------------------------
DoomRL (v.0.9.9.3) roguelike post-mortem character dump
--------------------------------------------------------------
Tim!, level 14 Hell Baron Lt. Colonel, defeated the Cyberdemon
on level 25 of the Phobos base.
He survived 81389 turns and scored 642996 points.
He played for 1 hour, 31 minutes and 31 seconds.
He opposed the Nightmare!
He killed 1097 out of 1405 hellspawn. (78%)
-- Special levels --------------------------------------------
Levels generated : 9
Levels visited : 5
Levels completed : 0
-- Awards ----------------------------------------------------
UAC Star (gold cluster)
Grim Reaper's Badge
UAC Platinum Badge
Reaper Platinum Badge
-- Graveyard -------------------------------------------------
###########################################################
#..........................................................
#..........................................................
#..X.....................................###...............
#........................................###...............
#........................................###...............
#........}|...................................###..........
#.............................................#>#..........
#.............................................###..........
#..........#......###.........###..........................
#........###......###.........###..........................
#........###......###.........###..###..###................
#..................................###..###.....###........
#..................................###..###.....###........
#......###......................................###........
#......###......###........................................
#......###......###........................................
#...............###........................................
#..........................................................
###########################################################
-- Statistics ------------------------------------------------
Health 69/90 Experience 98268/14
ToHit Ranged +4 ToHit Melee +4 ToDmg Ranged +0 ToDmg Melee +0
-- Traits ----------------------------------------------------
Ironman (Level 4)
Finesse (Level 3)
Tough as nails (Level 2)
Eagle Eye (Level 2)
Intuition (Level 2)
Badass (Level 1)
Fin->Fin->TaN->TaN->Bad->Iro->Iro->Iro->EE->EE->Int->Int->Iro->Fin->
-- Equipment -------------------------------------------------
[a] [ Armor ] red armor [2/4] (31%)
[b] [ Weapon ] modified rocket launcher (6d6) [0/1] (N1)
[c] [ Boots ] modified phaseshift boots [4/4] (100%) (A)
[d] [ Prepared ] nuclear BFG 9000 (8d8) [32/40]
-- Inventory -------------------------------------------------
[a] combat shotgun (7d3) [5/5]
[b] rocket launcher (6d6) [1/1]
[c] plasma rifle (1d7)x6 [40/40]
[d] assault shotgun (7d3) [6/6]
[e] Angelic Armor [1/7] (9%)
[f] shotgun shell (x36)
[g] shotgun shell (x50)
[h] shotgun shell (x50)
[i] shotgun shell (x50)
[j] shotgun shell (x50)
[k] shotgun shell (x50)
[l] shotgun shell (x50)
[m] power cell (x50)
[n] power cell (x10)
[o] small med-pack
[p] large med-pack
[q] large med-pack
[r] large med-pack
[s] phase device
[t] phase device
[u] power mod pack
[v] technical mod pack
-- Kills -----------------------------------------------------
134 former humans
98 former sergeants
53 former captains
162 imps
95 demons
157 lost souls
45 cacodemons
48 barons of hell
1 Cyberdemon
48 hell knights
28 arachnotrons
57 former commandos
29 pain elementals
32 arch-viles
64 mancubi
27 revenants
4 nightmare imps
4 nightmare cacodemons
8 nightmare demons
3 bruiser brothers
-- History ---------------------------------------------------
He started his journey on the surface of Phobos.
On level 6 he stormed the Chained Court.
On level 7 he witnessed the Wall.
Not knowing what to do, he left.
On level 10 he entered Hell's Armory.
He left the Armory without drawing too much attention.
On level 12 he found the Nano Pack!
On level 15 he encountered the Phobos Hellgate.
On level 16 he invaded the Unholy Cathedral!
He fled the Unholy Cathedral seeing no chance to win.
On level 22 he ran for his life from lava!
On level 22 he was foolish enough to enter the Mortuary!
On level 22 he found the Angelic Armor!
He managed to clear the Mortuary from evil!
On level 23 he encountered an armed nuke!
Then at last he found Phobos Arena!
On level 25 he finally defeated the Cyberdemon.
-- Messages --------------------------------------------------
Fire -- Choose target...
You see : a Cyberdemon (mortally wounded) [m]ore | pool of blood
The missile hits the Cyberdemon.
Fire -- Choose target...
You see : a Cyberdemon (mortally wounded) [m]ore | pool of blood
The missile hits the Cyberdemon. The Cyberdemon reloads his rocket launcher.
Fire -- Choose target...
You see : a Cyberdemon (almost dead) [m]ore | pool of blood
Fire -- Choose target...
You see : a Cyberdemon (almost dead) [m]ore | pool of blood
The missile hits the Cyberdemon. The Cyberdemon fires! You are hit! Your
red armor is damaged!
Fire -- Choose target...
You see : a Cyberdemon (almost dead) [m]ore | pool of blood
The missile hits the Cyberdemon. The Cyberdemon dies. Congratulations! You
defeated the Cyberdemon! Press <Enter>...
-- General ---------------------------------------------------
Before him 233 brave souls have ventured into Phobos:
196 of those were killed.
3 of those were killed by something unknown.
3 didn't read the thermonuclear bomb manual.
And 8 couldn't handle the stress and committed a stupid suicide.
Some rumours though, say that the Cyberdemon was killed already!
Is he immortal? 23 souls claim to have killed him...
5 sacrificed itself for the good of mankind.
18 killed the bastard and survived.
--------------------------------------------------------------
Hello mortem board. It's been quite some time.
I was going for my normal build when I found a Nano mod... and I had nothing good to put it on. Luckily, I found a rocket launcher on level 14. Everything else was easy including the mortuary (although that took a while). Let's spray rockets everywhere! Yay, nano mod is so good.
Somehow, I forgot to do the Halls of Carnage, so that ruled out going for nanomachic bfg. Probably for the best anyway.
11
Modding / Scrolling demo
« on: May 09, 2011, 18:59 »
tehtmi:play_sound("whistle.innocently")
So, here is a demo of scrolling maps in sandbox. There's a few minor issues, but overall it works quite well I think. As always, feel free to use/abuse this code.
Edit: fixed tearing issue.
Edit: fixed item teleporting bug
So, here is a demo of scrolling maps in sandbox. There's a few minor issues, but overall it works quite well I think. As always, feel free to use/abuse this code.
Edit: fixed tearing issue.
Edit: fixed item teleporting bug
12
Modding / Using Generator
« on: May 03, 2011, 12:16 »
Hi again!
I made this mod that uses the built-in map generation module to make an infinite dungeon (multi-levels inspired by Simon-v's multi-level module, but perhaps less elegant). Also, it is set up to allow you to specify special levels like in real DoomRL. Included is Hell's Arena on level 1. The multi-level bit may be dodgy, but I think the random level stuff should work well (potentially perfectly).
The player placement issue is resolved by replacing Generator.place_player (and a few other problematic doodads) with a more single-level friendly version.
That said, this mod isn't really fun (or it's not any more fun than playing Doom RL on itytd), but it's a proof of concept that anyone is welcome to use for their own devious purposes. Since special levels are included in the sandbox, it would be very easy to make this a very close copy of DoomRL. Hence, we could make our own challenges or new special levels :)
I made this mod that uses the built-in map generation module to make an infinite dungeon (multi-levels inspired by Simon-v's multi-level module, but perhaps less elegant). Also, it is set up to allow you to specify special levels like in real DoomRL. Included is Hell's Arena on level 1. The multi-level bit may be dodgy, but I think the random level stuff should work well (potentially perfectly).
The player placement issue is resolved by replacing Generator.place_player (and a few other problematic doodads) with a more single-level friendly version.
That said, this mod isn't really fun (or it's not any more fun than playing Doom RL on itytd), but it's a proof of concept that anyone is welcome to use for their own devious purposes. Since special levels are included in the sandbox, it would be very easy to make this a very close copy of DoomRL. Hence, we could make our own challenges or new special levels :)
13
Modding / Hellgate remix (0.9.9.3)
« on: May 02, 2011, 07:08 »
I present to you: Hellgate remix.
I recommend that you try to play the mod at least once before looking at the source :)
This was mostly a fun test of custom AI scripts. So, observe the cool things you can do. They're not entirely polished because the API isn't there yet (as far as I know), and they're not entirely robust because I'm lazy, but I thought it was pretty cool anyway.
Edit:
For those of you interested in making custom AIs, one issue I didn't address is that you have to be very careful of self-deaths: if you being dies while in it's AI script, then further reference to self are probably bad. This was happening to me earlier, but it doesn't often happen in the current version.
I recommend that you try to play the mod at least once before looking at the source :)
This was mostly a fun test of custom AI scripts. So, observe the cool things you can do. They're not entirely polished because the API isn't there yet (as far as I know), and they're not entirely robust because I'm lazy, but I thought it was pretty cool anyway.
Edit:
For those of you interested in making custom AIs, one issue I didn't address is that you have to be very careful of self-deaths: if you being dies while in it's AI script, then further reference to self are probably bad. This was happening to me earlier, but it doesn't often happen in the current version.
14
Discussion / Color bindings for fun and profit!
« on: May 01, 2011, 19:16 »
I was messing around with color bindings (in color.lua) to see if I could use them to gain an advantage in the game. In fact, you can, but the advantage is quite small. Anyway, here is my new color bindings file so y'all can see what is possible. Some are more obtrusive than others.
(My favorite: bridge_dark = LIGHTGREY)
Those foreground/background color bindings probably won't work for those of you not using windows.
Other possibilities: changing your favorite uniques and exotics to have special colors so you can recognize them with the automap. And anything else you can think of!
(And kudos to whoever foiled my attempt to distinguish levers using color bindings :P)
Edit: Fixed water color (oops)
(My favorite: bridge_dark = LIGHTGREY)
Code: [Select]
BLACK = 0
BLUE = 1
GREEN = 2
CYAN = 3
RED = 4
MAGENTA = 5
BROWN = 6
LIGHTGRAY = 7
DARKGRAY = 8
LIGHTBLUE = 9
LIGHTGREEN = 10
LIGHTCYAN = 11
LIGHTRED = 12
LIGHTMAGENTA= 13
YELLOW = 14
WHITE = 15
-- overrides color(MAGENTA, BLUE)
WATER = 21
-- overrides color(BROWN, BLUE)
ACID = 22
-- overrides color(LIGHTGRAY, BLUE)
LAVA = 23
-- Calculates the code with foreground color "front" and background color "back"
-- Three don't work (as noted above).
local color = function(front, back)
return front + 16 * (back or 0)
end
Colors = {
-- This thing is too easy to miss!
dshotgun = LIGHTRED,
-- For nostalgia's sake.
chainsaw = RED,
bfg9000 = MAGENTA,
-- This is quite useful and unobtrusive.
bridge_dark = LIGHTGRAY,
-- This a bit cheaty, but it's nice for noticing locked vaults.
-- Note: pwalls are those that cannot be destroyed!
pwall_light = color(LIGHTGRAY, LIGHTGRAY),
pwall_dark = color(DARKGRAY, DARKGRAY),
prwall_light = color(RED, RED),
prwall_dark = color(DARKGRAY, DARKGRAY),
-- These are nice with automaps, or if you like to run around the level.
-- after clearing it without being careful.
acid_light = color(GREEN, GREEN),
lava_light = color(LIGHTRED, LIGHTRED),
acid_dark = ACID,
lava_dark = LAVA,
pacid_light = color(GREEN, GREEN),
pacid_dark = ACID,
plava_light = color(LIGHTRED, LIGHTRED),
plava_dark = LAVA,
-- These are mildly useful for remembering barrel types, or finding them
-- out with automaps.
barrel_light = YELLOW,
barrel_dark = BROWN,
barrela_light = LIGHTGREEN,
barrela_dark = GREEN,
barreln_light = LIGHTRED,
barreln_dark = RED,
-- For automaps/intuition and quick recognition.
-- (To avoid confusion with large health globe.)
bpack = MAGENTA
}
Those foreground/background color bindings probably won't work for those of you not using windows.
Other possibilities: changing your favorite uniques and exotics to have special colors so you can recognize them with the automap. And anything else you can think of!
(And kudos to whoever foiled my attempt to distinguish levers using color bindings :P)
Edit: Fixed water color (oops)
15
Bug Reports / BB Screenshot colors are wrong
« on: February 03, 2010, 15:54 »
This is what a BB screenshot looks like:
BB Screenshot created.
BB Screenshot created.
############### ##### ###### ####################
================== ======= ============================
=================== ====== =============================
==================== ===== =============================
#================... ...= =================....######
#=============....#######..#########.=====..#########...#....#######
#========.........#....%#..#.......#..===...#..|.|..#...#....#.....#
#======...........#.....#..#.....%.#..==....#..|....#...#....#.....# ..=
#====.............###/###.%###/#####..==..%.####/####...###+#####/##....===
#==..........................%.....%....%..%..............................=
#===.......#########/####..######/##..==....####/####...#######/####....===
#====..>...# #..%...#..# .....#..==%...#|}+@|.|#...#..........# ....
#===.......# ../...%.%#..#.......#..==....#|"|"|"|#...#..%%......# .
#====......# ....#......#..#########.====...#########...#..........#
#====......# ### ########... ..======.... ....############
=========.. ...= ============== =.....
=========== ===== ============= ========
======== ===== ============= ========
=== ==== ========== =======
##### ####
Tim! Armor : green armor [1/1] (100%)
Health: 28% Exp: 6/71% Weapon: modified chaingun (1d6)x4 [15/40] (A1)
cautious Hell's Armory
This is what I think it should look like:
BB Screenshot created.
BB Screenshot created.
############### ##### ###### ####################
================== ======= ============================
=================== ====== =============================
==================== ===== =============================
#================... ...= =================....######
#=============....#######..#########.=====..#########...#....#######
#========.........#....%#..#.......#..===...#..|.|..#...#....#.....#
#======...........#.....#..#.....%.#..==....#..|....#...#....#.....# ..=
#====.............###/###.%###/#####..==..%.####/####...###+#####/##....===
#==..........................%.....%....%..%..............................=
#===.......#########/####..######/##..==....####/####...#######/####....===
#====..>...# #..%...#..# .....#..==%...#|}+@|.|#...#..........# ....
#===.......# ../...%.%#..#.......#..==....#|"|"|"|#...#..%%......# .
#====......# ....#......#..#########.====...#########...#..........#
#====......# ### ########... ..======.... ....############
=========.. ...= ============== =.....
=========== ===== ============= ========
======== ===== ============= ========
=== ==== ========== =======
##### ####
Tim! Armor : green armor [1/1] (100%)
Health: 28% Exp: 6/71% Weapon: modified chaingun (1d6)x4 [15/40] (A1)
cautious Hell's Armory
This should be really easy to fix: just change the color tags the game generates. Here is a list that matches the currently used color tags (without [ and ]) with my suggested replacements:
color=#F66->color=red
color=red->color=maroon
color=blue->color=navy
color=#BBB->color=silver
color=#777->color=gray
color=brown->color=olive
color=green==color=green
color=yellow==color=yellow
color=#66F->color=blue
color=#6F6->color=lime
color=#6FF->color=aqua
color=#F66->color=fuchsia (NOTE: #F66 is currently used twice)
color=purple==color=purple
color=#FFF==color=white
Gray, silver and white may be the same, but I would use the named versions for consistency.
Thanks to Malgond for suggesting these colors for the wiki (as justified here).
BB Screenshot created.
BB Screenshot created.
############### ##### ###### ####################
================== ======= ============================
=================== ====== =============================
==================== ===== =============================
#================... ...= =================....######
#=============....#######..#########.=====..#########...#....#######
#========.........#....%#..#.......#..===...#..|.|..#...#....#.....#
#======...........#.....#..#.....%.#..==....#..|....#...#....#.....# ..=
#====.............###/###.%###/#####..==..%.####/####...###+#####/##....===
#==..........................%.....%....%..%..............................=
#===.......#########/####..######/##..==....####/####...#######/####....===
#====..>...# #..%...#..# .....#..==%...#|}+@|.|#...#..........# ....
#===.......# ../...%.%#..#.......#..==....#|"|"|"|#...#..%%......# .
#====......# ....#......#..#########.====...#########...#..........#
#====......# ### ########... ..======.... ....############
=========.. ...= ============== =.....
=========== ===== ============= ========
======== ===== ============= ========
=== ==== ========== =======
##### ####
Tim! Armor : green armor [1/1] (100%)
Health: 28% Exp: 6/71% Weapon: modified chaingun (1d6)x4 [15/40] (A1)
cautious Hell's Armory
This is what I think it should look like:
BB Screenshot created.
BB Screenshot created.
############### ##### ###### ####################
================== ======= ============================
=================== ====== =============================
==================== ===== =============================
#================... ...= =================....######
#=============....#######..#########.=====..#########...#....#######
#========.........#....%#..#.......#..===...#..|.|..#...#....#.....#
#======...........#.....#..#.....%.#..==....#..|....#...#....#.....# ..=
#====.............###/###.%###/#####..==..%.####/####...###+#####/##....===
#==..........................%.....%....%..%..............................=
#===.......#########/####..######/##..==....####/####...#######/####....===
#====..>...# #..%...#..# .....#..==%...#|}+@|.|#...#..........# ....
#===.......# ../...%.%#..#.......#..==....#|"|"|"|#...#..%%......# .
#====......# ....#......#..#########.====...#########...#..........#
#====......# ### ########... ..======.... ....############
=========.. ...= ============== =.....
=========== ===== ============= ========
======== ===== ============= ========
=== ==== ========== =======
##### ####
Tim! Armor : green armor [1/1] (100%)
Health: 28% Exp: 6/71% Weapon: modified chaingun (1d6)x4 [15/40] (A1)
cautious Hell's Armory
This should be really easy to fix: just change the color tags the game generates. Here is a list that matches the currently used color tags (without [ and ]) with my suggested replacements:
color=#F66->color=red
color=red->color=maroon
color=blue->color=navy
color=#BBB->color=silver
color=#777->color=gray
color=brown->color=olive
color=green==color=green
color=yellow==color=yellow
color=#66F->color=blue
color=#6F6->color=lime
color=#6FF->color=aqua
color=#F66->color=fuchsia (NOTE: #F66 is currently used twice)
color=purple==color=purple
color=#FFF==color=white
Gray, silver and white may be the same, but I would use the named versions for consistency.
Thanks to Malgond for suggesting these colors for the wiki (as justified here).
Pages: [1] 2