Allow players to buy and sell materials

[darozak]

I recently added a section to the Design Manual that describes how trade will be handled in Ex Machinis.

Basically, drones use protocols to post buy and sell orders, which allow other drones to add or remove resources to or from their cargo holds in exchange for money. These orders place both limits and costs on the transfers of specific materials between drones and can be updated at any time.

If one player's done attempts to add or remove resources from the cargo hold of a drone that belongs to another player, the Event Engine will first confirm that the transfer is taking place within the limits that were previously set by the target drone. If the transfer is permitted, the Event Engine will create transfer events for both the resource and money (credits).

This logic needs to be implemented in the Events Engine. But first, I need to document one or two examples, which demonstrate how market orders are placed by one drone and acted upon by another.

[darozak]

I've begun working through an example of how a sell order will work. The process will become clearer once I define the the specific protocols that will be used to place market orders and transfer materials between ships. I also need to work through the details of how credits will be transferred between players.

[darozak]

I've modified the procedures for the Event Engine to follow when ensuring that items are added and removed from another player's cargo hold in accordance with existing buy and sell orders. The new routine will be invoked whenever a drone tries to add or remove resources from the cargo hold of another player's drone. The Event Engine will insure that added or depleted materials a permitted under the terms of an existing market order. If so, the Event Engine will create contemporaneous events which transfer money between players in accordance with the market order.

I've also added an example which demonstrates how one player creates a sell order and another player responds to it by placing the desired goods into that player's cargo hold.

Please review and comment on the proposed mechanism. Thanks!

[crodnun]

Hi Dave, I started working on this and (as usual ;-)), here you have my doubts:

1 - Now that we are going to sell and buy resources, is there any amount of credits that each user will have as default? Is this amount distributed per drone/per player? This starts a new topic, how we deal with money within the game, at the user's level or at the drone's level, lol. I guess that not important now, but interesting for the future to think about this.

2 - After reading your documentation, I envisage 2 new protocols, the selling protocol and the buying one. The selling part seems clear for me (3 params: resource, min amount to keep and price), but the protocol required to buy is not detailed in-depth, I mean: as a user, how I can select what to buy, amount, where to buy - the selected seller - (each seller can have different prices if different drones are selling the same resource at the same location). Could you detail a bit more this part at stack and protocol level, parameters received, etc?

3 - You mention at the docs that it is possible for the credits to be negative, but one of the conditions we validate (a rule we added a long time ago to accept or reject an event) when processing events is:

//d. The player has insufficient credits to cover the purchase price of transferred items.

What would be the approach here?

As usual, these are the initial doubts to go deeper into this part and help me to implement it, let me know your thoughts regarding the same.

[darozak]

Hi Carlos. Great questions. Hopefully I can provide you with clear and unambiguous answers.

1. Yes. For now, each player should start with 1000 credits. The credits belong to the player and not the individual drone although any of the drones can add to or remove credits from their owner's bank account in response to successful market transactions. In fact, current credits are recorded in the user table. They will also be recorded in events when those events cause a change in the amount of money contained in a player's account.

2. You need to envision market transactions as two separate events. In the first part of the transaction, a drone that has materials to sell or has materials that it needs to buy places sell or buy bids that other drones can respond to. Sell orders take three params, which set the resource, min amount to be retained in the drones cargo hold after sales, and the price per unit. Buy orders also take three params to set the resource, max amount to be held in the cargo hold (including pre-existing amounts), and the price per unit. The buy and sell orders are like wanted ads that are put in the DB for any other drone to see and respond to. In the second part of a market transaction a second drone sees one of these wanted ads and adds or removes a certain amount of material from the first drone's cargo hold in direct response to a buy or sell order (ie. wanted ad) that the first drone might have posted. The second drone is permitted to add or remove as much resource as they want from the first drone's hold provided the action complies with the limits set by one of the first drone's buy or sell order. The event engine polices this transactions by ensuring that the addition or depletion event complies with an existing buy or sell order and that the correct amount of money changes hands after the action has been competed.

3. I've decided that we will allow a player to have negative credits. Neg credits will be treated as a loan from the bank, which will incur interest charges (an issue we'll tackle later). I remove the clause which prohibits negative credits from the design manual. Will this condition be hard to reverse in the game logic?

I hope my answers make sense.

[crodnun]

Hi Dave, I have started to push this stuff today, and more doubts came to my mind. I detail firstly what I have done so far and then will describe my doubts.

