New GUI scripting concepts and foundation

[JKos]

Oh, sorry about the missing file I will upload it immediately (with some new features and bug fixes). And GrimQ is included already, because it's included in my framework which is included in grimwidgets
GrimQ can be used right away, no need to setup anything.

[JKos]

Ok, it's fixed now.

[thomson]

Thanks. I've updated my repo, but there's a problem when trying to run it in dungeon editor. It stops with "attempt to modify a read only value" error in line 5 of logfw_init, in line fwInit:close(). I don't know what it is about, but I'll try to take a look.

[thomson]

Ok, I managed to find out what was wrong. Someone created an empty script in level 1 and used unfortunate name gw_elements for it. That conflicted with
gw_elements.lua. It seems that entities in dungeon take precence over scripts in mod_assets if there is a name conflict.

The whole thing crashed the first time our framework tried to create any gw object.

I've fixed it by removing this empty script. If you needed it for any reason, please add it back, but use different name for it.

I tried to upgrade grimq to 1.3.2 (we are using 1.2), but it gave me cryptic errors about getMaxLevels() function being nil. That is strange, because that is a valid function provided by the grimrock engine. I haven't pursued that matter further. I think I don't need any new features in 1.3.2, so 1.2 is ok for me, at least for now.

Anyway, the dungeon now loads and runs.

[Xanathar]

Really weird. I'll take the task of grimq upgrade, for obvious reasons

[JKos]

Someone created an empty script in level 1 and used unfortunate name gw_elements for it. That conflicted with
gw_elements.lua. It seems that entities in dungeon take precence over scripts in mod_assets if there is a name conflict.

That was me, sorry again! I was debugging gw_element in dungeon and forgot to remove the script entity completely.
It is intentional that if there is a script with a same name in dungeon than the script loaded by fw_loadModule (or gw_loadModule) the script in dungeon will be used instead of the external script. It's a feature of my framework. This way it's possible to debug/develop scripts in dungeon and copy paste them to external lua scripts when done. I implemented this feature because the editor doesn't show errors caused by dynamically loaded script entities, so it's pretty hard to hunt down the bugs.

I try to be more careful in the future.

Edit: you should pull the newest version again, I removed some unnecessary scripts from the dungeon.

[thomson]

That was me, sorry again! I was debugging gw_element in dungeon and forgot to remove the script entity completely. [...] It's a feature of my framework. This way it's possible to debug/develop scripts in dungeon and copy paste them to external lua scripts when done.

No worries. That's a very handy debugging technique. Since there's no debugger of any kind available, I resorted to the oldest debugging trick - adding tons of printfs Having a copy in the editor in much more convenient.

[djoldgames]

I spending lot of time finding the workaroud to create somthing like onClick() hook for grimrock objects. I using the invisible buttons, levers, alcoves ect...
When I try to use grimwidgets, I think it is the best solution!

All I need was a simple, fully configurable button object without the model, animation or sounds. I make a small update to "gw_events.lua" script and here is working result:

gw_events.lua

Code: Select all

...
function processEvents(ctx)
    local items=""
    for i in entitiesAt(party.level, party.x, party.y) do
        if i.name == "gw_event" then
            processEncounter(ctx, i)
		end
		if (i.name == "gw_event_wallclick" and i.facing == party.facing) then
            processEventWallClick(ctx, i)
		end
    end
end

function processEventWallClick(ctx, eventScript)
	local enabled = eventScript.enabled
	if (enabled ~= true) then
		return
	end
	
	local showButtonProps = eventScript.showButtonProps
	local x = eventScript.x
	local y = eventScript.y
	local width = eventScript.width
	local height = eventScript.height
	local bname="button"..x..y
	
	if (showButtonProps == true) then
		ctx.color(128, 128, 128)
		ctx.drawRect(x, y, width, height)
	end
    if ctx.button(bname, x, y, width, height) then
		eventScript.onClick(ctx)
	end
end
...
...
...
cloneObject{
	name = "gw_event_wallclick",
	baseObject = "script_entity",
	editorIcon = 148
}

example of "default" script inside script_entity in editor, where the button and its onClick() hook is configured:

Code: Select all

-- is this event enabled?
enabled = true

-- show button proportions as gray rectangle?
showButtonProps = true

-- button proportions
x = 500
y = 500
width = 200
height = 40

-- onClick function
function onClick()
    hudPrint("Clicked!")
end

[djoldgames]

...I make a small update to "gw_events.lua" script and here is working result...

Hmm, I see there is a problem I missed before - resolution! Again, this type of onClick() workaroud is useless

[thomson]

The "select character" GUI during acquiring new guy is now not displayed if there is less than 4 characters in party.
The skills can now be set for the new guy.

Do you guys know how can set up character's level? There's champion:levelUp(), so going up is easy. How about the opposite? There is champion:gainExp(), which takes integer. It can be negative. I can decrease experience value, but this will not downgrade character's level. Is there any way to achieve that?