Okay, after further testing the above code reports the same timestamp, even if you delete the subject file and resave new content to force a change in the timestamp, the timestamp acquired by FileSystem.stat does not seem to report accurate results.
Is this a bug in the Haxe standard library, do you think?
Okay, perhaps I went too far ahead of myself without testing it properly, and realising that I was saving the wrong file…
So now I have a new question, which I may or may not be able to resolve on my own. I am going to place my entire engine onto Github so that you can test these results yourself and play around with it if you wish.
Currently, I have a function which “reloads” conversations.
public function reloadConvo()
{
if (_state.currentConvo > _state.conversations.length - 1 || _state.currentConvo < 0)
return;
_lastModifiedTime = [];
for (i in 0..._state.conversations.length + 1)
_lastModifiedTime.push(Date.now());
if (_convo == null)
{
_convo = new Conversation(getConvoFile(), _parser, _interp);
_convo.setupUnitScale();
_convo.gotoDialogue(_state.currentPassage);
}
else
{
if (_previousConvoId != _state.currentConvo)
_convo.startConvo(getConvoFile(), _state.currentPassage);
else
_convo.gotoDialogue(_state.currentPassage);
}
_previousConvoId = _state.currentConvo;
}
With the above code, this is how a conversation reloads “on-the-fly” without needing to recompile.
However, when modifying the file, the length is reported as inaccessible by Neko straight after setting the _state.
If you wish to test this, the project can be found here. I haven’t upgraded OpenFL (v 3.4) in a while, so results may differ slightly in unprecedented scenarios.
EDIT: I actually forgot to parse the new results, which was causing the issue.