## HUMP - yet another set of helpers

Jack Dandy
Prole
Posts: 49
Joined: Mon Sep 08, 2014 4:26 pm

### Re: HUMP - yet another set of helpers

Whoops. I forgot to put 'Timer_enemyturn:update(dt)' in love.update.
Thanks

Zireael
Party member
Posts: 139
Joined: Fri Sep 02, 2016 10:52 am

### Re: HUMP - yet another set of helpers

I'm using HUMP camera but am running into problems avoiding scrolling under the HUD. My current code only works for a certain map size. I would like to have a viewport - so that nothing can ever go under the HUD on the left or the planned HUD on the bottom. I understand there is a way to do viewports in HUMP, but I'm not certain how to do it?

Positive07
Party member
Posts: 1006
Joined: Sun Aug 12, 2012 4:34 pm
Location: Argentina

### Re: HUMP - yet another set of helpers

Have you tried [wiki]love.graphics.setScissors[/wiki]?
for i, person in ipairs(everybody) do
[tab]if not person.obey then person:setObey(true) end
end
love.system.openURL(Github.com/Positive07)

benreed
Prole
Posts: 6
Joined: Fri Oct 21, 2016 3:07 pm

### Re: HUMP - yet another set of helpers

Quick question:

I want one of my menu state callbacks to call love.quit(). Since I called registerEvents() with no arguments in love.load(), I know that I've remapped the default LOVE callback, and now I'll have to define a new way of getting that behavior. My first naiive thoughts were these:

(1) Define an empty function body for menu:quit() and love.quit() will get called in the background. If I had paid more attention when I was skimming the contents of gamestate.lua, I would have realized this wasn't going to happen. So naturally I pressed my button and all I got was my print statement in the console, and I realized I had more work/reading to do.

(2) Call love.quit() explicitly inside menu:quit(). As you can expect, the resulting segfault (IDK what else it could be, the behavior smacked of unintentional recursion while re/deallocating memory to me) was moderately spectacular.

So what's the RIGHT way to make a user-defined callback in a HUMP gamestate call love.quit()? I read further in the docs and realized (as I was drafting this post) that you could pass a table argument to registerEvents() and remap only certain callbacks. I feel like that's part of the solution, but I'm not sure how to make it work yet. I passed in a table with only 'draw' to see how it worked, and all that happened was that it looks like my menu:draw() was never called (I put a print statement in there to be sure).

I have moderate programming experience in a bunch of different languages, but this is my first time working with Lua for more than 30 minutes (only just finished part 1 of Programming in Lua, still alt-tabbing between it and various LOVE library docs), so I'm still wrapping my brain around all of Lua's features & their uses. My programming experience is mostly rooted in Java, C++, Python, and a bit of C, so adapting to the way Lua does things is taking me a bit of adjustment. Any help you can give -- or any further reading you can assign -- is greatly appreciated.

Here's the relevant code snippets:

Code: Select all

-- main.lua (still learning how to properly use "require" with my face)
-- code to move cursor up and down in the menu

-- Act on menu selection if confirmation button is pressed
end
end

if index == 3 then
print("You selected : " .. options[index].label)
elseif index == 5 then
end
end

print("Quittin' time")
end


Code: Select all

-- main.lua, very bottom of the code
Gamestate.registerEvents()
end


Positive07
Party member
Posts: 1006
Joined: Sun Aug 12, 2012 4:34 pm
Location: Argentina

### Re: HUMP - yet another set of helpers

You shouldn't have a problem defining love.quit in your main.lua, HUMP is intelligent and will call it even if you do registerEvents, note that if you redefine the love.quit in other point HUMP will lose control over it.

That means that if your love.quit function is defined in a file that is required after HUMP registers then you'll probably override HUMP's love.quit.

Note that if you are using love.quit once throughout your program and don't want specific per-gamestate love.quits then taking control over love.quit (that is redefining love.quit after HUMP registerEvents) shouldn't pose a problem to you.

PS: You have to pass at least "update" in the callbacks table not just "draw", so {"update", "draw"} should at least do something. This is just a thought, I haven't tested.

Also if what you want is cancel the quit event then return true from menu:quit(). Otherwise I don't really get your problem
for i, person in ipairs(everybody) do
[tab]if not person.obey then person:setObey(true) end
end
love.system.openURL(Github.com/Positive07)

benreed
Prole
Posts: 6
Joined: Fri Oct 21, 2016 3:07 pm

### Re: HUMP - yet another set of helpers

EDIT: Figured it out. Googled "love2d quit game from menu", blundered into the doc page for love.event.quit(), tested it, does exactly what I wanted. Sorry for taking up your time, Positive07, and thank you very much for your help.

To answer more specifically about what I want, all I want is to give one of the main menu choices the power to quit the game in the same way a window quit (clicking the "X") would. Right now this is the only part of the game
I want to have this power; in other states, I expect the user to close the window instead.

I refactored my code a bit while I was waiting on a reply, but I still can't figure out how to implement my menu quit properly.

Here's what changed:
I dumped all the menu state code that used to be in main.lua into its own file (r_menustate.lua; I finally learned what I was doing wrong with "require" and the gamestate table).

Code: Select all

local Gamestate = require("gamestate")

function love.quit()
print("love.quit(): Bye!")
end

Gamestate.registerEvents()
end

But while my code is now much neater, that, of course, doesn't solve my problem. If I write a menu:quit() function, the statements inside the body execute, but love.quit() is never called.

Here's the relevant r_menustate.lua code now:

Code: Select all

-- r_menustate.lua
-- cursor movement code
end

end

if index == 3 then
print("You selected : " .. options[index].label)
elseif index == 5 then
end
end

-- calling this function with empty body does not result in love.quit() being called;
--   the statements inside the body are executed, but love.quit() never happens at the
--   end
end

Do I need to send more information up to main.lua with an event or something to result in a single, explicit call to love.quit()? I still don't get what I'm doing or not doing to not get the love.quit() call I want.

EDIT: I also tried explicitly passing all the callback names to registerEvents() that I wanted my menu state to handle, but the behavior is still the same.

Code: Select all

-- main.lua

local Gamestate = require("gamestate")

end

--function love.quit()
--print("love.quit(): Bye!")
--end



Prole
Posts: 15
Joined: Sat Jun 27, 2020 10:43 am

### Re: HUMP - yet another set of helpers

Hi,
I'm having trouble using (and understanding) the lockWindow() function in the hump camera.
How can i set it up to define the boarders of a level? Something like this. Ignore the values though.
This code just causes the screen to jutter and shake like there's an earthquake.

Code: Select all

function scene:update(dt)
local dx, dy = player.x - camera.x, player.y - camera.y
camera:move(dx/2, dy/2)
camera:lockWindow(1000,0,2000,4000,0,0)
end


### Who is online

Users browsing this forum: No registered users and 29 guests