My original question has now been changed. Post 4 is my new question.
A way to test this can be as follows:
currentTime = FileSystem.stat("info/convos.json").mtime;
if (currentTime.getTime() > _lastModifiedTime)
_lastModifiedTime = currentTime.getTime();
_currentFileState = File.getContent("info/convos.json");
if (_currentFileState != _previousFileState)
_state = _currentFileState;
_previousFileState = _currentFileState;
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?
That’s interesting, Developers should have an ability to
set which files they think could be updated periodically.
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)
_lastModifiedTime = ;
for (i in 0..._state.conversations.length + 1)
if (_convo == null)
_convo = new Conversation(getConvoFile(), _parser, _interp);
if (_previousConvoId != _state.currentConvo)
_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
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.