浏览代码

Fix typos and grammar (#543)

Alex Miranda 4 月之前
父节点
当前提交
25dda2659e
共有 3 个文件被更改,包括 11 次插入11 次删除
  1. 3 3
      docs/en/manuals/addressing.md
  2. 4 4
      docs/en/manuals/message-passing.md
  3. 4 4
      docs/en/manuals/script-properties.md

+ 3 - 3
docs/en/manuals/addressing.md

@@ -111,7 +111,7 @@ Relative addressing works by automatically prepending the current naming context
 
 
 ### Shorthands
 ### Shorthands
 
 
-Defold provides two handy shorthands that you can use to send message without specifying a complete URL:
+Defold provides two handy shorthands that you can use to send messages without specifying a complete URL:
 
 
 :[Shorthands](../shared/url-shorthands.md)
 :[Shorthands](../shared/url-shorthands.md)
 
 
@@ -155,7 +155,7 @@ The absolute address of the manager script is `"/manager#controller"` and this a
 
 
 ## Hashed identifiers
 ## Hashed identifiers
 
 
-The engine stores all identifiers as hashed values. All functions that take as argument a component or a game object accepts a string, hash or an URL object. We have seen how to use strings for addressing above.
+The engine stores all identifiers as hashed values. All functions that take as argument a component or a game object accepts a string, hash or a URL object. We have seen how to use strings for addressing above.
 
 
 When you get the identifier of a game object, the engine will always return an absolute path identifier that is hashed:
 When you get the identifier of a game object, the engine will always return an absolute path identifier that is hashed:
 
 
@@ -190,7 +190,7 @@ go.set_position(pos, relative_id)
 
 
 To complete the picture, let's look at the full format of Defold addresses: the URL.
 To complete the picture, let's look at the full format of Defold addresses: the URL.
 
 
-An URL is an object, usually written as specially formatted strings. A generic URL consists of three parts:
+A URL is an object, usually written as a specially formatted string. A generic URL consists of three parts:
 
 
 `[socket:][path][#fragment]`
 `[socket:][path][#fragment]`
 
 

+ 4 - 4
docs/en/manuals/message-passing.md

@@ -20,7 +20,7 @@ Let's first look at a few simple usage examples. Suppose that you are building a
 ![Message passing structure](images/message_passing/message_passing_structure.png)
 ![Message passing structure](images/message_passing/message_passing_structure.png)
 
 
 ::: sidenote
 ::: sidenote
-The content of this example lives in two separate files. There is one file for the main bootstrap collection and one for the collection with the id "level". However, file names _do not matter_ in Defold. The identity you assign instances does.
+The content of this example lives in two separate files. There is one file for the main bootstrap collection and one for the collection with the id "level". However, file names _do not matter_ in Defold. The identity you assign to instances does.
 :::
 :::
 
 
 The game contains a few simple mechanics that require communication between the objects:
 The game contains a few simple mechanics that require communication between the objects:
@@ -110,7 +110,7 @@ The game contains a few simple mechanics that require communication between the
 
 
 ## Sending messages
 ## Sending messages
 
 
-The mechanics of sending a message is, as we have seen above, very simple. You call the function `msg.post()` which posts  your message to the message queue. Then, each frame, the engine runs through the queue and delivers each message to its target address. For some system messages (like `"enable"`, `"disable"`, `"set_parent"` etc) the engine code handles the message. The engine also produces some system messages (like `"collision_response"` on physics collisions) that are delivered to your objects. For user messages sent to script components, the engine simply calls a special Defold Lua function named `on_message()`.
+The mechanics of sending a message are, as we have seen above, very simple. You call the function `msg.post()` which posts  your message to the message queue. Then, each frame, the engine runs through the queue and delivers each message to its target address. For some system messages (like `"enable"`, `"disable"`, `"set_parent"` etc) the engine code handles the message. The engine also produces some system messages (like `"collision_response"` on physics collisions) that are delivered to your objects. For user messages sent to script components, the engine simply calls a special Defold Lua function named `on_message()`.
 
 
 You can send arbitrary messages to any existing object or component and it is up to the code on the recipient side to respond to the message. If you send a message to a script component and the script code ignores the message, that is fine. The responsibility of dealing with messages is fully on the receiving end.
 You can send arbitrary messages to any existing object or component and it is up to the code on the recipient side to respond to the message. If you send a message to a script component and the script code ignores the message, that is fine. The responsibility of dealing with messages is fully on the receiving end.
 
 
@@ -151,7 +151,7 @@ There is a hard limit to the `message` parameter table size. This limit is set t
 
 
 ### Shorthands
 ### Shorthands
 
 
-Defold provides two handy shorthands that you can use to send message without specifying a complete URL:
+Defold provides two handy shorthands that you can use to send messages without specifying a complete URL:
 
 
 :[Shorthands](../shared/url-shorthands.md)
 :[Shorthands](../shared/url-shorthands.md)
 
 
@@ -203,7 +203,7 @@ A more in depth description on how proxies work can be found in the [Collection
 
 
 ## Message chains
 ## Message chains
 
 
-When a message that has been posted is eventually dispatched the recipients’ `on_message()` is called. It is quite common that the reaction code post new messages, which are added to the message queue.
+When a message that has been posted is eventually dispatched, the recipients’ `on_message()` is called. It is quite common that the reaction code posts new messages, which are added to the message queue.
 
 
 When the engine starts dispatching it will work through the message queue and call each message recipient's `on_message()` function and go on until the message queue is empty. If the dispatching pass adds new messages to the queue, it will do another pass. There is, however, a hard limit to how many times the engine tries to empty the queue, which effectively puts a limit to how long message chains you can expect to be fully dispatched within a frame. You can easily test how many dispatch passes the engine performs between each `update()` with the following script:
 When the engine starts dispatching it will work through the message queue and call each message recipient's `on_message()` function and go on until the message queue is empty. If the dispatching pass adds new messages to the queue, it will do another pass. There is, however, a hard limit to how many times the engine tries to empty the queue, which effectively puts a limit to how long message chains you can expect to be fully dispatched within a frame. You can easily test how many dispatch passes the engine performs between each `update()` with the following script:
 
 

+ 4 - 4
docs/en/manuals/script-properties.md

@@ -31,7 +31,7 @@ go.property("target", msg.url())
 
 
 function init(self)
 function init(self)
   -- store initial position of target.
   -- store initial position of target.
-  -- self.target is an url referencing another objects.
+  -- self.target is a url referencing another object.
   self.target_pos = go.get_position(self.target)
   self.target_pos = go.get_position(self.target)
   ...
   ...
 end
 end
@@ -78,7 +78,7 @@ function update(self, dt)
 end
 end
 ```
 ```
 
 
-User-defined script properties can also be accessed through the getting, setting and animation functions, the same way as any other property:
+User-defined script properties can also be accessed through the get, set and animate functions, the same way as any other property:
 
 
 ```lua
 ```lua
 -- another.script
 -- another.script
@@ -99,7 +99,7 @@ If you use a factory to create the game object, it is possible to set script pro
 local props = { health = 50, target = msg.url("player") }
 local props = { health = 50, target = msg.url("player") }
 local id = factory.create("#can_factory", nil, nil, props)
 local id = factory.create("#can_factory", nil, nil, props)
 
 
--- Accessing to factory created script properties
+-- Accessing factory-created script properties
 local url = msg.url(nil, id, "can")
 local url = msg.url(nil, id, "can")
 local can_health = go.get(url, "health")
 local can_health = go.get(url, "health")
 ```
 ```
@@ -117,7 +117,7 @@ local ids = collectionfactory.create("#cangang_factory", nil, nil, props)
 
 
 The property values provided via `factory.create()` and `collectionfactory.create()` will override any value set in the prototype file as well as the default values in the script.
 The property values provided via `factory.create()` and `collectionfactory.create()` will override any value set in the prototype file as well as the default values in the script.
 
 
-If several script components attached to a game object defines the same property, each component will get initialized with the value provided to `factory.create()` or `collectionfactory.create()`.
+If several script components attached to a game object define the same property, each component will get initialized with the value provided to `factory.create()` or `collectionfactory.create()`.
 
 
 
 
 ## Resource properties
 ## Resource properties