約 5,664,299 件
https://w.atwiki.jp/api_programming/pages/194.html
下位ページ Content PrerequisitesCreate authorization credentials Identify access scopes Obtaining OAuth 2.0 access tokensStep 1 Configure the client object Step 2 Redirect to Google's OAuth 2.0 serverサンプル（Sample redirect to Google's authorization server） OAuth 2.0 for Client-side Web Applications OAuth 2.0 for Client-side Web Applications This document explains how to implement OAuth 2.0 authorization to access Google APIs from a JavaScript web application. OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives. This OAuth 2.0 flow is called the implicit grant flow. It is designed for applications that access APIs only while the user is present at the application. These applications are not able to store confidential information. In this flow, your app opens a Google URL that uses query parameters to identify your app and the type of API access that the app requires. You can open the URL in the current browser window or a popup. The user can authenticate with Google and grant the requested permissions. Google then redirects the user back to your app. The redirect includes an access token, which your app verifies and then uses to make API requests. Note Given the security implications of getting the implementation correct, we strongly encourage you to use OAuth 2.0 libraries when interacting with Google's OAuth 2.0 endpoints. It is a best practice to use well-debugged code provided by others, and it will help you protect yourself and your users. See the JS Client Library tabs in this document for examples that show how to authorize users with the Google APIs Client Library for JavaScript. Prerequisites Enable APIs for your project Any application that calls Google APIs needs to enable those APIs in the API Console. To enable the appropriate APIs for your project Open the Library page in the API Console. Select the project associated with your application. Create a project if you do not have one already. Use the Library page to find each API that your application will use. Click on each API and enable it for your project. Create authorization credentials Any application that uses OAuth 2.0 to access Google APIs must have authorization credentials that identify the application to Google's OAuth 2.0 server. The following steps explain how to create credentials for your project. Your applications can then use the credentials to access APIs that you have enabled for that project. Open the Credentials page in the API Console. Click Create credentials OAuth client ID. Complete the form. Set the application type to Web application. Applications that use JavaScript to make authorized Google API requests must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests. Identify access scopes Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. Before you start implementing OAuth 2.0 authorization, we recommend that you identify the scopes that your app will need permission to access. The OAuth 2.0 API Scopes document contains a full list of scopes that you might use to access Google APIs. Obtaining OAuth 2.0 access tokens The following steps show how your application interacts with Google's OAuth 2.0 server to obtain a user's consent to perform an API request on the user's behalf. Your application must have that consent before it can execute a Google API request that requires user authorization. Step 1 Configure the client object If you are using Google APIs client library for JavaScript to handle the OAuth 2.0 flow, your first step is to configure the gapi.auth2 and gapi.client objects. These objects enable your application to obtain user authorization and to make authorized API requests. The client object identifies the scopes that your application is requesting permission to access. These values inform the consent screen that Google displays to the user. The Choosing access scopes section provides information about how to determine which scopes your application should request permission to access. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS If you are directly accessing the OAuth 2.0 endpoints, you can proceed to the next step. Step 2 Redirect to Google's OAuth 2.0 server To request permission to access a user's data, redirect the user to Google's OAuth 2.0 server. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS Generate a URL to request access from Google's OAuth 2.0 endpoint at https //accounts.google.com/o/oauth2/v2/auth. This endpoint is accessible over HTTPS; plain HTTP connections are refused. The Google authorization server supports the following query string parameters for web server applications Parameters client_id 必須The client ID for your application. You can find this value in the API Console. redirect_uri 必須ユーザが認証を行った後、API サーバがリダイレクトする場所を指定。この値は API Console で指定したリダイレクトURLのどれかと正確に一致している必要がある。http or https, case, ('/') まですべて一致。 response_type 必須JavaScript アプリケーションでは token を指定する。この指示により Google 認証サーバは アクセストークンを name=value のペアで、ハッシュ (#) fragment をつけて、返すようになる。 scope 必須A space-delimited list of scopes that identify the resources that your application could access on the user's behalf. These values inform the consent screen that Google displays to the user. Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there is an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. The OAuth 2.0 API Scopes document provides a full list of scopes that you might use to access Google APIs. We recommend that your application request access to authorization scopes in context whenever possible. By requesting access to user data in context, via incremental authorization, you help users to more easily understand why your application needs the access it is requesting. state RecommendedSpecifies any string value that your application uses to maintain state between your authorization request and the authorization server's response. The server returns the exact value that you send as a name=value pair in the hash (#) fragment of the redirect_uri after the user consents to or denies your application's access request. You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. Since your redirect_uri can be guessed, using a state value can increase your assurance that an incoming connection is the result of an authentication request. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery. See the OpenID Connect documentation for an example of how to create and confirm a state token. include_granted_scopes OptionalEnables applications to use incremental authorization to request access to additional scopes in context. If you set this parameter's value to true and the authorization request is granted, then the new access token will also cover any scopes to which the user previously granted the application access. See the incremental authorization section for examples. login_hint OptionalIf your application knows which user is trying to authenticate, it can use this parameter to provide a hint to the Google Authentication Server. The server uses the hint to simplify the login flow either by prefilling the email field in the sign-in form or by selecting the appropriate multi-login session. Set the parameter value to an email address or sub identifier. promptOptional. A space-delimited, case-sensitive list of prompts to present the user. If you don't specify this parameter, the user will be prompted only the first time your app requests access. Possible values are noneDo not display any authentication or consent screens. Must not be specified with other values. consentPrompt the user for consent. select_accountPrompt the user to select an account. サンプル（Sample redirect to Google's authorization server） An example URL is shown below, with line breaks and spaces for readability. https //accounts.google.com/o/oauth2/v2/auth ?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly include_granted_scopes=true state=state_parameter_passthrough_value redirect_uri=http%3A%2F%2Foauth2.example.com%2Fcallback response_type=token client_id=client_id After you create the request URL, redirect the user to it. JavaScript sample code The following JavaScript snippet shows how to initiate the authorization flow in JavaScript without using the Google APIs Client Library for JavaScript. Since this OAuth 2.0 endpoint does not support Cross-origin resource sharing (CORS), the snippet creates a form that opens the request to that endpoint. /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https //accounts.google.com/o/oauth2/v2/auth'; // Create form element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id' 'YOUR_CLIENT_ID', 'redirect_uri' 'YOUR_REDIRECT_URI', 'response_type' 'token', 'scope' 'https //www.googleapis.com/auth/drive.metadata.readonly', 'include_granted_scopes' 'true', 'state' 'pass-through value'}); // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } Step 3 Google prompts user for consent In this step, the user decides whether to grant your application the requested access. At this stage, Google displays a consent window that shows the name of your application and the Google API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application. Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2.0 server indicating whether the access was granted. That response is explained in the following step. Step 4 Handle the OAuth 2.0 server response JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS The OAuth 2.0 server sends a response to the redirect_uri specified in your access token request. If the user approves the request, then the response contains an access token. If the user does not approve the request, the response contains an error message. The access token or error message is returned on the hash fragment of the redirect URI, as shown below An authorization code response https //oauth2.example.com/callback#access_token=4/P7q7W91 token_type=Bearer expires_in=3600 In addition to the access_token parameter, the query string also contains the token_type parameter, which is always set to Bearer, and the expires_in parameter, which specifies the lifetime of the token, in seconds. If the state parameter was specified in the access token request, its value is also included in the response. An error response https //oauth2.example.com/callback#error=access_denied Note Your application should ignore any additional, unrecognized fields included in the query string. Sample OAuth 2.0 server response You can test this flow by clicking on the following sample URL, which requests read-only access to view metadata for files in your Google Drive https //accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly include_granted_scopes=true state=state_parameter_passthrough_value redirect_uri=http%3A%2F%2Foauth2.example.com%2Fcallback response_type=token client_id=client_id After completing the OAuth 2.0 flow, you will be redirected to http //localhost/oauth2callback. That URL will yield a 404 NOT FOUND error unless your local machine happens to serve a file at that address. The next step provides more detail about the information returned in the URI when the user is redirected back to your application. The code snippet in step 5 shows how to parse the OAuth 2.0 server response and then validate the access token. Step 5 Validate the user's token JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS If the user has granted access to your application, you must explicitly validate the token returned in the hash fragment of the redirect_uri. By validating, or verifying, the token, you ensure that your application is not vulnerable to the confused deputy problem. To validate the token, send a request to https //www.googleapis.com/oauth2/v3/tokeninfo and set the token as the access_token parameter's value. The following URL shows a sample request https //www.googleapis.com/oauth2/v3/tokeninfo?access_token= access_token Google's authorization server responds to the request with a JSON object that either describes the token or contains an error message. If the token is valid, the JSON object includes the properties in the following table Fields audThe application that is the intended user of the access token. Important Before using the token, you need to verify that this field's value exactly matches your Client ID in the Google API Console. This verification ensures that your application is not vulnerable to the confused deputy problem. expires_inThe number of seconds left before the token becomes invalid. scopeA space-delimited list of scopes that the user granted access to. The list should match the scopes specified in your authorization request in step 1. useridThis value lets you correlate profile information from multiple Google APIs. It is only present in the response if you included the profile scope in your request in step 1. The field value is an immutable identifier for the logged-in user that can be used to create and manage user sessions in your application. The identifier is the same regardless of which client ID is used to retrieve it. This enables multiple applications in the same organization to correlate profile information. A sample response is shown below { "aud" "8819981768.apps.googleusercontent.com", "user_id" "123456789", "scope" "https //www.googleapis.com/auth/drive.metadata.readonly", "expires_in" 436 } If the token has expired, been tampered with, or had its permissions revoked, Google's authorization server returns an error message in the JSON object. The error surfaces as a 400 error and a JSON body in the format shown below. {"error" "invalid_token"} By design, no additional information is given as to the reason for the failure. Note In practice, a 400 error typically indicates that the access token request URL was malformed, often due to improper URL escaping. The JavaScript snippet below parses the response from Google's authorization server and then validates the access token. If the token is valid, the code stores it in the browser's local storage. You could modify the snippet to also send the token to your server as a means of making the token available to other API clients. var queryString = location.hash.substring(1); var params = {}; var regex = /([^ =]+)=([^ ]*)/g, m; while (m = regex.exec(queryString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); // Try to exchange the param values for an access token. exchangeOAuth2Token(params); } /* Validate the access token received on the query string. */ function exchangeOAuth2Token(params) { var oauth2Endpoint = 'https //www.googleapis.com/oauth2/v3/tokeninfo'; if (params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('POST', oauth2Endpoint + '?access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { var response = JSON.parse(xhr.response); // Verify that the 'aud' property in the response matches YOUR_CLIENT_ID. if (xhr.readyState == 4 xhr.status == 200 response['aud'] response['aud'] == YOUR_CLIENT_ID) { localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); } else if (xhr.readyState == 4) { console.log('There was an error processing the token, another ' + 'response was returned, or the token was invalid.') } }; xhr.send(null); } } Calling Google APIs JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account or service account. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization Bearer HTTP header. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive API). You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground. HTTP GET examples A call to the drive.files endpoint (the Drive API) using the Authorization Bearer HTTP header might look like the following. Note that you need to specify your own access token GET /drive/v2/files HTTP/1.1 Authorization Bearer access_token Host www.googleapis.com/ Here is a call to the same API for the authenticated user using the access_token query string parameter GET https //www.googleapis.com/drive/v2/files?access_token= access_token curl examples You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred) curl -H "Authorization Bearer access_token " https //www.googleapis.com/drive/v2/files Or, alternatively, the query string parameter option curl https //www.googleapis.com/drive/v2/files?access_token= access_token JavaScript sample code The code snippet below demonstrates how to use CORS (Cross-origin resource sharing) to send a request to a Google API. This example does not use the Google APIs Client Library for JavaScript. However, even if you are not using the client library, the CORS support guide in that library's documentation will likely help you to better understand these requests. In this code snippet, the access_token variable represents the token you have obtained to make API requests on the authorized user's behalf. The complete example demonstrates how to store that token in the browser's local storage and retrieve it when making an API request. var xhr = new XMLHttpRequest(); xhr.open('GET', 'https //www.googleapis.com/drive/v3/about?fields=user ' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null); Complete example JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS This code sample demonstrates how to complete the OAuth 2.0 flow in JavaScript without using the Google APIs Client Library for JavaScript. The code is for an HTML page that displays a button to try an API request. If you click the button, the code checks to see whether the page has stored an API access token in your browser's local storage. If so, it executes the API request. Otherwise, it initiates the OAuth 2.0 flow. For the OAuth 2.0 flow, the page follows these steps It directs the user to Google's OAuth 2.0 server, which requests access to the https //www.googleapis.com/auth/drive.metadata.readonly scope. After granting (or denying) access, the user is redirected to the original page, which parses the access token from the query string. The page validates the access token and, if it is valid, executes the sample API request. The API request calls the Drive API's about.get method to retrieve information about the authorized user's Google Drive account. If the request executes successfully, the API response is logged in the browser's debugging console. You can revoke access to the app through the Permissions page for your Google Account. The app will be listed as OAuth 2.0 Demo for Google API Docs. To run this code locally, you need to set values for the YOUR_CLIENT_ID and REDIRECT_URI variables that correspond to your authorization credentials. The REDIRECT_URI should be the same URL where the page is being served. Your project in the Google API Console must also have enabled the appropriate API for this request. html head /head body script var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE'; var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE'; var queryString = location.hash.substring(1); // Parse query string to see if page request is coming from OAuth 2.0 server. var params = {}; var regex = /([^ =]+)=([^ ]*)/g, m; while (m = regex.exec(queryString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); // Try to exchange the param values for an access token. exchangeOAuth2Token(params); } // If there's an access token, try an API request. // Otherwise, start OAuth 2.0 flow. function trySampleRequest() { var params = JSON.parse(localStorage.getItem('oauth2-test-params')); if (params params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('GET', 'https //www.googleapis.com/drive/v3/about?fields=user ' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null); } else { oauth2SignIn(); } } /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauth2SignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https //accounts.google.com/o/oauth2/v2/auth'; // Create element to open OAuth 2.0 endpoint in new window. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id' YOUR_CLIENT_ID, 'redirect_uri' YOUR_REDIRECT_URI, 'scope' 'https //www.googleapis.com/auth/drive.metadata.readonly', 'state' 'try_sample_request', 'include_granted_scopes' 'true', 'response_type' 'token'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } /* Verify the access token received on the query string. */ function exchangeOAuth2Token(params) { var oauth2Endpoint = 'https //www.googleapis.com/oauth2/v3/tokeninfo'; if (params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('POST', oauth2Endpoint + '?access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { var response = JSON.parse(xhr.response); // When request is finished, verify that the 'aud' property in the // response matches YOUR_CLIENT_ID. if (xhr.readyState == 4 xhr.status == 200 response['aud'] response['aud'] == YOUR_CLIENT_ID) { // Store granted scopes in local storage to facilitate // incremental authorization. params['scope'] = response['scope']; localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); if (params['state'] == 'try_sample_request') { trySampleRequest(); } } else if (xhr.readyState == 4) { console.log('There was an error processing the token, another ' + 'response was returned, or the token was invalid.') } }; xhr.send(null); } } /script button onclick="trySampleRequest();" Try sample request /button /body /html Incremental authorization In the OAuth 2.0 protocol, your app requests authorization to access resources, which are identified by scopes. It is considered a best user-experience practice to request authorization for resources at the time you need them. To enable that practice, Google's authorization server supports incremental authorization. This feature lets you request scopes as they are needed and, if the user grants permission, add those scopes to your existing access token for that user. For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it. In this case, at sign-in time the app might request the profile scope to perform basic sign-in, and then later request the https //www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix. The following rules apply to an access token obtained from an incremental authorization The token can be used to access resources corresponding to any of the scopes rolled into the new, combined authorization. When you use the refresh token for the combined authorization to obtain an access token, the access token represents the combined authorization and can be used for any of its scopes. The combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one scope using an application's desktop client and then granted another scope to the same application via a mobile client, the combined authorization would include both scopes. If you revoke a token that represents a combined authorization, access to all of that authorization's scopes on behalf of the associated user are revoked simultaneously. The code samples below show how to add scopes to an existing access token. This approach allows your app to avoid having to manage multiple access tokens. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS To add scopes to an existing access token, include the include_granted_scopes parameter in your request to Google's OAuth 2.0 server. The following code snippet demonstrates how to do that. The snippet assumes that you have stored the scopes for which your access token is valid in the browser's local storage. (The complete example code stores a list of scopes for which the access token is valid by setting the oauth2-test-params.scope property in the browser's local storage.) The snippet compares the scopes for which the access token is valid to the scope you want to use for a particular query. If the access token does not cover that scope, the OAuth 2.0 flow starts. Here, the oauth2SignIn function is the same as the one that was provided in step 2 (and that is provided later in the complete example). var SCOPE = 'https //www.googleapis.com/auth/drive.metadata.readonly'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. } Revoking a token In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS To programmatically revoke a token, your application makes a request to https //accounts.google.com/o/oauth2/revoke and includes the token as a parameter curl -H "Content-type application/x-www-form-urlencoded" \ https //accounts.google.com/o/oauth2/revoke?token={token} The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked. Note Google's OAuth 2.0 endpoint for revoking tokens supports JSONP and form submissions. It does not support Cross-origin Resource Sharing (CORS). If the revocation is successfully processed, then the status code of the response is 200. For error conditions, a status code 400 is returned along with an error code. The following JavaScript snippet shows how to revoke a token in JavaScript without using the Google APIs Client Library for JavaScript. Since the Google's OAuth 2.0 endpoint for revoking tokens does not support Cross-origin Resource Sharing (CORS), the code creates a form and submits the form to the endpoint rather than using the XMLHttpRequest() method to post the request. function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https //accounts.google.com/o/oauth2/revoke'; // Create form element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is // https //accounts.google.com/o/oauth2/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); } Note Following a successful revocation response, it might take some time before the revocation has full effect.
https://w.atwiki.jp/skyrim_mod/pages/18.html
ここではスクリプトの小技やタメになる情報を扱います。 スクリプト作成時の注意点初心者はSE版のみ対応として作成を行う事(慣れるまでLE・SE両用を作成しない) アルゴリズムを組む前にSKSEプラグインを確認する コンソール経由でしか処理できないものもある デバッグのためエフェクトや状態をコンソールから確認できる環境を整える Papyrusでキー入力系のスクリプトを作成する時は高速なレスポンスを求めた処理は望まない 戦闘が絡むスクリプトの動作確認について大規模戦闘下での確認は行う事 ニューゲーム、途中導入での動作確認は怠らない (SE版のみ)Papyrusに慣れたらSkyrim Platformでのスクリプト開発を検討する 予約語self 否定の "!" 関数の処理について イベントの処理 スクリプト最適化Tips重複処理をさせない→Stateを使う（スタックエラーの防止策） return文で処理を中断する None（エラーを少なくする方法）Noneを代入して完全に消す 同じアクセサ関数(Get～系)を複数回使用しないこと。 変数はローカルで保持する Is3Dloaded() 引数が多い関数やイベントほど重い 安易なスクリプト使用の代替回避をしない WhileとWaitによる処理及び処理待ちの多用は厳禁 スクリプト最適化実践編装備時のイベント重複防止 OnHitの重複防止 スクリプトログをとる(デバッグの仕方)スクリプトログの設定 LogExpertを導入 スクリプトにデバッグ情報の記載 OnAnimationEventで取得できるイベント AnimationVariableの使い方さまざまな状態の判定 iStateの変数 セーブデータに残るもの不必要になったプロパティの削除 SM Eventを使ったRepeatQuest セル移動時関係のイベント NPCへのPerk付与について Perkの挙動について特定行動時にスペル付与系 Add ValueやSet Value等の数値変動系の計算の優先度 IsInKillMove関数の注意点 スクリプトによる一部のフォームの値変更について ConsoleUtilによるターゲットコマンド実行の注意点及び安全な実行について負荷が掛かると誤実行される危険性がある 対策 アビリティ付与に関する注意 Activate関係の処理についてBlockActivation関数でアクティベートをブロックしてもOnActivateイベントは発生する パークのアクティベート処理変更についての注意点OnActivateイベントが発生しない BlockActivation関数でアクティベートのブロックをしても処理が実行される スクリプト側でアクティベートした場合は動作変更が行われない 対処法のサンプル スクリプト作成時の注意点 初心者はSE版のみ対応として作成を行う事(慣れるまでLE・SE両用を作成しない) SE版が販売して数年はSKSEの更新等で不安定だった事もありLE版が主流でしたが、現在はSE版の販売から10年以上経過しており環境が比較的安定したため、SKSEプラグイン等のModリソース開発者の多くがSE版に移行しています。 それに伴いSPID等、Mod作成用のリソースがLE版での更新がされなくなっている、またはSE版のみリリースしてる所が多くなっているため、LE版と比較してSE版の方が開発リソースは豊富となっています。このため、LE版で高度な事をやりたい場合、特にLE・SE版両用を行いたい場合は作成のハードルが高くなります。 (特にこのwikiでも紹介しているPapyrus関数拡張SKSEであるpowerofthree's Papyrus ExtenderはLE版の更新が2020/07/08が最後となっており、当然SE版と比べてやれる事が少なくなってます) また、慣れない内にLE・SE両用のMod作成をした場合、配布後のトラブル対応に苦労する可能性があるため初心者はSE版のみの開発をオススメします。 アルゴリズムを組む前にSKSEプラグインを確認する アルゴリズムを組む前に、wikiメニュー一覧の「SKSEプラグイン」に記載されてる「主なPapyrus関数拡張SKSE」のSKSEをダウンロードし、それのソースを確認して実現したい処理がそのSKSEが提供しているPapyrus関数一つで行えるかを確認しましょう。 （例としてInt型をstring型に変換、string型の数値をInt型に変換する処理を作りたい場合、自前でアルゴリズムを組もうとするとかなり手間が掛かりますが"powerofthree's Papyrus Extender"のIntToString、StringToInt関数を用いる事で容易に実行可能でかつ自前でアルゴリズムを組んだ処理よりも高速に処理できます） また、アクターやオブジェクトの状態の操作や確認、アクターやフォームの一覧を取得したい場合は"powerofthree's Papyrus Extender"、AIパッケージ上書きやファイル関連の操作は"PapyrusUtil"を使用する事で大抵の事はできます。 まずはこの2つだけでもダウンロードしてどのような処理が行えるか把握しておくと良いでしょう。 コンソール経由でしか処理できないものもある Papyrusで実行したい関数が無かった場合はコンソールコマンドも確認するようにしましょう。 例えばレベル設定はPapyrusではプレイヤーのみしか行えずNPCに対してはコンソールコマンドでしかレベル設定はできません。 SKSEプラグインのConsoleUtilを利用する事でPapyrus経由でのコンソールコマンドの実行が可能となります。 (ConsoleUtilは指定した文字列をコンソールに出力する関数があるため、デバッグ等でも便利です) コンソールコマンドの表については以下のサイトが参考になります。 https //www.creationkit.com/index.php?title=Category Console_Commands https //elderscrolls.fandom.com/wiki/Console_Commands_(Skyrim) https //en.uesp.net/wiki/Skyrim Console デバッグのためエフェクトや状態をコンソールから確認できる環境を整える LE版はMfg Console、SE版はMore Informative Consoleを導入すれば、コンソール画面で対象を選ぶだけで対象の状態の確認が行えるようになります。 アビリティは付与されたけどマジックエフェクトがアクティブになってない等の確認も簡単に行えるようになるのでデバッグが非常に容易になります。 Papyrusでキー入力系のスクリプトを作成する時は高速なレスポンスを求めた処理は望まない キー入力後からの判定や処理は冗長化しないように可能な限り最適化するように心掛けましょう。これを怠るとキー入力直後に処理を実行したいのに入力後しばらくした後に処理が実行されるという事が起こります。 PapyrusはSkyrimのバックグラウンド処理の仕組み上の問題からどのように最適化しても基本的には僅かでも遅延は起こりえるという事を念頭にスクリプトを作成してください。 また、『敵の攻撃がヒットする直前に特定のボタンを押せば相手の攻撃をキャンセルor自身を無敵化させてダメージ無効化』のような非常に早いレスポンスが求められるものはPapyrusだけで実現するのはまず不可能です。 実際にやろうとすると「判定処理→判定成功→相手の攻撃キャンセルor無敵処理」の判定成功からの判定成功後処理を行う直前で攻撃を受けてしまい、その後に判定成功後の処理が実行されるという事態がよく起こります。 (特にスクリプトのスタックが発生しやすい大規模戦闘では判定処理成功→攻撃を受ける→1秒以上経過した後に判定成功処理が行われるという事態が起こります) 高速なレスポンスを要求されるModを作成したい場合はSKSEプラグインを作成するか、Skyrim Platformでスクリプトを作成してください。 戦闘が絡むスクリプトの動作確認について大規模戦闘下での確認は行う事 数人程度の敵と戦闘して問題ない事があっても内戦などの大規模戦闘ではスクリプト遅延の多発は容易に起こります。 このため、戦闘関連のスクリプトの動作確認は数人程度の敵と戦闘して問題ないか確認した後、大規模戦闘で動作に支障が無いかの確認をしましょう。 負荷テスト確認を行う場合は事前に「ホワイトランの戦い」等の大規模戦闘前のセーブデータを用意しておくと確認しやすくなります。 また、Assault on ValenwoodというModは内戦クエスト以上の大規模戦闘かつ開始が非常に容易のためこちらを導入しての確認もオススメです。 ニューゲーム、途中導入での動作確認は怠らない ニューゲームで開始時、ゲーム途中からのMod導入どちらでも動作に問題ないか念の為確認しましょう。 スタート地点変更Modがあると確認がしやすくなります。 (SE版のみ)Papyrusに慣れたらSkyrim Platformでのスクリプト開発を検討する 開発環境の構築に手間が掛かりますが、Skyrim Platform(SP)で開発が行えるならばスクリプト作成はこちらで作成したほうが良いです。理由として SKSEプラグインのDLLがスクリプトを読み込んで実行するという形なのでPapyrusの数十倍処理が高速 特定の処理で実行しない限りはバックグラウンドでは実行せず、フォアグラウンドで実行されるため高速なレスポンスを求められる処理を作成可能 Papyrusだと処理件数が非常に多くなると一部の処理を後回しにしてしまい、結果スタックが溜まって処理が遅れる（そしてそうゆう状況下だと高確率でまずスタックがどんどん貯まる可能性が高いため最悪フリーズという事態になる）がSkyrim Platformでは処理の後回しによる遅延はなく、仮に処理件数が膨大だった場合でも処理落ちという形で処理遅延の回避が可能となる ゲーム中にスクリプトを編集可能、編集内容の反映が可能でデバッグが非常に容易 とPapyrusでのスクリプト作成よりも遥かに利点が多いです。 Skyrim Platformのスクリプト関数はPapyrus関数を準拠にしておりPapyrusで実行できる関数のほとんどが実行可能(開発途中のため一部の関数で確定CTDするため注意)、 さらにSKSEプラグインのPapyrus関数拡張SKSEの関数も定義ファイルを作成すればSkyrim Platform上で実行可能とPapyrusでの経験も応用しやすいためPapyrusに慣れたらSkyrim Platformのスクリプト作成も検討しましょう。 予約語self 予約語は役割が予め決まっており変数で使用できない語です。 selfはそのスクリプトをつけているオブジェクトそのものを指します。 例えばリディア(Actor)についているスクリプトの場合はselfが指すのはリディア(housecarlwhiterun)です。 わざわざプロパティ作ったり変数作ったりしなくていいのできれいにコードが書けます。 self.GetDistance(player) ;リディアとプレイヤーとの距離を測ったり Debug.SendAnimationEvent(self,"attackStop") ;リディアに攻撃停止のモーションを送ったりできます 他にもActiveMagicEffectにつけたものでその魔法効果を消す場合は self.dispel() クエストにつけたものでそのクエストを停止させるには self.stop() このように幅広く使えます。 否定の "!" スクリプト上で!をつけると～でないという否定の意味になります。 !Actor.IsSprinting() ;スプリント中でない、Actor.IsSprinting() == falseと同じ。 !(Actor.GetEquippedItemType(1) == 0) ; 右手の武器が素手ではない Actor.GetEquippedItemType(1) != 0と同じ 関数の処理について 関数の処理の仕方についておおまかに3つに分類します。 1.同期が必要なLatent Function スクリプトは上から順に処理していきますが、関数の中でも処理が終わるまでスクリプトが止まるのがLatent Functionです。 代表的な例はWait()です。 Utilty.Wait(1.0)なら１秒経過するまでWaitの部分でスクリプトは待ってます。 次にCast関数です。 これも実際に画面上で魔法が放たれるまで待ってます。 しかし、ノーモーションで魔法が放たれるので、非常に処理が速いです。 CK wiki内のリストには入ってませんがFind系の関数は値が返ってくるまで待ち、処理が遅いです。 2.非同期処理の関数 これは関数の実行が終わったかどうかは関係なく、処理の手続きをしたらさっさと次に進む関数です。 モーションを再生するPlayIdle()がそうです。 モーションが終わったかどうかは関係なく次に進みます。 SoundのPlay()なども同じく、処理の手続きすればすぐ次に行きます。 これと同じ機能で同期処理版がPlayAndWaitです。 スクリプトではなく実際の処理自体はフレームレートやPCの性能に左右されます。 手続された順に再生されるので画面上では遅延が起きるかもしれません。 ※仮説上の話ですが、パピルスが言語として遅いのは画面と同期するために意図的に遅くしている可能性も。 3.画面と同期する必要のないNon-delayed Native Function 画面で起こってることとは全く関係ない、MathやRegister系の関数などです。 これらの関数はフレームレートに左右されずに、常に高速で動きます。 3.以外は1.だから速いとか2.だから遅いというわけではなく、個々での関数で速度を勘定したほうがいいでしょう。 イベントの処理 同一のフォーム内のスクリプトではイベントのフラグは同時に受けとります。 たとえば、クエスト1に対してスクリプトA・スクリプトBをつけ、 ;スクリプトA Event OnInit() RegisterForSingleUpdate(1) EndEvent Event OnUpdate() Debug.trace("Script A") EndEvent ;スクリプトB Event OnUpdate() Debug.trace("Script B") EndEvent どっちのOnUpdateも動きます。 OnUpdateを別に動かしたい場合は、クエストを別にするか、Stateを使ってうまく振り分けましょう。 また、別のスクリプトが誤作動してしまうために、スクリプトをアクターにつけず、基本的に独立しているMagic Effect使います。 スクリプト最適化Tips エラーの少なく、処理の早い書き方があります。 原則 イベントも関数も呼び出しが少ないほうがよい なので重複処理を防止したり、繰り返しの処理をまとめたりが重要です。 重複処理をさせない→Stateを使う（スタックエラーの防止策） 敵から攻撃受けた時に両手武器の場合はスタミナに5ダメージという仕組みに加えて、 一度イベントが起きたら0.5秒間同じ処理をさせたくない場合です。 Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked) ;攻撃者がいない場合、ダメージソースが武器以外の場合は即処理中断 if akAggressor == None || !(akSource as Weapon) return endif ;BusyのStateに飛ばす GotoState("Busy") ;武器の種類を取得 int WeapType = (akSource as Weapon).GetWeaponType() ;両手剣または両手斧槌ならば if WeapType == 5 || WeapType == 6 Game.GetPlayer().DamageAV("Stamina",5.0) endif ;重複防止のために0.5秒待機 Utility.Wait(0.5) ;Stateを元の状態に戻す GotoState("") EndEvent State Busy ;StateがBusyの時はOnHitイベントが起こっても何も処理しない Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked) EndEvent EndState Stateはその名のとおり状態を表してまして、指定したState中にイベントが起こった場合は、Stateに記述したイベントが優先されます。 例のスクリプトはGotoState()で"Busy"というStateに移動します。Stateが変わっても元のOnHitイベントは継続して処理が進みます。 この間にOnHitイベントが起こっても、すべてState Busyの方で処理されます。最後に空のStateにGotoStateで戻って、また通常のOnHitイベントが起きるようになります。 スタックエラーは特定の条件下で、何回も処理が動いてしまうのが原因の一つなので、Stateを使って複数回処理するのを制限することで回避できます。 return文で処理を中断する returnは本来、戻り値を返すためのものですが、実行されると、実行中のイベントや関数から強制的に中断します。 OnHitなどの頻繁に動くイベントの場合は、条件に合わない処理を事前にreturnで中断させるのは非常に有効です。 ダメな例 Event SomeEvent() bool keepRunning = true If someCondition1() keepRunning = false ElseIf someCondition2() keepRunning = false EndIf If(!keepRunning) DoStuff() EndIf EndEvent 良い例 Event SomeEvent() If someCondition1() || someCondition2() return EndIf DoStuff() EndEvent 悪い例ではkeepRunningを代入したり、チェックしたりの分の処理してますが、 良い例では条件が合わない場合は即処理を中断します。 Stateとreturnを組み合わせる場合は、returnで中断されるとStateが戻ってこれなくなるので、 GotoState前に書くか、return前にGotoState("")で抜け出します。 if return endif GotoState("Busy") if GotoState("") return endif None（エラーを少なくする方法） スクリプトが対象のオブジェクトが見つけれない時にエラーになりますが、これがエラーの中ではもっとも多いかと思います。 None Object、 has no 3d 基本的にスクリプトエンジンはこのエラーを無視するので問題無いですが、エラーログ出すぎると重くなったり不安定になったりする可能性があるのと、ログが読みにくくなるのでその対処法です。 オブジェクトがない状態をオブジェクトはNoneと返します。 また、不必要になったオブジェクトにはNoneを代入すると安全です。 if PlayerRef != None ; プレイヤーのリファレンスがないときは処理を行わない ..... endif もしくは if PlayerRef == None ; プレイヤーのリファレンスが取得できない時はリターンでイベントの強制終了。 return endif Noneを代入して完全に消す ObjectReferenceやFormのデータはDeleteを使っただけではスクリプト上では完全に消えてないので、 これを解放するにはNoneを代入する必要があります。 ObjectReference Box = PlayerRef.placeAtMe(FXEmptyActivator) ;透明オブジェクトを置く Box.MoveTo(PlayerRef, 0, 50, 85) ;透明オブジェクト移動 Box.Delete() ;透明オブジェクトを削除 Box = None ;Deleteでゲーム上からは消えますがスクリプトでは残っているのでNone入れて、ないことにする。 同じアクセサ関数(Get～系)を複数回使用しないこと。 アクセサ関数はなにか取得する(Get～)関数です。Game.GetPlayer()だとか、GetTargetActor()ですね。 ダメな例 Event SomeEvent() GetTargetActor().AddItem(coolItem, 1) GetTargetActor().AddSpell(coolSpell) GetTargetActor().Kill() GetTargetActor().Resurrect() EndEvent なぜダメかといえば、毎行たびにGetTargetActor()の処理を行い、取得しているからです。 つまり例では4回処理してます。 はじめの一行でGetTargetActor()を取得して変数に代入し、あとはそれを当てはめたほうがコードの見通しもよく効率的です。 よい例 Event SomeEvent() Actor selfActor = GetTargetActor() selfActor.AddItem(coolItem, 1) selfActor.AddSpell(coolSpell) selfActor.Kill() selfActor.Resurrect() EndEvent 例外としてはGetTargetActor()の使用が1回だけの場合にはselfActor等の不必要な変数を追加する必要はなく、以下のが効率的です。 GetTargetActor().AddItem(coolItem, 1) 変数はローカルで保持する 不必要な静的変数を設定しないことです。 ダメな例 int onHitVariable ;OnHitイベントで使う変数 int onDeathVariable ;OnDeath event int bothEventsVariable ;両方のイベントで使う変数 Event OnHit( parameters ) DoStuffWith(onHitVariable) DoStuffWith(bothEventsVariable) EndEvent Event OnDeath( parameters ) DoStuffWith(onDeathVariable) DoStuffWith(bothEventsVariable) EndEvent 良い例 int bothEventsVariable ;両方のイベント間で使う変数は静的変数としてイベント外で定義しておく Event OnHit( parameters ) int onHitVariable ;OnHitでしか使わない変数はOnHit内で定義 DoStuffWith(onHitVariable) DoStuffWith(bothEventsVariable) EndEvent Event OnDeath( parameters ) int onDeathVariable ;OnDeathでしか使わない変数はOnDeath内で定義 DoStuffWith(onDeathVariable) DoStuffWith(bothEventsVariable) EndEvent Is3Dloaded() 3Dデータとして読み込まれているかどうかの判定をする関数で、has no 3d～のエラー対策に使えます。 インベントリに回収しちゃって処理ができない場合や、ラグがあって3Dオブジェクトが設置される前にスクリプトが稼働した場合にhas no 3dのエラーがでます。 If self.Is3Dloaded() == True ;3Dデータが読まれているなら処理 Endif ラグ防止の場合：3Dデータが読まれるまで待機 int i = 10 ;時間切れを10秒に設定 While self.Is3Dloaded() == False i 0 ;3Dデータが読み込まれるか時間切れまで待つ Utility.Wait(1.0) i -= 1 EndWhile 3Dデータが必ず読み込まれるという保証はないため、タイムアウトを設定するのは極めて重要です。 引数が多い関数やイベントほど重い パピルスの仕様で、引数から変換するときの処理が重いのです。したがって引数が多いほど重いので OnHitイベントやFind～()は重いです(OnHitは頻発するのとFindはそもそも探索が遅いのあります)。 別のイベントや関数で代替できるならそちらでしたほうが良い場合もあります。 安易なスクリプト使用の代替回避をしない スクリプト使わないパターンでよくあるのが魔法のアビリティのコンディションで代替するパターンでこれは極めて悪手です。 スペルのアビリティのコンディションは毎秒条件の判定があるのでスクリプトで毎秒ループしてるのと同じぐらい重いです。 スクリプトのループと違って、papyrusログにスタックエラーが出ないのでより悪質です。 素直にスクリプト使ってイベント駆動型にしたほうが断然軽く安定します。 WhileとWaitによる処理及び処理待ちの多用は厳禁 以下のようにWhileとWaitを用いる処理について、Quest等の単一のスクリプトで行う場合ならまだしも、多数のアクターにアビリティを付与して以下のWhileとWait処理を行う場合は状況によってはスタックが溜まってしまい処理遅延発生の元になってしまいます。特に大規模戦闘等のアクターが大勢いる状況だと処理遅延の多発が起こり、最悪CTDが起きる可能性が高まるため注意が必要です。(例としてはEnhanced Blood Textures。アクターの死亡時で以下と同じような処理を行っている) int i = 0 while i 100 ; ループ処理 ～ 省略 ～ Utility.wait(1) i += 1 endWhile 多数のアクターでどうしてもこのような処理を使用する必要がある場合は、GlobalVariable等にWhile＆Wait処理を行っているアクターの総数を記録しておき、処理を行える人数を制限するか、一定数存在したら処理の中断を行うようにする事。(演出系の場合はHasLOS等でプレイヤーが視認できない場合は処理を省略する等を行う) ；一例、GlobalVariableで処理人数を記録して処理可能人数を制限する if GlobalVariable.GetValueInt() 5 GlobalVariable.Mod(1) int i = 0 while i 100 ; ループ処理 ～ 省略 ～ Utility.wait(1) i += 1 endWhile GlobalVariable.Mod(-1) endif スクリプト最適化実践編 装備時のイベント重複防止 OnObjectEquippedは何か装備したときに発動するイベントですが、 一つのアイテムにもかかわらず、6回以上(特にエンチャント武器)呼び出されたりするうえ、対処が厄介です。 例では武器装備時に処理したい場合です。 Form PreObj = None Event OnObjectEquipped(Form akBaseObject, ObjectReference akReference) ; ベースオブジェクトが取得できない、エンチャント、装備が前と同じ場合は何もしない if akBaseObject == None || akBaseObject as Enchantment || akBaseObject == PreObj return endif ; OnObjectEquippedイベントを受け取らないようにする GotoState("Busy") ; 装備を記憶する PreObj = akBaseObject ; やりたいことをここに書く ; 装備の記憶を解除する PreObj = None ; OnObjectEquippedイベントを受け取るようにする GotoState("") EndEvent State Busy Event OnObjectEquipped(Form akBaseObject, ObjectReference akReference) EndEvent EndState 解説 aksourceをas enchantmentでキャスト(変換)すると、エンチャントかどうかの判定になる。 エンチャントが武器より先に処理されてしまって肝心の武器のほうがBusyで除外されちゃうので、エンチャントは最初にリターンで中断。 PreObjに前回のオブジェクトを代入しておいて、前回と同じだったらリターンで中断。ほぼ同タイミングぐらいに処理されるのでBusyだけだと間に合わずにこれが必要。 OnHitの重複防止 OnHitはエンチャントなどで延焼させている場合に、延焼ダメージが攻撃した武器ダメージと同じ換算してしまう仕様なので、けっこう重複しやすいのです。 事前にソース元を代入して被ったら飛ばす仕組み。 Form PreSource = None Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked) ;攻撃者がいない場合のエラー防止とダメージソースが武器以外はリターンで即処理中断 if akAggressor == None || !(akSource as Weapon) || akSource == PreSource return endif ;BusyのStateに飛ばす GotoState("Busy") ;PreSourceに今のダメージ元を代入 PreSource = akSource ;武器の種類を取得 int WeapType = (akSource as Weapon).GetWeaponType() ;両手剣または両手斧槌ならば if WeapType == 5 || WeapType == 6 Game.GetPlayer().DamageAV("Stamina",5.0) endif ;重複防止のため0.5秒待機 Utility.Wait(0.5) ;PreSourceをなしの状態に戻す PreSource = None ;Stateを元の状態に戻す GotoState("") EndEvent State Busy ;StateがBusyの時はOnHitイベントが起こっても何も処理しない Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked) EndEvent EndState スクリプトログをとる(デバッグの仕方) スクリプトログの設定 マイドキュメント\My Games\Skyrim\Skyrim.ini を開いて、以下の通りにしたあと保存。(項目がなければ追加) [Papyrus] bEnableLogging=1 bEnableTrace=1 bLoadDebugInformation=1 すると次回から マイドキュメント\My Games\Skyrim\Logs\Script にPapyrus.0.logというのが出ますのでメモ帳以外のテキストエディタで開くとデバッグの内容が見れます。 LogExpertを導入 リアルタイムでログが取れるツールです。 LogExpertをダウンロードします。 LogExpert.exeを起動します。 File→Openから、マイドキュメント\My Games\Skyrim\Logs\Script\Papyrus.0.logを開きます。 Options→Always on Topを押して、常に手前に表示にします。 Optionの下あたりにあるメニューのFollow Tailsにチェックを入れます。 スクリプトにデバッグ情報の記載 ログに書き出すにはDebug.Trace("文字")を使います。""のあとに+を使うと変数や関数の結果を書き出せます。 例： Event OnObjectEquipped(Form akBaseObject, ObjectReference akReference) Debug.Trace("Debug FormName" + akBaseObject.GetName() ) EndEvent これでゲームとLogExpertを起動して、装備を付けたりすることでスクリプトの動作をリアルタイムで確認できます。 意図する結果になるまで以下の手順で実験してみてください。 スクリプトを書き直してコンパイル コンソールコマンドで reloadscript script名 OnAnimationEventで取得できるイベント RegisterForAnimationEventで登録したアニメーションイベント（モーション）をOnAnimationEventで取得することができますが、 取得できるのとできないのがあります。 ☓staggerStart ○staggerStop Start系のモーションは軒並みダメです。 Skyrim - Animation.bsaの中のmeshes\responses\actorresponse.txt というテキストファイルに記載されてるのが使用可能なアニメーションイベントです。 ブロックの動作はじめにイベントを受け取りたい場合にBlockStartだとダメですが、裏ワザ的なやり方があります。 SoundPlay.NPCHumanCombatShieldBlockです。 SoundPlay系は受け取れるので開始時にイベント取得したいなという時にSoundPlayのAnimeEventをあたってみるといいと思います。 Gameplay - Animations.. - AnimEventの選択項目でSoundPlayを探して手当たり次第試してみましょう。 使えそうなイベント一覧 MRh_SpellFire_Event 右手で魔法を放ったとき MLh_SpellFire_Event 左手で魔法を放ったとき arrowRelease 矢を放ったとき BowDrawn 最大限弓を引いたとき weaponSwing 右手の武器を振ったとき weaponLeftSwing 右手の武器を振ったとき preHitFrame 近接攻撃がヒットする直前 HitFrame 近接攻撃がヒットしたとき。当たらない場合も検出する BashExit バッシュしたとき BashStop バッシュしたとき BashRelease バッシュボタンを押し続けてバッシュが発動したとき。パワーバッシュは盾装備時のみ検出する RemoveCharacterControllerFromWorld ラグドール状態になった時 KillMoveStart キルムーブが発生した時。実行者及び被害者両方で検出されるため注意 Decapitate キルムーブ等で首を刎ねられた時 参考になりそうなサイト Creationkit.com プレイヤー動作時のAnimEventが動く順番 Withe01さんのMOD作成日誌 20130930-対人用KillMove一覧 Withe01さんのMOD作成日誌 AnimationEvent Withe01さんブログは主に動作をさせる(イベントを起こす)ときのことが書いてある。 AnimationVariableの使い方 スカイリムのモーションを司るHavok Behaviorが扱うアニメーション変数(AnimationVariable)を取得したり変更したりできます。 これを使うことによってActorに関して細かく状態を判定したり、制御したりできます。 この変数はActorの種類によって異なります。 例えばCharacter(人)だとIsStaggeringはありますが、Dragonにはありません。 どんなアニメーション変数が何があるのかは以下のスプレッドシートのデータを確認してください。 人のアニメーション変数とイベントデータ 人以外のアニメーション変数とイベントデータ そのほかは、Josh Behavior file patcherで確認ができます。 人ならbehaviorフォルダの0_master.hkx、ドラゴンならdragonbehavior.hkx。 関数： Get/SetAnimationVariableBool Get/SetAnimationVariableFloat Get/SetAnimationVariableInt これらのアニメーション関数はConditionでも使えます。 Condtionでの関数名はGetGraphVariableFloatとGetGraphVariableIntです。 例：GetGraphVariableInt "IsStaggering" == 1 ;BoolはIntで代用。1はtrue 0はfalse さまざまな状態の判定 Actor.GetAnimationVariableBool("xxx") 判定 xxxに記載する文字列 攻撃中 IsAttacking ブロック中 IsBlocking バッシュ中 IsBashing はじかれ中 IsRecoiling よろめき中 IsStaggering 抜刀中 IsEquipping 納刀中 IsUnequipping ジャンプ中 bInJumpState ブロック成功 IsBlockHit 例：Actor.GetAnimationVariableBool("IsAttacking") ;攻撃中、パワーアタックも含まれる 一人称視点かどうかの判定 player.GetAnimationVariableInt("i1stPerson") == 1 移動方向の判定 floatのDirectionを使います。 Actor.GetAnimationVariableFloat("Direction") == 0 ; forward 時計回りに0から1まで。 0 前と立ち状態 0.125 右斜め前 0.25 右 0.375 右斜め後 0.5 後ろ 0.625 左斜め後 0.75 左 0.875 左斜め前 コントローラーのアナログスティックはSKSEやScriptDragon(※ScriptDragonはAnimationVaribleが使えません)でも検知できないので、このDirectionを使います。 立ち状態と前とで区別つけるときは下の移動中判定と組み合わせてください。 移動中かどうかの判定 一見するとbInMoveStateなんですが、壮大なトラップで片手どちらかに魔法か杖を持ってると移動中でもFalseを返します。 代わりにSpeedを使います。 if Actor.GetAnimationVariableFloat("Speed") 5.0 ;停止中 iStateの変数 GetAnimationVariableInt("iState")で取得できる値はMovement Typeと連動していると思われます。 何ができるかというと、状態判定ができます。 例：パピルスにはIsBlockingがないので、以下のようにします。(上のIsBlockingを使ったほうが確実) if (Actor.GetAnimationVariableInt("iState") == 4) || (Actor.GetAnimationVariableInt("iState") == 17) 変数の数値が何を意味するかは以下の通り。 スプリント中 1 iState_NPCSprinting スニーク移動中 2 iState_NPCSneaking 弓・クロスボウ構え中、リロード中 3 iState_NPCBowDrawn ブロック中 4 iState_NPCBlocking ダウン中 5 iState_NPCBleedout 片手・素手移動中 6 iState_NPC1HM 両手移動中 7 iState_NPC2HM 弓・クロスボウ移動中 8 iState_NPCBow 魔法移動中・停止中 9 iState_NPCMagic 魔法・杖キャスト中 10 iState_NPCMagicCasting 騎乗時？ 11 iState_NPCHorse 片手・素手攻撃中 12 iState_NPCAttacking 両手攻撃中 13 iState_NPCAttacking2H パワーアタック中 14 iState_NPCPowerAttacking 酩酊中？ 15 iState_NPCDrunk 弓・クロスボウ構え中(QuickShot習得後) 16 iState_NPCBowDrawnQuickShot ブロックランナー取得後ブロック中 17 iState_NPCBlockingShieldCharge 騎乗時移動中 60 iState_HorseDefault 騎乗時スプリント中 61 iState_HorseSprint 騎乗時ジャンプ中 62 iState_HorseFall 騎乗時水泳中 63 iState_HorseSwim これはBehaviorファイルのBSiStateTaggingGeneratorという項目で指定してます。 iStateToSetAsで数値指定で、iPriorityが優先度です。 一部プレイヤーとNPCで違う模様。アクターによっても違います。 セーブデータに残るもの Save File Note(CK wiki) セーブするとセーブデータに保存されるものがあります。 グローバル変数 静的変数 プロパティ 一旦セーブされたデータでMODを更新したときにプロパティや静的変数などを削除した場合やMODを抜いた場合はセーブ内と一致しないのでログにエラーを吐きます。 エラーを吐くのですが、データがないと無視するので基本的に害はありません。 不必要になったプロパティの削除 プロパティはesp側にも紐ついてるので、そちらも消す必要があります。 スクリプトのついてるPropertyボタンを押してプロパティウィンドウを出します。 不要なプロパティのClear Valueを押して消してください。 そのあと、スクリプト側のプロパティの記述を消します。 espを保存します。 SM Eventを使ったRepeatQuest OnUpdateを使わずにループができるクエストの作り方です。 セル移動時関係のイベント セル移動時にスクリプトを動かしたいときにいくつかイベントがあるんですが、どれも癖があってそれを記したいと思います。 Onload 3Dオブジェクトがロードされるときに発生するイベントで、ロード画面が挟むセル移動でなら起きます。 ただしセルを移動してすぐ戻る場合はセル移動時にロード挟まないのでその場合は発生しません。 プレイヤーは稼働しません。 OnAttachedToCell セルからセルに移動するときに発生するイベントです。 たとえばワールドTamrielのWildness1からWildness2に移動するときにも発生します。 ただしプレイヤーは稼働しません。 またスカイリムからホワイトランに入るときには動きません。（逆は動くので条件不明） OnLocationChange ロケーションの移動時に動くイベントですが、複数のセルをまとめて一つのロケーションとして扱う場合があって、例えばホワイトラン→スカイリム、スカイリム→ホワイトランは動きません。 ですので一般的にセル移動時判定には向いてません。 OnCellLoad セルロード時にイベントが発生しますが、メモリキャッシュ済みのセルの場合は発生しません。 続けてゲームプレイする場合に一度入ったセルにもう一度入った場合に発生しない可能性が高いです。 プレイヤー(エイリアス)に使えます。 NPCであれば、Onloadをおすすめします。 プレイヤーは厳密さを要求しないのであれば、OnCellLoadで大抵何とかなります。 NPCへのPerk付与について オススメはSPIDを使ったゲーム起動時のPerk付与です。 スクリプトのAddPerk関数 プレイヤーに対しては正常に機能しますが、NPCに対しては全く機能しません。 コンソールのAddPerkコマンド スクリプトのAddPerk関数と同様、プレイヤーに対してのみ正常に機能します。 マジックエフェクトの"Perk to Apply" スクリプトのAddPerk関数と同様、プレイヤーに対してのみ正常に機能します。 CKやxEditにて事前にPerkを持たせる プラグインを作成して事前にPerkを持たせておけば確実ですが、レコードの競合等により不具合が起こる危険性があります。 Spell Perk Item Distributor (SPID) にてゲーム起動時にPerkを持たせる NPCに事前にPerkを持たせておくことができるというSKSEプラグイン(LE/SE)です。ゲーム起動時にあたかもはじめから所持していたかのように処理されるため、レコードが競合する心配がありません。 powerofthree's Papyrus ExtenderのAddBasePerk関数 スクリプトでNPCへPerkの付与が可能になるSKSEプラグイン(LE / SE)です。いまのところゲーム中でPerkを付与する唯一の方法となります。 パークを付与する ; targetActorに対象のActor、addPerkに付与させたいPerkを渡す po3_sksefunctions.AddBasePerk(targetActor, addPerk) 付与したパークを消す po3_sksefunctions.RemoveBasePerk(targetActor, addPerk) ただし、powerofthree's Papyrus Extenderのパーク付与は以下の問題点もあるため、使用する場合は付与状況の監視が必要となります。 ※現状だと問題点あり NPCにパーク付与後に『対象NPCがパーク付与前かつセルにロードされている』セーブデータをロードするとセーブ時点でパーク未付与前のNPCにパークが付与される NPCにパーク付与後にNPCがセルからアンロードされた状態で保存した後にスカイリムを終了させ、再度起動してタイトルからロードした場合、ロード後のパーク付与がNPCに適用されない（正確にはセーブ時にAddBasePerkで何を追加されたかを保存するのだが、対象のNPCがアンロードされてると保存されない） 同一のアクターに二回以上AddBasePerkを行うと最初にAddBasePerkで付与したパークが再付与され二重に適用される(disable→enableで正常に戻る) → 4.5.2で修正 Perkの挙動について 追加Perk系のModを制作する時には特に下記の点に注意する事。 特定行動時にスペル付与系 Apply Combat Hit SpellやApply Weapon Swing Spellなど、 特定行動時にスペル効果を付与するパークについて条件を満たしたものが複数ある場合、 Priorityが0に近いパークのスペル効果のみが付与されます。 例として両手武器のウォーマスター(後ろパワーアタックで麻痺効果付与)はPriorityが0、出血攻撃(両手斧攻撃で出血状態付与)はPriorityは3～10が設定されており、 この場合、両手斧で後ろパワーアタックを行った場合はウォーマスターの効果が優先され出血攻撃の効果は出ません。 攻撃時やヒット時に魔法効果を付与といったものを作成したい場合、下手にパークのApply Combat Hit SpellやApply Weapon Swing Spellを使うとバニラのパークを含めて上手く動作しなくなる可能性が高いため、スクリプトで処理を行うことをオススメします。 なおこの制限についてはScrambled BugsというSKSEプラグインを導入して、ScrambledBugs.jsonのmultipleSpellsをtrueにする事で解除は可能です。 (制限解除時だと上の例にある両手斧で後ろパワーアタックで麻痺効果と出血攻撃の両方の効果が付与される) Add ValueやSet Value等の数値変動系の計算の優先度 バニラのクリティカル率や同時付呪数を変更するパークを確認するとEntry PointのFunctionがSet Value(絶対値)となっています。もし、クリティカル率が増減するパークを作成したい時に下記のようにAとBのパーク両方を保持した際に絶対値の後に計算されるのか疑問に思った人はいるはずです。 A. クリティカル率(Calculate My Critical Hit Chance)の値をSet Valueで設定 B. クリティカル率の値をAdd ValueやMultiply Valueで変動 結論としてAとBのパークについてどちらも保持した場合、Priorityの数値が高いパークから先に適応され計算されます。 Priorityが同値の場合はFormIDが大きい方から先に適応されます。 例： ※AのSet Valueが25、BはAdd Valueで50を設定していた場合 AのPriorityが0で、BのPriorityが1の場合：Bの数値設定でどれほど値を変動させてもAの数値となる(25) AのPriorityが1で、BのPriorityが0の場合：Aの数値に対してBの設定値で変動したものが最終的な値(75) AとBのPriorityが同値：FormIDが大きいものから先に適応 そして、クリティカル率が変動するパーク(片手武器の剣士等)、追加付呪のパークはSet Valueで値を固定されていてなおかつPriorityが0となっています。このため、クリティカル率の増減、または同時付呪数の増減パークをModで作成してもバニラのパークを所有した瞬間、Mod追加パークの効果が正常に反映されなくなってしまいます。 解決策として、追加付呪等の一部を除いたパークは非公式パッチ(SEのUSSEPで確認)でAdd Valueに修正されているため、非公式パッチを前提Modとして作成する必要があります。 非公式パッチを前提Modにしない場合は修正用espを別途作成し、「剣士(片手武器パーク)、深手(両手武器パーク)、クリティカルショット(弓パーク)、追加付呪(付呪パーク)」のEntry PointのFunctionをAdd Valueに修正する必要があります。 IsInKillMove関数の注意点 IsInKillMoveはアクターがキルムーブを実行中、またはキルムーブを受けてる最中の場合にもtrueを返すため、キルムーブの実行者か受けてる側かの判定はOnHitイベント(キルムーブの一撃でもHitイベントは発生する)やOnDyingイベント(キルムーブを受けてる最中に発生)を併用する必要があります。 スクリプトによる一部のフォームの値変更について SpellやArmor、Weapon等のベースフォームについてSet～関数等で値を変更しても一時的な値変更と扱われるためセーブデータに保存されません。(ActorBaseの関数もSetEssential等はセーブデータに保存されるが一部は一時的な変更になるものも存在する) また、一時的な値変更となるものに関してはゲームを再起動するまではリセットされないため、値変更後に変更前のセーブデータをロードしても値は変更後のままになります。 ConsoleUtilによるターゲットコマンド実行の注意点及び安全な実行について 負荷が掛かると誤実行される危険性がある ConsoleUtilでターゲットコマンド(SetAVやSetLevel等)を実行する場合、SetSelectedReference関数を使って対象の選択をすると思いますがSetSelectedReference関数にはコマンドの実行まで対象の切り替えを抑止する機能はありません。 ConsoleUtilを使ってるModが一つだけなら問題ないのですが複数のModがConsoleUtilでターゲットコマンドを使ってる場合は注意が必要です。 もしConsoleUtilを使ってるスクリプトの処理が重なるような事が起こった時にコマンド実行直前で別のスクリプトのSetSelectedReference関数で対象が変更される可能性があり指定していない対象に対してターゲットコマンドの誤実行が行われる危険性があります。（特にスクリプト遅延が起こってる状態では高確率で発生します） 対策 これに対する回避策としてターゲットコマンドを行う場合、下記のサンプルのようにコマンド文を "[ID]".[コマンド]にする事でコンソールの選択対象に関係無く[ID]の対象に対してコマンドを実行されます。 こうする事により指定した対象以外への誤実行を防ぐ事ができます。 ; ターゲットコマンドの安全実行 ; SetSelectedReference→ExecuteCommandの順で実行する場合、複数のスクリプトがConsoleUtilを使ってると、 ; コマンドが指定していない対象に対して誤実行される危険性があるため ; コマンド文を"[ID]".[コマンド]に変換し、コマンド実行を指定した対象に対して確実に行うようにする ; 数値の16進数文字変換はpowerofthree`s Papyrus ExtenderのSKSE関数を使用 function SafeTargetCommandExecute(string cmd, Form target) if target ; IDをダブルクォートで囲まないとIDに英文字が混ざってない場合にエラーが起こる cmd = "\"" + PO3_SKSEFunctions.IntToString(target.getFormID(), true) + "\"." + cmd else Debug.trace("Console Command Target is None " + cmd, 2) return endif ConsoleUtil.ExecuteCommand(cmd) endfunction アビリティ付与に関する注意 SPIDやスクリプト等でNPCに何かしらのアビリティを直接持たせた場合、NPCをテレポートしたり内部セルへ移動する等何かしらの要因で偶にアビリティに付属してる魔法効果が消滅するという現象が発生します。 アビリティに付属した魔法効果が消えた場合はアビリティの再付与を行わない限りは魔法効果が復活しません。 この現象はパーク効果にアビリティが付属してるものをNPCに持たせた場合は発生しません。アビリティをNPCに直接持たせた場合にのみに発生します。 (パークに付属したアビリティはゲームエンジンレベルで魔法効果が機能してるかチェックしてる？) そのためスクリプト付きアビリティをプレイヤーやNPCに配布するModを作成する場合、確実にアビリティを持たせて機能させたければダミーパークにアビリティを付属させてそのパークを付与させるようにしましょう。 Activate関係の処理について BlockActivation関数でアクティベートをブロックしてもOnActivateイベントは発生する アクター等に対してBlockActivation関数を実行した場合、 対象をアクティベートしても見た目上は反応が返ってきませんが、この時OnActivateイベントはしっかり発生します。 これはスクリプトのActivate関数で第ニ引数にfalseを渡してアクティベートがブロックされた際も同様です。 パークのアクティベート処理変更についての注意点 パークのEntry PointでActivateを設定してReplace Defaultにチェックを付けると 対象のアクティベート時に本来の動作の代わりにパークに付属したスクリプトの処理にすげ替える事ができます。 しかし、このアクティベートの動作変更を使用する場合は下記の点を考慮する必要があり、 特に下記の上2つの現象についてはちゃんと対処しておかないと 他のアクティベート関係の処理が行われるModと一緒に使用した場合に問題が発生する可能性があります。 (上2つの現象はEFFで確認が可能です) OnActivateイベントが発生しない 本来ならばアクティベートした瞬間にOnActivateイベントが発生するのですが パークによるアクティベート処理をスクリプト処理に挿げ替えてる場合はOnActivateイベントが発生しません。 アクティベート処理変更を行いつつOnActivateイベントを発生させたい場合は スクリプト処理内で対象に対してActivate関数を使用する事でOnActivateイベントを発生させられます。 デフォルトのアクティベート処理を実行させずに スクリプト処理だけ実行してOnActivateイベントを発生させたい場合は blockActivation関数でアクティベートをブロック後にActivate関数(第二引数はfalse)を実行し 再度blockActivation関数でブロック解除を行う必要があります。 スクリプト処理後にデフォルトのアクティベート処理を実行をする場合は blockActivation関数は使用せずに スクリプトの最後にActivate関数を実行すればよいだけです。 なお、Activate関数の第ニ引数をtrueを渡した場合はOnActivateイベントは発生しないので注意しましょう。 BlockActivation関数でアクティベートのブロックをしても処理が実行される BlockActivation関数によるアクティベートのブロックについては デフォルトのアクティベート動作のみが対象となり、 アクティベート処理をスクリプト処理に挿げ替えた場合は下記のようにスクリプト側で対象が アクティベートブロック状態かをチェックして抑制しないとそのままスクリプト処理が実行されてしまいます。 if akTargetRef.isActivationBlocked()returnendif スクリプト側でアクティベートした場合は動作変更が行われない パークによるアクティベート変更はゲーム内で直接アクティベートした場合のみ有効で スクリプトでActivate関数を呼び出した場合はデフォルトのアクティベート処理が行われます。 対処法のサンプル 上記のOnActivateイベントとblockActivation関数による抑制による スクリプトのサンプルは下記の通りとなります。 ; パークによるアクティベート動作変更時に; blockActivation関数によるアクティベートのブロックをしてる時に; 処理を実行しないようにしたり、; OnActivateイベントを発生させるためのサンプル; Fragment_2の関数名は環境によって異なるはずなので注意Function Fragment_2(ObjectReference akTargetRef, Actor akActor); パークによるアクティベート動作変更時は; スクリプト側でブロックしないとそのまま処理されてしまうif akTargetRef.isActivationBlocked();OnActivateイベントを発生させるakTargetRef.activate(akActor, false);Debug.trace("Block Activate")returnendif ; 以下～～～にアクティベート時に行う処理を記述する～～～～ ; パークによるアクティベート動作変更時はOnActivateイベントが発生しない; アクティベート対象に対してActivate関数を使用すればOnActivateイベントを発生させられるが; デフォルトのアクティベート処理まで実行してしまうため; blockActivation関数でデフォルトのアクティベート処理をブロックし、; Activate関数を使用後、再びブロックを解除するようにする; ; 処理後にデフォルトのアクティベート処理をしたい場合は; blockActivationはコメントアウトするakTargetRef.blockActivation(true);akTargetRef.activate(akActor, false);akTargetRef.blockActivation(false);EndFunction
https://w.atwiki.jp/customcombo/pages/12.html
2014年6月20日開催 新宿MARZ ■Ultimate Marvel vs Capcom 3 エントリー34名 優勝「TSS Takumi」 準優勝「てんぼす」 参加者一覧及びトーナメント表 Ultimate Marvel vs Capcom 3 決勝戦動画 ■The King of Fighters 13 エントリー32名 優勝「書記」 準優勝「ピクニック」 参加者及びトーナメント表 The King of Fighters 13 決勝戦動画 ■会場の風景 CCA7.jpg CCA8.jpg CCA9.jpg CCA10.jpg CCA11.jpg CCA12.jpg CCA13.jpg CCA14.jpg CCA15.jpg CCA16.jpg CCA17.jpg CCA18.jpg CCA19.jpg
https://w.atwiki.jp/abwiki/pages/218.html
MinGWのパブリックドメインのソース を ABに変換する 途中まで…あとはまかせた Const DLG_SCRNSAVECONFIGURE= 2003Const idsIsPassword=1000Const idsIniFile=1001Const idsScreenSaver=1002Const idsPassword=1003Const idsDifferentPW=1004Const idsChangePW=1005Const idsBadOldPW=1006Const idsAppName=1007Const idsNoHelpMemory=1008Const idsHelpFile=1009Const idsDefKeyword=1010Const IDS_DESCRIPTION =1Const ID_APP =100Const WS_GT =WS_GROUP or WS_TABSTOPConst SCRM_VERIFYPW=WM_APPConst MAXFILELEN=13Const TITLEBARNAMELEN=40Const APPNAMEBUFFERLEN=40Const BUFFLEN=255Const CLASS_SCRNSAVE = "WindowsScreenSaverClass"/* globals */Dim hMainWindow = NULL As HWNDDim fChildPreview = FALSE As LongDim hMainInstance As HINSTANCEDim szName[TITLEBARNAMELEN] As ByteDim szAppName[APPNAMEBUFFERLEN] As ByteDim szIniFile[MAXFILELEN] As ByteDim szScreenSaver[22] As ByteDim szHelpFile[MAXFILELEN] As ByteDim szNoHelpMemory[BUFFLEN] As ByteDim MyHelpMessage As DWord/* local house keeping */Dim hPwdLib = NULL As HINSTANCEDim pt_orig As POINTAPIDim checking_pwd = FALSE As LongDim closing = FALSE As LongDim w95 = FALSE As LongTypedef VERIFYPWDPROC = *Function(hwnd As HWND) As LongTypedef CHPWDPROC = *Function(s As *Byte,hwnd As HWND, wp As DWord, lp As DWord) As DWORDDim VerifyScreenSavePwd = NULL As VERIFYPWDPROC/* function names */Const szVerifyPassword = "VerifyScreenSavePwd"Const szPwdChangePassword = "PwdChangePasswordA"/*static void TerminateScreenSaver(HWND hWnd);static BOOL RegisterClasses(void);static LRESULT WINAPI SysScreenSaverProc(HWND,UINT,WPARAM,LPARAM);static int LaunchScreenSaver(HWND hParent);static void LaunchConfig(void);*/Function ISSPACE(c As Byte) As LongIf c = Asc(" ") Or c = Asc(Ex"\t") ThenISSPACE = TRUEEnd IfEnd FunctionFunction ISNUM(c As Byte) As LongIf c = Asc("0") And c = Asc("9") ThenISNUM = TRUEEnd IfEnd FunctionFunction _toul(s As *Byte) As DWord_toul = Val(s)'?End Function/* screen saver entry point */int APIENTRY WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR CmdLine, int nCmdShow) { LPSTR p; OSVERSIONINFO vi; /* initialize */ hMainInstance = hInst; vi.dwOSVersionInfoSize = sizeof(vi); GetVersionEx( vi); /* check if we are going to check for passwords */ if (vi.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) { HKEY hKey; /* we are using windows 95 */ w95 = TRUE; if (RegOpenKey(HKEY_CURRENT_USER, REGSTR_PATH_SCREENSAVE , hKey) == ERROR_SUCCESS) { DWORD check_pwd; DWORD size = sizeof(DWORD); DWORD type; LONG res; res = RegQueryValueEx(hKey, REGSTR_VALUE_USESCRPASSWORD, NULL, type, (PBYTE) check_pwd, size); if (check_pwd res == ERROR_SUCCESS) { hPwdLib = LoadLibrary(TEXT("PASSWORD.CPL")); if (hPwdLib) VerifyScreenSavePwd = GetProcAddress(hPwdLib, szVerifyPassword); } RegCloseKey(hKey); } } /* parse arguments */ for (p = CmdLine; *p; p++) { switch (*p) { case 'S' case 's' /* start screen saver */ return LaunchScreenSaver(NULL); case 'P' case 'p' { /* start screen saver in preview window */ HWND hParent; fChildPreview = TRUE; while (ISSPACE(*++p)); hParent = (HWND) _toul(p); if (hParent IsWindow(hParent)) return LaunchScreenSaver(hParent); } return 0; case 'C' case 'c' /* display configure dialog */ LaunchConfig(); return 0; case 'A' case 'a' { /* change screen saver password */ HWND hParent; while (ISSPACE(*++p)); hParent = (HWND) _toul(p); if (!hParent || !IsWindow(hParent)) hParent = GetForegroundWindow(); ScreenSaverChangePassword(hParent); } return 0; case '-' case '/' case ' ' default ; } } LaunchConfig(); return 0; }static void LaunchConfig(void) { /* FIXME should this be called */ RegisterDialogClasses(hMainInstance); /* display configure dialog */ DialogBox(hMainInstance, MAKEINTRESOURCE(DLG_SCRNSAVECONFIGURE), GetForegroundWindow(), (DLGPROC) ScreenSaverConfigureDialog); }static int LaunchScreenSaver(HWND hParent) { BOOL foo; UINT style; RECT rc; MSG msg; /* don't allow other tasks to get into the foreground */ if (w95 !fChildPreview) SystemParametersInfo(SPI_SCREENSAVERRUNNING, TRUE, foo, 0); msg.wParam = 0; /* register classes, both user defined and classes used by screen saver library */ if (!RegisterClasses()) { MessageBox(NULL, TEXT("RegisterClasses() failed"), NULL, MB_ICONHAND); goto restore; } /* a slightly different approach needs to be used when displaying in a preview window */ if (hParent) { style = WS_CHILD; GetClientRect(hParent, rc); } else { style = WS_POPUP; rc.right = GetSystemMetrics(SM_CXSCREEN); rc.bottom = GetSystemMetrics(SM_CYSCREEN); style |= WS_VISIBLE; } /* create main screen saver window */ hMainWindow = CreateWindowEx(hParent ? 0 WS_EX_TOPMOST, CLASS_SCRNSAVE, TEXT("SCREENSAVER"), style, 0, 0, rc.right, rc.bottom, hParent, NULL, hMainInstance, NULL); /* display window and start pumping messages */ if (hMainWindow) { UpdateWindow(hMainWindow); ShowWindow(hMainWindow, SW_SHOW); while (GetMessage( msg, NULL, 0, 0) == TRUE) { TranslateMessage( msg); DispatchMessage( msg); } }restore /* restore system */ if (w95 !fChildPreview) SystemParametersInfo(SPI_SCREENSAVERRUNNING, FALSE, foo, 0); FreeLibrary(hPwdLib); return msg.wParam; }/* this function takes care of *must* do tasks, like terminating screen saver */static LRESULT WINAPI SysScreenSaverProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_CREATE if (!fChildPreview) SetCursor(NULL); /* mouse is not supposed to move from this position */ GetCursorPos( pt_orig); break; case WM_DESTROY PostQuitMessage(0); break; case WM_TIMER if (closing) return 0; break; case WM_PAINT if (closing) return DefWindowProc(hWnd, msg, wParam, lParam); break; case WM_SYSCOMMAND if (!fChildPreview) switch (wParam) { case SC_CLOSE case SC_SCREENSAVE case SC_NEXTWINDOW case SC_PREVWINDOW return FALSE; } break; case WM_MOUSEMOVE case WM_LBUTTONDOWN case WM_RBUTTONDOWN case WM_MBUTTONDOWN case WM_KEYDOWN case WM_SYSKEYDOWN case WM_NCACTIVATE case WM_ACTIVATE case WM_ACTIVATEAPP if (closing) return DefWindowProc(hWnd, msg, wParam, lParam); break; } return ScreenSaverProc(hWnd, msg, wParam, lParam); }LONG WINAPI DefScreenSaverProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { /* don't do any special processing when in preview mode */ if (fChildPreview || closing) return DefWindowProc(hWnd, msg, wParam, lParam); switch (msg) { case WM_CLOSE TerminateScreenSaver(hWnd); /* do NOT pass this to DefWindowProc; it will terminate even if an invalid password was given. */ return 0; case SCRM_VERIFYPW /* verify password or return TRUE if password checking is turned off */ if (VerifyScreenSavePwd) return VerifyScreenSavePwd(hWnd); else return TRUE; case WM_SETCURSOR if (checking_pwd) break; SetCursor(NULL); return TRUE; case WM_NCACTIVATE case WM_ACTIVATE case WM_ACTIVATEAPP if (wParam != FALSE) break; case WM_MOUSEMOVE { POINT pt; GetCursorPos( pt); if (pt.x == pt_orig.x pt.y == pt_orig.y) break; } case WM_LBUTTONDOWN case WM_RBUTTONDOWN case WM_MBUTTONDOWN case WM_KEYDOWN case WM_SYSKEYDOWN /* try to terminate screen saver */ if (!checking_pwd) PostMessage(hWnd, WM_CLOSE, 0, 0); break; } return DefWindowProc(hWnd, msg, wParam, lParam); }static void TerminateScreenSaver(HWND hWnd) { /* don't allow recursion */ if (checking_pwd || closing) return; /* verify password */ if (VerifyScreenSavePwd) { checking_pwd = TRUE; closing = SendMessage(hWnd, SCRM_VERIFYPW, 0, 0); checking_pwd = FALSE; } else closing = TRUE; /* are we closing? */ if (closing) { DestroyWindow(hWnd); } else GetCursorPos( pt_orig); /* if not get new mouse position */ }/* Register screen saver window class and call user supplied hook. */static BOOL RegisterClasses(void) { WNDCLASS cls; cls.hCursor = NULL; cls.hIcon = LoadIcon(hMainInstance, MAKEINTATOM(ID_APP)); cls.lpszMenuName = NULL; cls.lpszClassName = CLASS_SCRNSAVE; cls.hbrBackground = GetStockObject(BLACK_BRUSH); cls.hInstance = hMainInstance; cls.style = CS_VREDRAW | CS_HREDRAW | CS_SAVEBITS | CS_PARENTDC; cls.lpfnWndProc = (WNDPROC) SysScreenSaverProc; cls.cbWndExtra = 0; cls.cbClsExtra = 0; if (!RegisterClass( cls)) return FALSE; return RegisterDialogClasses(hMainInstance); }void WINAPI ScreenSaverChangePassword(HWND hParent) { /* load Master Password Router (MPR) */ HINSTANCE hMpr = LoadLibrary(TEXT("MPR.DLL")); if (hMpr) { CHPWDPROC ChangePassword; ChangePassword = (CHPWDPROC) GetProcAddress(hMpr, szPwdChangePassword); /* change password for screen saver provider */ if (ChangePassword) ChangePassword(TEXT("SCRSAVE"), hParent, 0, NULL); FreeLibrary(hMpr); } }
https://w.atwiki.jp/code_matome/pages/37.html
Internet Engineering Task Force (IETF) Z. Shelby Request for Comments 7252 ARM Category Standards Track K. Hartke ISSN 2070-1721 C. Bormann Universitaet Bremen TZI June 2014 The Constrained Application Protocol (CoAP) 制約付きアプリケーションプロトコル（CoAP） Abstract The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAPは制約の有るノードや制約のあるネットワーク(例：低消費電力、損失の多い)で使用するためのWeb転送プロトコルである。ノードは低容量のRAM and ROMで8bitのマイコンであることが多く、IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) では高いパケットエラー率でありスループットは10kbit/sである。このプロトコルはスマートエネルギーやビルオートメーションとしてM2Mアプリケーションのために設計された。 CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. CoAPはアプリケーションエンドポイント間のrequest/responseモデルを提供し、URIとInternet media typeのようなWebの主要な要素を含むサービス、リソースへのアクセスを提供する。CoAPは制限のある環境のためにシンプル、低オーバーヘッド、マルチキャストのような特殊な要求を満たしながら、HTTPとの相互運用性を容易に満たすインターフェースとして設計されている。 Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http //www.rfc-editor.org/info/rfc7252. Shelby, et al. Standards Track [Page 1] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust s Legal Provisions Relating to IETF Documents (http //trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 専門用語 2. Constrained Application Protocol . . . . . . . . . . . . . . 10 2.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 11 2.2. Request/Response Model . . . . . . . . . . . . . . . . . 12 2.3. Intermediaries and Caching . . . . . . . . . . . . . . . 15 仲介、媒介とキャッシュ 2.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 15 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Option Value Formats . . . . . . . . . . . . . . . . . . 19 4. Message Transmission . . . . . . . . . . . . . . . . . . . . 20 4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 20 4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 21 信頼性のあるメッセージ送信 4.3. Messages Transmitted without Reliability . . . . . . . . 23 信頼性のないメッセージ送信 4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 24 メッセージの関連性 4.5. Message Deduplication . . . . . . . . . . . . . . . . . . 24 メッセージの重複排除 4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 25 4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 26 輻輳制御 4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 27 4.8.1. Changing the Parameters . . . . . . . . . . . . . . . 27 4.8.2. Time Values Derived from Transmission Parameters . . 28 5. Request/Response Semantics . . . . . . . . . . . . . . . . . 31 5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1. Piggybacked . . . . . . . . . . . . . . . . . . . . . 33 5.2.2. Separate . . . . . . . . . . . . . . . . . . . . . . 33 5.2.3. Non-confirmable . . . . . . . . . . . . . . . . . . . 34 5.3. Request/Response Matching . . . . . . . . . . . . . . . . 34 5.3.1. Token . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.2. Request/Response Matching Rules . . . . . . . . . . . 35 Shelby, et al. Standards Track [Page 2] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 5.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.4.1. Critical/Elective . . . . . . . . . . . . . . . . . . 37 5.4.2. Proxy Unsafe or Safe-to-Forward and NoCacheKey . . . 38 5.4.3. Length . . . . . . . . . . . . . . . . . . . . . . . 38 5.4.4. Default Values . . . . . . . . . . . . . . . . . . . 38 5.4.5. Repeatable Options . . . . . . . . . . . . . . . . . 39 5.4.6. Option Numbers . . . . . . . . . . . . . . . . . . . 39 5.5. Payloads and Representations . . . . . . . . . . . . . . 40 5.5.1. Representation . . . . . . . . . . . . . . . . . . . 40 5.5.2. Diagnostic Payload . . . . . . . . . . . . . . . . . 41 5.5.3. Selected Representation . . . . . . . . . . . . . . . 41 5.5.4. Content Negotiation . . . . . . . . . . . . . . . . . 41 5.6. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.6.1. Freshness Model . . . . . . . . . . . . . . . . . . . 43 5.6.2. Validation Model . . . . . . . . . . . . . . . . . . 43 5.7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . 44 5.7.1. Proxy Operation . . . . . . . . . . . . . . . . . . . 44 5.7.2. Forward-Proxies . . . . . . . . . . . . . . . . . . . 46 5.7.3. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 46 5.8. Method Definitions . . . . . . . . . . . . . . . . . . . 47 5.8.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.8.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 47 5.8.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.8.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 48 5.9. Response Code Definitions . . . . . . . . . . . . . . . . 48 5.9.1. Success 2.xx . . . . . . . . . . . . . . . . . . . . 48 5.9.2. Client Error 4.xx . . . . . . . . . . . . . . . . . . 50 5.9.3. Server Error 5.xx . . . . . . . . . . . . . . . . . . 51 5.10. Option Definitions . . . . . . . . . . . . . . . . . . . 52 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query . . . . 53 5.10.2. Proxy-Uri and Proxy-Scheme . . . . . . . . . . . . . 54 5.10.3. Content-Format . . . . . . . . . . . . . . . . . . . 55 5.10.4. Accept . . . . . . . . . . . . . . . . . . . . . . . 55 5.10.5. Max-Age . . . . . . . . . . . . . . . . . . . . . . 55 5.10.6. ETag . . . . . . . . . . . . . . . . . . . . . . . . 56 5.10.7. Location-Path and Location-Query . . . . . . . . . . 57 5.10.8. Conditional Request Options . . . . . . . . . . . . 57 5.10.9. Size1 Option . . . . . . . . . . . . . . . . . . . . 59 6. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.1. coap URI Scheme . . . . . . . . . . . . . . . . . . . . . 59 6.2. coaps URI Scheme . . . . . . . . . . . . . . . . . . . . 60 6.3. Normalization and Comparison Rules . . . . . . . . . . . 61 6.4. Decomposing URIs into Options . . . . . . . . . . . . . . 61 6.5. Composing URIs from Options . . . . . . . . . . . . . . . 62 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 64 7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 64 7.2.1. ct Attribute . . . . . . . . . . . . . . . . . . . 64 Shelby, et al. Standards Track [Page 3] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 65 8.1. Messaging Layer . . . . . . . . . . . . . . . . . . . . . 65 8.2. Request/Response Layer . . . . . . . . . . . . . . . . . 66 8.2.1. Caching . . . . . . . . . . . . . . . . . . . . . . . 67 8.2.2. Proxying . . . . . . . . . . . . . . . . . . . . . . 67 9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 68 9.1. DTLS-Secured CoAP . . . . . . . . . . . . . . . . . . . . 69 9.1.1. Messaging Layer . . . . . . . . . . . . . . . . . . . 70 9.1.2. Request/Response Layer . . . . . . . . . . . . . . . 71 9.1.3. Endpoint Identity . . . . . . . . . . . . . . . . . . 71 10. Cross-Protocol Proxying between CoAP and HTTP . . . . . . . . 74 10.1. CoAP-HTTP Proxying . . . . . . . . . . . . . . . . . . . 75 10.1.1. GET . . . . . . . . . . . . . . . . . . . . . . . . 76 10.1.2. PUT . . . . . . . . . . . . . . . . . . . . . . . . 77 10.1.3. DELETE . . . . . . . . . . . . . . . . . . . . . . . 77 10.1.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 77 10.2. HTTP-CoAP Proxying . . . . . . . . . . . . . . . . . . . 77 10.2.1. OPTIONS and TRACE . . . . . . . . . . . . . . . . . 78 10.2.2. GET . . . . . . . . . . . . . . . . . . . . . . . . 78 10.2.3. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 79 10.2.4. POST . . . . . . . . . . . . . . . . . . . . . . . . 79 10.2.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . 79 10.2.6. DELETE . . . . . . . . . . . . . . . . . . . . . . . 80 10.2.7. CONNECT . . . . . . . . . . . . . . . . . . . . . . 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 11.1. Parsing the Protocol and Processing URIs . . . . . . . . 80 11.2. Proxying and Caching . . . . . . . . . . . . . . . . . . 81 11.3. Risk of Amplification . . . . . . . . . . . . . . . . . 81 11.4. IP Address Spoofing Attacks . . . . . . . . . . . . . . 83 11.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 84 11.6. Constrained-Node Considerations . . . . . . . . . . . . 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 12.1. CoAP Code Registries . . . . . . . . . . . . . . . . . . 86 12.1.1. Method Codes . . . . . . . . . . . . . . . . . . . . 87 12.1.2. Response Codes . . . . . . . . . . . . . . . . . . . 88 12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 89 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 91 12.4. URI Scheme Registration . . . . . . . . . . . . . . . . 93 12.5. Secure URI Scheme Registration . . . . . . . . . . . . . 94 12.6. Service Name and Port Number Registration . . . . . . . 95 12.7. Secure Service Name and Port Number Registration . . . . 96 12.8. Multicast Address Registration . . . . . . . . . . . . . 97 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 98 14.2. Informative References . . . . . . . . . . . . . . . . . 100 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 104 Appendix B. URI Examples . . . . . . . . . . . . . . . . . . . . 110 Shelby, et al. Standards Track [Page 4] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 1. Introduction The use of web services (web APIs) on the Internet has become ubiquitous in most applications and depends on the fundamental Representational State Transfer [REST] architecture of the Web. Internetのweb serviceの利用(web API)はWebのRESTアーキテクチャに依存した多くのアプリケーションで普及している。 The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g., 6LoWPAN, [RFC4944]). Constrained networks such as 6LoWPAN support the fragmentation of IPv6 packets into small link- layer frames; however, this causes significant reduction in packet delivery probability. One design goal of CoAP has been to keep message overhead small, thus limiting the need for fragmentation. 制約付きRESTful Environment(CoRE)は制約されたノード(8bitマイコン、RAM and ROM制限あり)とnetwork(6LoWPAN)に適したRESTアーキテクチャの実現を目指している。6LoWPANのような制約付きネットワークでは小さなLink-layerフレームへのIPv6パケットのフラグメンテーションをサポートする。しかし、これはパケット転送率の低下を引き起こす。CoAPの設計の一つの目標はフラグメンテーションを抑え、メッセージのオーバーヘッドを減らすことである。 One of the main goals of CoAP is to design a generic web protocol for the special requirements of this constrained environment, especially considering energy, building automation, and other machine-to-machine (M2M) applications. The goal of CoAP is not to blindly compress HTTP [RFC2616], but rather to realize a subset of REST common with HTTP but optimized for M2M applications. Although CoAP could be used for refashioning simple HTTP interfaces into a more compact protocol, more importantly it also offers features for M2M such as built-in discovery, multicast support, and asynchronous message exchanges. CoAPの目的のひとつは、エネルギー制限、ビルオートメーション、その他のM2Mアプリケーションのような制約された環境への特別な要求への一般的なWebプロトコルを設計することである。CoAPの目的は単にHTTPを圧縮することではなく、HTTPと共通のRESTを実現しながら、M2Mアプリケーション向けに最適化することである。CoAPはHTTPを単純化するために使用でき、M2Mのためのbuilt-in discovery（SSDP?）、マルチキャスト、非同期メッセージ交換をサポートする。 This document specifies the Constrained Application Protocol (CoAP), which easily translates to HTTP for integration with the existing Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments and M2M applications. 本ドキュメントでは制約のある環境、M2Mアプリケーション、マルチキャスト、低オーバーヘッドのような要求を満たし、簡単にHTTPと変換して既存のWebとの互換性を実現できるCoAPを規定する。 1.1. Features CoAP has the following main features CoAPには主要な下記の機能がある。 o Web protocol fulfilling M2M requirements in constrained environments Webプロトコル：制約のある環境におけるM2M要求を満たす。 o UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests. UDP：信頼性のあるユニキャストとマルチキャストをサポートする。 o Asynchronous message exchanges. 非同期メッセージの交換。 o Low header overhead and parsing complexity. ヘッダー：オーバーヘッドとパーサーの複雑さが低い。 o URI and Content-type support. URIとContent-typeのサポート。 o Simple proxy and caching capabilities. Simple proxyとキャッシュ機能のサポート。 Shelby, et al. Standards Track [Page 5] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 o A stateless HTTP mapping, allowing proxies to be built providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP. HTTP経由でのCoAPリソースへのアクセスおよびCoAPでのHTTP interfaceの大体が可能なstatelessなHTTPとの対応付けが可能。 o Security binding to Datagram Transport Layer Security (DTLS) [RFC6347]. セキュリティ：DTLSによる。 1.2. Terminology The key words MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , NOT RECOMMENDED , MAY , and OPTIONAL in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lowercase, absent their normative meanings. This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC2616], including resource , representation , cache , and fresh . (Having been completed before the updated set of HTTP RFCs, RFC 7230 to RFC 7235, became available, this specification specifically references the predecessor version -- RFC 2616.) In addition, this specification defines the following terminology Endpoint An entity participating in the CoAP protocol. Colloquially, an endpoint lives on a Node , although Host would be more consistent with Internet standards usage, and is further identified by transport-layer multiplexing information that can include a UDP port number and a security association (Section 4.1). CoAPプロトコルを利用するエンティティ。Node内に位置し、Hostとも呼ばれる。Transport-layerのUDP port番号とsecurity association（Section 4.1）により識別できる。 Sender The originating endpoint of a message. When the aspect of identification of the specific sender is in focus, also source endpoint . メッセージを発信するendpoint。特定の送信者に注目する場合、source endpointともいう。 Recipient The destination endpoint of a message. When the aspect of identification of the specific recipient is in focus, also destination endpoint . メッセージを受信するendpoint。特定の受信者に注目する場合、destination endpointともいう。 Client The originating endpoint of a request; the destination endpoint of a response. requestを発信するendpoint。responseの宛先のendpoint。 Server The destination endpoint of a request; the originating endpoint of a response. requestの宛先のendpoint。responseを発信するendpoint。 Shelby, et al. Standards Track [Page 6] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Origin Server The server on which a given resource resides or is to be created. リソースが存在するか生成されるサーバー。 Intermediary A CoAP endpoint that acts both as a server and as a client towards an origin server (possibly via further intermediaries). A common form of an intermediary is a proxy; several classes of such proxies are discussed in this specification. serverとしてと、origin serverに対するclientとして（他のintermediary経由でもよい）動作するCoAP endpoint。一般的にはproxyである。本仕様で議論する。 Proxy An intermediary that mainly is concerned with forwarding requests and relaying back responses, possibly performing caching, namespace translation, or protocol translation in the process. As opposed to intermediaries in the general sense, proxies generally do not implement specific application semantics. Based on the position in the overall structure of the request forwarding, there are two common forms of proxy forward-proxy and reverse-proxy. In some cases, a single endpoint might act as an origin server, forward-proxy, or reverse-proxy, switching behavior based on the nature of each request. 主にrequestの転送とresponseの中継、キャッシュ、名前空間の変換、プロトコル変換などをするintermediary。汎用的な意味を持つintermediaryに対して、proxyは通常、特別なアプリケーションセマンティクスを実装しない。request転送の方法により、forward-proxyとreverse-proxyに分類される。あるケースでは各リクエストに従い一つのendpointがorigin server、forward-proxy、revere-proxyの役目を切り替える。 Forward-Proxy An endpoint selected by a client, usually via local configuration rules, to perform requests on behalf of the client, doing any necessary translations. Some translations are minimal, such as for proxy requests for coap URIs, whereas other requests might require translation to and from entirely different application- layer protocols. 設定によりclientが選択したendpointで、clientに代わって必要に応じて変換をしてrequestを実行する。全く異なるrequestをするとapplication-layerプロトコルでも変換が必要になるため、変換は最小限である。 Reverse-Proxy An endpoint that stands in for one or more other server(s) and satisfies requests on behalf of these, doing any necessary translations. Unlike a forward-proxy, the client may not be aware that it is communicating with a reverse-proxy; a reverse-proxy receives requests as if it were the origin server for the target resource. 複数のserverの代わりに必要に応じて変換してリクエストを処理するendpoint。reverse-proxyはtarget resourceのorigin serverであるかのようにrequestを受信するため、forward-proxyと異なり、clientはreverse-proxyを意識しないかもしれない。 CoAP-to-CoAP Proxy A proxy that maps from a CoAP request to a CoAP request, i.e., uses the CoAP protocol both on the server and the client side. Contrast to cross-proxy. CoAP requestとCoAP requestをmapするproxy。server、clientとしてCoAPプロトコルを使用する。cross-proxyとは対照的。 Cross-Proxy A cross-protocol proxy, or cross-proxy for short, is a proxy that translates between different protocols, such as a CoAP-to- HTTP proxy or an HTTP-to-CoAP proxy. While this specification makes very specific demands of CoAP-to-CoAP proxies, there is more variation possible in cross-proxies. cross-protocol proxy、cross-proxyはCoAP-to-HTTPやHTTP-to-CoAPのように異なるプロトコルを変換する。この仕様ではCoAP-to-CoAP proxyについて様々な規定をしているが、cross-proxyにも様々なバリエーションがある。 Shelby, et al. Standards Track [Page 7] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Confirmable Message Some messages require an acknowledgement. These messages are called Confirmable . When no packets are lost, each Confirmable message elicits exactly one return message of type Acknowledgement or type Reset. 一部のmessageはacknowledgementが必要である。そのようなメッセージはConfirmableと呼ばれる。パケットがロスしない場合、各Confrmable messageはAcknowledgementかResetのメッセージを応答する。 Non-confirmable Message Some other messages do not require an acknowledgement. This is particularly true for messages that are repeated regularly for application requirements, such as repeated readings from a sensor. Acknowledgementが必要でないメッセージ。センサーから定期的にデータを読み込むような、定期的なメッセージのアプリケーション要件のために使用される。 Acknowledgement Message An Acknowledgement message acknowledges that a specific Confirmable message arrived. By itself, an Acknowledgement message does not indicate success or failure of any request encapsulated in the Confirmable message, but the Acknowledgement message may also carry a Piggybacked Response (see below). Acknowledgement messageは特定のConfirmable messageの到達を伝える。このmessage自体がConfirmable messageのfailure/successを示すわけではないが、Piggybacked Responseで送信することはできる。 Reset Message A Reset message indicates that a specific message (Confirmable or Non-confirmable) was received, but some context is missing to properly process it. This condition is usually caused when the receiving node has rebooted and has forgotten some state that would be required to interpret the message. Provoking a Reset message (e.g., by sending an Empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ( CoAP ping ). Reset messageは特定のメッセージ(Confrmable or Non-confirmable)を受信したが、そのmessageを処理するためのcontextが失われていることを示す。受信nodeがrebootや状態を忘れてしまった場合にこの状態が発生する。Reset messageはエンドポイントの死活確認にも有効である（例：Empty Confirmable messageの送信）。 Piggybacked Response A piggybacked Response is included right in a CoAP Acknowledgement (ACK) message that is sent to acknowledge receipt of the Request for this Response (Section 5.2.1). piggybacked ResponseはCoAP Acknowledgement(ACK) messageに含まれる、Requestの受信のacknowledgeのためのResponse。 Separate Response When a Confirmable message carrying a request is acknowledged with an Empty message (e.g., because the server doesn t have the answer right away), a Separate Response is sent in a separate message exchange (Section 5.2.2). Requestを送信するConfirmable messageのacknowledgeがEmpty messageの場合（例えば、serverがすぐに応答できなかった場合）、Separate message exchangeのSeparate Responseが送信される(Section 5.2.2)。 Empty Message A message with a Code of 0.00; neither a request nor a response. An Empty message only contains the 4-byte header. Codeが0.00のmessage。requestでもresponseでもない。Empty messageは4byteのheaderのみで構成される。 Shelby, et al. Standards Track [Page 8] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Critical Option An option that would need to be understood by the endpoint ultimately receiving the message in order to properly process the message (Section 5.4.1). Note that the implementation of critical options is, as the name Option implies, generally optional unsupported critical options lead to an error response or summary rejection of the message. endpointが受信したメッセージを正しく処理するために必要なオプション。 Option は一般的にはoptionalという意味があるため、critical optionの実装には注意すること。critical optionがサポートされていない場合、error responseかmessageのsummary rejection★(summary rejectionって何？)をする。 Elective Option An option that is intended to be ignored by an endpoint that does not understand it. Processing the message even without understanding the option is acceptable (Section 5.4.1). optionをサポートしていないendpointでは無視されるoption。optionを無視してメッセージを処理することは許容される。(Section 5.4.1) Unsafe Option An option that would need to be understood by a proxy receiving the message in order to safely forward the message (Section 5.4.2). Not every critical option is an unsafe option. messageを安全に転送するため()Section 5.4.2 ★(safely forwardって何)、このmessageを受信したproxyによって使用される。全てのcritical optionがunsafe optionというわけではない。 Safe-to-Forward Option An option that is intended to be safe for forwarding by a proxy that does not understand it. Forwarding the message even without understanding the option is acceptable (Section 5.4.2). 対応していないproxyが転送をsafeにすることを意図する。optionを理解できない場合の転送も許容される(Section 5.4.2★safe転送が不明)。 Resource Discovery The process where a CoAP client queries a server for its list of hosted resources (i.e., links as defined in Section 7). CoAP clientがserverのもつresourceのlistを取得するためのプロセス。(Section 7のlink) Content-Format The combination of an Internet media type, potentially with specific parameters given, and a content-coding (which is often the identity content-coding), identified by a numeric identifier defined by the CoAP Content-Formats registry. When the focus is less on the numeric identifier than on the combination of these characteristics of a resource representation, this is also called representation format . Internet media typeとcontent-coding（content-codingの識別子）の組み合わせで、 CoAP Content-Formats のレジストリで定義された数値で識別される。 Additional terminology for constrained nodes and constrained-node networks can be found in [RFC7228]. 制約のあるノードと制約のあるノードのネットワークに関する用語はRFC7228にある。 In this specification, the term byte is used in its now customary sense as a synonym for octet . 本仕様における byte という用語は、 octet と同義で仕様される。 All multi-byte integers in this protocol are interpreted in network byte order. このプロトコルのマルチバイトの整数は、ネットワークバイトオーダー（ビッグエンディアン）で解釈される。 Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator ** stands for exponentiation. 算術演算では、**のべき乗以外は、C言語と同じ表記を使用する。 Shelby, et al. Standards Track [Page 9] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 2. Constrained Application Protocol 制約のあるアプリケーションプロトコル The interaction model of CoAP is similar to the client/server model of HTTP. However, machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles. A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identified by a URI) on a server. The server then sends a response with a Response Code; this response may include a resource representation. CoAPのモデルはHTTPのclient/server modelに似ている。M2MではCoAPはclient/serverの両方で動作する。CoAP requestはHTTPと同様に、serverのresource(URIで識別される)に対するaction(Methed Codeを使用)を要求としてclientから送信する。serverはResponse Codeおよび場合によってはresouceを応答として送信する。 Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such as UDP. This is done logically using a layer of messages that supports optional reliability (with exponential back-off). CoAP defines four types of messages Confirmable, Non-confirmable, Acknowledgement, Reset. Method Codes and Response Codes included in some of these messages make them carry requests or responses. The basic exchanges of the four types of messages are somewhat orthogonal to the request/response interactions; requests can be carried in Confirmable and Non- confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages. HTTPと異なり、CoAPではUDPのようなdatagram-oriented転送の非同期の交換を使用する。信頼性がオプションとして提供される。CoAPでは4つのメッセージ（Confrmable、Non-confirmable、Acknowledgement、Reset）が定義される。これらのメッセージがrequestやresponseで送信されるとき、Method CodeやResponse Codeが含まれる。4つのメッセージはRequest/Responseに関係している。RequestはConfirmableとNon-confirmable message、ResponseはAcknowledgementにpiggybackしてメッセージを含めることができる。 One could think of CoAP logically as using a two-layer approach, a CoAP messaging layer used to deal with UDP and the asynchronous nature of the interactions, and the request/response interactions using Method and Response Codes (see Figure 1). CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header. CoAPは2つのレイヤとして考えるとこができる。CoAP Message layerはUDPとの間の処理、request/responseはMethod/Response Codeによる処理を実施する(Figure 1参照)。しかし、CoAPは1つのプロトコルであり、messaging、request/responseはCoAP headerで実現される。 +----------------------+ | Application | +----------------------+ +----------------------+ \ | Requests/Responses | | |----------------------| | CoAP | Messages | | +----------------------+ / +----------------------+ | UDP | +----------------------+ Figure 1 Abstract Layering of CoAP Shelby, et al. Standards Track [Page 10] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 2.1. Messaging Model The CoAP messaging model is based on the exchange of messages over UDP between endpoints. CoAP messaging modelはendpoint間のUDPメッセージ交換に基いている。 CoAP uses a short fixed-length binary header (4 bytes) that may be followed by compact binary options and a payload. This message format is shared by requests and responses. The CoAP message format is specified in Section 3. Each message contains a Message ID used to detect duplicates and for optional reliability. (The Message ID is compact; its 16-bit size enables up to about 250 messages per second from one endpoint to another with default protocol parameters.) CoAPは後にバイナリのオプションとpayloadが続く、固定長のbinary header(4 bytes)を使用する。このメッセージフォーマットはrequest/responseで共通である。CoAPのメッセージフォーマットはSection 3で規定される。各メッセージには重複検出とoptionの信頼性のためのMessage IDが含まれる。Message IDはコンパクトで、16bitであり、あるendpointから別のendpointに対して250メッセージ/sを可能とする（Memo 16bit=65535★250メッセージ/sの理由）。 Reliability is provided by marking a message as Confirmable (CON). A Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends an Acknowledgement message (ACK) with the same Message ID (in this example, 0x7d34) from the corresponding endpoint; see Figure 2. When a recipient is not at all able to process a Confirmable message (i.e., not even able to provide a suitable error response), it replies with a Reset message (RST) instead of an Acknowledgement (ACK). 信頼性はConfirmable(CON)のmessageとして提供される。Confirmable messageは再送期間中、受信者が対応するendpointからの同じMessage IDをもつAcknowledgement message(ACK)を送信するまで、timeoutとexponential back-offを使用して再送される（Figure 2参照）。受信者がConfirmable messageを処理できない場合（エレー responseもできない場合）、ACKの代わりにReset message(RST)で応答する。 Client Server | | | CON [0x7d34] | +----------------- | | | | ACK [0x7d34] | | -----------------+ | | Figure 2 Reliable Message Transmission A message that does not require reliable transmission (for example, each single measurement out of a stream of sensor data) can be sent as a Non-confirmable message (NON). These are not acknowledged, but still have a Message ID for duplicate detection (in this example, 0x01a0); see Figure 3. When a recipient is not able to process a Non-confirmable message, it may reply with a Reset message (RST). 信頼性が要求されないmessage（例えば1単位時間のセンサ情報）はNon-confirmable message(NON)で送信してよい。それらはACKを必要としないが、重複検出用のMessage IDは持っている(Figure 3参照)。受信者がNon-confirmable messageを処理できない場合、Reset message(RST)を応答してもよい。 Shelby, et al. Standards Track [Page 11] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Client Server | | | NON [0x01a0] | +----------------- | | | Figure 3 Unreliable Message Transmission See Section 4 for details of CoAP messages. 詳細なCoAP messageはSection 4参照。 As CoAP runs over UDP, it also supports the use of multicast IP destination addresses, enabling multicast CoAP requests. Section 8 discusses the proper use of CoAP messages with multicast addresses and precautions for avoiding response congestion. CoAPはUDP上で動作するため、multicast IP宛の送信をサポートし、CoAP requestのmulticast送信をサポートする。Section 8ではmulticast addressのCoAP messageの使用方法とresponseの輻輳回避について説明する。 Several security modes are defined for CoAP in Section 9 ranging from no security to certificate-based security. This document specifies a binding to DTLS for securing the protocol; the use of IPsec with CoAP is discussed in [IPsec-CoAP]. 証明書ベースのセキュリティについてはSection 9で定義される。このドキュメントではDTLSへのbindについて規定する。CoAPとIPsecの使用については [IPsec-CoAP]参照。 2.2. Request/Response Model CoAP request and response semantics are carried in CoAP messages, which include either a Method Code or Response Code, respectively. Optional (or default) request and response information, such as the URI and payload media type are carried as CoAP options. A Token is used to match responses to requests independently from the underlying messages (Section 5.3). (Note that the Token is a concept separate from the Message ID.) CoAP request/responseのsemanticsはそれぞれCoAP messageのMethod Code/Response Codeにより提供される。URIやpayload media typeのようなOptionalまたはdefaultのrequest/responseの情報は、CoAP optionとして提供される。Tokenはunderlying message（Section 5.3★underlying message不明）から独立してresponse/requestを関連付けるために使用される（TokenはMessage IDとは異なる概念である。）。 A request is carried in a Confirmable (CON) or Non-confirmable (NON) message, and, if immediately available, the response to a request carried in a Confirmable message is carried in the resulting Acknowledgement (ACK) message. This is called a piggybacked response, detailed in Section 5.2.1. (There is no need for separately acknowledging a piggybacked response, as the client will retransmit the request if the Acknowledgement message carrying the piggybacked response is lost.) Two examples for a basic GET request with piggybacked response are shown in Figure 4, one successful, one resulting in a 4.04 (Not Found) response. requestがConfirmable(CON)またはNon-confirmable(NON)で送信され、可能な場合、CONに対するResponseがACK messageで送信される。これはpiggybacked responseと呼ばれ、詳細はSection 5.2.1で述べられる。piggybacked responseのGET requestの例をFigure 4に示す。ひとつは成功で、もう一つは4.04(Not Fount) Responseである。 Shelby, et al. Standards Track [Page 12] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Client Server Client Server | | | | | CON [0xbc90] | | CON [0xbc91] | | GET /temperature | | GET /temperature | | (Token 0x71) | | (Token 0x72) | +----------------- | +----------------- | | | | | | ACK [0xbc90] | | ACK [0xbc91] | | 2.05 Content | | 4.04 Not Found | | (Token 0x71) | | (Token 0x72) | | 22.5 C | | Not found | | -----------------+ | -----------------+ | | | | Figure 4 Two GET Requests with Piggybacked Responses If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an Empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). This is called a separate response , as illustrated in Figure 5 and described in more detail in Section 5.2.2. serverがConfirmable messageのrequestに即座に応答できない場合、clientのrequest再送を停止させるため、Empty Acknowledgement messageを応答する。responseの準備ができた場合、serverは新しいConfirmable message（その後ClinetにACKが返される必要がある）を送信する。これは Separate Response と呼ばれ、Figure 5に示され、Section 5.2.2で説明する。 Client Server | | | CON [0x7a10] | | GET /temperature | | (Token 0x73) | +----------------- | | | | ACK [0x7a10] | | -----------------+ | | ... Time Passes ... | | | CON [0x23bb] | | 2.05 Content | | (Token 0x73) | | 22.5 C | | -----------------+ | | | ACK [0x23bb] | +----------------- | | | Figure 5 A GET Request with a Separate Response Shelby, et al. Standards Track [Page 13] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 If a request is sent in a Non-confirmable message, then the response is sent using a new Non-confirmable message, although the server may instead send a Confirmable message. This type of exchange is illustrated in Figure 6. requestがNONで送信された場合、severはCONで応答してもよく、新たなNONで応答してもよい。Figure 6に示す。 Client Server | | | NON [0x7a11] | | GET /temperature | | (Token 0x74) | +----------------- | | | | NON [0x23bc] | | 2.05 Content | | (Token 0x74) | | 22.5 C | | -----------------+ | | Figure 6 A Request and a Response Carried in Non-confirmable Messages CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to HTTP, with the semantics specified in Section 5.8. (Note that the detailed semantics of CoAP methods are almost, but not entirely unlike [HHGTTG] those of HTTP methods intuition taken from HTTP experience generally does apply well, but there are enough differences that make it worthwhile to actually read the present specification.) CoAPはHTTPと同様にGET, PUT, POST, DELETE methodが使用される。それらのsemanticsはSection 5.8で規定される。CoAP methodのsemanticsはHTTPとは異なる。 Methods beyond the basic four can be added to CoAP in separate specifications. New methods do not necessarily have to use requests and responses in pairs. Even for existing methods, a single request may yield multiple responses, e.g., for a multicast request (Section 8) or with the Observe option [OBSERVE]. 4つのmethod以外もCoAPに追加することができる。新しいmethodは必ずしもrequest/responseである必要はない。既存のmethodでは1つのrequestに対して複数のresponseがある（multicast request。Section 8参照）場合がある。 URI support in a server is simplified as the client already parses the URI and splits it into host, port, path, and query components, making use of default values for efficiency. Response Codes relate to a small subset of HTTP status codes with a few CoAP-specific codes added, as defined in Section 5.9. serverでサポートされるURIはclientがパースした後、簡略化される（★よくわからない）。Section 5.9 で定義されるResponse CodeはCoAP固有のcodeとHTTPのstatus codeのサブセットである。 Shelby, et al. Standards Track [Page 14] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 2.3. Intermediaries and Caching 仲介、媒介とキャッシュ The protocol supports the caching of responses in order to efficiently fulfill requests. Simple caching is enabled using freshness and validity information carried with CoAP responses. A cache could be located in an endpoint or an intermediary. Caching functionality is specified in Section 5.6. プロトコルは効率的にrequestに対応するためresponseのキャッシュをサポートする。単純なキャッシュはCoAP responseにfreshnessとvalidityの情報を付与することで可能となる。キャッシュはendpointまたはintermediaryに配置することができる。キャッシュについてはSection 5.6で述べる。 Proxying is useful in constrained networks for several reasons, including to limit network traffic, to improve performance, to access resources of sleeping devices, and for security reasons. The proxying of requests on behalf of another CoAP endpoint is supported in the protocol. When using a proxy, the URI of the resource to request is included in the request, while the destination IP address is set to the address of the proxy. See Section 5.7 for more information on proxy functionality. Proxyはネットワークトラフィックの制限、パフォーマンスの向上、sleeping deviceのリソースへのアクセス、セキュリティーなどの理由で制約のあるネットワークには有効である。CoAP endpointの代わりにrequestするproxyはCoAPでサポートされる。proxyを使用する場合、宛先IPアドレスにproxyのアドレスが設定され、requestには要求するリソースのURIが含まれている。proxyについてはSection 5.7参照。 As CoAP was designed according to the REST architecture [REST], and thus exhibits functionality similar to that of the HTTP protocol, it is quite straightforward to map from CoAP to HTTP and from HTTP to CoAP. Such a mapping may be used to realize an HTTP REST interface using CoAP or to convert between HTTP and CoAP. This conversion can be carried out by a cross-protocol proxy ( cross-proxy ), which converts the Method or Response Code, media type, and options to the corresponding HTTP feature. Section 10 provides more detail about HTTP mapping. CoAPはRESTアーキテクチャに従って設計されており、HTTPと機能的にも類似しているため、CoAPからHTTP、HTTPからCoAPにmapすることは容易である。mappingはCoAPを使用してHTTP REST interfaceを実現するため、またはHTTP-CoAP間の変換をするために使用できる。この変換は、cross-protocol proxy( cross-proxy )により実現でき、Method/Response Code/media type/optionを対応するHTTP機能に変換する。Section 10ではHTTPとのmappingについて述べる。 2.4. Resource Discovery Resource discovery is important for machine-to-machine interactions and is supported using the CoRE Link Format [RFC6690] as discussed in Section 7. Resource discoveryはM2Mに必要であり、Section 7のCoRE Link Format [RFC6690]を使用して提供される。 3. Message Format CoAP is based on the exchange of compact messages that, by default, are transported over UDP (i.e., each CoAP message occupies the data section of one UDP datagram). CoAP may also be used over Datagram Transport Layer Security (DTLS) (see Section 9.1). It could also be used over other transports such as SMS, TCP, or SCTP, the specification of which is out of this document s scope. (UDP-lite [RFC3828] and UDP zero checksum [RFC6936] are not supported by CoAP.) CoAPはUDPで送信され、デフォルトでcompact message交換に基いている。CoAPはDTLSを使用してよい(Section 9.1参照)。その他の転送方法（SMS, TCP, SCTP）は本ドキュメントのスコープ外である。UDP-lite[RFC3828] UDP zero checksum [RFC6936] はCoAPでは未サポートである（ヘッダ、pktフォーマット等の問題？）。 CoAP messages are encoded in a simple binary format. The message format starts with a fixed-size 4-byte header. This is followed by a variable-length Token value, which can be between 0 and 8 bytes long. CoAPはbinary形式でエンコードされる。message formatは固定長の4byteのヘッダーで始まる。これに可変長（0～8byte）のToken値が続く。 Shelby, et al. Standards Track [Page 15] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram. Token valueの後に0以上のType-Length-Value(TLV)のCoAP Optionが続き、 オプションでdatagramの残りの部分にpayloadが設定される。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver| T | TKL | Code | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token (if any, TKL bytes) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| Payload (if any) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Message Format The fields in the header are defined as follows headerのfieldは下記のように定義される。 Version (Ver) 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1 (01 binary). Other values are reserved for future versions. Messages with unknown version numbers MUST be silently ignored. 2bit 符号なし整数。CoAP version numberを示す。この仕様では1(01 binary)を設定すること。他の値は後のバージョンのためのreserve。未知のversion numberをmessageはsilnetly ignoreすること。 Type (T) 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3). The semantics of these message types are defined in Section 4. 2bit 符号なし整数。message type Confirmable(0), Non-confrmable(1), Acknowledgement(2), Reset(3)を示す。message typeのsemanticsはSection 4で定義される。 Token Length (TKL) 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error. 4bit 符号なし整数。可変長のToken field(0～8 byte)の長さを示す。長さ9～15はreserveで、送信しないこととし、message format errorとして処理すること。 Code 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits), documented as c.dd where c is a digit from 0 to 7 for the 3-bit subfield and dd are two digits from 00 to 31 for the 5-bit subfield. The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code. Possible values are maintained in the CoAP Code Registries (Section 12.1). The semantics of requests and responses are defined in Section 5. 8bit符号なし整数。上位3bit classと下位5bit detailに分けられ、このドキュメントでは c.dd と表現する。 c は0～7までの3bitの値で、 dd は2桁で00～31の5bitの値である。classはrequest(0), success response(2), client error response(4), server error response(5)を示し、他の値はreserveである。Code 0.00はEmpty messageを示す。requestの場合、Code fieldはRequest Methodを示し、responseの場合はResponse Codeを示す。CoAP Code RegistriesはSection 12.1参照。request/responseのsemanticsはSection 5参照。 Shelby, et al. Standards Track [Page 16] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Message ID 16-bit unsigned integer in network byte order. Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non- confirmable. The rules for generating a Message ID and matching messages are defined in Section 4. ネットワークバイトオーダー(ビッグエンディアン)の16bit符号なし整数。メッセージの重複検出とAcknowledgement/ResetとConfirmable/Non-confirmableのmessageを照合するために使用する。Message IDの生成方法と照合の方法はSection 4で定義される。 The header is followed by the Token value, which may be 0 to 8 bytes, as given by the Token Length field. The Token value is used to correlate requests and responses. The rules for generating a Token and correlating requests and responses are defined in Section 5.3.1. headerはその後、Token Length fieldによって示される0～8byteのToken valueが続く。Token valueはrequest/responseを関連付けるために使用される。Tokenの生成方法と、request/responseの関連付け方はSection 5.3.1参照。 Header and Token are followed by zero or more Options (Section 3.1). An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload. Header、Tokenの後には0以上のOptionが続く（Section 3.1参照）。Optionはmessageの最後になるか、もしくは他のOptionかPayload Markerとpayloadが後に続く。（Payload Maker⇒0xFFのpayloadの開始marker） Following the header, token, and options, if any, comes the optional payload. If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0xFF), which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, i.e., the Payload Length is calculated from the datagram size. The absence of the Payload Marker denotes a zero-length payload. The presence of a marker followed by a zero-length payload MUST be processed as a message format error. Header, token, optionに続いてオプションでpayloadが付与される。payloadが存在し、非0のlengthの場合、optionの終わりとpayloadの始まりを示す固定長の1byteのPayload Marker(0xFF)が付与される（Optionに0xFFがきた場合は？⇒optionが始まるところに0xFFがあるかどうかで判別可能。）。payload dataはmarkerの後からUDP dataの終わり、つまりPayload Lengthはdatagram sizeから計算される。Payload Markerが無い場合は、zero-length payloadであることを示している。markerの後がzero-length payloadの場合はmessage format errorとして処理すること。 Implementation Note The byte value 0xFF may also occur within an option length or value, so simple byte-wise scanning for 0xFF is not a viable technique for finding the payload marker. The byte 0xFF has the meaning of a payload marker only where the beginning of another option could occur. 0xFFでもoption lengthやoptionに含まれる場合があるため、単純に0xFFをバイト単位でスキャンするのは、payload markerを探す方法には使えない。0xFFがpayload markerとして意味を持つのは、別のoptionが始まる可能性のある場所にある場合のみである（Optionの開始位置に0xFFは使用できない）。 3.1. Option Format CoAP defines a number of options that can be included in a message. Each option instance in a message specifies the Option Number of the defined CoAP option, the length of the Option Value, and the Option Value itself. CoAPはmessageに含まれるoptionの数を定義する。message内のoptionのインスタンスは、CoAP optionのOption Number、Option Valueの長さ、Option Valueを規定する。 Instead of specifying the Option Number directly, the instances MUST appear in order of their Option Numbers and a delta encoding is used between them the Option Number for each instance is calculated as the sum of its delta and the Option Number of the preceding instance in the message. For the first instance in a message, a preceding option instance with Option Number zero is assumed. Multiple instances of the same option can be included by using a delta of zero. Option Numberを直接規定する代わりに、インスタンスはOption Numberの順に設定され、delta encodingがそれらの間で使われる。各インスタンスのOption Numberはdeltaとmessage内の先行のOption Numberの合計として計算される。 Shelby, et al. Standards Track [Page 17] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Option Numbers are maintained in the CoAP Option Numbers registry (Section 12.2). See Section 5.4 for the semantics of the options defined in this document. Option NumberはSection 12.2の CoAP Option Numbers registryで規定される。本ドキュメントで定義されたoptionのsemanticsはSection 5.4参照。 0 1 2 3 4 5 6 7 +---------------+---------------+ | | | | Option Delta | Option Length | 1 byte | | | +---------------+---------------+ \ \ / Option Delta / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / Option Length / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / / \ \ / Option Value / 0 or more bytes \ \ / / \ \ +-------------------------------+ Figure 8 Option Format The fields in an option are defined as follows option fieldは次のように定義される。 Option Delta 4-bit unsigned integer. A value between 0 and 12 indicates the Option Delta. Three values are reserved for special constructs 4bit 符号なし整数。Option Deltaを示す0～12の値。13～15はreserve。 13 An 8-bit unsigned integer follows the initial byte and indicates the Option Delta minus 13. 8bit 符号なし整数が続き、Option Delta -13を示す。（★イマイチ意味わからない） 14 A 16-bit unsigned integer in network byte order follows the initial byte and indicates the Option Delta minus 269. ネットワークバイトオーダー（ビッグエンディアン）の16bit 符号なし整数が続き、Option Delta -269を示す。（★イマイチ意味わからない） 15 Reserved for the Payload Marker. If the field is set to this value but the entire byte is not the payload marker, this MUST be processed as a message format error. Payload Markerのためのreserve。fieldがこの値に設定され、payload markerでない場合はmessage format errorとして処理すること。 Shelby, et al. Standards Track [Page 18] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 The resulting Option Delta is used as the difference between the Option Number of this option and that of the previous option (or zero for the first option). In other words, the Option Number is calculated by simply summing the Option Delta values of this and all previous options before it. 結果、Option DeltaはそのoptionのOption Numberと前のoption（最初のoptionの場合は0）との差として使用される。言い換えると、Option NumberはそのOptionの前のすべてのOption Deltaを加算することで計算できる。 Option Length 4-bit unsigned integer. A value between 0 and 12 indicates the length of the Option Value, in bytes. Three values are reserved for special constructs 4bit 符号なし整数。Option Valueの長さを示す0～12の値。13～15はreserve。 13 An 8-bit unsigned integer precedes the Option Value and indicates the Option Length minus 13. 8bit 符号なし整数がOption Valueの前にあり、Option Length -13を示す。 14 A 16-bit unsigned integer in network byte order precedes the Option Value and indicates the Option Length minus 269. ネットワークバイトオーダー（ビッグエンディアン）の16bit 符号なし整数がOption Valueの前にあり、Option Length -269を示す。 15 Reserved for future use. If the field is set to this value, it MUST be processed as a message format error. 後のためのreserve。このfieldに15が設定された場合、message format errorとして処理する。 Value A sequence of exactly Option Length bytes. The length and format of the Option Value depend on the respective option, which MAY define variable-length values. See Section 3.2 for the formats used in this document; options defined in other documents MAY make use of other option value formats. Option Lengthのbyte sequence。Option Valueのlengthとformatは各オプションに依存する。本ドキュメントで使用するformatはSection 3.2参照。他のドキュメントで定義されたoptionは他のoption value formatを持つ。 3.2. Option Value Formats The options defined in this document make use of the following option value formats. 本ドキュメントで定義されたoptionは下記のoption value formatを使用する。 empty A zero-length sequence of bytes. zero-lengthのbyte列。 opaque An opaque sequence of bytes. 曖昧な長さのbyte列。 uint A non-negative integer that is represented in network byte order using the number of bytes given by the Option Length field. Option Lengthのbyte数長のネットワークバイトオーダーの非負の整数。 An option definition may specify a range of permissible numbers of bytes; if it has a choice, a sender SHOULD represent the integer with as few bytes as possible, i.e., without leading zero bytes. For example, the number 0 is represented with an empty option value (a zero-length sequence of bytes) and the number 1 by a single byte with the numerical value of 1 (bit combination 00000001 in most significant bit first notation). A recipient MUST be prepared to process values with leading zero bytes. Optionの定義はbyte数の範囲を規定する。選択可能な場合、senderは0byteを除く、できるだけ少ないbyteで表現する。例えば、0はempty option value(0byte)で、1は1byte(0000 0001)で表現される。recipientは0 byteを考慮して処理すること。(★いまいちわからない) Shelby, et al. Standards Track [Page 19] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 Implementation Note The exceptional behavior permitted for the sender is intended for highly constrained, templated implementations (e.g., hardware implementations) that use fixed-size options in the templates. senderの動作は、hardwareのような制約がある場合を意図している。 string A Unicode string that is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. Net-Unicode[RFC5198]でUTF-8[RFC3629]を使用してエンコードしたUnicode文字。 Note that here, and in all other places where UTF-8★★ encoding is used in the CoAP protocol, the intention is that the encoded strings can be directly used and compared as opaque byte strings by CoAP protocol implementations. There is no expectation and no need to perform normalization within a CoAP implementation (except where Unicode strings that are not known to be normalized are imported from sources outside the CoAP protocol). Note also that ASCII strings (that do not make use of special control characters) are always valid UTF-8 Net-Unicode strings. 4. Message Transmission CoAP messages are exchanged asynchronously between CoAP endpoints. They are used to transport CoAP requests and responses, the semantics of which are defined in Section 5. CoAP messageはCoAP endpoint間で非同期に交換される。Section 5で定義されたsemanticsを持つCoAP request/responseが送信される。 As CoAP is bound to unreliable transports such as UDP, CoAP messages may arrive out of order, appear duplicated, or go missing without notice. For this reason, CoAP implements a lightweight reliability mechanism, without trying to re-create the full feature set of a transport like TCP. It has the following features CoAPはUDPのような信頼性の無いTransportにバインドされるため、CoAP messageは順不同だったり、重複したり、消失する場合がある。CoAPはTCPのようなTrasnportによる完全な再送メカニズム無しに、軽量の信頼性メカニズムを実装している。それには下記の機能がある。 o Simple stop-and-wait retransmission reliability with exponential back-off for Confirmable messages. Confirmable messageのためのexponential back-offを使用した単純なstop-and-wait再送。 o Duplicate detection for both Confirmable and Non-confirmable messages. Confirmable/Non-confirmable message両方での重複メッセージ検出。 4.1. Messages and Endpoints A CoAP endpoint is the source or destination of a CoAP message. The specific definition of an endpoint depends on the transport being used for CoAP. For the transports defined in this specification, the endpoint is identified depending on the security mode used (see Section 9) With no security, the endpoint is solely identified by an IP address and a UDP port number. With other security modes, the endpoint is identified as defined by the security mode. CoAP endpointはCoAP messageのsourceかdestinationである。endpointの定義はCoAPに仕様される転送方法に依存する。Security無しの場合、endpointはIP addressとUDP port番号で識別される。Security有りの場合、endpointはSecurity modeの定義に従って識別される。 Shelby, et al. Standards Track [Page 20] RFC 7252 The Constrained Application Protocol (CoAP) June 2014 There are different types of messages. The type of a message is specified by the Type field of the CoAP Header. 異なるタイプのmessageがある。message typeはCoAP HeaderのType fieldで規定される。 Separate from the message type, a message may carry a request, a response, or be Empty. This is signaled by the Request/Response Code field in the CoAP Header and is relevant to the request/response model. Possible values for the field are maintained in the CoAP Code Registries (Section 12.1). message typeとは別に、messageはrequest/response/Emptyを送ってよい。CoAP HeaderのRequest/Response Codeはrequest/response modelに関連する。filedの値はCoAP Code Registries(Section 12.1)で管理されている。 An Empty message has the Code field set to 0.00. The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. If there are any bytes, they MUST be processed as a message format error. Empty messageはCode filedが0.00に設定される。Token Length fieldは0であり、dataはMessage ID fieldの後には存在しないこと。
https://w.atwiki.jp/vocalive/pages/184.html
LIVEと行事一覧DB データベース (DataBase for Vocaloid Live Concerts and Events) メニューMENU +←クリック目次 [←Click here for CONTENTS] ↓↓↓現在のページ名（Current Page Name）↓ 自動作成目次(contents) 行事紹介（Vocaloid Live Concert and Event Information） 【LIVE/海外/Vocaloid Concerts of Synthesized Reality Productions SRP】 Under writing from following links Synthesized Reality Productions (SRP)The new voice of Yume competition! ダイジェスト映像・動画配信・写真等（Summary Video, Live Streaming Photo） Mascot Development of SRP "YUME" (マスコットキャラの作成と育成） チケット情報・グッズ情報・BD/CD・その他 (Ticket Goods Information, etc.) 技術情報・出演ボーカロイド・スクリーン・MMD・3Dモデル・プロジェクター・ソフト・舞台等 (Technology・Vocaloid Name・Screen・MikuMikuDance・3D Model・Projector・Software) 出演者・製作者・関連ブログ等 (Musician, Staff and Related Blog) セットリスト（演奏曲目）・その他 (Set List, name of music) Summary in English and other language（英語等での紹介） 行事を行う団体や個人等 (Organizer and Group) スポンサー・協賛等 (Sponsor and Support) 関連行事 (Related Event Info.) 紹介記事・参考サイト・謝辞・文献等 (News, References, Acknowledgement and Credit) Blog (このサイト内での関連内部リンク・補助リンク・Internal Link) Memo・メモ帳 EDIT Page 行事紹介（Vocaloid Live Concert and Event Information） ↓このページ名（Current Page Name）↓ 【LIVE/海外/Vocaloid Concerts of Synthesized Reality Productions SRP】 LIVE/海外/Vocaloid Concerts of Synthesized Reality Productions SRP Under writing from following links 2手作りライブ等の為の技術情報 Technology for the Vocaloid Handmade Live Concert (ページ作成中 CONSTRUCTION) Fanmade Vocaloid Show - SkeCon 2014 http //www.youtube.com/watch?v=HMNtOMdC7fc Authorized FAN MADE SRP VOCALOID Concert at KamiCon 2014 http //www.youtube.com/watch?v=saCch6DjIOo Synthesized Reality Productions (SRP) http //synthreality.com/ http //synthreality.com/about/ [After Tempo left Vocalekt Visions, Wolf Neve set out to find a new group wanting to focus on live VOCALOID shows. Now, with NeutrinoP, Alfred, EmpathP, Apparatus and RuchiiP, the team has one goal – to keep the bar set high and try to put on the best show possible. Our dream is to make live concerts for VOCALOID all over the world. With us and all of you, we can make this dream come true!] Recent Events Lists http //synthreality.com/shows/ SKECON Date July 05, 2014 Time TBD Place Folkparken Skellefteå (Sweden) Links SKECON Event Page KAMI-CON Date Febuary 15, 2014 Time 9 00 – 10 00 PM Place Birmingham, Alabama (USA) Links KAMI-CON Event Page event_pmx PACIFIC MEDIA EXPO Date November 09, 2013 Time 2 00 – 3 00 PM Place Los Angeles, California (USA) Links PACIFIC MEDIA EXPO Event Page 藤本健の“DTMステーション” DTM Station ( by Ken Fujimoto) ボカロ曲をアメリカとルーマニアで合作するVOCALECT VISIONS http //www.dtmstation.com/archives/51859052.html neutrinoP s Vocaloid channel http //www.youtube.com/user/neutrino006 Synthesized Reality Productions channel http //www.youtube.com/channel/UCK-AamXDoFQ6Kik2ebye6-g Talk With SRP/Synthesized Reality Productions Wolf Neve The new voice of Yume competition! (SRP-Yumeの声募集のコンテスト：ボーカロイド候補の声募集中) 英語と日本語 Synthesized Reality Productions 8月9日 8 36 · We have started to get in tracks for the new voice of Yume competition! So fare we have some great Stuff! But is there is still time!! It end on August 25th! Tag your friends! This is a exclusive SRP contract for the new Yume! This is the dream! You could be the next Vocaloid. Please sing, talk or more! and send to English please, Japanese is a plus! synthesizedrealityproductions ＠ gmail.com (Please change ＠ to @) It can be Youtube, Soundcloud, Mp3, Wav. or even a video file! We are looking for a female voice! Sorry guys! Not this time!! Again all entries must be in by August 25. Good Luck and Thank You! SRP http //www.facebook.com/SynthesizedRealityProductions/posts/315731811940780 ダイジェスト映像・動画配信・写真等（Summary Video, Live Streaming Photo） Part 1 of PMX 2013 http //www.youtube.com/watch?v=4dZYsHFrtn8 http //www.youtube.com/watch?v=5tFjMULVKPA http //www.youtube.com/watch?v=Zri86JCmT0Q http //www.youtube.com/watch?v=bZhwM3wMNmE http //www.youtube.com/watch?v=Ob2zJ-eQP0o http //www.youtube.com/watch?v=bSsE3XFbMN4 Related video pmx2013 - SRP vocaloid panel Mascot Development of SRP "YUME" (マスコットキャラの作成と育成） Yume is the official mascot of the Vocaloid concert group Synthesized Reality Productions. imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 http //synthreality.com/wp-content/uploads/YumeMMDwall_1280X720.png Mascot of YUME made by http //synthreality.com/about/ MMD Development of "YUME" imageプラグインエラー ご指定のURLはサポートしていません。png, jpg, gif などの画像URLを指定してください。 http //synthreality.com/wp-content/uploads/yume-mmd.png Model MMD YUME Mascot YUME MMD made by RuchiiP downloads DOWNLOADS for MMD MODEL of YUME http //synthreality.com/downloads/ SRP’s Mascot Yume as a Free MMD Download Yume MMD Wallpaper http //synthreality.com/downloads/ [MMDPV] Nekomimi Archive [SRP s YUME Cathood vers.] http //www.youtube.com/watch?v=gLRUvq02rPM チケット情報・グッズ情報・BD/CD・その他 (Ticket Goods Information, etc.) チケット情報一覧 DVD/BD及びグッズ情報 Official goods 技術情報・出演ボーカロイド・スクリーン・MMD・3Dモデル・プロジェクター・ソフト・舞台等 (Technology・Vocaloid Name・Screen・MikuMikuDance・3D Model・Projector・Software) ライブ技術一覧 技術内容が不明の部分は、空けておいて下さい。 (IF YOU DO NOT UNDERSTAND, LEAVE THE TECHNOLOGY SECTION OPEN.) See also AniMIku for the technical data of Screen 投影スクリーンの種類 (Screen Type)： スクリーンの素材（Materials for making screen）： 投影スクリーン等への映り込み状態(Reflection)： 鮮明度 Clearness, resolution of screen： 舞台の高さ（stage height）： スクリーンの高さ（Screen height）： スクリーンの湾曲の程度=(映りこんだ物の歪み方の程度)： スクリーンの大きさ又は横の長さ (Screen Size)： スクリーンの継ぎ目の数(Junction within the screen)=(つないで使用された投影ボード等の枚数-1、?) ：0 number of materials used for making main screen：1 使用された投影ボード等の枚数（Number of board used）： 音響設備及び音響状態 (Sound)： プロジェクタの種類・台数 (Projector)： 使用ソフト (Software)： Projection software 3D model： Producer of 3D Model：モデル製作： スクリーン及び映像の解像度（Resolution of Screen and video）： 投影時の色補正（Color Adjustment to view on screen）： MMDのモデルの種類（Model Type of MikuMikuDance）： Motion： Computer and OS： レンダリング ソフトRendering software レンダリング速度等 fps フレーム速度(frame speed) fps カメラ等 (Camera)： 技術説明動画・写真等 (Tech Video Photo)： 会場設備のホームページ (Homepage of the Event Hall)： 会場設備 その他 (others)： 衣装モジュール及びデザイン： (Clothing design of the models) 同期システム (Synchronization system)： 選曲 (music selection)： 出演者・製作者・関連ブログ等 (Musician, Staff and Related Blog) 演奏者と関連ブログ Synthesized Reality Productions http //synthreality.com/ http //synthreality.com/about/ Official Blog http //synthreality.com/category/blog/ Official FaceBook http //www.facebook.com/SynthesizedRealityProductions Twitter Page https //twitter.com/SRealityP Talk With SRP/Synthesized Reality Productions Wolf Neve 「They are looking for MikuMikuDance animators and rendering staff to prepare the MMD files to be projected on screen. They would prefer people who can commit to doing these tasks full time if possible. They really need the help, so on behalf of the Miku America Fusion Staff, please check out their work and give them your support. 」 セットリスト（演奏曲目）・その他 (Set List, name of music) Set List Fanmade Vocaloid Show - SkeCon 2014 http //www.youtube.com/watch?v=HMNtOMdC7fc This is the full length Vocaloid show created by Synthesized Reality Productions (Links below) for SkeCon 2014. Song List 00 40 Viva Happy 04 11 Nekomimi Switch 08 05 Electric Love 12 55 Seasons Changes 15 20 Freely Tomorrow 19 30 Mirai Tokei 4 30AM 22 35 Tornado 25 28 Just be Friends 28 44 Remote Control 33 55 Te-yut-te 35 17 Wonderful Nippon 39 13 Mozaik Roll 42 23 neutrino 45 45 The Snow White Princess is 48 56 Senbonzakura 53 12 Happy Synth -ending Full song list with additional information can be found here https //www.facebook.com/SynthesizedRealityProductions/photos/a.176437885870174.1073741829.176018195912143/301599530020675/?type=1 theater Authorized FAN MADE SRP VOCALOID Concert at KamiCon 2014 http //www.youtube.com/watch?v=saCch6DjIOo Yume intro Viva Happy Electric Star 未来時計AM430 Seasons changes Nekomimi Switch Electric Love Tornado Step On Your Heart En tu Mirar Remote Control Te-yut-te Wonderful Nippon だってだってだって Freely Tomorrow Schrodinger s Cat kotobatoraborato Senbonzakura ending - Happy Synthesizer PMX 2013 http //www.youtube.com/watch?v=4dZYsHFrtn8 Yume intro Songs Artiest Model Motion 1. Freely Tomorrow Mitchie_M Mamama Kuraudo-p 2. 未来時計AM430 Tonbo Mamama Rick-P 3. "だってだってだって Takanon Mamama Cort 4. Neutrino Vocalket Visions dond xTokashxMahlazer 5. Nekomimi Switch Daniwell dondon Hino 6. Seasons changes Vocalekt Visions Kummd Keeprefrigeratedful 7. Tornado Vocalekt Visions ULA Keeprefrigeratedful 8. Remote Control Jesus-P (じーざすP) ? (Teihen508?) BOT 9. Te-yut-te Fei-P (フェイP) ? (Teihen508?) Tsurukame 10. Overseas Travel Vocalekt Visions Mamama Raiku-P 11. Wonderful Nippon kagomeP(かごめP) Mamama + KIO 12. Eazy Dance Mitchie_M Mamama Raiku-P 13. Senbonzakura 2Q3WERT65 Dondon Shoubu (菖蒲) Summary in English and other language（英語等での紹介） 行事を行う団体や個人等 (Organizer and Group) Wolf Neve NeutrinoP Wolf Neve is the owner of SRP, and neutrinoP (me) is the co-owner and co-founder of this group. Together with our friends, we have managed to put together the stuff needed for this concert, but to make it happen, I literally killed my own old studio system. That s why, this video is also a small tribute to those that have contributed to, and helped me in recovering and upgrading my studio system. THANK YOU! http //www.youtube.com/watch?v=saCch6DjIOo スポンサー・協賛等 (Sponsor and Support) 関連行事 (Related Event Info.) [After Tempo left Vocalekt Visions, Wolf Neve set out to find a new group wanting to focus on live VOCALOID shows. Now, with NeutrinoP, Alfred, EmpathP, Apparatus and RuchiiP, the team has one goal – to keep the bar set high and try to put on the best show possible. http //synthreality.com/about/ Please find the separate page for Vocalekt Visions in this Wiki. LIVE/海外/Vocaloid Concerts of Vocalekt Visions [AOD] [Hatsune Miku Animation Concert] Vocalekt Visions @ Anime on Display 2012 WVD01 AniMiku http //www.youtube.com/watch?v=uIpT1kRSmPo Vocaloid MMD Live starts after 20min. Vocalekt Visions after 34min, Staff introduction around 48min English GUMI official demo 【Megpoid English DEMO】 You Are The Reason FULL Ver. http //www.youtube.com/watch?v=jyE7uoE2_lQ Full Album Vocaloid Vacation (feat. Tempo-P Neutrinop) Vocalekt Visions on Itunes Vocaloid Vacation (feat. Tempo-P Neutrinop) Vocalekt Visions on Itunes Please enjoy the whole concert footage and share this with the world! https //www.facebook.com/MikuFusion citizen-16 https //www.facebook.com/citizen16theband http //soundcloud.com/citizen-16 https //www.facebook.com/citizen16theband/info Basic Info Started2010 LocationSF Bay area GenreElectronic, Industrial, Dark wave, Agro, Future core. MembersWolf Neve Vocals, Lyrics, Programming, Keys, Drums, recording. Miki Branescu (neutrinoP) Music composer, all Instruments, Drums, Programming, Studio Recording and Mastering. Brian O Hara. (Live keys) Special thanks to Shane Richard ,Kyle Cameron and Dan Dulle For helping "Angelificatum", "Deception" and "Bring down the Sun" Former members Kitty Nyu (Keys) Live "Leaving" Unitt 77. HometownNorthern CA/SF Bay Area Digital Album Construct by Citizen 16 http //citizen16theband.bandcamp.com/ http //f1.bcbits.com/img/a2532989478_10.jpg Citizen 16 - Deception http //www.youtube.com/watch?v=FOgkbGEmgPw http //www.youtube.com/watch?v=HsGFgk0mLAQ Juggernaut Music Group http //www.juggernautmusic.co.uk/artists/ Juggernaut is a UK based label bringing together the worlds of EBM, Synthpop and Industrial 紹介記事・参考サイト・謝辞・文献等 (News, References, Acknowledgement and Credit) 情報一覧MEMO Blog 藤本健の“DTMステーション” DTM Station ( by Ken Fujimoto) ボカロ曲をアメリカとルーマニアで合作するVOCALECT VISIONS http //www.dtmstation.com/archives/51859052.html vocaloidism http //www.vocaloidism.com/tag/vocalekt-visions/ (このサイト内での関連内部リンク・補助リンク・Internal Link) Memo・メモ帳 ライブ技術一覧/過去のライブの反省会等の一部 some オススメ osusume [GUMI] On my Way to Nowhere [VOCALOID3] ORIGINAL http //www.youtube.com/watch?v=S2C2dyOE4pk [Kokone] Vise de îndrăgostit [ROMANIAN] [VOCALOID] [ORIGINAL SONG] http //www.youtube.com/watch?v=PyKqxG49id4 English GUMI official demo 【Megpoid English DEMO】 You Are The Reason FULL Ver. http //www.youtube.com/watch?v=jyE7uoE2_lQ [GUMI ENGLISH] Happy New Year [COVER] https //soundcloud.com/shootingstar-p/gumi-english-happy-new-year [GUMI COMPLETE] Open your mind [REAPER_REMASTER] https //soundcloud.com/shootingstar-p/gumi-complete-open-your-mind コメント・Comment 名前 コメント EDIT Page If do not know about editing web page of this Wiki, DO NOT EDIT. Click HERE to Edit Current Page or click following URL to edit this page. http //www18.atwiki.jp/vocalive/editx/184.html Make sure to rewrite correct page number after (/vocalive/editx/) or (/vocalive//editx/PAGE NUMBER.html) to edit current page. [ページ保存] button below the editing window=means SAVE the page after editing to finish editing. [プレビュー] button below the editing window=means PREVIEW the page during editing. input the code number shown to perform these command. To cancel editing, just use Web browser button out side the editing window to go back. or CLOSE the editing page of the Web browser s window. If you make mistake, DO NOT SAVE the page. Do NOT press [ページ保存] button. [» タグ ]box below the editing window=means make TAG of this page after editing. If you have any problem, insert "HELP" in the TAG to identify the page at later for repair. EDIT & MAKE Page
https://w.atwiki.jp/taptitans2/pages/106.html
༼ つ ◕_◕ ༽つ DevLog #20 Summoned V.2.7.0 Patch Notes ༼ つ ◕_◕ ༽つ//New Features in V.2.7.0// Easter Event Special Equipment Enhancements Aura Rework! New Equipment Sets Artifact Graveyard! New Artifacts / Update Artifact Skills //Balancing Efforts in V.2.7.0//Equipment Clan Quest Skills Perks Artifacts //Bugs Fixed in V.2.7.0//Equipment Shop Skills Pets Artifacts Game Optimization (02/23/2018) Update Log #19 What's to come in March ⚔In artifacts... In skills… In spring… □ Bugs we're working on Game Optimization ༼ つ ◕_◕ ༽つ DevLog #20 Summoned V.2.7.0 Patch Notes ༼ つ ◕_◕ ༽つ 3/24付けのアップデート告知の機械翻訳に簡単な意訳を加えたものになります。 編者に理解できない部分が多くあるため、原文と合わせ読んでください。 https //redd.it/86ngru なお、wiki内各リンク先のスキル情報詳細は最新バージョンではない場合があり、 効果数値や内容は現在の仕様と合致しないものがあります。 NRG sending…. NRG received! エネルギー送信…エネルギーを受け取りました！ Here they are, heroes -- the long-awaited notes for update V.2.7.0 are here! This massive update contains several new expansions and features for you to explore and play through. From brand new artifacts equipment, to a refreshing seasonal theme change, our team has simply been itching to spring in this new update to the app store near you! さぁどうぞ、ヒーロー達 - 待望のV.2.7.0アップデートノートはここにあります！この大規模なアップデートには、いくつかの新しい新要素と機能が含まれています。新しいアーティファクト＆装備から季節ごとのテーマ変更まで… アプリストアへのこの新しいアップデートで、私たちのチームは春を待ち焦がれています！ We apologize for the slight delay in pushing this update forward and the quiet since the latest DevLog, but we wanted to ensure that all the new features for this update have been tested and polished to make v.2.7 one of the most exciting updates to date! 最新のDevLogからこのアップデート開発が少し遅れたことをお詫びしますが、このアップデートの新機能がすべてテストされ、洗練され、v.2.7が今日までの最もエキサイティングなアップデートになります！ And with your energy focused by the power of Greyskull… the patch notes have been revealed. Greyskullのパワーによってフォーカスされたあなたのエネルギーで、パッチノートが公開されました。 Redditにて、Grayskullの力でパッチノートを召喚しよう！という スレッド(https //redd.it/86k70y)がパッチノートスレッドの直前に立ち、 100以上の高評価投票と数十の召喚コメントが続いたことに対する返答。 Reminder that the notes below are subject to change and we will be sure to update this thread should changes be made. 下記のパッチノートは変更される可能性があることにご注意ください。変更があれば、このスレッドは必ず更新されます。 //New Features in V.2.7.0// V.2.7.0での新機能 What you'll be seeing in our spring update… 春のアップデートで見られるものは… Stage Expansion Can you reach stage 20k? ステージ延長 20kステージに到達できますか？ Goodbye my Valentine! -- A new spring theme is taking over, and this includes limited-time event equipment. Additionally, you can earn free pet eggs x4 as fast for the whole month of April! さようなら私のバレンタイン！ - 新しい春のテーマに引き継がれ、これには期間限定のイベント装備が含まれています。 さらに、あなたは4月の一ヶ月間、無料のペットの卵を4倍速で得ることができます！ Equipment Enhancements! Event, Rare, Legendary, and Mythic equipment now have random secondary stats. 装備の機能強化！ Event、Rare、Legendary、Mythicの装備にランダムな二つ目のステータスが追加されます。 Aura Rework! Auras now boost other equipment and no longer give chance-based stats as their primary effect. オーラの改修！ チャンス関連ステータスから他の装備の増強へと主な効果を変更します。 Meet Portar! This new stage skip Titan is will warp you through additional stages when defeated. Portarに会おう！ ステージをスキップするこの新しいタイタンは、倒した時に追加のステージスキップであなたをワープさせます。 Equipment Crafting info panels see what bonus each craftable piece of equipment gives by tapping on it. 装備クラフト情報パネル：各装備をタップしてそれが与えるボーナスを(クラフト前に)確認できます。 4 New Equipment Sets Hand of Midas mythic set, along with new Legendary, Rare and Spring event sets. 4つの新しい装備セット：Hand of MidasのMythicセットと新しいLegendaryセット、Rareセット、春のEventセット。 All-new Artifact Graveyard! -- A place where you can selectively choose to unlock previously salvaged artifacts. 最新のアーティファクト墓地！ - 以前に解体されたアーティファクトを選択しアンロックできます。 5 New Artifacts; And reworks to artifacts, Stone of the Valrunes and The Master's Sword. 5つの新アーティファクト; そしてStone of the Valrunes【ヴァルリユーンズの石】とThe Master's Sword【マスターズソード】の改修。 New pieces of non-event equipment; And a new Unskilled Gold armor type. イベント関連以外の新しい装備; そして新しい金のアーマータイプ。 Active skills max level increased to 25. アクティブスキルの最大レベルが25に上昇します。 New player Tutorial overhaul. 新プレーヤーのチュートリアルが刷新されます。 Keep on reading for the details for these new features below... 以下の新機能の詳細をお読みください。 Easter Event Special イースターイベントの特徴 Like last year's Easter event, pet eggs will spawn every hour instead of every 4 hours for the duration of the event! During our Easter event, the egg limit will be increased from 2 to 8! 去年のイースターイベントのように、ペットの卵は、イベントの期間中、4時間ごとではなく1時間ごとに生成されます！ イースターイベントでは、卵のストック上限は2個から8個に増えます！ Equipment Enhancements 装備の機能強化 Each equipment category has been assigned a pool of five unique secondary stats. 各装備カテゴリには、5つの固有の第二ステータスが割り当てられます。 Equipment dropped before v2.7 will be given default enhancement values as per each category. v2.7以前にドロップした装備には、各カテゴリごとにデフォルトのステータスが与えられます。 Number of enhancements per rarity -- [Rare/Event 1 enhancement; Legendary 2 enhancements; Mythic 3 enhancements]. レアリティごとに付加される強化数が増えます - [Rare/Event 1つの強化。 Legendary 2つの強化。 Mythic 3つの強化] Weapon Enhancements Boosts for each of the five damage-based active skills. 武器の強化：5種類のダメージベースのアクティブスキルをそれぞれブーストします。 Hat Enhancements inactive damage, boss damage, non-boss damage, ground hero damage, flying hero damage. 頭の強化：非アクティブダメージ、ボスダメージ、非ボスダメージ、地上ヒーローダメージ、飛行ヒーローダメージ。 Suit Enhancements inactive gold, splash gold, perk gold, fairy gold, Hand of Midas gold. 鎧の強化：非アクティブゴールド、スプラッシュゴールド、Perkゴールド、フェアリーゴールド、Hand of Midas【ミダスの祝福】ゴールド。 Aura Enhancements Chesterson chance, fairy multi-spawn chance, chest gold x10 chance, boss gold x10 chance, Manni Mana chance. オーラの強化：Chestersonチャンス、フェアリーのマルチスポーンチャンス、箱のゴールドx10のチャンス、ボスゴールドx10のチャンス、ManniManaのチャンス。 Slash Enhancements critical chance, deadly chance, multi-spawn chance, all probability boost, Portar spawn chance. 剣さばきの強化：クリティカルチャンス、デッドリーチャンス、マルチスポーンチャンス、すべての確率ブースト、Portarスポーンチャンス これまでは同じ装備のレベルが上がれば、無条件で上位互換となったが 今後はプレイスタイルやビルド選択に合わせて考える必要がある。 単にレベル(第一ステータス)だけでは比較できず、 装備ごとにランダムにつく第二ステータスも合わせて 持ち変えるべきかどうかを総合判断していかなければならない。 単純な比較が難しくなり、運要素が大きくなったと言える。 Aura Rework! オーラ改修！ Auras now provide direct boosts to weapons, hats, and slashes as their primary effect. オーラは武器、頭、剣さばきを直接的にブーストしてその主要な効果を発揮するように変更されます。 Previous aura chance-based effects (i.e. critical chance, Chesterson chance, multi-spawn chance) have been added as enhancements on Auras and Slashes. 以前のオーラチャンスベースのエフェクト（クリティカルチャンス、Chestersonチャンス、マルチスポーンチャンス）がオーラと剣さばきの第二ステータスに含まれるようになります。 Auras are now affected by the all-equipment boost artifact. オーラはすべての装備ブーストのアーティファクトの影響を受けます。 New Equipment Sets 新しい装備セット： [Mythic] Treasure Hunter -- x1.5 Enhanced Equipment Chance, x100 Hand of Midas Gold, x1.5 Prestige Relics. [Mythic]トレジャーハンター - x1.5 Enhanced Equipment Chance、x100Hand of Midas【ミダスの祝福】ゴールド、x1.5プレステージレリック。 Enhanced Equipment Chanceは高レアリティのドロップ率上昇 [Legendary] Corrupt Emerald Knight -- x1.5 Pet Damage Bonuses, x0.7 Pet Skill Cooldowns. [Legendary]腐敗したエメラルド騎士 - x1.5ペットダメージボーナス、x0.7ペットスキルのクールダウン。 [Rare] Cybernetic Enhancements -- x3 All-Hero Damage (note* some common equipment were elevated to rare status to fill out this set). [Rare]電脳強化 - x3オールヒーローダメージ。（注：このセットを構成するため、いくつかのコモン装備はレア装備になりました） [Event] Defender of the Egg -- x5 Pet Damage. [Event]卵の守護者 - x5ペットダメージ。 Note The [Legendary] Corrupt Emerald Knight set and [Event] Defender of the Egg set will be available for in-app purchase as well. 注：[Legendary]腐敗したエメラルド騎士セットと[Event]卵の守護者セットは、アプリ内購入でも利用可能です。 Artifact Graveyard! アーティファクト墓地！ The long-awaited panel is here. 待望のパネルがここにあります。 Selectively unlock previously-salvaged artifacts using relics. レリックを使用して以前に解体されたアーティファクトを選択的にロック解除します。 Any owned or previously salvaged artifact will now be considered as 'discovered.' 所有または以前に救助されたアーティファクトは、「発見済み」とみなされます。 Artifact-salvage cost scaling reduced; Will now depend on the number of artifacts you have discovered instead of the number owned. アーティファクト解体のコスト上昇値が減少します。 現在所有している数ではなく、発見済みアーティファクト数に依存します。 New Artifacts / Update Artifact Skills 新しいアーティファクトと変更されるアーティファクトスキル： Unskilled Damage Unskilled Gold provide bonuses when active skills aren't running, as well as during inactive play. スキル未使用ダメージ(アイドルダメージ)＆スキル未使用ゴールド(アイドルゴールド)：アクティブスキルが実行されていない場合と、非アクティブプレイの場合にもボーナスが適用されます。 All-Probability Boost boosts each probability that is listed in the stats panel, including Deadly Chance, Mana Siphon, Manni Mana, and Lightning Strike! 全ての確率ボーナス デッドリーチャンス、Mana Siphon【マナサイホン】、Manni Mana【マニマナ】、Lightning Strike【ライトニングストライク】を含め、統計パネルに表示されている各確率を上げます！ Mana Refund Percent a percentage of mana spent on active skills is refunded each time a skill is used. マナ払い戻し率 スキルを使用するたびにアクティブスキルに費やされたマナの一定割合が払い戻されます。 Portar Spawn Chance increases your chance to spawn Portar, the stage skip Titan. Portarスポーンチャンス Portarが出現する機会を増やします。 Stone of the Valrunes now provides a gold multiplier based on how many active skills are running (excluding Heavenly Strike). Stone of the Valrunes【ヴァルリユーンズの石】は、実行中のアクティブスキルの数（Heavenly Strike【天空落とし】を除く）に基づいてゴールドボーナスを提供するようになります。 The Master's Sword now provides tap damage from heroes. The Master's Sword【マスターズソード】はヒーローからタップダメージを与えるようになります。 //Balancing Efforts in V.2.7.0// V.2.7.0でのバランス調整 Equipment 装備 Equipment enhancements along with the aura rework have resulted in a massive strength increase for ALL players, so several balancing decisions have been made to help control this growth. オーラ改修に伴う装備の強化により、すべてのプレイヤーの強度が大幅に向上します。この増加を抑えるために、いくつかのバランスのとれた決定が行われます。 Primary equipment stats now scale slightly weaker with respect to equipment level. 装備の第一ステータスは、装備のレベルに対してわずかに弱くなります。 Clan Quest クランクエスト Clan quest advanced start scaling has been increased. クランクエストによるアドバンススタートの上昇値が増加します。 Skills スキル Tap damage from heroes now give a weaker bonus to Shadow Clone. ヒーローからのタップダメージは、Shadow Clone【影分身】に弱いボーナスを与えるようになります。 Deadly Strike now gives a stronger bonus to pets. Deadly Strike【致命的な一撃】がペットに強いボーナスを与えるようになります。 Ambush now increases maximum multi-spawns as the primary effect and multi-spawn chance as a secondary effect. Ambush【待ち伏せ】は、第一効果として最大マルチスポーン数を増やし、第二効果としてマルチスポーンチャンスを増加させるようになります。 Ambush multi-spawn chance per level has been reduced. Ambush【待ち伏せ】のレベルごとのマルチスポーンチャンスが減少します。 Assassinate secondary effect now increases Deadly Strike duration instead of increasing Deadly Chance. Assassinate【暗殺】の第二効果として、デッドリーチャンスが増加するのではなく、Deadly Strike【致命的な一撃】の持続時間が増加するようになります。 Deadly Chance scaling within Deadly Strike active skill upgrades has been reduced. Deadly Strike【致命的な一撃】アクティブスキルのアップグレードでデッドリーチャンスの上昇値が減少します。 Manni Mana skill tree upgrade no longer increases spawn chance and mana per level reduced (as this skill will be replaced in a future update). Manni Mana【マニマナ】のスキルツリーのアップグレードでは、スポーンチャンスが増加しなくなり、レベルごとのマナ回復量も減少します。（このスキルは将来のアップデートで置き換えられる予定） Manni Mana base mana awarded is set to 4; the skill tree upgrade adds to this value. Manni Mana【マニマナ】の基本回復マナは4に設定されます。 スキルツリーのアップグレードによってこの値が加算されます。 Astral Awakening damage bonus can now be retained from one orb sequence to the next; cooldown reduction secondary effect removed. Astral Awakening【星の目覚め】のダメージボーナスは、1つのオーブ連弾から次のオーブまで保持できるようになります。 クールダウンの第二効果が除去されます。 Perks Perks Maximum total fairies that can be multi-spawned increased from 6 to 8. マルチスポーン可能な最大のフェアリー数は6から8に増加します。 Critical chance, Chesterson chance, and multi-spawn artifact maximum levels increased (each capped at 20%). クリティカルチャンス、チェスターソンチャンス、マルチスポーンの(3種の)アーティファクトの最大レベルが上昇します。（それぞれ20％上限） Perk Gold (Make it Rain Clan Crate) now reflects the bonus given by Invader's Gjallarhorn artifact. Perkゴールド（Make it Rain【黄金の雨】とClan Crate【クランの補給物資】）は、Invader's Gjalarhorn【インベーダーのギャラルホルン】アーティファクトによって与えられたボーナスを反映します。 Perk Gold no longer depends on skill tree gold upgrades; instead it gets a small multiplier based on the number skill points owned. Perkゴールドはもはやスキルツリーのゴールド系アップグレードに依存しません。 代わりに所有しているスキルポイント数に基づいて小さなボーナスが得られます。 Artifacts アーティファクト Artifact discover cost scaling increased for artifacts 66+. 66個目以上のアーティファクトの発見コスト(レリック)の上昇値が増加します。 //Bugs Fixed in V.2.7.0// V.2.7.0でのバグフィックス Equipment 装備 Equipment scroll list bug where equipped items would show up in the wrong equipment tab. 装備アイテムが誤った装備カテゴリのタブに現れるという装備スクロールリストのバグ(が修正されます)。 Unequipped equipment bonuses now update when their associated bonus is increased. 装備されていない装備ボーナスも、関連するボーナスが増加すると更新されるようになります。 Shop ショップ Shop bundles now show equipment levels. ショップバンドルに装備品のレベルが表示されるようになります。 Skills スキル Tactical Insight bonus was being applied up to three times on ascended heroes, and twice when the game was reloaded. Tactical Insight【戦術的洞察力】のボーナスは、昇格ヒーローで最大3回、ゲームが再ロードされたときに2回適用されていました。 重複して上昇してしまっていた分、修正されて上昇効果が低くなる。 Passive Skill panel cleaned up and now displays a bonus description and progress bar -- you will now notice that the Clan Ship Splash Skip (i.e. Anti-Titan Cannon) will now be based on individual Clan Quest participation パッシブスキルパネルがクリーンアップされ、ボーナスの説明と進行状況バーが表示されるようになります。ここで、クランシップスプラッシュスキップ（つまり、対タイタン砲火力）が個々のクランクエストの参加数に基づいていることがわかるようになります。 Heavenly Strike splash skip visual correction in the stats panel. Heavenly Strike【天空落とし】 のスプラッシュスキップ数は、統計パネルに集約されます。 Corrected extended skill tree descriptions for Pet Heart of Midas and Heroic Might. ペットのHeart of Midas【ミダスの心】とHeroic Might【英雄の力】のスキルツリーの記述を修正します。 Fairies now correctly reward active skills (drop rates will appear much higher). フェアリーはアクティブスキルを正しくドロップするようになります。（ドロップ率はもっと高くなるでしょう） Pets ペット Free pet eggs awarded in the pet tab now appear on a single reward screen. 無料のペットの卵は、1つの報酬画面に(まとめて)表示されるようになります。 Normal pet attacks are now prioritized over Sword Master attacks. 通常のペット攻撃は、ソードマスターの攻撃よりも優先されるようになります。 プレステ直後の[[ペット]]攻撃空振りの防止として修正 Artifacts アーティファクト Fixed an issue where uncapped artifacts couldn't be upgraded anymore after their level became too high. 上限レベルのないアーティファクトがレベルが高すぎてももうアップグレードできない問題を修正します。 トッププレイヤーのみに関わるようなバグで、 一定以上のAFレベルで上げれなくなっていた問題 Game Optimization ゲームの最適化 Display problem with the clan ship drifting off the screen. クランシップが画面からずれていく表示の問題(を修正します)。 Screen shake during clan quest attacks has been removed. クランクエスト攻撃中の画面振動が削除されます。 Fixed skill point drops appearing on screen when there were none to collect. 収集するものがないときに画面上にスキルポイントが表示される問題が修正されます。 Fixed crashes associated with Hand of Midas, fairy chest drops, and Power of Swiping. ミダスの祝福、フェアリーチェストのドロップ、そしてスワイプの力に関連するクラッシュを修正します。 Note we are currently aware of various other bugs that have not yet been fixed (above) -- but if there any bugs you would like us to specifically look into, please post below so that we can investigate further. Although the bugs would most likely not be resolved for v.2.7, it would be a great way to get certain bugs experienced further on to our radar. 注：現在のところ、まだ修正されていない他のバグも認識していますが、具体的に調べて欲しいバグがあれば、さらに調査するために(元スレッドのコメント欄に)コメントしてください。 バグはv.2.7では解決されない可能性がありますが、我々の関知する範囲にバグを知らせるには最適な方法です。 Excited yet? もうワクワクしてる？ We are currently reviewing and testing a couple of the new features going in -- as soon as we have definite dates, we will update this thread or announce on our Twitter with the specific date of release. 私たちは現在、新しい機能のいくつかを見直し、テストしています。日付が確定するとすぐに、このスレッドを更新したり、特定のリリース日にTwitterでアナウンスしたりします。 Friendly reminder! If you haven't liked or followed us already… あなたがまだ「いいね」やフォローがお済みでないなら… Facebook Twitter Website Tap On! ⚔ (02/23/2018) Update Log #19 What's to come in March ⚔ 2/23付けのアップデート告知の機械翻訳に簡単な意訳を加えたものになります。 編者に理解できない部分が多くあるため、原文と合わせ読んでください。 https //redd.it/7zrcgv なお、wiki内各リンク先のスキル情報詳細は最新バージョンではない場合があり、 効果数値や内容は現在の仕様と合致しないものがあります。 As the short month of love comes to a close, we're gearing up to switch into the spirit of spring! □ 二月の終わりが近づくにつれて、私たちは春の気質に切り替える準備をしています！□ Right now we're working on the next update (V.2.7.0) to be released in approximately a month's time, ~mid-to-late March. For v.2.7, you can anticipate these exciting updates 今、私たちは次のアップデート(V.2.7.0)を3月中旬～下旬にリリースする予定です。 v.2.7では、次のようなエキサイティングなアップデートを期待できます。 In artifacts... アーティファクトにおいて 5 New Artifacts for you to discover! You can expect these new previous artifacts to apply the following Idle gold/damage boost; Mana refund percent; All-probability boost; and one that will be linked to a new special titan. 5つの新しいアーティファクトが見つかります！ これらの新しいアーティファクトには、以下のものを適用することができます。アイドルゴールド/ダメージブースト。 マナ払い戻し率。 全確率ブースト。 そして新しい特別なタイタンとリンクされるもの。 Artifact Rework Master's Sword and Stone of the Valrunes are getting revamped! You can expect these two artifacts to be much stronger in this update. アーティファクトリワーク：The Master's Sword【マスターズソード】とStone of the Valrunes【ヴァルリユーンズの石】が強化されます！ このアップデートでは、これらの2つの成果物がはるかに強くなると期待できます。 Salvaged Artifacts Panel you will now be able to easily see and repurchase any previously salvaged artifact! 解体されたアーティファクトパネル：以前に解体されたアーティファクトを簡単に確認でき、買い戻すことができます！ In skills… スキルにおいて The Pet and Clan Ship splash skips will be converted into passive skills, similar to what we did with Intimidating Presence a few updates ago. PetとClan Shipのスプラッシュスキップはパッシブスキルに変換されます。いくつか前のアップデートでIntimidating Presence【威圧感】で行ったのと同様です。 Pets will still be based on total pet levels -- but Clan Ship splash skip will now be based on each player's individual clan quest attack count (i.e. contribution), instead of a clan's level itself. ペットはまだペットの合計レベルに基づいていますが、Clan Shipのスプラッシュスキップは、クランのレベル自体ではなく、各プレイヤーの個別のクエスト攻撃のカウント（つまり、貢献回数）に基づきます。 These are the biggest changes that will be going into V.2.7 so far, with more to come as we finalize a few additional features for the big spring update, including an enhancement to equipment that should vastly improve the current situation and application of auras. 現状のオーラ(装備)がおかれている状況を大幅に改善するような装備強化など、大きな春のアップデートのいくつかの追加要素を完成させるために、ここまでがV.2.7に移行する予定の最大の変更点です。 We are also working on the much-anticipated notification options panel -- it may not be ready for v.2.7, but we do want to affirm that the panel is on its way! また、期待されていた通知オプションパネルについても作業しています。v.2.7では準備ができていないかもしれませんが、パネル(作成)が進行中であることをお伝えしておきたいと思います。 In spring… □ 春のアップデートにおいて And finally, of course, with this spring update comes an event to celebrate the Easter holiday. We are currently reviewing the potential ideas for the TT2 Easter event this year, so we won't be able to outline what you'll be seeing just yet -- but what you can expect is that this Easter theme and event will bring new equipment! 最後に、もちろん、この春のアップデートではイースターの休日を祝うイベントがあります。 今年はTT2イースターイベントの潜在的なアイデアを見直しているので、今概要をお伝えすることはできませんが、このイースターのテーマとイベントは新しい装備をもたらすでしょう！ Some of our older players can recall that to celebrate Easter last year, we held an event with pet eggs released every hour. This is definitely another activity that we may run again this year, in conjunction with another in-game event to ring in the warmth and spring! 古参プレイヤーの中には、昨年のイースターを祝うために、私たちは1時間ごとにペットの卵が産まれるというイベントを開催したことを思い出してください。 これは間違いなく、私たちが今年もまた別のインゲームイベントと一緒に、暖かさと春に鳴り響いているもう一つの活動です！ Although our team is currently bouncing ideas off each other, we also want to open the floor to our community as well for any event ideas you'd like to see. How do you think the heroes should celebrate Easter this year? Moreover, we would also love general feedback after the changes since v.2.6 -- i.e. What do you think of the new artifact percentage upgrade option? Please post in this thread your ideas and thoughts so we can open up the forum to potential changes influenced by you, our reddit community! 私たちのチームは現在、アイデアを練り上げている最中ですが、私たちのコミュニティにも広く、あなた方が見たいイベントアイデアを公募したいと思っています。 今年、ヒーローたちはイースターをどのように祝うべきだと思いますか？ また、v.2.6以降の変更後の一般的なフィードバックも歓迎します。新しいアーティファクトのパーセンテージアップグレードオプションについてどう思いますか？ あなたのアイデアや考えをこのスレッドに投稿して、私たちがあなた、Redditコミュニティの影響を受ける潜在的な変化を知ることができるようにしてください！ Bugs we're working on 対策中のバグ Hotfixed in v.2.6.7 Some of the very highest level players are currently having an issue upgrading artifacts when the artifact level gets a bit bigger than 2.1 billion -- we will be rolling out an unforced hotfix for this bug next week. v.2.6.7で修正：最高レベルのプレイヤーの一部が、アーティファクトレベルが2.1bを少し上回ると、アーティフトをアップグレードする際に現状問題を抱えています - 私たちは来週、このバグに対する強制的な修正を展開します。 Fixed in v.2.7 Display problem with the clan ship drifting off the screen will be fixed in v.2.7.0. v.2.7で修正：画面からずれるクランシップの表示問題はv.2.7.0で修正されます。 Investigating there is a bug with damage loss when the game is restarted, related to Tactical Insight. There is no specific release for this resolve, but it is being looked into. 調査中：Tactical Insight【戦術的洞察力】に関連して、ゲームが再開されたときにダメージロスが発生するバグがあります。 この解決策には特定のリリースはありませんが、検討中です。 Game Optimization ゲームの最適化 Understanding that there has been an increase in game crashes with specific device models, we have been working on reducing the install size by doing several optimizations to the game. 特定のデバイスモデルでゲームのクラッシュが増えていることを理解し、私たちはゲームにいくつかの最適化を行うことでインストールサイズを縮小する作業を行ってきました。 Specifically, we have found that players on Samsung devices may be experiencing more crashes due to notifications. We are currently investigating and working on resolving this, but we do recommend that Samsung users who are crashing when tabbing in and out of the game should disable notifications in your options panel to reduce crashes. 具体的には、Samsungデバイスのプレーヤーが通知によるクラッシュを経験している可能性があることがわかりました。 現在調査中であり、解決に向けて取り組んでいますが、ゲームの前後にタブを移動するとクラッシュするSamsungのユーザーは、クラッシュを減らすためにオプションパネルの通知を無効にすることをおすすめします。 If you haven't liked or followed us already… あなたがまだ「いいね」やフォローがお済みでないなら… Facebook Twitter Website Tap On! ⚔
https://w.atwiki.jp/how_to_use_ffmpegx/pages/13.html
6. Options tab ここでやること： 映像コデックのオプション。 このタブの内容は選択したエンジン/コデックにより大幅に変わる。また、同じ設定名でも挙動が異なる箇所もある ここでは、MEncoder-XvidとH264(MEncoder-x264)のみ解説。 6. Options tab6.1. Xvid MEncoderQuantizerとは 6.2. MP4 H.264x264のQuantizer 留意点 6.1. Xvid MEncoder 左列 High Quality 動き予測の精度。速度は概ね３倍程度変わるが、画質は向上し、ファイルサイズ（＝必要なビットレート）も減る。 Use B-frames Bフレームの使用。一般にBが多すぎると画質が下がるが、ffmpegXは最小限しか使わないのでさほどでもない。 ファイルサイズ（＝必要なビットレート）も減る。 Cartoon content 使わない方が画質は良い。 印象としては、隣接ピクセルを同系色で塗り潰そうとする傾向がある。バグス・バニーあたりの「カートゥーン」には良さげだが、「アニメ」や「アニメーション」には向かない。 Interlaced content 素材のインターレースをそのまま残す。または、プログレッシブ素材にインターレースをかける。 Two pass encoding 2パスエンコード。1stは2ndのほぼ２倍速で進むのでエンコード時間は2倍にはならない。 Trellis quantization 若干ファイルサイズ（＝必要なビットレート）が減る。 具体的な理屈は不明。 Quarter pixel ME（qpel） 1/4ピクセル精度の動き予測。 効果は素材によって違うため、確認してから使ったほうが良い。 また、古い再生チップは非対応な事があるので、家電再生機で見る場合は確認した方が良い。 右列 Scaling method 映像の拡大縮小の方式。 上のものほど早く、下の物程遅い。 720x480を640x480にする場合、どれでも大差ない。 bilinear；縮小向き bicubic；拡大向き、ターミナルでMEncoderを使う場合のデフォルト lanczos以下；映像をシャープにする。拡大する場合に良い。 Keyframe interval I-frame（キーフレーム）間隔の選択。I-frame はデータが大きい。 シークはキーフレーム間でのみ可能。 XviDは30fpsなら最大300、24fpsなら240まで。それ以上にすると画質低下。 QMin Quantizerの最小値*。範囲は1-31だが実用上は2-31が適切。整数のみ。下記参照。 QMax Quantizerの最大値*。範囲は1-31だが実用上は2-31が適切。整数のみ。下記参照。 5 sec test clip 5秒だけエンコード。設定確認に使う。 Print PSNR エンコード結果のログファイルを書き出す。PSNR（peak signal tonoiseratio）は高い程良い。単位はデシベル。 5 sec test clipと一緒に使って設定確認に使う。 Quantizerとは 画質劣化度とでも思えば良いだろう。数値が高いほど高圧縮、低画質。 Xvidは指定されたビットレートに収まるよう、各フレーム毎になるたけ低いQuantizerを使おうとする。 1パスは全てのフレームが指定ビットレートに収まるようにするので画質はよくない。 2パスは、1stで一旦映像全体を分析し、映像全体で指定ビットレートに収まるようにビットレートを配分する。動きまくったり、ディテイルの細かい部分には手厚く、ソレ以外のとこには薄く。配分の方針はコデックや他の要素にも左右される。通常はデフォルトの2-9で問題ないハズ。 QMin=QMaxの1パスで、画質固定エンコードになる。4-4でDivxコンポーネントや3ivxの言う「元画質の90％」になる。 もしこれでできたファイルの映像ビットレートが1500kbpsになったら、1500kbpsで2パスかけると、同じファイルサイズでより画質の良いものができる。 6.2. MP4 H.264 ffmpegXが内蔵するH.264コデックはx264というオープンソース、フリーのコデック。ISO MPEG-4 AVC規格（別名H.264）準拠。 比較的新しい為、ノウハウが少なく、設定方式も異なる。0.0.9tでは音ズレが発生したり、B-フレームを使うとQuickTime Player 7 proで再生はできるが加工不能になるなどの問題が生じている。 左列 Use CABAC エンコード、デコード共に速度低下（CPU負荷が高くなる）。サイズは縮む。 Use B-frames Bフレームの使用。一般にBが多すぎると画質が下がるが、ffmpegXは最小限しか使わないのでさほどでもない。 ファイルサイズ（＝必要なビットレート）も減る。 使うとQuickTime Player 7 proで再生はできるが加工不能になる。 Constant bitrate オン（デフォルト）；ビットレート固定エンコード。QMin〜QMaxの間でQuantizer値を変動させながら指定ビットレートを守る。 オフ；画質固定エンコード。下記参照。 Two pass encoding 2パスエンコード。0.0.9tでは1stと2ndは等速。 MEncoderでは既に1stを2ndの２〜4倍速にするturboモードがあるので、いずれ採用されるだろう。 右列 Scaling method Xvidの項参照 ME function 動き予測の範囲。 XvidのHigh Qualityと効果はほぼ同じで上から速いもの順。 Hexagonの速度は概ねXvidと大差ない。 ExhaustiveはG5-2Ghz Dualで1フレームに2秒近くかかる、、、たのしひ。 I-rames interval I-frame間隔の選択。I-frame はデータが大きい。 AVC/H.264ではI-frame=キーフレームではなくなった（早送りや巻き戻しに使えないI-frameができた） ffmpegXの120が適正かどうかはなんとも言えない。ターミナルでMEncoderを使う場合のデフォルトは250だが、これはEUのDVDに合わせた数値に思える。 QMin Quantizerの最小値*。範囲は2-51。整数のみ。下記参照。 QMax Quantizerの最小値*。範囲は2-51。整数のみ。下記参照。 Print PSNR Xvidの項参照 x264のQuantizer 目盛りが対数尺。つっても解っちゃいない。 q=20とq=40ではビットレートの差は10しか無いとか言うから、変動幅が小さいのだろう。 XvidのQuantizerの感覚からすると2.3とか、小数点で細かく指定できると思っておけば良いのはないか。 留意点 1パス；Constant bitrateオン、ビットレートを指定。 2パス；Constant bitrateオン、ビットレートを指定。 画質固定1パス；Constant bitrateオフ、ビットレートは無視する。 qmax=qmin=22。21 か 20 でもうちょびっと高画質（あまり低くしすぎてもそんなに意味が無い）。 なお、MEncoderのx264にはロスレスの設定も存在するので、今後の対応もあるかも知れない。 名前 コメント
https://w.atwiki.jp/cohstatsjp/pages/286.html
Vehicle Funkwagen Vampire Halftrack Contents 1 Funkwagen Vampire Halftrack Veterancy 2Info 3Tactics 4History 5Built From 5.1 Logistik Kompanie 6Vehicle Abilities 6.1 Vehicle Cover 6.2 Divert Supplies 6.3 Goliath Drop Funkwagen Vampire Halftrack Health 285 Max Speed 6.5 Sight 35 Cost 220 Acceleration 6 Detection 0/0 Time 45 Deceleration 3 Hotkey V Population 2 Rotation 50 Target Type vehicle_22x Upkeep 4.032 Crush Human Critical Type supply_truck Crush Mode Rear Damage Enabled false Funkwagen Vampire Halftrack Veterancy [Expand][Hide] Received Damage Received Accuracy Maximum Speed Maximum Health 0.9 0.9 1.15 1.15 8 Vet-Exp Received Damage Received Accuracy Maximum Speed Maximum Health 0.95 0.95 1.05 1.15 22 Vet-Exp Received Damage Received Accuracy Maximum Speed Maximum Health 0.95 0.95 1.05 1.15 38 Vet-Exp Info The Funkwagen Vampire is a complicated unit. Divert Supplies is a toggled ability that actually causes many different effects, at the cost of mobility. In summary, Divert Supplies allows the Vampire to steal resources, deny enemy resources, spot enemy infantry units through the Fog of War with extended sight , and act as a detector unit. In addition, the Vampire is the only Panzer Elite unit capable of producing Goliaths. Refer to this guide made byRelicNews forummemberYurdleTheTurtlefor more information and detailed explanation of how the Vampire works (2.502) Funkwagen Vampire Halftrack Guide. Tactics The Vampire can be used to deny a large amount of resources from the enemy, and can be used as a powerful reconnaissance unit. Finding the right places to deploy the Vampire can be difficult however. For recon work, have the Vampire deployed in areas so its extended sight provides coverage over as much possible routes/entrances as possible, while also keeping the Vampire relatively hidden from view. Hiding behind obstacles and away from regular traffic routes is also a good idea. Due to complicated mechanics, resource denying and stealing is not as simple as it seems. The Vampire not only steals resources from one sector, but is also capable of denying a large amount of resource income to the enemy overall. Refer to theVampire Guidefor detailed explanation. Using thetactical mapwith a deployed Vampire allows it to see the unit type (by unit symbols) and the health bars of approaching enemy infantry. This will allow you to use the intelligence gained from the Vampire in order to plan ahead of the enemy - for example, preventing sneaky attempts to decap your resources/strategic points, or to bring your forces to bear before large attacks arrive. Remember, a Vampire can only detectinfantryunits through the fog of war. Also note that even camouflaged (Snipers, etc.) units are also detected through the fog of war - however, they cannot be physically targeted unless detected normally through detection range. A Vampire with the Tank Awareness perk from the Panzer Elite Tank Destroyer doctrine has extended sight against both infantry and vehicles units. Note that Anti-Tank guns (51mm AT Gun, etc.) count as vehicle units, not infantry. A deployed Vampire increases its detection range from 0 to 30. This means the Vampire has the highest detection range out of any unit, although it is hampered by its immobility. Deployed Vampires gain a 50% increase in health. This bonus is removed when the Vampire is mobile again. Deployed Vampires cannot move. Vampires are the only Panzer Elite units that can produce Goliaths. They can build them regardless of whether or not that are deployed. History The SdKfz 250/3 (SdKfz 250 model, third variant) was a radio-equipped 250 series half-track. They were primarily used by the headquarters of reconnaissance forces, and as Forward Air Controllers by the Luftwaffe. The large bed frame antenna was a distinctive trait of this vehicle. Built From Logistik Kompanie [Expand][Hide] Health 1000 Target Type building Cost 22020 Critical Type building Time 115 Hotkey L Effects Makes available the Scout Car, Munitions Halftrack and 250/3 Funkwagen Vampire Halftrack. Upgrades will equip squads with Anti Tank Grenades and increase the size of infantry squads. ESeeStructure Logistik Kompaniefor details. Vehicle Abilities Vehicle Cover [Expand][Hide] Cost Activation always_on Duration _ Target tp_any Recharge 0 Hotkey Effects $0 no key ESeeAbility Vehicle Coverfor details. Divert Supplies [Expand][Hide] Cost Activation toggle Duration 3 Target tp_any Recharge 10 Hotkey S Effects Enables the Funkwagen Vampire to divert resources produced from an enemy sector. It will also deny the enemy resources in a connected supply line. When deployed, infantry can be detected in the Fog of War. ESeeAbility Divert Suppliesfor details. Goliath Drop [Expand][Hide] Cost 125 Activation targeted Duration _ Target tp_position Recharge 90 Hotkey G Effects Halftrack can drop a Goliath Remote Controlled Bomb. ESeeAbility Goliath Dropfor details. Retrieved from http //coh-stats.com/Vehicle Funkwagen_%27Vampire%27_Halftrack
https://w.atwiki.jp/dy-ud200/pages/19.html
2009/3/3に公開された新バージョン。 無改造のままでもHDCP非対応環境でSD画質で視聴できるようになった。 1.0.0.4が登場以降、メーカーHPからはダウンロードできず、1.0.0.4を入れてしまうと一切の改造ができなくなるので注意。 早くもTS抜きは可能に。解析神に感謝！ ただ、改造して利用する人間にとってはめぼしい改善点が少なく、逆にBonDriverが使えない、HDCP非対応環境で全画面表示を利用するのが不便になるなど問題点が多いので、改造前提での利用であれば1.0.0.1を使い続けることを強く推奨。 1.0.0.1で改造の対象だったDAWIN DTV.exeやUniMFSegPF.axなどのファイルは1.0.0.3ではUPXで圧縮されているのでまず解凍して非圧縮のファイルにする必要があるが、ヘッダが変造されておりそのままでは解凍できない。そこで変造されたヘッダを元に戻してUPXで解凍してからバイナリをいじる手順になる。バイナリ改造後は特にUPXで再圧縮する必要はない。 2009/3/5に1.0.0.1用ファームウェアへの書き戻し方法が発見された。(6スレ502)1.0.0.1と1.0.0.3の双方のDAWIN DTV.exeが必要。 TS抜きまでの改造まとめ(第6スレ254) UPXで解凍するUPX解凍 (第6スレ 129) UPX解凍まとめ(第6スレ 147) TS抜き関係uesファイルを暗号化しない(第6スレ177) uesファイルにヘッダを書き込まない(第6スレ177) 録画時に出力されるファイルの拡張子をtsにする(第6スレ177) その他HDCP非対応環境で便利に視聴する(第6スレ190) MULTI2のデコードに関するバグを取り除く(第6スレ191) 映像表示をなくして録画時の負荷軽減(第6スレ191) ウィンドウを表示しないことで録画を意識させない(第6スレ394) ファームウェアの更新を強制する(第6スレ493) 1.0.0.1のファームウェアに書き戻し(第6スレ502) デバッガチェックをクラックする(第6スレ852) TS抜きまでの改造まとめ(第6スレ254) 現時点(2008/3/4)での、Ver1.0.0.3のts抜きまでの道のりまとめ・ツール不使用版。添削よろ １．D/Y-UD200を接続し、公式からVer1.0.0.3をダウンロードし、ファームウェアの更新も含めセットアップして正常に視聴できることを確認 ２．インストールフォルダ(C \Program Files\DAWIN DTVとか)にあるDAWIN DTV.exeなどをバイナリエディタで以下のように編集 DAWIN DTV.exe 00000210 44 59 55 - 55 50 58 00000238 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 UniMFSegPF.ax 000001F0 44 59 55 - 55 50 58 00000218 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 ３．ttp //upx.sourceforge.net/download/upx303w.zipをダウンロード・解凍し、「upx303w」フォルダにある「upx.exe」を DAWIN DTVインストールフォルダにコピー ４．以下の記述のBATファイルを作成し、実行。知識があるなら同じ事をコマンドラインで実行しても良い upx -dk "DAWIN DTV.exe" upx -dk "UniMFSegPF.ax" ５．実行可能なまま圧縮されていたDAWINなどが解凍されるので、再度バイナリエディタで以下のように編集 DAWIN DTV.exe 00028BCC E8 5B 66 17 00 - 33 C0 90 90 90 001E9348 75 00 65 00 73 - 74 00 73 00 00 UniMFSegPF.ax 0001C3D0 51 56 8B F1 - C2 10 00 90 00017522 20 03 - 00 00 00017539 20 03 - 00 00 000176AE A4 - 00 00019679 08 - 00 ←NHKパッチ ６．tsファイルで録画されるので、DAWINDTVから録画した番組は再生できないが、GOMやPowerDVDその他のMPEG2TS とAAC対応ソフトで再生や編集ができる 。それぞれの改変箇所の意味はログを参照 UPXで解凍する UPX解凍 (第6スレ 129) DAWIN DTV.exe 00000210 44 59 55 - 55 50 58 00000238 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 とすれば upx -d で復号できることを確認。 で、UPXってGPLだから圧縮したファイルもGPLになる。 The stub which is imbedded in each UPX compressed program is part of UPX and UCL, and contains code that is under our copyright. The terms of the GNU General Public License still apply as compressing a program is a special form of linking with our stub. http //upx.sourceforge.net/upx-license.html でも、それだと困るから特定の制限の元に（GPLに汚染されずに）自由に 使うことを認めてくれている。 Hereby Markus F.X.J. Oberhumer and Laszlo Molnar grant you special permission to freely use and distribute all UPX compressed programs (including commercial ones), subject to the following restrictions UPX圧縮したファイルを後から書き換える（UPX- DYU, 3.03- 9.09）のは この制限に違反してる可能性がある。 2. This also implies that the UPX stub must be completely unmodfied, i.e. the stub imbedded in your compressed program must be byte-identical to the stub that is produced by the official unmodified UPX version. GPL違反ktkr ソース公開ktkr wwwww 編注：typo訂正 UPX解凍まとめ(第6スレ 147) DAWIN DTV.exe 00000210 44 59 55 - 55 50 58 00000238 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 UniM_FSeg.dll 000001F8 44 59 55 - 55 50 58 00000220 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 UniMFSegPF.ax 000001F0 44 59 55 - 55 50 58 00000218 44 59 55 - 55 50 58 000003DB 39 - 33 000003DE 39 - 33 こんな感じ？ TS抜き関係 uesファイルを暗号化しない(第6スレ177) # 暗号化OFF "UniMFSegPF.ax" 0001C3D0 51568BF1 C2100090 uesファイルにヘッダを書き込まない(第6スレ177) # 独自ヘッダー書き込み抑制 "UniMFSegPF.ax" 00017522 2003 0000 "UniMFSegPF.ax" 00017539 2003 0000 "UniMFSegPF.ax" 000176AE A4 00 "DAWIN DTV.exe" 00028BCC E85B661700 33C0909090 録画時に出力されるファイルの拡張子をtsにする(第6スレ177) # 拡張子 TS "DAWIN DTV.exe" 001E9348 7500650073 7400730000 その他 HDCP非対応環境で便利に視聴する(第6スレ190) 0002CA46 0F 84 5D 05 00 00 - E9 5E 05 00 00 90 0002CB37 0F 85 6C 04 00 00 - E9 6D 04 00 00 90 0002CB43 0F 84 60 04 00 00 - E9 61 04 00 00 90 でどうですか？ 編注：1.0.0.1と違い、再生時にウィンドウサイズを変更するようになっており、 マルチディスプレイ環境でしか実質的に意味はない。 MULTI2のデコードに関するバグを取り除く(第6スレ191) 00019679 08 - 00 #デコードミス修復 映像表示をなくして録画時の負荷軽減(第6スレ191) 0001967A 53 - 52 # 映像表示OFF ウィンドウを表示しないことで録画を意識させない(第6スレ394) 録画中にウィンドウ表示させない(1.0.0.3) DAWIN DV内に新しいフォルダ(例 「For Watch」)を作って デスクトップ等のショートカットもそちらの方へ移動。これを視聴専用とする。 DAWIN DV内のフォルダのDAWIN DV.exeを書き換え 001827D1 FF 74 24 04 → 6A 00 90 90 これでウィンドウ自体が表示されなくなる。録画予約したやつはこっちが 非表示ながら録画してくれるので使えるかも。 2重起動は多分できないようになってるから録画中に視聴専用の方を起動しても何も起こらない。 逆もあり得るので注意。 ファームウェアの更新を強制する(第6スレ493) # 1.0.0.3 force firmware update "DAWIN DTV.exe" 00020470 0F87CD000000 909090909090 1.0.0.1のファームウェアに書き戻し(第6スレ502) 手順 １．ver1.0.0.1 の DAWIN DTV.exe からリソースを一つファイルに書き出す BINARY-603-1041 ２．ver1.0.0.3 の DAWIN DTV.exe を upx -d する ３．ver1.0.0.3 の DAWIN DTV.exe のリソース BINARY-603-1041 を手順１で抜き出したリソースと置き換える ４． 493 適用 ５．DAWIN DTV.exe 実行 ６．一回目のファームウェア更新を行う ７．二回目の更新を中断する（何度でもファームウェア更新しようとします） ※Resource Hackerを使うと確実に失敗しUD200がスクラップと化します。注意しましょう。 デバッガチェックをクラックする(第6スレ852) 1003でオリー様が弾かれる件。 DAWINDTV.EXE の000A082ACの09を00に変えると一瞬起動する。UNIMFSEGPF.axでもチェックしてるらしく、まだ視聴できるまでにはなってない。 83 FF 09→83 FF 00