Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[SPTX]

Doesn't seem to work by simply doing that.

I have "psprite = SPRITE_CYBERDEMON," on my item that gives the player the cyberdemon's sprite.
I tried with both "flags = {F_LARGE}" and "OnEquip = function (self,player) player.flags[F_LARGE] = true".

[tehtmi]

Doesn't seem to work by simply doing that.

It looks like changing it on the fly won't work because the current implementation only checks the flag when the thing is loaded.  It might be hard to do for the player at all because of how early the player is loaded.

[Autoquark]

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.

I've got this working by recording the stats at the start of OnAltFire and OnFire and restoring them in OnFired. The problem is that if the user cancels the firing by pressing escape, the stats aren't set back because OnFired doesn't trigger. I don't want to hard code the stats for each mode because this will break weapon modding. Is there any way of fixing this? If not, could you explain how the rocket launcher does it only using OnFire?

Here's my current code:

Code: [Select]

register_item "hl_handgun" {
name = "Glock-17",
desc = "A guard's pistol. Has a large clip and a semi-automatic mode for when you need more firepower.",
ascii = "}" ,
sprite = SPRITE_PISTOL,
level = 0,
weight = 1000, --bit of a guess, see item generation page on wiki
flags = {IF_PISTOL},
firstmsg = "",
color_id = "generic",
--type specific
    type         = ITEMTYPE_RANGED, --required field
damage        = "2d4",           --required field
    damagetype    = DAMAGE_BULLET,   --required field
    group         = "weapon-pistol", --defaults to "weapon-other"
    fire          = 10,              --defaults to 10
    acc           = 2,               --defaults to 0
    radius        = 0,               --defaults to 0 (_RANGED and _NRANGED only)
    shots         = 0,               --defaults to 0. I think 1 makes it a rapid-fire weapon and 0 a single-shot
    ammo_id       = "ammo",        --bullets are "ammo" shells are "" rockets are "" cells are
    ammomax       = 17,              --required field (_RANGED only)
    reload        = 12,              --defaults to 10 (_RANGED only)
    shotcost      = 1,               --defaults to 0 (_RANGED only)
    altfire       = ALT_SCRIPT,       --defaults to ALT_NONE (_MELEE and _RANGED only)
    altfirename   = "semi-auto",    --default depends on altfire (_MELEE and _RANGED only)
    altreload     = RELOAD_DUAL ,     --defaults to RELOAD_NONE (_RANGED only)
    altreloadname = "dualreload",     --default depends on altreload (_RANGED only)
    --soundID       = "pistol",       --defaults to "id" (_RANGED and _NRANGED only)
    missile       = "mgun",
psprite   = SPRITE_PLAYER_PISTOL, --the sprite used to represent the player when equipped

OnCreate = function(self)
self:add_property("normal_shots", self.shots) --these are set again in OnFire to respect changes made by mod packs
self:add_property("normal_acc", self.acc)
end,

OnFire = function(self, being)
self:set_property("normal_shots", self.shots)
self:set_property("normal_acc", self.acc)
return true
end,

OnAltFire = function(self, being)
self:set_property("normal_shots", self.shots)
self:set_property("normal_acc", self.acc)
self.shots = self.shots + 3
self.acc = self.acc - 3
return true
end,

OnFired = function(self, being)
self.shots = self:get_property("normal_shots") --these are set again in OnFire to respect changes made by mod packs
self.acc = self:get_property("normal_acc")
end,
}

[tehtmi]

The rocket launcher is able to get away with this because it only changes the missile which nothing else really modifies.

If you are worried about modding, I think you could fix this by using a custom item property to keep track of which mode the weapon is in.  In OnFire and OnFired, you can subtract 3 shots and add 3 accuracy, but only if the weapon is in "alt-fire-mode", and in OnAltFire you can add 3 shots and subtract 3 accuracy, but only if the weapon is in "normal-mode".  It still isn't perfect because the effect of a mod sometimes depends on the item's current stats which may be in either mode, so you could also try resetting the stats to normal mode in OnEquipTick.

