SENTInce

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #75 on: September 21, 2007, 03:44:38 pm »

Yes I was quite disappointed that it can't be made to scroll on keywords (short of a complete rewrite I think). However just scrolling on icons might be ok.

Anyway, something has come up meaning I'll be AFK for a week or two. I'll commit all my latest client changes this evening. It'll compile and run fine but this in particular is unfinished so if anyone does want to test SENTInce don't expect too much from SENTInce options or ib:AddListItem().


	Logged

Read Smacky's Guides

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #76 on: October 19, 2007, 12:25:32 pm »

This is a quick note as much to remind me as to bump the thread.

A few SENTInce features are currently implemented server-side (ie, in Lua) but would ideally be done client-side (ie, in C).

This is because doing them server-side maintains backwards compatibility with unaware clients whereas client-side would break this.

For example, if a button command is prefixed with '#' it will take the number of the selected selectable icon as its argument -- so '#select' becomes 'select #1'.

In full you would write this in your script as:

Code:

ib:SetAction("Select", "#Select")

However, as shorthand you can just do:

Code:

ib:SetAction("#Select")

Both examples are currently sent from server to client as '<dt="Select"c="#Select">'. The 't="Select"' bit is 10 bytes of unnecessary data.

If the server just sends '<dc="#Select">' then the client can say 'hey, I have no title' and look at the command. As the command starts with a hash it knows to strip that first character and use the suffix as a title. You would of course still be able to send an explicit title and command to suppress this automatic figuring out.

Unfortunately unaware clients will fall over (or maybe just not work as expected -- untested) if they receive '<dt="#Select">' so therefore this sort of feature needs to remain server-side until SENTInce becomes official (although I might make it a compile-time option for easy testing).

EDIT: Mixed up command and title.


	Logged

Read Smacky's Guides

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #77 on: October 29, 2007, 12:05:38 pm »

I've merged an older thread from the hidden dev forum with this one (first couple of pages) to better portray the development, if anyone is interested in that sort of thing. I actually started it about 6 months before the first post here IIRC.


	Logged

Read Smacky's Guides

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #78 on: November 05, 2007, 05:30:45 pm »

I've just uploaded the latest version of SENTInce to sourceforge. This very nearly completes the client changes. But not quite. There are a couple of known bugs and one or two features not yet implemented. But here's a screenshot anyway:

http://www.daimonin.net/modules.php?full=1&set_albumName=SENTInce&id=aware_true&op=modload&name=gallery&file=index&include=view_photo.php

The script that does that interface isn't quite finished yet (the version in streams/SENTInce/maps/scripts/church.lua is a bit old and I can't guarantee it works properly) so you're a bit stuck testing out SENTInce's new features for yourself.

However, the test server is (and has been for months) running SENTInce maps/lua/ scripts. You can connect to this with either a SENTInce aware client or an unaware one (official or widget) and everything should work the same (well, the aware one has few enhancements so interfaces look prettier, there are a few more hotkeys, etc.). Similarly, you can play on the main server with a SENTInce aware client and it'll work fine.

So what are the enhancements?

