4,836 karma · joined February 6, 2010
Module.onEnemyKilled();Module.onEnemyKilled();Module.onEnemyKilled()
probably should run part of the game on the server if you want to prevent bypassing the captcha easilyi also tried looking at ‘nearby stations’ and while standing on the 34th st A platform it didn’t list the 34th st subway station at all, just a bunch of bus stops.
please let me just look at a station list instead.
I see a lot of people asking why someone would distribute an Electron-wrapped version of a program you could run natively, and I see it as an extension of the the same reason why I ported these emulators to the browser in the first place: accessibility. While you can install BasiliskII natively, it's a bit of a pain, especially if you are not super technical. If you find a binary floating around online it may not work for your OS version. Wrapping it in Electron is one way to ameliorate the OS compatibility issue; Chromium has been battle-tested across many OS versions. Ideally BasiliskII would have a better OS compatibility story (as well as being more portably distributable with data files) but, like many open source projects, it doesn't have a lot of maintainer-time to make this happen.
Additionally, you can always fall back to clickable links if you really want to support subsequent interactions for users with no JS, if you've built the routing infrastructure for that
https://jamesfriend.com.au/projects/tryhypercard/
For Mac users, you can also easily run it on your local machine: https://jamesfriend.com.au/running-hypercard-stack-2014
Also, if you're taken by the HyperCard aesthetic, you be interested in this interactive artwork created in HyperCard (which I contributed technical assistance to): https://www.upprojects.com/projects/commissions/formality/
coincidently today firefox 79 was released, which brings back support for SharedArrayBuffer, which is a key part of the browser port of this emulator
One 'nice' thing about working with old architectures like classic Macintosh is that there is basically no abstraction between the software and the hardware, so manipulating the behavior of the emulated hardware becomes a powerful debugging tool.
Compare with Australia's National Public Toilet Map: https://toiletmap.gov.au/Find/20547
Also, it seems like this article is falling surprisingly fast down the front page. dang can you confirm whether this is getting aggressively flagged?
I have a short tutorial[3] for running HyperCard stacks locally which might be interesting to anyone who has some stacks lying around on their filesystem, or who just wants to play around with Mac OS 9.
[1] https://jamesfriend.com.au/pce-js/
You're also misrepresenting what the docs say about replacing class components. They're saying that you don't need to replace class components just for the sake of using 'the new thing'. However if there was some concern you wanted to extract from a class component that you could not previously, you absolutely could adapt it to use hooks, and then extract and reuse that concern in another component.
If you want to have no abstraction and show all state in your component, just don't extract any into Custom Hooks. Then it's really not very different to a class component.
Grouping these parts this way means they can be trivially extracted as a Custom Hook[1] (analogous to a 'mixin' or 'trait' in OOP).
By extracting this concern into a Custom Hook it can easily be reused by different components, as well as composed by other Custom Hooks. This was previously possible using Higher Order Components, Render Props and the (really old) React Mixins concept, but Hooks addresses problems with each of these previous approaches.
If you want to know more about how Hooks improves over these previous approaches, see my previous comment: https://news.ycombinator.com/item?id=19074469