1- I have created 2 new protocols in DB:

|  7 | Sell Resource   |          3 |           100 | [P M R 7 perform]: Places order to sell resource R at price P, keeping min M units at drone's cargo hold. |          1 |          1 |          0 |
|  8 | Buy Resource    |          3 |           100 | [P M R 8 perform]: Places order to buy resource R at price P, keeping max M units at drone's cargo hold.  |          1 |          1 |          0 |
+----+-----------------+------------+---------------+-----------------------------------------------------------------------------------------------------------+------------+------------+------------+

2 - Have added 2 new event types (to identify sell and buy events):

mysql> select * from event_types;
+----+------------------------+
| id | name                   |
+----+------------------------+
|  1 | Increment inventory to |
|  2 | Decrement inventory to |
|  3 | Move to                |
|  4 | Sell resource          |
|  5 | Buy resource           |
+----+------------------------+

3 - Have added some initial market_effects:

mysql> select * from market_effects;
+----+----------+------------+----------+-------------+----------+-------+------+
| id | protocol | event_type | resource | upper_limit | quantity | price | time |
+----+----------+------------+----------+-------------+----------+-------+------+
|  1 |        7 |          4 |        1 |           0 |       10 |     1 |    0 |
|  2 |        8 |          5 |        1 |           1 |      100 |     1 |    0 |
|  3 |        7 |          4 |        3 |           0 |       10 |     1 |    0 |
|  4 |        8 |          5 |        3 |           1 |      100 |     1 |    0 |
+----+----------+------------+----------+-------------+----------+-------+------+

4 - We are able to process "sell commands", like the following:

<run>1 1 1 7 perform</run>

This means, place an order to sell resource 1 (carbon ore), keep always 1 unit onboard and sell it with price 1 (credits).

5 - The game engine receives this event, looks for market-effects entries associated with this protocol and resource but for the moment does nothing, just inserts the following entry at events table:

mysql> select * from events;
+-----+------------+--------+--------+---------+-------+----------+-----------+--------+--------------+-------------+--------------+------------------+-----------+---------------------+
| id  | event_type | action | logged | outcome | drone | resource | installed | locked | new_quantity | new_credits | new_location | new_transmission | new_cargo | timestamp           |
+-----+------------+--------+--------+---------+-------+----------+-----------+--------+--------------+-------------+--------------+------------------+-----------+---------------------+
| 148 |          4 |    185 |      1 |       1 |     1 |        3 |         0 |      0 |           10 |          10 |            1 |             NULL |      NULL | 2020-02-12 07:50:03 |
+-----+------------+--------+--------+---------+-------+----------+-----------+--------+--------------+-------------+--------------+------------------+-----------+---------------------+

You can see here that we set the following fields:

• Event_type = 4 (Selling resource)
• Outcome = 1 (OK)
• new_quantity = quantity received at the command
• new_credits = price received at the command
• new_location = current drone location (this was added by me to identify the location where somebody is selling this resource)

And now the doubts:

1) Could you detail a bit more in your example how the market_effects affect the sell/buy order?, I guess that you want to use this table as a rule that limits the amounts/prices somebody can buy/sell, but not clear for me how to apply this before inserting the event in DB. It would be really helpful if you can detail a bit more how you want to combine the market_effects table with buy and sell orders.

2) As you noticed, I have included the location information in the sell event, but not sure how you would like to deal with this. If a drone moves to another location, the sell order should be updated with the new location of the drone, or just assume that the drone left the resources at the original location and a sell order never changes its location once placed.

3) The buying part is also not clear for me, after reading the docs. I understand that this protocol has no market_effects parts, but not sure if it generates a dummy event (buy event) or not, before generating the transaction events. I would need to detail a bit more what will happen here to develop this part: since the user sends the command by email until the transaction is done, tables involved, events generated, etc,... as far as I see, there are 4 events, 2 related with credits and 2 involving resources,... so we should specify this requirement a bit more.

[darozak]

Hi Carlos. It looks like you've made good progress! Let me see if I can address your questions about the market system:

1. The market_effects table only logs the buy and sell orders. It does nothing more. The event engine doesn't need to do anything to modify the event other than mark it as active and create a corresponding observation table entry to ensure that the central database (drone id = 0) sees the event. It doesn't even need to confirm that the required resources are available in the drone's cargo bay. The physical exchange of resources and credits takes place at a later point in time when another spacecraft tries to add or remove the specified resources from the drone's cargo bay by using a protocol that invokes the resource_effects table. We'll deal with the physical transfer of materials later.