The old client used TAB/sTAB to cycle through keywords and/or links, and UP/DOWN to cycle through selectable icons. SENTInce changes the grouping. TAB/sTAB cycles through keywords only and UP/DOWN cycles through icons and/or links.
Buttons can be set in a script to take the selected icon/link as an argument (I mucked up an earlier implementation of this which is why GH Smith doesn't work properly).

Icons/links can also be clicked on on their own. This gives each icon/link 3 possible uses. Of course this behaviour is entirely optional (according to the script) and many times it will not be wanted.

On a page with links, the first 9 can be selected by pressing 1-9 or KP1-KP9.
Buttons can also be selected by pressing -/+ or KP0/KP or a letter key.
BACKSPACE is used to open the textfield to type something in, and RETURN/ENTER sends whatever command you have selected/typed.
As you may have noticed, this means the GUI is entirely useable with only the numberpad (with the exception of typing in the textfield which obviously requires the main keyboard).
The mouse behaviour is tweaked. Moving the pointer over any interactive element (keyword, icon, link, button) will select it (keywords and links turn purple, icons and buttons are framed in purple and the command appears in the textfield area). Clicking an element will send it's command (or in the case of modifying buttons on pages with selectable icons/links, the compound command), as shown in the textfield. As with the numberpad, an interface can be used with the mouse alone (excepting the textfield).
And some other stuff.

Anyway, there it is. As I say there are one or two bugs, but nothing to cause a crash or anythin. Because there are no demo scripts, it is probably quite unexciting. But at this stage it should be. I'm AFK for a week now.


	Logged

Read Smacky's Guides

grommit

Administrator

Karma: +28/-3
Posts: 2529

SENTInce

« Reply #79 on: November 05, 2007, 05:41:26 pm »

Couple of comments added to album - looking really good.


	Logged

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #80 on: November 06, 2007, 12:42:45 am »

Thanks.

I've made several additions/fixes tonight (in SVN):

The various BUG messages are no more, and other fixes.
Icons/links can be forced to default to either the left or the right button (if the scripter has made a booboo and the default button does not exist or is not a modifying button, the other will be used. If this fails too, the client will cope) or not to accept a modifying button at all. Each icon/link on a page can be set independently. The default default is the RHS button (going to LHS and none in the event of a script booboo).
Talking about: in the lower textwindow is replaced by Topic:. This is more apt given the terse nature of /talking I think ('Talking about: cast remove death sickness' sounds a bit silly IMO).

I really am AFK now! Cheesy


	Logged

Read Smacky's Guides

grommit

Administrator

Karma: +28/-3
Posts: 2529

SENTInce

« Reply #81 on: November 15, 2007, 02:29:22 pm »

The SENTince version of interface_builder.lua which is running on the test server is broken.

The order of parameters for ib:AddIcon has been changed. Any script calling ib:AddIcon(name, face) throws an assert "Parameter #5 must be a string". Huh? I can only see two

The original parameter spec for AddIcon is (name, face, [body]). The SENTince version has (name, command, face, body, ...) which is not backward compatible.

Currently no script running on the test server using AddIcon will run. There may be other problems but this is the first one I found.

Edit: as well as changing the function name to the right one ( Embarrassed

), I have temporarily renamed the version of interface_builder.lua on mapwiz to interface_builder_sentince.lua until the problem can be fixed.


	Logged

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #82 on: November 16, 2007, 01:47:38 am »

I'm not surprisrd I slipped up here. I actually added a couple of (semi)optional paramaters to ib:AddIcon() (and ib:AddSelect()), _quantity and _command.

_quantity is the number of items represented by the icon (essentially, a negative integer, a positive integer, or 0 [in the sense of nil]). Mainly this better allows icons to be used to indicate inventory changes, quest rewards, and goods for sale.

_command allows icons to have a command attached to them, in the same way as links, so we can, for example, cast remove damnation, not cast #4 (although if _command is nil #n will be used for backwards compatibility (and because sometimes a lengthy command is probably unnecessary).

The problem is that while _quantity is the final parameter (optional final params are easy to add without breaking backwards compatibility), _command is the second/third parameter for consistency (ie, with ib:AddLink()). Because it and the subsequent parameters are all optional and to preserver backwards compatibility, and as I've tried to use assert() throughout for easy bugtracking, I've done a bit of parameter parsing at the beginning of ib:_AddIcon() (the internal function). I guess I've slipped up in the logic somewhere (although I haven't noticed any local problems).

Well, I'll fix it tomorrow. Thanks for the report.

PS, here's the code:

Code:

