It would be a great addition if variables could be used within scene descriptions, titles, and maybe actions too. I suggest to maybe rely on twig or at least use a similar syntax, we might be able to use their code:

You enter the shop of {{ Scene.Property.VendorName }}. 
They look at you,
 {% if Character.Property.Race == "dwarf" %} and start to smile. "A fellow dwarf, I see", they mumble
 {% else %} and look at you with distrustful eyes {% endif %} 
as they show you their wares.

During the changes for the modules and preparation of release 0.2, I've found that doctrine throws a DBAL Exception if a scene gets deleted which has connection groups associated.

Doctrine\DBAL\DBALException: An exception occurred while executing 'DELETE FROM scene_connection_groups WHERE scene = ? AND name = ?' with params [null, "lotgd\/module-village\/outside"]:

SQLSTATE[HY000]: General error: 1 no such column: scene

Issue stems from the fact that ViewpointRestoration class does not allow for empty SceneTemplate field, but Scene does.

Checkout https://github.com/lotgd/module-weapon-shop

Most of our fk columns in our entities have the snaky _id at the end. This seems to sometimes cause troubles with doctrine during remove cascade. In future, all fk column names need to be identical to their PHP property name.

Fixing this contributes to #86

These permissions should live in a database table, like a mapping between users and permissions. Permissions can be simply strings.

@nekosune is taking this for right now.

Is it possible to check https://github.com/stephenKise/Legend-of-the-Green-Dragon and see if there are things can people can collaborate with (for example code standardization)?

See title.

Situation: I'm navigating from scene A to scene B and the new day module redirects to the new-day page, it's important for the new-day scene to link back to scene B without causing a re-execution of the code.

This is even more important if I'm doing redirects within redirects (e.g., race selection @ newday).

Currently, administration of Daenerys is difficult as the core does only offer a limited range of console commands.

I suggest the addition of the following features:

• Possibility to create new scenes from the cli, and connect existing ones
• Game configuration
• Message threads and messages
• Edit Module properties
• Message of the day

    public function isNewDay(DateTime $lastInteractionTime): bool
    {
        if ($lastInteractionTime == null) {
            return true;
        }
        $t1 = $this->gameTime();
        $t2 = $this->convertToGameTime($lastInteractionTime);
        $d1 = $t1->format("Y-m-d");
        $d2 = $t2->format("Y-m-d");
        return $d1 != $d2;
    }

$lastInteractionTime cannot be null, yet the function checks for this value.
Suggested fix: Change DateTime to ?DateTime.

Currently, if an error occurs during registering of a module, the module still is partially installed (it gets a database entry in the table module), while not saving the parts added in onRegister. This makes manual intervention necessary.

Build this on top of Symfony's console library (https://packagist.org/packages/symfony/console).

Brainstorming initial commands:

daenerys modules:validate: check the existing module setup for issues (like event subscriptions).
daenerys modules:freshen: setup any uninitialized modules and repair any issues found (like event subscriptions).

Hmm, I need to think about this since I want this command to also be used by module developers to automate tasks. Might just defer those issues until later.

I'm going back on my original decision to do soft deletion b/c it will make everything more complex to reason about.

Currently, characters and modules have properties. Both have them to allow arbitrary values, an important point when writing modules for Daenerys. Scenes should also get their own properties for the same reason: It would allow upon the creation of a scene to set scene-specific values. These values could be used for:

• Specific settings for that Scene, such as the name or the inventory list of a vendor. Imagine Pegasus and MightyE to be the same scene template!
• Scene-specific states. Examples might be a simple fountain scene were players could donate money, with the current amount being fountain-specific.

You can use something like https://github.com/vierbergenlars/php-semver

This is so modules can add things to the DB when they are installed and uninstalled, like scene data.

Module interface should also implement EventHandler since modules handle events.

1. Have it log to the Game's monlog instance.
2. Figure out some way to incorporate third-party event handlers in a flexible way, like Bugsnag.

Make bin\daenerys extensible so that crate's can take that console application and extend upon it. It's desirable that, if a crate wants to offer additional console commands, that it can extend upon the core's console application to have a common interface for the end-user.

Take the empty crate-www repo (https://github.com/lotgd/crate-www) and set up a basic crate to serve as a wrapper for the core game.

To make much progress, we need the core to support scenes, but you could at least start with some kind of basic authentication system.

@Vassyli: have a preference for web framework here?

lotgd/core requires monolog/monolog to be of version 1.16.0 which is incompatible with symfony 3.1 which accepts ^1.12. monolog/monolog 1.16.0 contains a missing method which is why it's incompatible.

ActionGroups and Actions loaded from the database (viewpoint.action) do not have the reference set to the viewpoint upon deserialisation.

So far, the entity registration for doctrine is encapsulated in LotGD\Core\Bootstrap::createGame. We need a method to add additional directories for doctrine to search for entities.

We should supply handleEvent as well with the module entity in order to access properties. This already is the case for onRegister/onUnregister. There are 2 possibilities:

• we provide the module in the context array
• we provide an additional parameter just as with onRegister/onUnregister. The function signature should be compatible as long as we add a parameter to the end of the function.

    public function getConnectionGroup(string $name): SceneConnectionGroup
    {
        return $this->filterConnectionGroupCollectionByName($name)->first();
    }

CollectionInterface->first() returns false if the collection is empty, causing PHP to throw a TypeError.

There are a few entities left that have snake_case column names instead of camelCase ones. This needs to be changed to conform to our coding standards.

Replace the vagrant instructions w/ a docker image that we host somewhere. This would make getting the dev environment set up easier.

It's time to improve the module system.

• Track module versions, and offer an upgrade path
• Offer a module:config command that modules can utilize.
• Add the possibility to deregister an existing module, making it self for removal.
  • Maybe prevent composer from removing if not deregistered. Doable?

See #61

Hello, please can you get 'timmyboyox' approved on DragonPrime.
Waiting for admin approval and been contacting for days but no one is answering or accepting!

Since PHPUnit 7 is out for a while, we'd like to use it instead of PHPUnit 5.7 due to it being up to date with PHP7. However, direct migration is impossible since test recognition relies on extending from the correct base class (which, in this case, still is PHPUnit 5.7). Additionally, some dependencies seem to rely on PHPUnit 5.7 still and don't work together with PHPUnit 7.

This seems like a weird bug for me, but I am not able to run two independent test files in module/new-day without data infererring with each other, while in the core it seems to work without any issue at all...?

Build a $game->getLogger() method that returns an instance of Monolog.

Initially, make a rotation file logger (pick one of Monolog's built-in ones).
Set up an environment variable called LOG_DIR or something to specify where the logs should go.

Use the adjacency list structure: change parent to parents basically.