Page 2 of 14

Re: Petri consumes glögg and codes with you

Posted: Thu Dec 06, 2012 12:28 am
by Komag
This is so awesome. Sometimes I want be Adam Sandler and just use the remote to see what this community will create with these tools in the next year or two! :lol:

Re: Petri consumes glögg and codes with you

Posted: Thu Dec 06, 2012 12:38 am
by Xanathar
Let's start from the bottom! :)
But I think this subject needs it's own thread.
I agree!
That kind of library would be great, but I think we also definitely need some simple standard method of how we develop the gui elements.
I agree! (meh this is getting predictable).

One possibility I am thinking right now:
  • 1 - Having your gui compositor framework as a base layer
  • 2 - Some kind of factory system (in the end, a table <name>,<constructorfunction>) to create a graphic object from a name
  • 3 - A library like the one I said before, but using the factory to construct the graphic objects
This way:
  • A complex scenario which is better to go owner-drawn is implemented directly using (1) in immediate mode, as per petri example. Gain: easier for complex scnarios, loss: some things have to be reinvented everytime like stopping monsters and party (if this is desired of course).
  • Controls of various complexity could be implemented by scripters for reuse using (2) and (1). This may range from a button or label, to an inventory table (petri use case seem complex enough, even if we then would have to create textures for every item, as the gui API do not have a blit function where you can take only part of the source - say, an icon in an atlas - but I'm getting lost in a detail! :lol: )
  • Widgets and dialogs of various complexity can be more easily implemented using (3), and they have at their disposal all the controls which registered themselves in the factories at (2).
But, as we were saying, it's premature and off-topic to this thread, so probably worth moving to a new thread.
Now, if only I could find a good idea on how to move this whole part of discussion without losing each other replies... :roll: :oops:

Re: New GUI scripting concepts and foundation

Posted: Thu Dec 06, 2012 3:54 am
by Neikun
Is it still only possible to draw rectangles with some of the definition?
I think we should make it possible to load images as the gui backdrop.
That way if someone were to draw a really elegant backdrop, they could use that.

Post Script: I am exceptionally tired, and likely missed something.

Re: New GUI scripting concepts and foundation

Posted: Thu Dec 06, 2012 5:09 pm
by thomson
One thing you should consider is using some revision control system, like git or older SVN. That's everyday must have tool for software developers. There are couple obvious benefits. First, it makes updates by several people simultaneously very easy and you don't waste time on merging changes. Every change is recorded, so it is easy to track was was changed, and who changed what. This is very convenient, when you get a bug report "hey! It used to work 5 versions ago". In projects where there are several developers, you may get into other type of problems. There may be a code that you don't understand or don't know the reason it is written in a specific way. When the code is versioned, you can check, who wrote that specific line, so you can ask the author. It also makes easy branching and merging - someone can start developing its own feature and then get back to you with updated code version when the new feature is ready.

If you consider using this and don't have any specific preference, I highly recommend http://github.com. That's a free hosting service with lots of useful additions (easy sources download as single files or zip for current or previous revisions, nice diffs between revisions, bug/issue tracking if you need it, wiki etc.). It is software developers oriented site, rather than modders oriented, but that's ok for this type of mod (it basically is a code). I keep all my software projects there and it works greatly (EobConverter for example, but also my non-gaming related stuff like DHCPv6 implementation).

I wish I had more time to dedicate for LoG. There's already way too much on my head.

Re: New GUI scripting concepts and foundation

Posted: Tue Dec 18, 2012 9:08 pm
by JKos
I tested my idea with the beta version and it works as I expected.
Working example code:

to objects.lua

Code: Select all

cloneObject{
	name='party',
	baseObject='party',
	onDrawGui = function(g)
	   gui.draw(g)
	end 
}
Script entity gui

Code: Select all

elements = {}

function addElement(element)
   elements[element.id] = element
end

function removeElement(id)
   elements[id] = nil
end

function draw(g)
   for id,element in pairs(elements) do
      element:draw(g)
   end
end

function createDialog(id,text)
   local e = {}
   e.id = id
   e.draw = function(self,g)
      g.color(30,30,30,150)
      g.drawRect(30, 50, 345, 300)
      g.drawText(text, 200, 80)
      -- draw button with text
      g.color(128, 128, 128)
      g.drawRect(200, 120, 115, 20)
      g.color(255, 255, 255)
      g.drawText("Ok", 210, 135)
      -- close dialog when the button is pressed
      if g.button("button1", 200, 120, 115, 20) then
         gui.removeElement(self.id)
      end
   end
   return e
end

local dialog = createDialog('hello_dialog_1','Hello grimrockers!')
gui.addElement(dialog)
opens up a dialog with a button, and the dialog is closed when the button is pressed.

Re: New GUI scripting concepts and foundation

Posted: Tue Dec 25, 2012 1:23 am
by JKos
@Xanathar. Are you still going to start this graphics library project? I mean we definitely need some kind of standard base where to build on because the gui support is so low level that you can do almost anything with it, so I'm afraid that the scripts created by different people most likely won't be easily portable between dungeons.

I would like to contribute to this of course, so could we use github as the code repository? Or google code, like GrimQ? Is it any good? I haven't used it. Of course I can start the project too if you are too busy. I think that we could use my skeleton model as a base of the project and start adding flesh on it.

I have also improved it a bit and added a addKeyHook-function (this is just sketching still):

Code: Select all

cloneObject{
	name='party',
	baseObject='party',
	onDrawGui = function(g)
	   gui.draw(g)
	end, 
	onDrawInventory = function(g,champ)
	   gui.drawInventory(g,champ)
	end, 
	onDrawSkills = function(g,champ)
	   gui.drawSkills(g,champ)
	end, 
	onDrawStats  = function(g,champ)
	   gui.drawStats(g,champ)
	end	
}

Code: Select all

keyHooks = {}

elements = {}

function addElement(element)
   elements[element.id] = element
end

function removeElement(id)
   elements[id] = nil
end

function draw(g)
	processKeyHooks(g)
   	for id,element in pairs(elements) do
		element:draw(g)
   	end
end

function drawInventory(g,champ)

end
function drawStats(g,champ)

end
function drawSkills(g,champ)

end

function processKeyHooks(g)
	for key,hookDef in pairs(keyHooks) do
		if hookDef.toggle then
			-- toggle key state and add small threshold so the state doesn't change immediately
			if not keyToggleThresholdTimer and g.keyDown(key) then
				hookDef.active = not hookDef.active
				local t = spawn('timer',party.level,0,0,1,'keyToggleThresholdTimer')
				t:setTimerInterval(0.1)
				t:addConnector('activate','gui','destroyKeyToggleThresholdTimer')
				t:activate()
			end
			if hookDef.active then
				hookDef.callback(g)
			end	
		elseif g.keyDown(key) then
			hookDef.callback(g)
		end
	end
end

function destroyKeyToggleThresholdTimer()
	keyToggleThresholdTimer:destroy()
end

function setKeyHook(key,pcallback,ptoggle)
	keyHooks[key] = {callback=pcallback,toggle=ptoggle,active=false}
end
Key hooks can be used like this:

(just an example)
gui.addKeyHook('m',magic.drawSpellBook,true)

Will call magic.drawSpellBook when the 'm' key is pressed until it is pressed again (toggle mode).

Re: New GUI scripting concepts and foundation

Posted: Tue Dec 25, 2012 7:16 pm
by thomson
JKos wrote:@Xanathar. Are you still going to start this graphics library project? I mean we definitely need some kind of standard base where to build on because the gui support is so low level that you can do almost anything with it, so I'm afraid that the scripts created by different people most likely won't be easily portable between dungeons.

I would like to contribute to this of course, so could we use github as the code repository? Or google code, like GrimQ? Is it any good? I haven't used it. Of course I can start the project too if you are too busy. I think that we could use my skeleton model as a base of the project and start adding flesh on it.
I'm playing with GUI to create encounters in EOB1. I definitely recommend writing a common framework for that purpose. Github is a very good idea. I've created grimrock account on github for that very purpose. I can create a repo if that helps. Just let me know if you want it. Google code is fine as well. I'd like to join, but won't be able to contribute much (my available time to spare is very limited).
I have also improved it a bit and added a addKeyHook-function (this is just sketching still):
I was playing around with scripted events, where you can take certain actions (heal, talk, kill, leave etc.) The first and most important part is to decide on data format. Depending on player's answers this leads to a different set of possible actions. This can be modelled as a tree of choices. While nested arrays are allowed in Lua, it may be a bit awkward to define it recursively. I think it would be more convenient to define it as an array.

For each possible conversation point, we need:
- some kind of id
- action name (like "talk", "fight", "kill", "buy" etc)
- action comment (text comment that explains what has happened)
- function (function that is called when action is taken)
- id of the next conversation point (or 0 if event has ended)

Re: New GUI scripting concepts and foundation

Posted: Tue Dec 25, 2012 10:39 pm
by Xanathar
Hi and merry Christmas to all :)
I'm totally for doing it - my only problem is time. In theory I was supposed to be away from home for the whole Christmas holidays (until the 7th of January which incidentally is my birthday) but my daughter has the flu (like every Christmas, seems like a tradition :( ) so I might be able to find some time for it.