2. You don't need to track the spacecraft's current location as part of the market_effects event. The current location is already updated in the agent table whenever the drone changes locations.

3. I think it will best to break coding the market mechanism into two distinct coding tasks. The first will be to set up the event engine so that it responds to new market_effects events as described here, entering them as active events and sharing them with the central database. Once that is done, I'll work with Fernando to generate a page which shows all active buy/sell events for a given resource. We'll also ensure that players can place and update these orders through their spacecraft. Once this is humming along, I'll help you implement the protocols and logic that actually facilities the exchange of resources and money. I have a feeling it will make much more sense at that point.

I hope this makes sense. I think that breaking this task into two parts will really help. For now, just get the system to the point where players can create buy and sell orders via their drones and the orders are observed by the central database.

Dave

[crodnun]

Uppps ... I think that this explanation generated more doubts, lol.

If I understood, your goal is to store at market_effects the orders? So this table is empty by default at startup and then we populate it with a new entry each time we receive an order?... this breaks a bit the way we deal with the rest of effects (static info there). Am I correct?

No problem removing the location, neither breaking the logic into pieces, as far as I can understand it, lol.

Could you detail a bit more the place order logic (sell and buy), in special regarding the market_effects table... normally the effects were static data, but seems that not now. This is breaking a bit the rest of the logics, where we (as part of the protocol execution), apply the effects present in tables to generate the event. This part of using the table as "log" storage is really confusing for me.

[darozak]

Sorry for the confusion. Let me try to clarify.

The market_effects table is a static table just like resource_effects. This means that it's contents will be set at the start of the game and can only be updated by the admin. There will generally only be two entries in market_effects, one for creating a buy order and the other for creating a sell order. As with some resource_effect entries, the market_effect entries will generally contain negative values for resource, quantity, and price fields, indicating that the game engine will pull the actual values for these fields from the stack when executing the perform function.

When a player uses a perform command to invoke a protocol which is linked to a market_effects entry by the market_effects.protocol field, the game engine will use the market_effects entry, combined with parameters that are pulled from the stack, to create a new event. The new event will contain the details of the buy or sell bid, indicating the resource, quantity, and price in the events.resource, events.new_quantity, and events.new_credits fields, respectively.

When the events engine finds this event, it will mark it as logged (events.logged=true) and create a new observations table entry that links the event to the central DB by setting observations.drone equal to zero. This is all the events engine needs to do with events that represent buy/sell bids.

Now the player will be able to search the central database (via the website or query command) to identify valid buy and sell bids associated with a particular resource. They will also be able to identify the current location of the drone that is placing the bid and fly to that location to exchange materials and credits. However, we'll deal with the actual transfer of goods a little later.

I hope this clarifies things. Just to summarize: The market_effects table starts the game with entries and is not affected by player actions. Rather, when linked to a particular entry in the protocols table, it instructs the game engine to retrieve parameters from the stack (by use of negative values in the resource, new_quantity, and new_credits fields) and use those values to create a buy or sell bid event (in the events table) for the specified resource, quantity, and price. When the event engine encounters this event, it doesn't need to perform any checks. It simply needs to mark the event as logged and link it to the central DB via the observations,drone field. This will allow players to identify buy and sell orders in a DB search.

[crodnun]

OK Dave,

I think that we have this first part of the logic in place, at least to let you play around with Fernando.

We should be able to insert sell/buy events and generate the corresponding observations entries.

Feel free to play around with the same. The 2 protocols defined are the following:

|  7 | Sell Resource   |          3 |           100 | [P M R 7 perform]: Places order to sell resource R at price P, keeping min M units at drone's cargo hold. |          1 |          1 |          0 |
|  8 | Buy Resource    |          3 |           100 | [P M R 8 perform]: Places order to buy resource R at price P, keeping max M units at drone's cargo hold.  |          1 |          1 |          0 |

You can invoke them from email as follows:

<run>3 2 1 7 perform</run> 

Sell resource 1, keep 2 units onboard, unit price 3

<run>3 2 1 8 perform</run> 

Buy resource 1, get 2 units, buying unit price 3

For the moment that's all:

• We insert events
• Set their outcome to OK
• Generate the observation entries at DB for these buy/sell events.

Let me know if this is enough for the moment. Next step would be to specify a bit more how we want to deal with the buy/sell part & resources/credits update.

[darozak]