[yaflhdztioxo]

We have custom item properties?  I thought that was beings only...

[Autoquark]

We have custom item properties?  I thought that was beings only...

You definitely do, I've been using them.

If you are worried about modding, I think you could fix this by using a custom item property to keep track of which mode the weapon is in.  In OnFire and OnFired, you can subtract 3 shots and add 3 accuracy, but only if the weapon is in "alt-fire-mode", and in OnAltFire you can add 3 shots and subtract 3 accuracy, but only if the weapon is in "normal-mode".  It still isn't perfect because the effect of a mod sometimes depends on the item's current stats which may be in either mode, so you could also try resetting the stats to normal mode in OnEquipTick.

The problem with this is that OnEquipTick seems to be called before OnAltFire - at any rate, if I press alt fire then cancel the targeting, the alt fire stats remain until another tick has passed, so if I apply a mod pack immediately, it acts on the alt fire stats. The alt fire stats also remain if I immediately unequip the item, but this can be fixed with the OnRemove hook. So it almost works, but without any hook being called immediately after cancelling targeting, I don't see how I can make it perfect. Is there any chance we could get an OnCancelFire hook in the next version?

EDIT: I've decided to fix this by putting an extra check in all of my mod packs which will prevent a mod being applied in the one turn when the stats are wrong. It's not ideal, but as I'm not planning on using any of the original mod packs, it should work. I also have another question: From experimentation it seems that a being's scount can become negative without causing errors. What's the lowest value that it can be safely set to? Or are negative values not intended to be used at all?

EDIT2: Could I have an up to date list of the names of the ally prototype fields? When I use the values from the wiki, it doesn't recognise some of them.

[tehtmi]

I also have another question: From experimentation it seems that a being's scount can become negative without causing errors. What's the lowest value that it can be safely set to? Or are negative values not intended to be used at all?

Scount is a 32-bit signed integer, so it can be as small as -2147483648.  I found one bug relating to the player having a negative scount however.  It may not occur very much in practice because it only happens on the player's turn (when the player's scount will usually be positive).

EDIT2: Could I have an up to date list of the names of the ally prototype fields? When I use the values from the wiki, it doesn't recognise some of them.

Ally?  I'm not sure what you're referring to.

[Autoquark]

Scount is a 32-bit signed integer, so it can be as small as -2147483648.  I found one bug relating to the player having a negative scount however.  It may not occur very much in practice because it only happens on the player's turn (when the player's scount will usually be positive).

So far I'm only changing monster's scount values, so I guess I'll try allowing them to go negative. I'll post if anything odd happens.

Ally?  I'm not sure what you're referring to.

Oops. I meant to say "Being". I think I typed ally because one of the error fields was "group" and I'd tried "ally" and "allegiance" as random guesses at what the new name was.

[tehtmi]

Being prototype:

Code: [Select]

core.register_blueprint "being"
{
--     fieldname = { required, type, [default] }
name        = { true,  core.TSTRING },
name_plural = { false, core.TSTRING },
id          = { false, core.TSTRING }, -- doesn't need to be in the prototype table; id is passed to the declaration function
sound_id    = { false, core.TIDIN("beings") },
ascii       = { true,  core.TSTRING },
color       = { true,  core.TNUMBER },
sprite      = { true,  core.TNUMBER  },
coscolor    = { false, core.TTABLE },
glow        = { false, core.TTABLE },
overlay     = { false, core.TTABLE },
hp          = { false, core.TNUMBER , 10 },
armor       = { false, core.TNUMBER , 0 },
attackchance= { false, core.TNUMBER , 75 },
todam       = { false, core.TNUMBER , 0 },
tohit       = { false, core.TNUMBER , 0 },
tohitmelee  = { false, core.TNUMBER , 0 },
speed       = { false, core.TNUMBER , 100 },
vision      = { false, core.TNUMBER , 0 },
min_lev     = { true,  core.TNUMBER },
max_lev     = { false, core.TNUMBER , 10000 },
corpse      = { false, core.TANY, 0 },
danger      = { true,  core.TNUMBER },
weight      = { true,  core.TNUMBER },
xp          = { false, core.TNUMBER },
bulk        = { false, core.TNUMBER , 100 },
flags       = { false, core.TFLAGS, {} },
ai_type     = { true,  core.TSTRING },
is_group    = false, -- hard-coded prototype value; can't be specified

res_bullet  = { false, core.TNUMBER, 0 },
res_melee   = { false, core.TNUMBER, 0 },
res_shrapnel= { false, core.TNUMBER, 0 },
res_acid    = { false, core.TNUMBER, 0 },
res_fire    = { false, core.TNUMBER, 0 },
res_plasma  = { false, core.TNUMBER, 0 },

desc            = { true,  core.TSTRING },
kill_desc       = { false, core.TSTRING },
kill_desc_melee = { false, core.TSTRING },

weapon = { false, core.TANY },

OnCreate     = { false, core.TFUNC },
OnAction     = { false, core.TFUNC },
OnAttacked   = { false, core.TFUNC },
OnDie        = { false, core.TFUNC },
OnDieCheck   = { false, core.TFUNC },
OnPickupItem = { false, core.TFUNC },
}