I setup this : https://github.com/xanathar/grimwidgets
and in theory already added some of the users of the EOB1 project to this project; let me know if anyone interested has no access.

Regarding the technical bits: I'll read them as soon as I finish preparing the dishwasher :lol:

EDIT: Fixed the link.

Re: New GUI scripting concepts and foundation

Posted: Wed Dec 26, 2012 12:14 am
by thomson
Xanathar wrote:I setup this : https://github.com/xanathar/grimwidget
That should be https://github.com/xanathar/grimwidgets (you've lost 's' at the end). I've got access.

I think the following assumptions are reasonable: We want the framework to be easy to use. in Waterdeep sewers, I've created a new type of objects (which is a cloneObject of "script_entity"). The idea is that modder can easily place that type in the dungeon and our framework can easily distinguish if the object is something we want or not.

This event script will have couple required properties, like description, active, possible functions that will be called if player clicks something specific etc. I've cloned "party" object, so my method is called:

Code: Select all

cloneObject {
    name = "party",
    baseObject = "party",
    onDrawGui = function(ctx)
        encounters.update(ctx, self)
    end,
}
Function update checks all objects that are present at the same location as the party. If any of those objects passes sanity checks (i.e. is detected as event), this event is processed.

Code: Select all

function update(ctx, party)

	local items=""
    for i in entitiesAt(party.level, party.x, party.y) do
		if i.class == "ScriptEntity" then
			processEncounter(ctx, i)
		end
    end
