We will publish all changes and clarifications made to the specification in this thread.
In specification page 13 line 14ff, we need to make an adjustment:
Instead of
Once an order is placed by the customer, it is immediately registered in the kitchen, the order is queued, and the ingredients are reserved in the exact amount required by the recipes. The remaining portions ...
it should be
Once an order is placed by the customer, it is immediately registered in the kitchen, the order is queued, and the ingredients are reserved in the exact amount required by the recipes. **When selecting ingredient packages, open packages are given priority, followed by packages with the earliest best-before date.** The remaining portions ...
6 Likes
There were some small mistakes in the JSON objects provided in the Appendix. In Listing A.1, the customer group with id=5 should only have a single restaurantTypes property with "restaurantTypes": ["AMERICAN"]. In Listing A.2, the customer group with id=6 should have "foodPreferences": [{"size": 16, "excludedIngredients": ["chicken","potato"]}], as food preference.
In total, the customer groups should look like this:
A1 25-32 should be:
25 {
26 "id": 5, "type": "CASUAL", "size": 2,
27 "restaurantTypes": ["AMERICAN"], "deliveryDistance": 10,
28 "visitingEvenings": [30,34], "visitingTick": 6,
29
30 "foodPreferences": [],
31 "ratingLikelihood": "SOME"
32 }
A2 should be:
37 {
38 "customers":[
39 {
40 "id": 6, "type": "EVENT", "size": 16, "tableType": "COMMON",
41 "visitingTick": 4,
42 "restaurantTypes": ["EUROPEAN","AFRICAN"],
43 "foodPreferences": [{"size": 16, "excludedIngredients": ["chicken","potato"
44 ]}],
45 "eventEvening": 35,
46 "favoriteDishes": {"EUROPEAN": "potato soup"},
47 }
48 ]
45 }
On page 33, there is a typo in the log that describes the ordering process. For EVENT groups, where multiple waiters may take orders.
So, instead of:
[IMPORTANT] FOH Ordering (R $restaurant:id): Group $group:id placed
order $order:id of $dish:NameToAmount with waitstaff $waitstaff:id.
it should be
[IMPORTANT] FOH Ordering (R $restaurant:id): Group $group:id placed
order $order:id of $dish:NameToAmount with waitstaff $waitstaff:ids.
There is a minor issue in the definition of a waiter’s current load on page 15 line 25ff:
Instead of:
The current load is the amount of customers a waiter is waiting on, so any customer this waiter has SEATED before they are ESCORTED out of the restaurant.
it should be:
The current load is the amount of customers a waiter is waiting on, so any customer this waiter has SEATED before those customers **either left or were** ESCORTED out of the restaurant. **Customers leave without being ESCORTED for example if they cannot order a dish or if they have to wait too long for their meal.**
1 Like
For the log of the Seating Status on page 33f, there is a need for clarification:
The summary of the seating counts the number of tables that waiters seated customers on. Merged tables only count once toward that number.
So, instead of:
As a summary, the simulation logs the SEATING and TAKING ORDERS done this tick. First is the seating based on the number of waitstaff performing seating and the number of customers being seated and the number of (merged) tables on which they were seated. Status logs like this one only log successful attempts, so failing attempts for SEATING or taking an ORDER from a customer don’t count in either the waitstaff, customer or table number.
it should be:
As a summary, the simulation logs the SEATING and TAKING ORDERS done this tick. First is the seating based on the number of waitstaff performing seating and the number of customers being seated and the number of tables on which they were seated. **Merged tables only count once toward that number.** Status logs like this one only log successful attempts, so failing attempts for SEATING or taking an ORDER from a customer don’t count in either the waitstaff, customer or table number.
There is a clarification delivery orders on page 17, lines 15–18.
Instead of:
For deliveries, the meals queue until all meals of an order are ready and a driver is free. Then, all waiters with a SERVING tick load below the action limit deliver meals to the drivers waiting outside the restaurant until their limit is reached or the condition is negated. The waiters with the lowest id starts, and the order with the lowest id takes precedence.
it should be:
For deliveries, the meals queue until all meals of an order are ready and a driver is free. Then, the waitstaff manager orders all waiters with a SERVING tick load below the action limit to deliver meals to the drivers waiting outside the restaurant until their limit is reached or the condition is negated. The waiters with the lowest id starts, and the order with the lowest id takes precedence. **For this action, a waiter can deliver meals for one or multiple orders, even if the waiter cannot deliver the whole order. Therefore, multiple waiters may need to deliver meals for a single order to a driver, or waiters may need to deliver meals for a single order across multiple ticks, with delivered meals being stored with the delivery driver.**
2 Likes
There is a minor issue in the validation of ingredient unavailable incidents on page 30 line 9.
Instead of:
The duration of ingredient unavailable incidents must not overlap.
it should be:
The duration of ingredient unavailable incidents must not overlap **for the same ingredient**.
Here is a small clarification for page 20 line 34ff.
Instead of:
Those customers wanting deliveries decide on a restaurant and make their order early. They factor in the delivery distance and add 3 ticks for cooking. This way, an order that will be cooked immediately can always arrive at the visitingTick.
it should be:
Those customers wanting deliveries decide on a restaurant and make their order early. They factor in the delivery distance **by subtracting the number of ticks a driver would need to drive from the restaurrant to the group and subtract** 3 ticks for cooking. This way, an order that will be cooked immediately can always arrive **before or at** the visitingTick.
1 Like
There is another small mistakes in the JSON objects provided in the Appendix. In Listing A.1, the restaurant object should include "event": true.
2 Likes
Here is a clarification regarding the ordering of CASUAL customers that want a delivery.
The browsing system assigns a restaurant based on the restaurants’ recipes.
The ordering process is analogous to the visiting groups:
After being assigned a restaurant, the groups will order directly at the restaurant based on available dishes. In case customers within the group could not order, they use the log [IMPORTANT] FOH No Ordering (R $restaurant:id): Group $group:id could not place an order for $customer:number customers, they leave the restaurant..
There is a clarification to page 22, lines 18f:
Instead of: Customers with a delivery order wait until 3 ticks after the tick when they wanted it to arrive, afterward they abort their order.
It should be: Customers with a delivery order wait until 3 ticks after the tick when they wanted it to arrive, afterward they **reject the delivery**.
1 Like
There is a clarification for page 24 lines 17f. `
Instead of: For EVENTS, this means that after this decision has been made, the customer group makes a reservation at the restaurant immediately.
it should be: For EVENTS, this means that after this decision has been made, the customer group **contacts the restaurant immediately. The restaurants make note of the event, but they will not make reservations until the eventEvening, at which they will assign tables and notify the group if there is no table.**
Here is an adjustment for the JSON scheme of the recipes on Figure 5 on page 19:
Recipe
• id (id ≥ 0) The unique identifier of the recipe.
…
• ingredients (array of
(name : ingredient : name, amount : int > 0 ))
The list of ingredient names with their unit and integer amount.
…
There is a clarifcation for the browsing system behavior at the end of the opening time, on page 24 lines 2ff:
Instead of:
• for CASUAL groups whether the restaurant is currently open
• for EVENTS groups whether the restaurant will be open at the visitingTick of the eventEvening
it should be:
• for CASUAL groups whether the restaurant is currently open **and not within the last 3 ticks of its opening time**
• for EVENTS groups whether the restaurant will be open at the visitingTick of the eventEvening **and not within the last 3 ticks of its opening time**
There is a clarifcation for the restaurant behavior at the end of the opening time, on page 25 lines 2ff:
Instead of:
A restaurant does not accept new customers in the last 3 ticks of their opening time.
If a restaurant has reached the end of the opening time and customers are still inside, you can assume that they are all escorted outside immediately.
it should be:
A restaurant does not accept new customers in the last 3 ticks of their opening time. **This includes customers that arrived in the previous tick but could not be seated.**
If a restaurant has reached the end of the opening time and customers are still inside, you can assume that they are all escorted outside immediately**, without the waiters having to do an action.**
There is a clarification for the logging with regard to the opening and closing times of restaurants.
In the ticks before a restaurant’s openingTickStart, the simulation will not log any action or action status messages. This means that between the log messages
[DEBUG] Restaurant Start (R $restaurant:id): Restaurant $restaurant:id simulates a tick.
and
[DEBUG] Restaurant End (R $restaurant:id): Restaurant $restaurant:id finished simulating the tick.
there will be no log messages.
In the ticks after a restaurant’s openingTickEnd, the simulation log only some action or action status messages. Those are:
- All delivery-related logs, mentioned in the Section “Delivering”, if required that tick
- All eating-related logs, mentioned in the Section “Eating”, if required that tick
- The eating status log will be logged every tick
- All rating-related logs, mentioned in the Section “Ratings”, if required that tick
- The rating status log will be logged every tick
To simplify the simulation, we add the following validation constraint, which must be validated in the same way as the validation constraints presented on page 29 and page 30:
- The visiting tick of regular customer groups must lie within the opening times as follows:
openingTickStart <= visitingTick <= openingTickEnd - 3
There is a clarification for page 35, lines 26ff:
Instead of:
The following logs describe the delivery process. The logs will be presented in sequential order from the perspective of the driver, but not all will be performed for every driver / order in a single tick. Each of the subsequent logs will be logged for all drivers that require that log, in order of ascending group id, and then the next log will be output.
it should be:
The following logs describe the delivery process. Not all logs will be necessary for every driver / order in a single tick. Each of the subsequent logs will be logged for all drivers that require that log, in order of ascending group id. **Only then, the next of those logs may be output.**
2 Likes