The Mana World - User contributions [en]

User talk:LlubNek

2009-07-06T23:28:59Z

LlubNek:

I have seen you proposal for a signal-slot system and I have one remark to make: I'ld like to see the "event" that triggered the signal being given as parameter to the signal handler (slot) function. It allows one handler for all key up and down events on an object. (Do you want separate a-up, b-up, a-down, b-down functions?)
--[[User:MathFox|MathFox]] 13:33, 4 July 2009 (UTC)

: The problem with that is that the method used as a slot must then take an event object whenever it is called, even outside of the event system. For example, a void move_up(); or void attack_target(); method could easily be used by bot, npc or scripting code (for example, implementing one action as several others in sequence), whereas void move_up(SDL_EventType&); or void attack_target(SDL_EventType&); could not. There may be cases where you do want to pass a value, like what tile you're over when you click a mouse button, but translating the event object into mouse position should be handled before passing it to the triggered action. That said, it would make sense to store parameter info for each slot and event, so that only events which supply the appropriate information can be used with a particular action. Also, I really do want separate ''slots'' for each ''action'' (and separate ''signals'' for each ''event'')... --[[User:LlubNek|LlubNek]] 22:06, 5 July 2009 (UTC)

:: Having typed signals and typed slots is something that can easily be done in C++ (using templates to avoid source code duplication). The C++ compiler by itself will be very good in preventing you from attaching non-sense slots to signals. (Note: you want the slots to take const& parameters!) Can you detail your plans so that it becomes clearer what the effects of your proposal are for client programmers and players? --[[User:MathFox|MathFox]] 23:15, 5 July 2009 (UTC)

