Chaosforge Forum

  • March 28, 2024, 11:24
  • Welcome, Guest
Please login or register.



Login with username, password and session length

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.

Messages - tehtmi

Pages: 1 2 [3] 4 5 ... 25
31
Modding / Re: Changing the ammo system?
« on: March 30, 2013, 10:10 »
I tried looking through the inventory like this:
The "return false" needs to be outside the loop for this to work as you intended.  You may also need to manually :destroy() the item when its ammo reaches 0, but I'm not 100% sure.

32
To add a flag do
Code: [Select]
player.flags[BF_ENVIROSAFE] = true
If you are doing this in OnEquip, OnRemove, it is possible for there to be strange interactions.  For example, the player can equip your item, then equip the phaseshift set which also grants to the flag.  Then if the player unequips the phaseshift set, that will remove the flag even though your item is still equipped.  The only reason the phaseshift wet works is that there is no other way of changing this flag.  The classic way of solving this problem is to do something like
Code: [Select]
OnEquip(self, player)
  if not player:has_property("envirosafe") then
    player:add_property("envirosafe", 0)
  end
  player.envirosafe = player.envirosafe + 1
  player.flags[BF_ENVIROSAFE] = true
end,
...
OnRemove(self, player)
  if not player:has_property("envirosafe") then
    player:add_property("envirosafe", 0)
  end
  player.envirosafe = player.envirosafe - 1
  if player.envirosafe <= 0 then
    player.flags[BF_ENVIROSAFE] = false
  end
end,
However, this requires all things modifying this flag to use this protocol.  Or you can just ignore it since it's usually an edge case.

damage_add is a valid item property that just effects that particular item.  The corresponding prototype property isn't accepted by the blueprint because it is intended to be parsed from the damage string, as you discovered.

Weapon resistances are used in DoomRL by the Acid Spitter, so they are officially supported (if not widely used).

33
Modding / Re: Changing the ammo system?
« on: March 29, 2013, 21:14 »
...what's the property name of "fire" on a weapon? The wiki says "usetime", but I've tried both "usetime" and just "fire" and I get a lua error saying I'm reading an undeclared variable.
"fire" is the name of the prototype property and "usetime" is the object property.  If the Lua error is for an undeclared variable, the problem could be the context you are using it in, as that doesn't sound like an error you'd get when declaring an item.  I'd have to see what you're doing.

Quote
Also, how are OnAltFire hooks for scripted alt fire modes meant to be used. Should I temporarily alter the stats of the weapon and then change them back in the OnFired hook, or is that completely wrong?

OnAltFire is called when you use altfire = ALT_SCRIPT.  I don't consider this to be very mature yet, as most of DoomRL alternate fire modes are not implemented in Lua.  However, what you suggest sounds like the best way to do it to me.  DoomRL's rocket launcher actually uses OnFire to switch the stats back, but I think OnFired would generally work better.

Quote
I know the lua files for the main game aren't being released yet, but have you considered including an example file with each release containing the definitions for one or two items of each type, and perhaps the ai for one or two enemies? ...
This would probably be good, but I'd have to go through Kornel to get permission about what we can post.

Quote
how do I access the player's inventory? I want to go through it to check if a particular kind of ammo is present - I'm trying to make a weapon that draws ammo directly from the inventory.

Currently the only real access seems to be through the inventory iterator
Code: [Select]
for it in player.inv:items() do
  print(it.name)
end
The order they are stored in is undefined (i.e. should not be relied upon).  The rest of the inventory API would be .inv:empty() (this is a predicate), .inv:clear(), .inv:add(it, [params])

34
2. I intend to make a(some) new klasse(s), with their own traits, but I can't get my hands on any source of either klass or trait to see how they are made.

Sorry, I think klass and trait modification isn't really supported in the current version.

35
Ah, sorry.  I'm running in the dev environment, so I guess that's not allowed normally.  The example provided by classic.module should show you how to get a basic episode.  All that really remains is to add the special levels, which I believe are still available even in the normal environment.

classic.module shows how to do "script" levels that replace basic levels.  To add special stairs to a level (this is partly a function of the generator), do e.g.:
Code: [Select]
player.episode[2].special = "hells_arena"

The ids of the special levels are more or less what you would expect, but you can print out the "levels" table to check.

36
Isn't there a way to just call for the default one?

You can call DoomRL.OnCreateEpisode in the OnCreateEpisode hook to create the default episode (and use DoomRL.OnGenerate to use the default generator).

