headers
Alex Schultz | 1 Nov 2006 04:31

Re: 2.0 object-type refactoring

Mark Wedel wrote:
> <snip>
>   In that mode, I still think it would be easy to do an object type at a time - 
> you'd have something like:
>
>   ob_apply()
> {
>    if (we have callback) do_callback()
>   else call_old_apply_function()
> }
>
>   type of thing.
>   
Yes, I agree and do now believe that doing it one-type-at-a-time would
work better overall than one-callback-type-at-a-time. The way you say
above is about what I'm thinking.

Another thought, perhaps instead of the "else" though, we could use the
"BASECLASS" via another ob_methods structure as mentioned in a different
mail, to implement the falling back to the old function. Not only is it
well suited to falling back to the old function, it IMHO might prove a
useful system to have in place for after the conversion is complete,
particularly once getting into per-arch and per-object ones with plugin
support.

> <snip>
>   The previous example I had was about applying unpaid objects.  I can't think 
> of any case where that should be allowed, and if there was some specific reason, 
> I think a flag on the object should control that, and not object type (as 
> presumably, that object would have some behavior like existing objects).  I
(Continue reading)

Permalink | Reply | 5 comments |
headers
Christian Hujer | 1 Nov 2006 17:16
Picon
Favicon
Gravatar

Re: IRC traffic for Sunday Oct 22

Hi all,

my 2 cents to improve crossfire.

On Tuesday 24 October 2006 15:39 Alex Schultz wrote:
> Gridarta Ideas:
(Note: in Gridarta context, daimonin means Gridarta 4 daimonin, crossfire 
means Gridarta 4 crossfire, gridarta means code that's already unified and 
shared)
>     -Better 'connection' (i.e. buttons and gates) interface. Perhaps
> even give
>      the server new object types for boolean logic, and give Gridarta a
>      flow-chart-like interface to that.
Already on the way. Daimonin already has a connection view for that purpose.
>     -NPC dialog editor
>         -Understand  <at> match syntax and the subset of regexp syntax
Ay.
>     -Warn users when they are doing 'the wrong thing', as in putting
> object on
>      the map or in inventories that should never go there.
>         -Daiminion already does this. Code just need to merge this code
> and make
>          crossfire-specific rules for it.
Yep. We will move this from daimonin to gridarta once the code used by this 
feature is similar enough.
>         -Perhaps warn about connected object in inventories, because that
>          doesn't work and could confuse map-makers.
Dito.
>     -"but I think more importantly, it should be possible to create a
> crappy 'my first map' in 10 minutes or less" - Cavehippo
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alex Schultz | 2 Nov 2006 01:17

Gridarta concerns [was: IRC traffic for Sunday Oct 22]

(crossposting to the gridarta mailing list)

Christian Hujer wrote:
> On Tuesday 24 October 2006 15:39 Alex Schultz wrote:
>   
> <snip>
>>     -"but I think more importantly, it should be possible to create a
>> crappy 'my first map' in 10 minutes or less" - Cavehippo
>>     
> At least for daimonin that's possible, and I'd say so it is for crossfire. If 
> you think it's not, please let me know what we can improve.
>   
I haven't looked at gridarta4daimonin yet, however at least in
gridarta4crossfire, there are few interface issue which I feel affect
this. The current system of, left click to select, right click to insert
and middle to delete, is IMHO not the greatest. It *is* a very fast
interface to use, however I personally find it too error prone and also
could be easier for new users. I personally would advocate an interface
more like this:
    -Have a 'tool palette', and allow right, middle and left mouse
buttons to have separate palette modes assigned to each at once.
    -By default, have left click as select and middle click as insert,
and right as a new context menu.
    -Make an easy thing for resetting the tool selections to those
defaults, possibly a lock option.
    -The context menu contains actions that can be done to the whole
stack (i.e. cut, copy, paste, delete, select, insert) and also having
submenus for each object inside it, for doing similar actions (i.e. cut,
copy, delete, select) to that object alone.
    -Key bindings with the following defaults:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Wedel | 2 Nov 2006 07:10
Favicon

Re: 2.0 object-type refactoring