Help. I think I broke it :(

At 11:07 AM ET I successfully moved Sport@advolition.com to the Sun:

<run>
0 5 perform
</run>

At 11:09 AM ET I attempted to mine Iron Ore from the Sun:

<run>
1 perform
</run>

I got a fail error:

---- Position ----

At: Sun
Distance: 8.199748 light-minutes

---- Output ----

Protocol "Mine Iron Ore" failed

Subsequently simple math commands ( like 2 3 + .) work but all perform commands (move to, mine, etc...) result in a fail.

Checking the droplet usage states shows they spiked at 11:09 AM and haven't come down since:

The events engine log is spewing the same error:

And the stop script won't work:

Any thoughts on what caused the events engine to derail like this?

[crodnun]

Hi Dave, not available till Saturday night, but my guess is that us a bug I already fixed long time ago, an infinite loop when moving to Sun. My advice would be to restart the server or just execute this comnand against the engine processes.

kill -9 pid being pid the PID of the process.

[darozak]

Thanks Carlos. Resetting the server and moving the spacecraft away from the sun fixed the problem.

[crodnun]

We have still pending here to implement the transaction part of this feature: after inserting events, deal with credits and logic money's stuff

[darozak]

Correct. We can tackle this once we've addressed the bugs associated with cargo tallies and transferring materials between ships. Both features will be needed to support market transactions.On Mar 3, 2020 4:41 PM, Carlos Rodriguez Nuñuez notifications@github.com wrote:We have still pending here to implement the transaction part of this feature: after inserting events, deal with credits and logic money stuff

—You are receiving this because you were assigned.Reply to this email directly, view it on GitHub, or unsubscribe.

[darozak]

Carlos,

I added a couple of protocols to the DB (numbers 10 and 11), which allow one drone to push or pull cargo to or from another spacecraft. These work by depleting the resource in one drone and incrementing it in another.

However, right now there are no limits on this process and one player can easily use these protocols to steal resources from another.

The last part of the market mechanism will require the Event Engine to regulate when a one player's drone can use protocols 10 or 11 to remove or add resources from another player's drone. .

This will require the Event Engine to recognize when one player's drone is attempting to increment or decrement a resource in another player's cargo, When this happens, it will ensure that the action does not increase or decrease the amount of resource in the cargo bay above or bellow the limits that the other player's drone set in a market order if one exists. If a market order doesn't exist then the increment or decrement event will not take place.

If the increment or decrement event takes place, the Event Engine will also need to transfer credits between players to complete the transaction. The amount of credits that are exchanged will also depend on the conditions set by the market order if it exists.

I've updated the market section of the design manual in an effort to clarify this process and describe how credits will be transferred between accounts. Please review this and let me know if you have any questions. I hope it makes more sense now that market order and transfer protocols are in place and all we need to do is code the Event Engine so that it uses one to regulate the other.

[crodnun]

OK Dave, coping with codvid19 here but hope to take care of this issue along this weekend. Under lockdown for weeks here :-), a bit lost these days with the new situation but will retake this soon.

[crodnun]

Hi @darozak , one doubt regarding the latest protocols you added.

Checking the DB, I see the following new entries:

| 10 | Push Resource    |          2 |           100 | [Q R D 10 perform]: Delivers Q units of resource R to drone D.                                            |         -1 |         -1 |          1 |
| 11 | Pull Resource    |          2 |           100 | [Q R D 11 perform]: Pulls Q units or resource R from drone D.                                             |         -1 |         -1 |          1 |

Notice that the 3rd field says that the protocol expects 2 parameters but at description we expect 3 , is this correct or should we put there a 3?

As far as a see, we need to retrieve from the stack the D (drone), the R (resource) and the Q (quantity).

[crodnun]

Another doubt that I have is regarding how we can identify these new protocols univocally not hardcoding the 10 and 11 values inside the software.

We know that when they are executed, they generate a pair of events each:

+----+-------+----------+----------+------------+-------+-----------+--------+---------+-------------+----------+------+
| id | drone | resource | protocol | event_type | local | installed | locked | deplete | abundancies | quantity | time |
+----+-------+----------+----------+------------+-------+-----------+--------+---------+-------------+----------+------+
|  8 |     0 |       -2 |       10 |          2 |     0 |         0 |      0 |       1 |           0 |        1 |    0 |
|  9 |    -1 |       -2 |       10 |          1 |     0 |         0 |      0 |       0 |           0 |        1 |    1 |
| 10 |    -1 |       -2 |       11 |          2 |     0 |         0 |      0 |       1 |           0 |        1 |    0 |
| 11 |     0 |       -2 |       11 |          1 |     0 |         0 |      0 |       0 |           0 |        1 |    5 |