[Autoquark]

Thanks. Could you tell me what the names of the built in ai types are?

EDIT: Although I've set the weight of all the normal doomRL enemies to zero, the game is still generating special rooms full of lost souls, and it also seems to be generating imps on some levels. Is there any easy way to stop this?

[SPTX]

I think it may be related to scripted levels as they do not use the generator to place enemies. Try to make a replacement of each being you need replaced using the OnEnter hook.

[Autoquark]

I think it may be related to scripted levels as they do not use the generator to place enemies. Try to make a replacement of each being you need replaced using the OnEnter hook.

If you mean special levels like Hell's Arena, it's an episode mod, so they're not generated. If you mean stuff like vaults full of lost souls then you're probably right that the monsters are fixed. I was hoping I could specifically change the monsters in each special room, but just replacing each monster type might be the best I can do.

EDIT: Also, how do you add items to a monster's inventory. I've been trying

Code: [Select]

local i = 0
self:set_inv_item(i,being.new("hl_handgun")) i = i+1
self:set_inv_item(i,being.new("ammo")) i = i+1
But it errors. I don't actually need it to use the items, I just want them to be dropped when it dies, so I could spawn them on death instead.

[SPTX]

There is http://doom.chaosforge.org/wiki/Modding:Being#being_set_inv_item but having to define a slot may cause trouble for beings starting with an inventory.
I'd try

Code: [Select]

being.inv:add("item")Not sure if it's an actual procedure, but seeing how it isn't documented and that both player and being have inventory procedures while player inherits from being, it might just work.
However, don't quote me on that please.

[shark20061]

Thanks. Could you tell me what the names of the built in ai types are?

There's:
 former_ai (Used on all former-type enemies, including elite versions),
 baron_ai (Hell Knights and Barons),
 lostsoul_ai,
 demon_ai,
 melee_seek_ai (The previous ai for lost souls),
 cyberdemon_ai,
 jc_ai,
 melee_ranged_ai (Used for most enemies, like Imps and Cacodemons),
 ranged_ai,
 flee_ranged_ai (Unused and broken),
 archvile_ai,
 sequential_ai,
 teleboss_ai (e.g. Lava Elemental and Shambler),
 spawnonly_ai (e.g. Pain and Agony Elementals),
 mastermind_ai

[tehtmi]

Although I've set the weight of all the normal doomRL enemies to zero, the game is still generating special rooms full of lost souls, and it also seems to be generating imps on some levels. Is there any easy way to stop this?

There are a variety of reasons that enemies will spawn even with 0 weight.  I can think of:
1) being_groups (this is probably giving you those imps); these have weights that can be zeroed
2) vault rooms (this is the room with lost souls probably); I think you can set the weight of this room type to 0 with the new generator stuff
3) some level types (like caves) will pick a being and use it regardless of weights; you can disable these level types, or replace there monster generation functions