37
Modding / Re: Changing the ammo system?
« on: March 29, 2013, 11:51 »
I have the same error as this dude (and did the same mistake) however even after changing "gun" to "mgun" I still have the error.

Since you have IF_SHOTGUN, the game is looking in the shotgun list instead of the normal list.  If you want it to be a shotgun, change the missile to a proper shotgun type (like "snormal"), otherwise remove the IF_SHOTGUN flag.

38
Modding / Re: A couple questions
« on: March 29, 2013, 11:47 »
All the basic things that you normally have access to in a module (cells, items, beings, etc) are declared in code that runs from doomrl.wad which is still closed source.  You can, however, still modify things after they are declared.  (This doesn't always work quite as you expect since the declaration functions do some processing.  Feel free to ask if something in particular isn't working.)  Prototypes stored in global tables indexed by both number id and string id.  For example, items are in "items" and beings are in "beings".  There's nothing preventing you from printing out the contents of these tables if you need more info.  In fact, I've attached a logging library (from my own module "inferno") should help with logging the contents of the tables (although I haven't bothered to make it print in the correct order).

Use this code to print out the contents of e.g. the items tables (replace MY_MODULE_NAME):
Code: [Select]
require "MY_MODULE_NAME:lib_item"
require "MY_MODULE_NAME:lib_being"
require "MY_MODULE_NAME:lib_log"

MY_MODULE_NAME.log = lib_log.make_log_function("lib_log")

for _, it in ipairs(items) do -- It may take a minute to print all this out.
  MY_MODULE_NAME.log(it)
end
Then check log.txt.

To actually modify stuff, just do e.g.
Code: [Select]
items.pistol.name = "my pistol" -- P.S., this doesn't work great for starting equipment

To create a game with all the basic levels, you want an "episode" type module.  Since you say "no new levels", the hooks you care about are OnCreateEpisode which sets up special levels and the over all path of the game, and OnGenerate which creates random levels.  If you don't want to do anything special, you can just call DoomRL.CreateEpisode() and DoomRL.OnGenerate() respectively.

Edit:
Apparently you can't call DoomRL.CreateEpisode, but you can still replicate it pretty closely.  See here

39
"run" is a special function required "single" type levels that does what the OnCreate hook normally does for levels that are declared with register_level.  For other level hooks, "single" levels can just use the corresponding module hooks since there is only one level anyway.

Typically, the "run" function will set up the map (maybe with a generator.place_tile call) and place the player (level:player(x,y)).  Any other stuff is typically just as effective if it appears in the top-level scope of main.lua (or a required file).

As far as making a tutorial, we'd love to do it, but it is just a matter of finding the time, but feel free to continue asking questions.

40
Bug Reports / Re: [0.9.9.7G/Win] Indestructible things
« on: March 29, 2013, 02:26 »
For the tough walls, I'd probably change it to make things with CF_FRAGILE still destructible.  For non-modders, that means mainly doors, barrels, and supply crates.  (The whole pushing barrels interaction with this event, of course, is also not ideal.)

The indestructible corpse issue is annoying.  I know how to fix it, but it would be a pretty messy fix without some significant refactoring.

41
Modding / Re: Changing the ammo system?
« on: March 29, 2013, 02:22 »
2. I was also wondering about creating my own mod items. I guess you use ui.msg_choice to let the player choose an item slot to mod, but I can't find out from the wiki how to reference the player's equipped items. Is there any example code for this?

ui.msg_choice is actually what the real game uses, but there are more abstraction layers built up that you can use.  Mods are somewhat complicated, so here are the hooks from mod_power for you to base your stuff off of:
Code: [Select]
OnUseCheck = function(self,being)
local item, result = being:pick_mod_item('P',being.techbonus)
if not result then return false end
if item ~= nil then self:add_property("chosen_item", item) end
return true
end,

OnUse = function(self,being)
if not self:has_property("chosen_item") then return true end
local item = self.chosen_item
if item.itype == ITEMTYPE_MELEE then
item.damage_sides = item.damage_sides + 1
elseif item.itype == ITEMTYPE_RANGED then
if item.damage_sides >= item.damage_dice then
item.damage_sides = item.damage_sides + 1
else
item.damage_dice = item.damage_dice + 1
end
elseif item.itype == ITEMTYPE_ARMOR then
item.armor = item.armor + 2
elseif item.itype == ITEMTYPE_BOOTS then
item.armor = item.armor * 2
end
item:add_mod('P')
return true
end,
The whole dance with having to use OnUseCheck and the custom property is inelegant, but it allows the mod to not take any time when the player cancels it.  If you don't like that, here's the simpler version from before the change.
Code: [Select]
OnUse = function(self,being)
local item, result = being:pick_mod_item('P',being.techbonus)
if not item then return result end
if item.itype == ITEMTYPE_MELEE then
item.damage_sides = item.damage_sides + 1
elseif item.itype == ITEMTYPE_RANGED then
if item.damage_sides >= item.damage_dice then
item.damage_sides = item.damage_sides + 1
else
item.damage_dice = item.damage_dice + 1
end
elseif item.itype == ITEMTYPE_ARMOR then
item.armor = item.armor + 2
elseif item.itype == ITEMTYPE_BOOTS then
item.armor = item.armor * 2
end
item:add_mod('P')
return true
end,
Using :pick_mod_item will prompt the player, check for assemblies, and make sure you are allowed to mod the item with the given mod.

Quote
3. Is there any easy way to prevent the level generator from generating the built-in items, or will I have to wait for total conversion mod support?

For a particular item, you can just do e.g.
Code: [Select]
items.pistol.weight = 0
If you want to get rid of all of them, you can just loop through before registering any of your own items
Code: [Select]
for _, it in ipairs(items) do
  it.weight = 0
end
Modifying prototypes after they are declared is a bit messy, but it's the only option for built-in things.

Quote
Here's my item declaration:
Wow, what a useless error message.  It is failing because "gun" is not defined as a missile.  It has been renamed to "mgun".  (I think all the missiles gut "m" added at the beginning and all the shotgun-type missiles got "s" added to the beginning.)

Also, the id field should no longer be included in the table; the initial argument to register_item (e.g. "new_pulsecannon") will be used as the id.

42
Modding / Re: Changing the ammo system?
« on: March 28, 2013, 04:58 »
Ammo is maybe the weirdest item type in DoomRL because it is the only thing that stacks.  Ammo stack items are created automatically by the engine to do ammo management, sometimes in unintuitive ways.  Because of this, it won't be easy to implement this kind of system robustly, but here are some approaches you could try.

Hooks on ammo items don't work well in the current version.  OnPickupCheck doesn't seem to be called at all, and OnPickup is called after the ammo is added.  This could probably still be used, but you would have to fix up the ammo in the player's inventory after the fact.  Another thing you can do is use powerups to add ammo to the player's inventory like Game Hunter does in HereticRL.  OnPickupCheck and OnPickup work for powerups and could be used to implement any logic you like.  Either way, you have to worry about other ways that ammo can be created like dropping ammo from the inventory and unloading weapons.  These will probably be hard to handle well.

Yet another approach would be not to use items for ammo at all.  You could add custom properties to the player (or wherever) to track ammo, and again use powerups to add ammo to these counters.  If you go this approach, all your weapons would need to have custom OnFire and OnReload hooks to make use of the custom ammo system, but it is probably doable.  The difficulty I would anticipate here is displaying the ammo to the player.  Probably I would try to add it in to the name of currently equipped weapons using some combination of OnEquip, OnRemove, and OnEquipTick.

43
Discussion / Re: 0.9.9.7 - Dual-Reload still broke?
« on: March 27, 2013, 20:31 »
Dual reload takes the same as reloading each gun individually.  Since swapping between two pistols is free with dualgunner, it is superior to reload individually because you can react in between (plus you can't dual reload when your main pistol has another alternate reload mode).

44
Requests For Features / Re: "Mid"-Classic Doom feature?
« on: March 23, 2013, 17:32 »
You young whippersnappers! I remember when we only had version 0.9.8.10. In those days there weren't any of your new-fangled assemblies or fancy-schmancy master traits or high-falutin' classes! No! We only had UAC's leftover shit! And we had to pry it out of the dead marines' cold hands first! Uphill! In the snow! Both ways!

I was definitely going to say this.  "Modern classic" DoomRL is clearly 0.9.8.10 :P

45
Modding / Re: Mod Ports (from older versions)
« on: March 23, 2013, 17:29 »
Inferno will be ported.  I did got it mostly running during the beta, but that was before the level generation (which inferno uses in very fragile ways) was revamped, so there is more work to do.  My current guess is that I can get it out in mid-April maybe.

Pages: 1 2 [3] 4 5 ... 25