end

-- handles encounter
function processEncounter(ctx, eventScript)
	if not sanityCheck(eventScript) then
		return
	end
	
        -- @todo: this has to be written in a more convenient manner
	eventScript.event(ctx)

end

-- check if e is really an event
function sanityCheck(e)
       -- using lots of separate ifs is lame, but helps with debugging
	if e.name ~= "event" then
		return false
	end

    if e.description == nil then
		return false
	end
	
	if e.active == nil or e.active == false then
		return false
	end
	
	return true

end
You can see example event in Waterdeep sewers (https://github.com/grimrock/eob1-waterdeep) at (15,13) on level 4. The actual format of the event object is up for discussion.

I think this approach makes definition of new events intuitive (you place an object in your dungeon using editor) and you process only the events that are at the same location as party, so it shouldn't include much performance degradation. So, what do you guys think?

Re: New GUI scripting concepts and foundation

Posted: Wed Dec 26, 2012 12:14 am
by JKos
(Damn, I wrote a pretty long post and my session timeouted, but anyway)

Great, and merry Christmas to you too. I'm glad that I don't have to do this all by myself :) (I have time problems too, 2 kids here)

But maybe we should start with design principles. here is my suggestions:
- Easy to use and install (declarative api, no unnecessary fancy patterns)
- Versatile (low and high level apis. Low level api could use fancy patterns and all nice stuff)
- External "plugin" support (everyone should be able to develop their own widgets without touching the gw script)
- Light weight (we should keep in mind that gui scripts are executed in every frame)

I had some api suggestions too, but I don't feel like rewriting them now (damn timeout! :evil: ), maybe tomorrow :)