307 ---------------------------------------
308 -- The icons block.
309 ---------------------------------------
310 -------------------
311 -- ib:AddIcon() adds an icon.
312 -- ib:AddSelect() adds a selectable icon.
313 -------------------
314 function InterfaceBuilder:_AddIcon(_type, _title, _command, _face, _body, _quantity)
315 if _quantity == nil then
316 if type(_body) == "number" then
317 _quantity = _body
318 _body = _face
319 _face = _command
320 _command = nil
321 elseif _body == nil then
322 _body = _face
323 _face = _command
324 _command = nil
325 end
326 end
327 assert(type(_type) == "string", "Arg #1 must be string!")
328 assert(type(_title) == "string", "Arg #2 must be string!")
329 assert(type(_command) == "string" or _command == nil, "Arg #3 must be string or nil!")
330 assert(type(_face) == "string", "Arg #4 must be string!")
331 assert(type(_body) == "string", "Arg #5 must be string!")
332 assert(type(_quantity) == "number" or _quantity == nil, "Arg #6 must be number ot nil!")
333
334 if _command ~= nil then
335 _command = string.gsub(_command, "[°|~%^]", "")
336 end
337 if type(self.icons) ~= "table" then
338 self.icons = { }
339 end
340 table.insert(self.icons, { type = _type, title = _title, command = _command, face = _face, body = _body, quantity = _quantity })
341 end
342
343 function InterfaceBuilder:AddIcon(_title, _command, _face, _body, _quantity)
344 self:_AddIcon("normal", _title, _command, _face, _body, _quantity)
345 end
346
347 function InterfaceBuilder:AddSelect(_title, _command, _face, _body, _quantity)
348 self:_AddIcon("selectable", _title, _command, _face, _body, _quantity)
349 end


	Logged

Read Smacky's Guides

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #83 on: November 16, 2007, 12:37:50 pm »

ATM there are 3 'types' of button can be set: the accept (LHS) button, the decline (RHS) button, and the single button.

If only the accept button is set, the client fakes a dummy decline button (titled 'Decline', but no command, so it closes the GUI).

If only the decline button is set, the client fakes a dummy accept button (same behaviour as above).

If only the single button is set, this is internally converted to an accept button by the client, and appears to the player as an accept button too. There is no decline button.

If no button at all is set, the client fakes a dummy accept button (called 'Bye').

If the script sets both an accept/decline button and a single button by mistake, the single button setting is ignored and the accept/decline buttons are resolved as above.

This seems unnecessarily complicated. I don't see a need for a dedicated single button.

Since always, SENTInce has not used the single button at all, converting ib:SetButton() to ib:SetAccept() before the command is sent to the client. I wrote this behaviour, assuming it was correct and it caused no problems so it never got changed).

This potential backwards incompatibility does not seem to have any untoward affects, suggesting that scripters also find the three-becomes-two-buttons structure unnecessarily complicated.

So the question is, do I claim this change is not a compatibility error (although I have encountered no problems, undoubtedly some script somewhere has done something weird and would need to be changed) but a sensible behaviour fix, or do I slavishly stick to old behaviour even if it seems pointless (can anyone see the point I am missing?) and a bit confusing?