Alex Schultz wrote:
> Another thought, perhaps instead of the "else" though, we could use the
> "BASECLASS" via another ob_methods structure as mentioned in a different
> mail, to implement the falling back to the old function. Not only is it
> well suited to falling back to the old function, it IMHO might prove a
> useful system to have in place for after the conversion is complete,
> particularly once getting into per-arch and per-object ones with plugin
> support.

  I personally wouldn't  be overly concerned about neatness while in the 
transition.  After all, it is a transition, and will eventually go away, so 
being too concerned about how it work doesn't make tons of sense.

  per arch/per object I think gets into some other issues.  Registering them 
isn't hard - the more serious question is if those callbacks are in addition to 
the ones normally for that object, or are instead (or does something control 
that?).  But that is a future discussion.

  I'd think for generic callbacks, it depends on its purpose.  For the 
transition purpose, I think it'd have to fallback to a single function for all 
object types.  I'd personally rather just see a call like 'apply_fallback()' 
type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 
function for each type, it is easier to follow the code if you see exactly what 
the function is, and don't have to go look at BASECLASS to see what it is doing, 
etc.

> 
>> <snip>
>>   The previous example I had was about applying unpaid objects.  I can't think 
>> of any case where that should be allowed, and if there was some specific reason,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Wedel | 2 Nov 2006 08:26
Favicon

Protocol extension: exp table


  For the client to do things like display scrollbars for exp totals (how close 
to next level, etc), the client needs to know the exp table the server uses.

  The following is my proposed addition to requestinfo/replyinfo protocol 
command.  I can't think of anything more to add, but figure it is still a good 
idea to post it our here in case others have thoughts.

     exp_table (no parameters)
         This requests the experience table (what exp is needed for each
         level) from the server.  With this data, the client can easily
         display how much experience is needed for the different skills
         or total exp value for next level. Data format:

         <num_levels>: uint16 - max level/how many exp values follow.
         <level1> ... <level num_levels>: uint64 - amount of exp needed
         for the level.

         Note that num_levels and the actual exp values are transmitted
         as binary values.
Permalink | Reply | 1 comment |
headers
Christian Hujer | 3 Nov 2006 01:11
Picon
Favicon
Gravatar

Re: [Gridarta-devel] Gridarta concerns [was: IRC traffic for Sunday Oct 22]

Hi Alex,

On Thursday 02 November 2006 01:17 Alex Schultz wrote:
> (crossposting to the gridarta mailing list)
>
> Christian Hujer wrote:
> > On Tuesday 24 October 2006 15:39 Alex Schultz wrote:
> >
> > <snip>
> >
> >>     -"but I think more importantly, it should be possible to create a
> >> crappy 'my first map' in 10 minutes or less" - Cavehippo
> >
> > At least for daimonin that's possible, and I'd say so it is for
> > crossfire. If you think it's not, please let me know what we can improve.
>
> I haven't looked at gridarta4daimonin yet, however at least in
> gridarta4crossfire, there are few interface issue which I feel affect
> this. The current system of, left click to select, right click to insert
> and middle to delete, is IMHO not the greatest.
I agree.

> It *is* a very fast 
> interface to use, however I personally find it too error prone and also
> could be easier for new users. I personally would advocate an interface
> more like this:
>     -Have a 'tool palette', and allow right, middle and left mouse
> buttons to have separate palette modes assigned to each at once.
In gridarta4daimonin we have this already. It will be merged. I've added this 
to the todo list.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Schultz | 3 Nov 2006 03:22

Re: [Gridarta-devel] Gridarta concerns [was: IRC traffic for Sunday Oct 22]