We know the event type, but we can not identify univocally when these effects are due to a buy/sell operation and when it is just us loading or depleting our cargo. I do not see clearly how this can be identified inside our logic.

No problem at all hardcoding the condition at logic, but is not an elegant solution for the same, how we could identify them?

Maybe we should identify this type of events with something like "commercial transaction" or something like that, what do you think?

[darozak]

Hi Carlos. Things are shutting down here as well to combat the virus. All restaurants and bars are closed and many people are working from home. It won't be long before all of us are also confined to our homes. I hope that you and your family are staying safe and healthy.

With respect to your first concern, the third parameter, quantity, is automatically accounted for by the action multiplier, which is set to true (protocols.multiplier=1).

In regards to your second question, the Event Engine will be triggered to regulate increment/decrement events based on market orders whenever it sees an increment/decrement event that is being initiated by one player's drone and affects another player's drone. If an increment/decrement event affects the same drone that initiated the action or another drone that is owned by the same player, then the market orders will have no effect on the event.

This means that the Event Engine doesn't even need to be aware that a push or pull protocol is being invoked. It only needs to recognize that the owner of the drone that initiated the action to which the increment/decrement event is linked is different than the owner of the drone whose inventory is being affected. Basically, from the Event Engine's perspective, one player can not affect another player's inventory without a market order giving them permission to do so.

I hope this makes sense. But please let me know if anything needs further explanation, Thanks for your help with all this!

[crodnun]

OK, crystal clear now, I hope. just my head that was not focused on this at the moment I dropped the question.

[crodnun]