(There is another issue about buttons I'll ask for input on, but lets do this one first.)


	Logged

Read Smacky's Guides

Torchwood

MapMaster

Karma: +35/-5
Posts: 968

SENTInce

« Reply #84 on: November 16, 2007, 12:51:11 pm »

On the assumption that you've got it right, and there are no other complicating factors, then I think in this case you should claim the behaviour fix. Yes, maybe there will be some scripts that will need to be fixed, but IMO it is better to do this now and have a simple button behaviour rather than be forced into doing it later when, potentially, there may be many more scripts that need fixing.

Ignoring /unofficial type maps for now, how many InterfaceBuilder scritps are there currently on the main server, i.e. how many scripts would need to be checked for potential problems?


	Logged

Torch

Torchwoods Artwork
DAIMEX - Use Blender for Daimonin
Blender for Daimonin Tutorial

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #85 on: November 16, 2007, 01:44:46 pm »

Quote from: "grommit"

Only ib:AddIcon() with less than three parameters will cause this problem¹.

This brings up an issue. As noted above, SENTInce uses assert() a lot to check that all the correct mandatory parameters of the right type have been passed to whichever function. Old ib makes no effort whatsoever. As a result, ib:AddIcon() or even ib:AddIcon(true, 22, castle_0000) will be accepted by old ib with no question. It will display a bugged icon and either no text or garbage text, so is useless, but it will be accepted. SENTInce ib will complain about either occurrence.

Now if you look through some scripts there are a few which call, ie, ib:AddIcon("one", "two") (ie, the third parameter is nil) and others which call ib:AddIcon("one", "two", "") (ie, the third parameter is the empty string). IOW at this point nil is being equated with the empty string, which it is not.

Looking at the wiki, it seems that ib:AddIcon() takes three mandatory string parameters, but the actual ib script (the old one) does not enforce this (except through a slightly clumsy mechanism in ib:Build.default() to convert nils to empty strings).

So SENTInce ib:AddIcon() (and various other functions) needs a couple of tweaks to better handle calls with insufficient parameters, as above (ie, 'if param == nil then param = "" end), for compatibility, but what are opinions on the strictness? As noted, SENTInce tries to be strict as that will show up bugs and pointless/inefficient calls quickly. Old ib doesn't bother, which makes it more flexible, but pointlessly so as when parameters are the wrong type they will do nothing/produce garbage.

I can keep SENTInce strict and fix the few old scripts which no longer work right (this won't be a problem in the future) or I can (with resistance) make SENTInce as lazy as old ib, meaning no short term incompatabilities but perpetuating the long term sloppy script problem.

Which?


	Logged

Read Smacky's Guides

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #86 on: November 16, 2007, 01:58:15 pm »

Quote from: "Torchwood"

On the assumption that you've got it right,

That's why it's on test.

Quote

and there are no other complicating factors,

That's why I'm asking here.

Quote

then I think in this case you should claim the behaviour fix. Yes, maybe there will be some scripts that will need to be fixed, but IMO it is better to do this now and have a simple button behaviour rather than be forced into doing it later when, potentially, there may be many more scripts that need fixing.

That's what I wanted to hear.

hehe

Quote

Ignoring /unofficial type maps for now, how many InterfaceBuilder scritps are there currently on the main server, i.e. how many scripts would need to be checked for potential problems?

53. At some point I'll double check all the scripts anyway (at some point they all will need a rewrite in fact).


	Logged

Read Smacky's Guides

tehill

Lesser Moroch Avatar

Karma: +11/-2
Posts: 990

SENTInce

« Reply #87 on: November 16, 2007, 02:58:42 pm »

We presently have a choice of buttons, two buttons where there are two paths to leave the current interface view, and one button when there is only one path to go, and there is no going back.

This gives us great flexibility in NPC conversations. We can after the player has received all he can from an NPC , give the player some parting advice in the GUI and not down in the /say box.

Lua scripting was only introduced in Beta 4.
Michtoen and Gecko have given script writers a lot possibilities and capabilities for the future.
It is far too early to start restricting capabilities that future scripters may need to use for a new innovative script.


	Logged

smacky

Administrator

Karma: +120/-101
Posts: 5381

SENTInce

« Reply #88 on: November 16, 2007, 03:42:39 pm »

Nothing is restricted.

If the script defines a LHS and a RHS button, both are used.

If the script defines a RHS button only, the LHS button is 'faked'.

If the script defines a LHS button only, only one button is used.

If the script defines no buttons, a LHS button is 'faked'.

This is, I think, exactly the same as the old/current behaviour, except that we don't have the additional complexity (for the scripter) of having to disambiguate a LHS button on its own from a LHS button when there is also a RHS button. The client handles this invisibly.


	Logged

Read Smacky's Guides

ThePlaneskeeper

Administrator

Karma: +51/-23
Posts: 1294

SENTInce

« Reply #89 on: November 16, 2007, 04:04:00 pm »

I think what tehill was saying, was that there should really e no effort in restricting the usage of buttons at this point, but i don't seem to read where you are, you just are incorporating a script-fixer into program to allow scripters a bit of an easier time with it, is that correct?

The only thing you are really restricting is scripter's ability to send garbage commands to the client, right?

I see no harm in that, in fact i support it, just make sure its not as tehill fears, that your preventing a creative, unthought-of way of using buttons for something (like a mini-game)

In any case, scripters should (currently) make sure that teir scripts are backwards compatible with the existing client until SENTInce becomes official, so its not like your incorporating anything that will break the existing game play....


	Logged

Daimonin Audio Project
Screaming Flower Media
Daitropsis
Farms:36 of 125 (28.8%)
Supporter of DAIMEX
My Music Blog

Pages: 1 ... 4 5 [6] 7 8 Go Up

Daimonin Forum | Project News | Official announcements | Programmers' blogs | Topic: SENTInce

« previous next »