::: I plan to use this, [https://sourceforge.net/projects/signalslot/ signal/slot library], to create a new input system.
::: A list of controls will be generated by enumerating the keyboards, mouses and game controllers attached to the system (at least when compiled with SDL 1.3). There would also be virtual devices (for example, to combine keyboard input from several keyboards). Each control will have a text string associated with it, constructed from the name of the device, followed by the name of the specific control (such as "Logitech, Inc. Dual Action Gamepad 0: button 0"). There will also be a set of events associated with each control, which would also be named ("Logitech, Inc. Dual Action Gamepad 0: button 0: pressed", "Logitech, Inc. Dual Action Gamepad 0: button 0: released"). These are the names which would appear in an Advanced or Edit Binding window.
::: A list of slots will also be generated. Each slot will be given a name, the specific class instance to call it on, and, if necessary, a bit mask indicating what parameters it requires. This should all be registered with the input system when the instance is constructed.
::: Once the devices are enumerated and the actions registered, the current bindings will be loaded from a configuration file. The configuration file would consist of a list of entries, each containing an event name and modifier mask and the associated action name.
::: Signals will be constructed when specific controls and modifiers are bound and added to a `std::map`. The keys to this map will be a `std::pair` containing a mask of the modifiers and the event which triggers the signal. When an SDL event fires, a pair is constructed as above and is checked against the map. If there is a key which matches that pair, the associated signal is emitted.
::: Key points: multiple controls per action, multiple actions per control, virtual devices allow input from sources other than keyboard, mouse and joystick (an automated test suite for example), adding new input devices is fairly simple, adding new actions requires no changes to the input system, and, aside from registering slots with the input system at startup, the rest of the code can pretty much forget the input system exists. --[[User:LlubNek|LlubNek]] 23:28, 6 July 2009 (UTC)

Following up, not all handlers make sense in every situation... So you'ld have to be careful in what you present to the user (keep type information with the signals and slots.)
--[[User:MathFox|MathFox]] 13:42, 4 July 2009 (UTC)

User talk:LlubNek

2009-07-05T22:06:57Z

LlubNek:

User:LlubNek

2009-07-04T08:37:57Z

LlubNek: New page: == LlubNek == === TODO === * Apply signal/slot based input system to TMW client. : Why? :: It allows several different events to trigger the same action. :: Adding new actions is fairly s...

== LlubNek ==

=== TODO ===
* Apply signal/slot based input system to TMW client.
: Why?
:: It allows several different events to trigger the same action.
:: Adding new actions is fairly simple: create a member function with no parameters which performs the action, register the action with the event system (something like event_dispatch.registerAction("name", class_instance, &Class::member);, where class_instance is an instance of Class and Class is a subclass of the slot container class).
: What would this look like?
:: ''Default view''
:: You are presented with a hierarchal list with each action listed, followed immediately by that actions bindings. To add a new binding for an action select it or one of it's existing bindings, click add and trigger whatever event you want to associate with it. To remove a binding, select it and click remove. If you click remove with an action selected, all bindings for that action are removed.
:: ''Advanced view''
:: You would have a set of bindings which you can add to or delete from. When adding a member, you would be presented with a list of actions, a list of triggers (button/key press, button/key release, joystick axis goes positive, joystick axis goes negative, mouse/joystick axis increase, mouse/joystick axis decrease, joystick axis returns to 0), and a list of modifiers (shift, ctrl, etc.). You would select one action and one trigger and whatever modifiers and click OK/Add/whatever.
: Considerations:
:: Signal / slot mechanism introduces some additional overhead, however, this is unlikely to be noticeable in a user input system. Nobody types that fast.
:: Events from SDL should first be sent to GUI, then any unhandled events should be passed to input system. Not the other way around. However, modifier states will need to be monitored even for GUI handled events.
:: It may be advantageous to define a condition system instead of simple modifiers, so that action A is triggered only when condition B is true and event C occurs. So for example, to attack if lshift+A is pressed, but only if lctrl is not pressed use something like this: if ConditionAnd(left_shift_button_down, ConditionNot(left_ctrl_button_down)) casts to bool as true and KeyPressEvent[SDLK_a] is triggered, call player.attack_target();.

Development:Git repository

2009-07-04T06:58:25Z

LlubNek: Cloning: removed tmw-website from for statement. Website URL is of different form from other projects.

This page provides some information about our switch to git (which, as of Nov 14th, has been completed). As an initial comforting note, git really isn't so complicated as some people would have you believe. A few months ago I became familiar with distributed version control by using Mercurial, and since a few weeks we're using git at work. I think we'll benefit a lot from switching to it on the long run.

== The primary repository ==

=== Initial setup ===

With Git, we'll have one repository for each project. The central repositories through which we cooperate are hosted on [http://gitorious.org/ gitorious.org]. Gitorious is a friendly website that is also open source. On Gitorious the main repository for each project is called ''mainline''. Once you click to the mainline repository, you can see several ways to clone it (the new <code>svn checkout</code>).

We've categorized all projects related to The Mana World, so you can easily see the complete [http://gitorious.org/search?q=category%3Athe-mana-world list of The Mana World projects] on Gitorious. The projects have different clone URLs for read-only or developer access. The URL for developer access is called the "push URL", since it allows you to push commits into the repository via ssh. The list below is for your convenience.

{|border="1" cellspacing="0" cellpadding="5"
! Project
! Read-only URL
! Push URL (Developers only)
! Atom feed
|-
| '''[http://gitorious.org/tmw TMW client]'''
| git://gitorious.org/tmw/mainline.git
| git@gitorious.org:tmw/mainline.git
| [http://gitorious.org/tmw/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the client for The Mana World
|-
| '''[http://gitorious.org/tmwdata TMW client data]'''
| git://gitorious.org/tmwdata/mainline.git
| git@gitorious.org:tmwdata/mainline.git
| [http://gitorious.org/tmwdata/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the client data.
|-
| '''[http://gitorious.org/tmwserv TMW server]'''
| git://gitorious.org/tmwserv/mainline.git
| git@gitorious.org:tmwserv/mainline.git
| [http://gitorious.org/tmwserv/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the our own server.
|-
| '''[http://gitorious.org/tmwserv-data TMW server data]'''
| git://gitorious.org/tmwserv-data/mainline.git
| git@gitorious.org:tmwserv-data/mainline.git
| [http://gitorious.org/tmwserv-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains the data for TMWServ.
|-
| '''[http://gitorious.org/tmwweb TMW web frontend]'''
| git://gitorious.org/tmwweb/mainline.git
| git@gitorious.org:tmwweb/mainline.git
| [http://gitorious.org/tmwweb/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the web module for TMWServ.
|-
| '''[http://gitorious.org/tmw/website TMW website]'''
| git://gitorious.org/tmw/website.git
| git@gitorious.org:tmw/website.git
| [http://gitorious.org/tmw/website/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has our website.
|-
| '''[http://gitorious.org/tmw-eathena eAthena server]'''
| git://gitorious.org/tmw-eathena/mainline.git
| git@gitorious.org:tmw-eathena/mainline.git
| [http://gitorious.org/tmw-eathena/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository contains our hacked up eAthena.
|-
| '''[http://gitorious.org/tmw-eathena-data eAthena data]'''
| git://gitorious.org/tmw-eathena-data/mainline.git
| git@gitorious.org:tmw-eathena-data/mainline.git
| [http://gitorious.org/tmw-eathena-data/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has the data for our eAthena.
|-
| '''[http://gitorious.org/tmwart TMW Art]'''
| git://gitorious.org/tmwart/mainline.git
| git@gitorious.org:tmwart/mainline.git
| [http://gitorious.org/tmwart/mainline/commits/master/feed.atom Atom]
|-
|colspan=4|This repository has some sources for our artwork.
|}

Git uses ssh's private/public key authentication for identifying committers. For development purposes you should clone the "push url", but this requires that you have:

# Signed up to gitorious.org
# Generated a private/public ssh keypair (if you haven't got this already)
# Filled in your public key in your account details on Gitorious

=== Cloning ===

If you simply <code>git clone</code> the URL without any additional arguments, it will create the repository in a directory called "mainline". This is generally not what you want. Hence, after the clone url, you should pass the name of the directory you want to have created (just like with Subversion):

$ git clone <clone_url> project

If you want to have all projects in one place, you probably want to do something like this:

$ mkdir tmw
$ cd tmw
$ git clone git@gitorious.org:tmwserv/mainline.git tmwserv
$ git clone git@gitorious.org:tmw-eathena-data/mainline.git eathena-data
etc.
or for all of them in one go (after the cd tmw step):
$ for repo in tmw tmwdata tmwserv tmwweb tmw-eathena tmw-eathena-data ; do git clone git://gitorious.org/${repo}/mainline.git $repo ; done

The way Gitorious works, we can't have one top-level "tmw" project under which we put all these repositories, since they're really separate projects. Gitorious allows multiple repositories for each project, but they are clones of each other (you can only create new ones by cloning existing ones). This allows anybody (not just the development team) to make clones and start hacking on them. Changes can easily be merged from one one repository to another. So instead of all the inconvenience with TMW forks we had in the past, now comes the time to encourage people to clone!

==== Shallow cloning for non-developers ====

One of our repositories, tmwdata, has grown quite large cause of its long history filled with relatively large binary files. If you are only interested in getting the latest version, and have no need to be able to push back changes, then you can make a shallow clone:

$ git clone --depth 1 git://gitorious.org/tmwdata/mainline.git tmwdata

== Working with git ==

=== Commit ===

From now on, a commit is something you do locally. Others won't see your change on Gitorious unless you push it there. You'll notice committing is very fast, and you can commit multiple times before you decide to push. You can also make corrections to your last commit.

Before you start committing, it is important to identify yourself to git, so that it can include the correct authorship information with your commit. You are no longer identified with a username, as was the case with Subversion. You can read exactly how to do this, as well as other useful information geared towards people switching from Subversion, on this page:

* '''Git - SVN Crash Course:''' http://git.or.cz/course/svn.html

=== Pushing ===

Once you have committed some stuff, you can push these to the repository on Gitorious using <code>git push</code>. This works since by default the push command pushes to a ''remote'' called ''origin'', and this remote is automatically set up when you clone. However, the push will fail if there have been new commits on the remote repository. In that case, you'll first have to pull in these changes (just like with Subversion, however Subversion allowed this as long as the same files weren't touched, git doesn't).

=== Pulling ===

When you want to get the latest changes from the repository on Gitorious, you generally use <code>git pull</code>. However, note that this command does not work when you have local changes. Also, when you have local commits, the pull command will generate a merge commit (and before that you may have to resolve some conflicts).

If you don't want to create merge commits, but would rather stack your local commits on top of any incoming commits, you should use <code>git pull --rebase</code>. This ''rebases'' your local commits on top of the incoming ones. You should never do this when you have pushed these commits elsewhere, so only do it when you are sure the commits are only on your machine.

If you have local changes and want to update your checkout, then there are several options:

* You commit your local changes, and do a pull, optionally with --rebase.
* Or you use <code>git stash</code> to place your local changes on a "hidden" stash. Then, after pulling, you apply your changes again with <code>git stash apply</code>.
* Or you create a patch of your local changes that you apply again after the pull. This approach sometimes makes sense, but I would say in general it's the more clumsy way to go. There are git commands that help you with this though.

=== Resolving conflicts ===

Rather similar to Subversion. When there are conflicts, a merge or a rebase will add conflict markers into files. Use <code>git status</code> to see which files remain in conflict and use <code>git add</code> on files to mark them as resolved. When you did a merge and you have resolved all conflicts, you commit. When you were doing a rebase of several commits, you do <code>git rebase --continue</code> instead.

=== Patch making ===

Git has an easy way to send patches to other people to review and commit for you. After you have made a commit, <code>git format-patch</code> will make a patch out of it. The patch includes your author information the commit message you gave, and all the changes to be done. The recipient can just <code>git am [patch file]</code> to apply the commit. After it has been pushed, you'll need to remove the patch from your local repository, <code>git reset --hard HEAD^</code> will do that. If you don't do that, you'll get a conflict when your patch is pulled from the central repository.

=== Good to know ===

Git has several useful commands to figure out the current state of your repository, your files and what recently changed. Below is a non-exhaustive list of commands that are useful to know:

* '''git branch''': Without any parameters, this command lists your local branches, and indicates which branch you're currently on.
* '''git whatchanged''': This shows a list of all commits on the current branch similar to <code>git log</code>, but with a list of the files that have been touched in each commit as well.
* '''git status''': This shows all kind of things about your current checkout: which files changed, untracked (unknown) files, added or removed files, files that have conflicts (during merge), etc. It also shows the status of your index, which is what git will commit once you do <code>git commit</code>. If you're new to git I would recommend to wait a bit with learning how to use the index, but not to avoid it forever.

There are also additional applications that help you with using git:

* '''gitk''': A simple but effective tool that visualizes the history and some of your current state. Run with <code>--all</code> to have it show all branches, otherwise it will just show stuff relevant to your current branch.
* '''tig''': A textual interface, rather similar to an email reader.
* '''git gui''': A gui tool like gitk which helps you prepare and perform your commits. Also makes it easier to understand the index concept.

=== git on Windows ===

When using git on Windows you might use [http://code.google.com/p/msysgit/ msysgit]. If you notice that some files seem to have changed after doing a fresh clone, you may want to disable <code>core.autocrlf</code> using <code>git config core.autocrlf false</code>. However, this is not recommended for contributors since the setting makes sure you don't commit Windows style newlines into the repository. When encountering this problem it is usually best to consult other developers about the affected files.