Pillars, trees and other blockers?

This forum is for the Lua scriptable clone of DM/CSB called Dungeon Strikes Back by Sophia. Use DSB to build your own highly customised games.

Moderator: Sophia

Forum rules
Please read the Forum rules and policies before posting.
Post Reply
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Pillars, trees and other blockers?

Post by Gambit37 »

I'm stumped how to create blocking floor items such as a pillar or tree?

And is it possible to create half-height blockers that you can throw stuff over?

How would I make a blocker clickable that gives items to a character, eg, picking apples from a tree?
User avatar
Sophia
Concise and Honest
Posts: 4240
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Pillars, trees and other blockers?

Post by Sophia »

Blocking items are of type "FLOORUPRIGHT".
Here's a very simple example of an archetype for a pillar:
(note that you'll have to provide a gfx.pillar for this to work right)

Code: Select all

obj.pillar = {
    type="FLOORUPRIGHT",
    class="DECO",
    col = true,
    front=gfx.pillar
}
If you want a more complicated example, check out dm2table.lua included with the test_dungeon.

The col property is short for collision, and it determines what hits what when. If it's just true, the object is fully solid, but it can also be a function to allow for stranger behavior. Take a look at dm2table.lua. You can probably just copy its col function verbatim because a DM2 table has the exact behavior you want; dungeon objects can go through it but the party will bump into it. Allowing all objects to pass but setting no_monsters means only items can move through it, which I think is what you want.

Making the blocker clickable requires you set clickable to true and define an on_click function. Here is basic code to make your clickable floorupright behave just like a wallitem.

Code: Select all

obj.pillar = {
    type="FLOORUPRIGHT",
    class="DECO",
    col = true,
    front=gfx.pillar,
    clickable = true,
    on_click = wallitem_click,
    esb_take_opby_targets = true
}
That last property, esb_take_opby_targets, is optional, but it makes it a lot easier to work with your new object in ESB because that tells it to display the normal opby and target selectors, which aren't normally shown for flooruprights.

To make a tree that gives apples, you have two options:
:arrow: In ESB, set the target to an "item_action" instance (the IA with an arrow, available in FloorFlats/Mechanics) that will move a "Newly Created" instance of an apple into the mouse hand.
:arrow: Write a custom function (like give_apple) and assign that to the new arch's on_click instead of behaving like a generic wallitem.
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Pillars, trees and other blockers?

Post by Gambit37 »

Ah, right, thanks. I didn't realise col = collision, I thought the blocking ability was controlled by the type or class.

How do I know the right type or class to use for any given object? Do different classes and types have particular innate properties?

I don't understand this code at all:

Code: Select all

function table_collision(arch, id, what)
	if (not what) then
		return true
	end
	
	return false
end
User avatar
Sophia
Concise and Honest
Posts: 4240
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Pillars, trees and other blockers?

Post by Sophia »

Types have innate properties, but they're also broad enough that there won't ever be any confusion as to what type to use.
Valid types in DSB are: FLOORFLAT, FLOORUPRIGHT, WALLITEM, DOOR, THING, MONSTER, HAZE, CLOUD, and UNDEFINED.

Classes do not, they're solely an organizational tool used by the base code and ESB.

Any col function takes three parameters: the archetype that is being collided against (arch), the instance that is being collided against (id), and the instance that is doing the colliding (what). If what is nil, that means no instance is doing the colliding, so the colliding entity must be the player. That idiom is what makes the code work. If there is not a colliding entity, that means the player party collided with the other object, so it returns true, which means "stop the colliding thing." If there is a colliding instance (i.e., what is an actual instance id, not nil), it returns false, which means, "let the colliding thing pass through." Combining this with setting no_monsters means everything but monsters will be able to pass through-- but the only things, in practice, that move around in a typical dungeon are thrown items and monsters, so it will allow thrown items only.
User avatar
Gambit37
Should eat more pies
Posts: 13715
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Pillars, trees and other blockers?

Post by Gambit37 »

Okey dokey, I understand the explanation, but would never have figured out that logic on my own. Thank you for taking the time to explain it :)
Post Reply