I have an action, throwing, which is understood using "throw/chuck/lob/etc."
I have a noun, the log, which is understood using "log/trunk/wood/etc."
You can throw things, and throwing the log should behave the same as any other throw action... except when the user types the specific phrase "chuck wood", where the response should be "How much wood could a woodchuck chuck?".
Hilarious, I'm sure you'll agree!
In a similar vein, I want to respond to "throw party" with a special response; However, in this case party is not a noun in the game, so it should not be recognised in any other context and I don't really want to create a dummy object for it.
How do I implement the responses above?
Do I need to use a different technique for the first and second case (i.e. where the noun is an object in the game vs. when it is just 'some text' with no associated object)?
How do I implement the responses above?
After reading a command:
if the player's command matches "throw party":
say "I'll bring the appetizers!";
reject the player's command;
if the player's command matches "chuck wood":
say "How much wood could a woodchuck chuck?";
reject the player's command.
See §18.33. Reading a command for more info.
Do I need to use a different technique for the first and second case?
Apparently not. In fact the verb need not even be a real action (if the player's command matches "xyzzy" …)
Related
I have a non-player character in an Inform 7 Interactive Fiction story that I would like to get a simple reply from. The character is a robot doctor. When you get on the exam table the robot doctor holds out a tongue depressor and asks you to say, "Ah." I would like the character to say something when the player types, "say ah" but so far it's not working.
Here is my code thus far:
The exam table is a supporter in the Med Bay. It is fixed in place and enterable.
In the Med Bay is a person called Auto-Doc.
After entering the exam table, say "A number of bright lights embedded in an overhead panel bathe you in a cold, white light. A panel in the wall opens and an auto-doc trundles forth on a three-wheeled base. Clutching a tongue depressor in its mechanical grip, a small speaker hidden within crackles with the words 'Say, ah.'"
After speaking in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting."
The last line is causing the compiler to throw an error, but I am unable to figure out what to use. I've tried Instead of speaking, After telling the Auto-Doc something, After saying ah in the presence of the Auto-Doc, and so far nothing is working.
Any hints as to how I can get the Auto-Doc to say something after the player types "say ah"? I'd even be happy with the Auto-Doc replying the same way no matter what the player says.
Here's a handy tip: command ACTIONS while playing the game in the IDE to see the action name when you type commands.
>actions
Actions listing on.
>say ah
(to Auto-Doc)
[answering Auto-Doc that "ah"]
There is no reply.
[answering Auto-Doc that "ah" - succeeded]
>
So the rule you're looking for is:
Instead of answering Auto-Doc that "ah":
say "Mmm. Mm-hmm. Very interesting."
After some more research, I have discovered that the responses understood by Inform are yes, no, and sorry. So understand "ah" and "say ah" as saying yes. followed by Instead of saying yes in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting." is one way to do it.
Here's what the code looks like now:
The exam table is a supporter in the Med Bay. It is fixed in place and enterable.
After entering the exam table, say "A number of LEDs embedded in the ceiling switch on, bathing you in a cold, white light. A panel in the wall opens and an auto-doc trundles forth on a three-wheeled base. Clutching a tongue depressor in its mechanical grip, a small speaker hidden within crackles with the words 'Say, ah.'"
In the Med Bay is a person called Auto-Doc.
Instead of saying yes in the presence of the Auto-Doc, say "Mmm. Mm-hmm. Very interesting."
Understand "ah" and "say ah" as saying yes when location is Med Bay.
Instead of saying no in the presence of the Auto-Doc, say "Hmm..."
This sets up two different non-committal responses for saying yes and no. Saying 'ah' is understood as saying yes, so the player gets a response.
What if I send a message with a private key
My message is "Today is party at 7"
Devil copied my encrypted text with signature
After some days the devil sent the message to the same guy I sent.
The message is not changed,my friend still got the same message of party at 7 and it is digitally signed by my private key.
What should I do to prevent this type of scenario?
Replay attacks are most commonly prevented by adding an extra piece of unique information that is not part of the message. Here is a common solution:
Add to the message a timestamp and a random value.
If the message is older than some age (a minute, an hour, a day, depending on how messages are delivered), it generates a "message too old" error
If the message is within that time frame, make sure you have never seen that random value before. If you have, then it is a repeat and can be simply ignored.
By adding a timestamp, you bound how long you have to keep track of "what you've seen before."
Another general approach is to make all messages idempotent. This means that applying the same message multiple times is not problematic. Systems like git have this quality. Building idempotent systems is somewhat tricky, and not easily achieved for all problems, but is a powerful solution when possible. An example of making something idempotent is to say "at this point in time, X had value Y." You can apply that message repeatedly without causing any problems (either because it updates the same record in exactly the same way, or because you ignore all points in time older than the latest value you have).
Addressing the replay attack problem happens to also solve several other problems, which is nice. Messaging systems face a fundamental problem that no message can be guaranteed to be delivered exactly once. You can guarantee at most once, or at least once, but never exactly once. (Study the Two Generals' Problem for a common way of thinking through this. It is arguable that you can't actually promise "at least once" because the systems may never be connected, but we typically ignore that corner case). Idempotent systems are very nice because they are highly tolerant of "at least once" solutions.
I have a doubt about about whether I should consider a certain type of test functional or contract.
Let's say I have an API like /getToolType, that accepts a {object" "myObject"} as input, and returns at type in the form {type: "[a-z]+"}
It was agreed between client and server that the types returned will match a set of strings, let's say [hammer|knife|screwdriver], so the consumer decided to parse them in an enum, with a fallback value when the returned type is unknown.
Should the consumer include a test case for each type(hammer, knife, screwdriver) to ensure the producer is still following the agreement that it will always return , for instance , the lowercase string "hammer" when /getToolType is called with an hammer object?
Or would you consider such a test case as functional? And why?
IMO the short answer is 'no'.
Contract testing is more interested in structure, if we start boundary testing the API we move into functional test territory, which is best done in the provider code base. You can use a matcher to ensure only one of those three values is returned, this should ensure the Provider build can't return other values.
I would echo #J_A_X's comments - there is no right or wrong answer, just be wary of testing all permutations of input/output data.
Great question. Short answer: there's no right or wrong way, just how you want to do it.
Longer answer:
The point of Pact (and contract testing) is to test specific scenarios and making sure that they match up. You could simply, in your contract, create a regex that allows any string type for those enums, or maybe null, but only if your consumer simply doesn't care about that value. For instance, if the tool type had a brand, I wouldn't care about the brand, just that it's returned back as a string since I just display the brand verbatim on the consumer (front-end).
However, if it was up to me, from what I understand of your scenario, it seems like the tool type is actually pretty important considering the endpoint it's hitting, hence I would probably have specific tests and contracts for each enum to make sure that those particular scenarios on my consumer are valid (I call X with something and I expect Y to have tool type Z).
Both of these solutions are valid, what it comes down to is this: Do you think the specific tool type is important to the consumer? If it is, create contracts specific to it, if not, then just create a generic contract.
Hope that helps.
The proper state is that consumer consumes hammer, knife, and screwdriver, c=(hammer,knife,screwdriver) for short while producer produces hammer, knife, and screwdriver, p=(hammer,knife,screwdriver).
There are four regression scenarios:
c=(hammer,knife,screwdriver,sword), p=(hammer,knife,screwdriver)
c=(hammer,knife,screwdriver), p=(hammer,knife,screwdriver,sword)
c=(hammer,knife,screwdriver), p=(hammer,knife)
c=(hammer,knife), p=(hammer,knife,screwdriver)
1 and 3 break the contract in a very soft way.
In the 1st scenario, the customer declared a new type that is not (yet) supported by the producer.
In the 3rd scenario, the producer stops supporting a type.
The gravity of scenarios may of course wary, as something I consider soft regression, might be in a certain service in a business-critical process.
However, if it is critical then there is a significant motivation to cover it with a dedicated test case.
2nd and 4th scenarios are more severe, in both cases, the consumer may end up in an error, e.g. might be not able to deserialize the data.
Having a test case for each type should detect scenario 3 and 4.
In the 1st scenario, it may trigger the developer to create an extra test case that will fail on the producer site.
However, the test cases are helpless against the 2nd scenario.
So despite the relatively high cost, this strategy does not provide us with full test coverage.
Having one test case with a regex covering all valid types (i.e. hammer|knife|screwdriver) should be a strong trigger for the consumer developer to redesign the test case in 1st and 4th scenario.
Once the regex is adjusted to new consumer capabilities it can detect scenario 4 with probability p=1/3 (i.e. the test will fail if the producer selected screwdriver as sample value).
Even without regex adjustment, it will detect the 3rd scenario with p=1/3.
This strategy is helpless against the 1st and 2nd scenario.
However, on top of the regex, we can do more.
Namely, we can design the producer test case with random data.
Assuming that the type in question is defined as follows:
enum Tool {hammer,knife,screwdriver}
we can render the test data with:
responseBody = Arranger.some(Tool.class);
This piece of code uses test-arranger, but there are other libraries that can do the same as well.
It selects one of the valid enum values.
Each time it can be a different one.
What does it change?
Now we can detect the 2nd scenario and after regex adjustment the 4th one.
So it covers the most severe scenarios.
There is also a drawback to consider.
The producer test is nondeterministic, depending on the drawn value it can either succeed or fail which is considered to be an antipattern.
When some tests sometimes fail despite the tested code being correct, people start to ignore the results of the tests.
Please note that producer test case with random data is not the case, it is in fact the opposite.
It can sometimes succeed despite the tested code is not correct.
It still is far from perfect, but it is an interesting tradeoff as it is the first strategy that managed to address the very severe 2nd scenario.
My recommendation is to use the producer test case with random data supported with a regex on the customer side.
Nonetheless, there is no perfect solution, and you should always consider what is important for your services.
Specifically, if the consumer can safely ignore unknown values, the recommended approach might be not a perfect fit.
Alexa certification feedback says to use slot type "AMAZON.FIVE_DIGIT_NUMBER" for zipcodes. That would make sense, but it doesn't actually exist!
When I include this slot type, I am unable to save the intent json It gives the error: "Unknown slot type 'AMAZON.FIVE_DIGIT_NUMBER' for slot 'POSTCODE'".
I can replace with AMAZON.FOUR_DIGIT_NUMBER and it works great and captures all 5 digits nicely. However, this issue was mentioned as a reason for failed certification.
I can replace with AMAZON.NUMBER which kinda works (as per suggestion in certification), but often only captures the first 4 digits, ironically not as well as AMAZON.FOUR_DIGIT_NUMBER which almost always captures all 5.
I want to pass certification but the AMAZON.NUMBER seems to give inferior results.
What should I do?
Yes, you got back info from the Alexa certification people. There is no AMAZON.FIVE_DIGIT_NUMBER built-in slot, even in the big new batch of built-in slots that they added recently.
There is AMAZON.PostalAddress and various built-ins for cities, but neither of those really fit the bill, so you are stuck with AMAZON.NUMBER.
I have read the series "Purely Functional Retrogames"
http://prog21.dadgum.com/23.html
It discusses some interesting techniques to build a (semi-)pure game world update loop.
However, I have the following side remark, that I cannot seem to get my head around:
Suppose you have a system, where every enemy, and every player are separate actors, or separate pure functions.
Suppose they all get a "WorldState" as input, and output a New WorldState (or, if you're thinking in actor terms, send the new WorldState to the next actor, ending with for instance a "Game Render" actor).
Then, there's two ways to go with this:
Either you start with one actor, (f.i. the player), and feed him the "current world".
Then, you feed the new world, to the next enemy, and so on, until all actors have converted the worlds. Then, the last world is the new world you can feed to the render loop. (or, if you followed the above article, you end up with a list of events that have occurred in the world, which can be processed).
A second way, is to just give all actors the current WorldState at the same time. They generate any changes, which may conflict (for instance, two enemies and the player can take a coin in the same animation frame) -> it is up to the game system to solve these conflicts by processing the events. By processing all events, the Game actor creates the new world, to be used in the next update frame.
I have a feeling I'm just confronted with the exact same "race condition" problem I wished to avoid by using pure functions with immutable data.
Any advice here?
I didn't read the article, but with the coin example you are creating a kind of global variable: you give a copy of the world state to all actors and you suppose that each actor will evaluate the game, take decision and expect that their action will succeed, regardless of the last phase which is the conflict solving. I would not call this a race condition but rather a "blind condition", and yes, this will not work.
I imagine that you came to this solution in order to allow parallelism, not available in solution 1. In my opinion, the problem is about responsibility.
The coin must belong to an actor (a server acting as resource manager) as anything in the application. This actor is the only responsible to decide what will happen to the coin.
All requests (is there something to grab, grab it, drop something...) should be sent to this actor (one actor per cell, or per map, level or any split that make sense for the game).
The way you will manage it is then up to you: serve all requests in the receive order, buffer them until a synchro message comes and make a random decision or priority decision... In any case the server will be able to reply to all actors with success or failure without any risk of race condition since the server process is run (at least in erlang) on a single core and proceed one message at a time.
In addition to Pascal answer, you can solve parallelization by splitting (i assume huge map) to smaller chunks which depend on last state (or part of it, like an edge) of its neighbours. This allows you to distribute this game among many nodes.