Hi Dave, the core logic for this stuff is in place now at advolition server. I will need to create some email accounts to test the same, I noticed that I have always used my yahoo email, but for this, I will need more users and email accounts. Let me a couple of days to do the setup and review/fix issues and then it will be all yours. The situation is critical in Spain (lockdown has been extended for 2 weeks more - let's try to no go crazy after 1 month arrested), but family and friends are OK for the moment.

[darozak]

Hi Carlos. I'm excited to hear you've got the code in place! I guess it will require multiple accounts to play test. I'll be happy to jump in and test the system when its ready. Just let me know.

I'm glad to hear your family and friends are well. I worry most about my parents who are getting up there in age. But they're being careful to limit their public activities, which is good.

[crodnun]

Hi Dave, the great moment is here!, a pleasure to say that the sell/buy logic is mature enough to let you play around. I have done some basic testing, selling/buying resources, fixed some bugs and seen that at least the OK paths are working. I will continue testing on my own but feel free to jump in and test it and of course, report issues as usual that I am pretty sure that there will be.

Two main concerns at my side:

• We specified that we need to move to a given location to buy/sell (the location where the order was placed), but this is not taken into account right now at the game, we have no way to determine yet if the user is buying at the location expected, so, for now, you can buy/sell from any location (is not a mandatory condition and we should deal with this at a later stage).

• I have added credits for all users at DB (users.credits): 1000 for everybody. This is another point to take into account, how many an when we top their accounts. A good moment could be at registering but I let you decide the same, just take into account that everybody has 1000 now, and I added them manually.

Enjoy it!

Last but not least, my best wishes to you and yours, we will defeat this together! but for the moment the only way to combat this is isolation, I wish you strength!!! my parents are in their 80's, time to fight for them.

[darozak]

Fantastic!! I can't wait to play around with it. I'll let you know if anything comes up in the play-tests. I'll address your questions about spacecraft locations and starting credits in separate issues. These are both good points that I had considered previously but need to work out the details on.

As bad as this virus is, I'm hoping it will bring us all a little closer as we fight this together! Stay healthy.

[crodnun]

Hi Dave, just one comment. Implementing these protocols where 2 events are involved, I added a new outcome value (-9) to the list (just in case you want to document this new value):

// Outcome values
typedef enum
{
    OUTCOME_OK = 1,
    OUTCOME_NO_OUTCOME = 0,
    OUTCOME_NO_LOCAL = -1,
    OUTCOME_NO_RESOURCES = -2,
    OUTCOME_NO_CARGO_SPACE = -3,
    OUTCOME_NO_CREDITS = -4,
    OUTCOME_RESOURCES_LOWER_LIMIT = -5,
    OUTCOME_RESOURCES_UPPER_LIMIT = -6,
    OUTCOME_WRONG_DEPLETION_PRICE = -7,
    OUTCOME_WRONG_ACCUMULATION_PRICE = -8,
    OUTCOME_ACTION_ABORTED = -9,

If the action was already aborted, I put the new value there -9 to identify this condition. This happens when the first event of the sell/buy transaction fails, it does not make sense to execute the second and we set its outcome with this value.

[darozak]

Hi Carlos. I've been trying to test the system and am not getting any response to the emails I send to my drones. I can't even get my spacecraft to respond to a simple command like: 2 2 + .

I've tried different accounts, resetting the spacecraft (), and stopping and starting the system without success. I've confirmed that the Game Engine is running by watching the log. However, not even the log registers an email from my spacecraft. I even checked the ssl certificate and it is still current.

Not even emailing registrar@advolition.com provokes a response.

I do notice that the email_handler_20200328.log contains a lot of garbage. The log for the previous day appears to be fine.

Any idea what could be going on?

[crodnun]

Hi Dave, I have reviewed the same, here you have the explanation and some guidance to solve this in the future.

Just for your information, when this occurs, normally the description of the problem is at the top of every line logged by email handler.

The problem was generated here:

2020-03-28 19:21:11 : received mail with subject <b>register</b><br/><!DOCTYPE html><!-- Illuminate\Database\QueryException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column &#039;name&#039; cannot be null (SQL: insert into `users` (`name`, `email`, `updated_at`, `created_at`) values (?, david.rozak@darwinriver.com, 2020-03-28 19:21:11, 2020-03-28 19:21:11)) in file /var/www/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 664 Caused by Doctrine\DBAL\Driver\PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column &#039;name&#039; cannot be null

From my point of view seems that you started to use a new email, and this email does not provide the name or the php codes are not able to extract it from the email.

You can see there that we are trying to insert this entry:

SQL: insert into `users` (`name`, `email`, `updated_at`, `created_at`) values (?, david.rozak@darwinriver.com, 2020-03-28 19:21:11, 2020-03-28 19:21:11))

And name is not provided, so probably a good fix could be to obtain the name from the first part of the email address, when unable to obtain it. What do you think?

When this happens, the email handler crashes and we are not able to remove this email from the queue, (exception there), and we enter a loop, always reading the same email.

We should protect this PHP part somehow in order to avoid this again, my proposal would be to:

1-Fill a default value, when none present / we are not able to obtain it. 2- Catch the exception and try to remove the corrupted messages from email handler's queue.

The only solution, for now (without touching the system), is the following (it is what I have done to restore the system):

1- Stop the sytem 2- As root user, go to /var/mail and remove the inbox for both registrar and catchall, just remove the files present there for these users:

root@advolition:/var/mail# ls -tlasr
total 44
 4 drwxr-xr-x 14 root          root  4096 Jul  4  2018 ..
 0 -rw-------  1 root          mail     0 Jul 15  2019 root
 4 -rw-------  1 administrator mail  2320 Jul 23  2019 administrator
 0 -rw-------  1 forth         mail     0 Oct 20 20:29 forth
 8 -rw-------  1 registrar     mail  6849 Mar 29 01:12 registrar
24 -rw-------  1 catchall      mail 17421 Mar 29 01:15 catchall
 4 drwxrwsr-x  2 root          mail  4096 Mar 29 01:15 .

root@advolition:/var/mail# rm registrar catchall

3 - Remove/truncate huge log files generated (as forth user execute):

> cdlog
> rm email_handler_20200328.log email_handler_20200329.log

4 - Start the system again

So as a summary, we have a bug at the PHP codes when they are not able to retrieve the user's name. Feel free to decide what is your choice there, open a different issue for the same and assign it to me or Fernando if he is working at the PHP side now (just ensure that we do not modify codes at the same time).

Cheers! and go ahead with codvid19, we will defeat it!!!

[darozak]

Thanks Carlos! I'll create a new issue for the email handler and other things I might come across as I play test the new feature you put in place. I'm going to try tackling many of these myself because I really want to learn my way around the code that you and Fernando put in place. However, I'll likely reach out to you from time to time with questions or for guidance. I'm going to close out this particular thread and will address and adjustments that come up as separate issues.

I hope you and your family continue to do well in the midst of this pandemic. I hear Spain is being hit hard. Here in the US, our governor just issued a stay-at-home order, which means we can only leave the house for essentials.