Christian Hujer wrote:
> <snip>
>> It *is* a very fast 
>> interface to use, however I personally find it too error prone and also
>> could be easier for new users. I personally would advocate an interface
>> more like this:
>>     -Have a 'tool palette', and allow right, middle and left mouse
>> buttons to have separate palette modes assigned to each at once.
>>     
> In gridarta4daimonin we have this already. It will be merged. I've added this 
> to the todo list.
> <snip>
>   
Nice. Interesting to hear that gridarta4daimonin already has this,
because I've never heard of an app that implemented a tool palette with
each button selecting a different tool. Well... unless one counts GIMP's
extended input (drawing tablet) support that is. :)
I guess that's a sign it's a good idea when it's been independently
thought of few times :P
> <snip>
>>     -Key bindings with the following defaults:
>>           -Delete key deletes objects (something I wish for regardless
>> of if this interface is done or not)
>>           -Space bar inserts the selected object on the selected tile
>>           -Arrow keys move selection
>>     
> Good ideas. In Gridarta, nearly full keyboard control is possible. The cursor 
> and the selection can be changed using arrow keys. Though, space bar isn't 
> for insertion right now but for selection iirc. I'd rather use "i", "ctrl+i" 
> and the insert key for insertion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Schultz | 3 Nov 2006 07:38

Re: 2.0 object-type refactoring

Mark Wedel wrote:
> Alex Schultz wrote:
>   
>> Another thought, perhaps instead of the "else" though, we could use the
>> "BASECLASS" via another ob_methods structure as mentioned in a different
>> mail, to implement the falling back to the old function. Not only is it
>> well suited to falling back to the old function, it IMHO might prove a
>> useful system to have in place for after the conversion is complete,
>> particularly once getting into per-arch and per-object ones with plugin
>> support.
>>     
>
>   I personally wouldn't  be overly concerned about neatness while in the 
> transition.  After all, it is a transition, and will eventually go away, so 
> being too concerned about how it work doesn't make tons of sense.
> <snip>
>   I'd think for generic callbacks, it depends on its purpose.  For the 
> transition purpose, I think it'd have to fallback to a single function for all 
> object types.  I'd personally rather just see a call like 'apply_fallback()' 
> type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 
> function for each type, it is easier to follow the code if you see exactly what 
> the function is, and don't have to go look at BASECLASS to see what it is doing, 
> etc.
>   
Well, I'm thinking that we do have a "BASECLASS", we might as well use
it for transitional fallbacks, OR better yet make a "TRANSITONCLASS" or
something, which the "BASECLASS" is based on. I would say that would be
just as easy to follow as things like apply_fallback() and in fact on
can make names like that a convention for transitional functions.
Also, fallbacks could potentially be handled very easily and generically
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Wedel | 4 Nov 2006 08:29
Favicon

Re: 2.0 object-type refactoring

Alex Schultz wrote:
> Well, I'm thinking that we do have a "BASECLASS", we might as well use
> it for transitional fallbacks, OR better yet make a "TRANSITONCLASS" or
> something, which the "BASECLASS" is based on. I would say that would be
> just as easy to follow as things like apply_fallback() and in fact on
> can make names like that a convention for transitional functions.
> Also, fallbacks could potentially be handled very easily and generically
> in the functions like ob_apply(), such as in this example:

  The only issue with using the baseclass for fallbacks of old code is that the 
calling structure has to be the same.

  If the new callbacks have more/different parameters than the old function, 
then you have to go back to the old function and change it around a little bit. 
  Any functions so called may need other changes - they may generate error 
messages if the object type isn't handled for example, or possibly other issues. 
  The question then becomes if it is worth it to do changes/debugging vs just 
change the function, move it to the new code and callback method.

  I also think more thought/discussion on these different callback mechanisms 
need to be thought out.  The idea of per object callbacks have also been 
mentioned.  How all of these interact need to be clearly defined.

  For example, is the BASECLASS callback always made, regardless of anything 
else in the object?  Is it only made if if there isn't a specific callback 
registered, etc?  Depending which is done, that is a major difference, and has 
to be reflected in the code that is written.

  If it is always called, to a great extent, it then limits the usefulness of 
the callback structure as a whole (it limits what can be done with the object).
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicolas Weeger (Laposte | 4 Nov 2006 19:03
Favicon

Re: Protocol extension: exp table

Le Jeudi 02 Novembre 2006 08:26, Mark Wedel a écrit :
>   For the client to do things like display scrollbars for exp totals (how
> close to next level, etc), the client needs to know the exp table the
> server uses.

Hello, seems fine with me, easy & practical :)

Nicolas
Permalink | Reply | 0 comments |

Gmane