「そもそもスタミナ1個回復の時間が5分ってのが思い込みでは」

という可能性に行き当たりました。

で、

「スタミナMAXから1個使った瞬間の『スタミナ回復までMM:SS』の表示を撮ればハッキリするんじゃね？」

と思いつき、実行してみた結果がこちら。

「04:49」･･･どうやら「1個回復に5分」がただの思い込みだったみたい。

この例だとスタミナが10残ってるから、回復させるまでの時間を計算してみる。

回復の余地(？)は20個分。

まず簡単に計算できる19個×5分=95分(1時間35分)

で次の1個回復するまでの時間が03:45と出てるから、これと19個分の時間を足すと、

01:38:45

になる。しかし、実際に表示されているのは

01:35:35

でに食い違う。

ていうか1個回復と全回復で、少なくとも秒は同じになるだろう。

では逆にこの表示が正しいとして、計算してみる。

01:35:35から次のスタミナ回復までの03:45を引くと01:31:55

表示が正しいならば、これが19個のスタミナ回復にかかる時間だ。

秒に直すと1×3600秒+31×60秒+55秒=5515秒

でこの秒を19個で割って1個あたりの時間を出すと

5515秒÷19個=290.263157894・・・

ん、スタミナ1個あたり回復するのに4分50秒になってる？

折角なのでもう一例。

回復の余地は29個分。

28個×5分=140分(2時間20分)

そして次の1個回復するまでの時間が04:17と出てるから、これと28個分の時間を足すと、

02:24:17

になる。実際の表示は

02:19:37

でやっぱり食い違う。

でまた逆にこの表示が正しいとして、計算してみる。

02:19:37から次のスタミナ回復までの04:17を引くと02:15:20

これは28個のスタミナ回復にかかる時間だ。

秒に直すと2×3600秒+15×60秒+20秒=8120秒

この秒を28個で割って1個あたりの時間を出すと

8120秒÷28個=290

またもやスタミナ1個あたり回復するのに4分50秒となった。

表示がおかしいのではなく、前提としていた5分で1スタミナ回復が思い込みだったのか？

元々、4分50秒で1スタミナ回復する仕様だったのか？

検証のためには実際の時間を計る必要があるが、ちょっと面倒なのでやる気にならない。

謎は深まってしまった・・・。

いや問い合わせりゃいいんだろうけどさ。

カブ→白

赤カブ→赤

青マメ→青

黄タマネギ→黄

緑カボチャ→緑

と。

さっぱり気付かんかったわ。

今のドールパワーが8300くらいだから、スタミナ5使っても41,500、引っこ抜きスタミナは6分で1回復だから、30分ごとに41,500費やすとして、･･･5時間と30分か。

豊作タイムあってもこれ以上は消化し切れんなー。

バター風の壁を集めるクエストに専念するかな。

いくら何でも大盤振る舞い過ぎるなあと思ってたのよね(^_^;)

割と技術的な話なので、ダメだと思ったら早めに読むのを打ち切るのをオススメします。

自分は業務でFile Maker ProというアプリのWindowsOS版を使います。
データベースそのものとデータベース管理、データ処理が1つに組み合わされたような、なかなか使いでのあるアプリ（注：個人ではなかなか使い途がないと思います）なのですが、
微妙に不便を感じることがあります。

そのうちの1つがポップオーバー、ポップオーバーボタンと呼ばれる吹き出し機能です（13以降に追加された機能）。

ポップオーバーは、普段は必要がないデータフィールド（カラム）を配置しておき、必要ない時には表示させず、必要になったらボタンを押して吹き出しを呼び出して、そこに配置したデータフィールドを参照する、と言った感じで使います。

ただこの吹き出し、余所をクリックしたりすると簡単に引っ込んでしまいます。

また、レコード（データ行）を移動しても引っ込んでしまいます。

このうち後者はなかなか厄介で、レコードを順繰りに送って行きながら、ポップオーバー上のデータを見比べる、といったことをやろうとすると、いちいちポップオーバーボタンを押して吹き出しを表示する、という手間がかかることになります。

これを解決する手段を検討してみました。

使用するのはスクリプトとスクリプトトリガ機能、あとはオブジェクトに一定の規則に基づいて名前を付けることです。

前置きが長くなりましたが、早速サンプルを掲載します。

まずはポップオーバーボタンの設置です。

後々でも良いのですが、このポップオーバーボタンにはオブジェクト名を設定します。

次に吹き出しそのものであるポップオーバーを表示します。

このとき、ポップオーバーそのものにもオブジェクト名を設定します。

ポップオーバーそのもののオブジェクト名と、ポップオーバーボタンのオブジェクト名は一定の規則性がある方がいいと思われます。

文字列関数により、ポップオーバーボタン名から、ポップオーバー名に変換できる程度の規則性で十分です。

上記の例ではポップオーバーに「ポップオーバー1」、ポップオーバーボタンに「ポップオーバー1ボタン」とオブジェクト名を設定しています。

次にスクリプトです。

まずオブジェクト名を取得するスクリプトを作成します。

詳細は下図を参照して下さい。

スクリプトステップ「ポップオーバー閉じる」が実行されると、ポップオーバーボタンにフォーカスが移ることと、

オブジェクト名を取得した直後の時間をミリ秒で取得しているのがポイントです。

次に取得されたオブジェクト名に基づいて、特定のオブジェクトに移動するスクリプトを作成します。

詳細は下図を参照して下さい。

ポップオーバーが閉じてから経過した時間（ミリ秒）により、オブジェクトに移動するかどうか分岐しているところと、
取得したオブジェクト名から「ボタン」を削ったオブジェクトに移動しているのがポイントです。

最後にスクリプトトリガの設定です。
レイアウトに設定するOnRecordLoadトリガに先ほどのオブジェクトに移動するスクリプトをセットします。


次にポップオーバーそのものにスクリプトトリガを設定します。

OnObjectExitトリガに先ほどのオブジェクト名を取得するスクリプトをセットします。

これで完了です。

実際に試してみると、レコード移動してからポップオーバーが再度開くようになっているのが分かると思います。
経過時間により吹き出しに移動するかどうか（ポップオーバーを開くかどうか）分岐しているのは、ポップオーバーを予め閉じておいてレコード移動した場合に、無用なポップオーバーのポップアップを防ぐためです。

レコード移動に時間がかかる（非保存の計算フィールドに複雑な計算をやらせているなど）場合にはうまく動かないかも知れません。

その際には、オブジェクトに移動するスクリプトの、時間差と比較する定数の数値（図中では300）を大きくしてみて下さい。

以上です。