-
Posts
3,395 -
Joined
-
Last visited
-
Days Won
159
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Everything posted by johnparker007
-
Well that is certainly a novel approach! So a bit like those console streaming services. If several people want to play at the same time (on different layouts), that could get hairy, as you'd need to be running and streaming out 3x MFME windows. You can pretty much simulate how it might be, by using something like TeamViewer or Chrome remote desktop, and then you could run MFME on your PC desktop - however! You will see much better results if both the host and client are on the same network (i.e: your house). As then it won't go out onto the internet and will all be done over your house ethernet/Wifi, giving a false sense of performance. You could kinda simulate real world conditions by playing it on your phone over 4/5G perhaps.
-
When I said 'legacy', maybe that wasn't the best choice of word lol I guess once Oasis is at the point where it has a functioning version of the new Arcade Sim, with the machines built using its tools, and the servers are working, then the old Arcade Sim will truly be legacy.
-
Well this was just some very broad pointers, for if someone did want to do this system (I won't due to the time cost, as I'll be doing a system in Oasis that will work 'somewhat' differently to this (much less janky and much less straightforward to cheat! ). At the basic level, if it's working on an 'honour' system, so say everybody uses their Dif forum username as their username for the Windows-side app... then if a machine stays 'checked out' for a week or so, a message could be sent thru Dif to ask them to do check the file back in. And on the Windows app side, you'd have a button to check in the machine you currently have checked out (so it wouldn't matter if communication was lost at some point during play, they only need to be connected at the point when the click to check the machine back in again). Need to be online: Browse and check out an available machine from the list via the Windows app Don't need to be online: Play the checked out machine, launching it from the Windows app Need to be online: Check in (aka 'submit') the machine again
-
That is correct. The author Chris Wren sadly died, and so the source code is lost. Yes that's right. There is something on the Oasis repo that would probably be useful for this, as it's also used by MfmeTools to control Mfme for extracting the layout, and not polluting the real Mfme data in the Windows Registry. It's part of the dll injection that Arcade Sim uses - it does cause false positives with virus detection software though! The code's probably a mess, as it was a bit of a whirlwind developing all the technology to make Arcade Sim work, so I wasn't doing my tidiest work Oasis code is better, honest lol You prob do something like have a server running, or ideally set it up on an Amazon instance. That could manage the database of ram saves, who currently has a machine 'checked out' from the collection of machines (i.e: they are playing it). It could provide a web interface purely for viewing the data. It could then also provide some JSON IO stuff (something simple with plaintext GET/POST to start), that's how the Windows-side app would check out/submit RAM saves to the online database. The Windows app would display a list of the machines in the database, and whether they are currently being played by another user, or available to check out. When a machine is checked out by a user thru the app, it downloads the save, and prob fires MFME up under the DLL control, using its own copy of the layout. Then at some point the user can choose to submit this machine back to the server, making it available for others to play. You could also add some basic tracking of the meters, ensuring the layouts specifically set up for this system have them set correctly, I think it's in the .gam file where the accumulated values are recorded. So you could then give users a balance or 'high score' of how much they made/lost. This would all be extremely easy for someone to cheat on if they were so inclined btw! Editing gam file In/out totals, exiting MFME without saving the ram if they do poorly, plus other ways to cheat, hacking credits into RAM with something like cheat engine. It'd also all be highly janky, but that's a way it could be implemented in theory, if you chose to develop it
-
Ah cool, hopefully you are all sorted now then I'm afraid I'm not doing any further updates on this 'legacy' Arcade Sim, as the new Oasis suite of apps will include a new Arcade Sim... that one will have full VR support, but it's likely a couple of years out!
-
Hmm that's odd, I recall you said the video game machines were only showing black screens, so I just assumed you had an old PC with perhaps a slow hard drive! That sounds like it should be able to run it... though I must admit I've only tried it on SSDs (rather than the older 'spinning disc' hard drives). So, if from the in-arcade settings menu, you set these 3 settings to their defaults, so it looks like this: ...and then fully exit to the frontend, and reload back into the arcade... the videogame screens are black? For reference, they should look like in this video:
-
The way I plan to implement this will be that the user will be running the emulator (in this case MAME) in their own machine, not in the cloud. So for the 'arcade' version, the simplified version of how it will work is: when you walk up to a machine to play it (that doesn't have someone else currently playing it), the latest uploaded save state will be downloaded from the server, and the emulator will start up with that save state. User plays, money goes in, money pays out etc... then they exiting playing the machine, and the machine's current state is uploaded to the server as the new latest state, ready for the next user. If you get close to another player who is playing a machine (specifically in terms of the fruit machines), there will be a stream of the lamp/segment/dot matrix data, in a highly compressed lossless format. So then it'll be like how the fruit machines do their attract modes in the current Arcade Sim when you are walking around - it's just a somewhat compressed data stream, that flashes the various lamps etc. Unsure what direction to take wrt. streaming the emulated audio yet, will get into that when I actually come to implement this stuff ... though button clicks, coin payout, meter clicks etc will also play back perfectly as again it can be wrapped in the highly compressed codec as mere trigger bytes. So you'll be able to wander around and watch people actually play the machines next to you... In terms of doing something for MFME, I couldn't get into that myself, since I need to use my free FME dev time to work on Oasis... but someone could knock something up that would work like how Amber did it, so simply uploading the RAM save when the user finishes playing locally, and then the next user downloads that RAM save, and boots up the machine...
-
On this version of Arcade Sim, you only get the ambient sound on PCs that have fast enough CPU / disk drive to support the attract mode videos, sorry about that. So without a faster PC that can support running those attract mode videos, there is no ambient sound.
-
Are the other fruit machines fully playable, and it's just Andy Capp not working correctly? Usually it's the '0' (zero) key to insert a coin, 'Space' to press the Start button... or clicking on the coin slots/buttons works the same way.
-
This I am not sure about - do you perhaps have a joystick/gamepad plugged in with something resting on the joystick? Ok so unfortunately this old version of Arcade Sim triggers a false positive in the inbuilte WIndows Defender anti-virus software. There are instructions to work around it here: Sorry for the inconvenience, the new version of Arcade Sim uses a different emulation backend which doesn't cause these issues, but it's a long way from being ready yet, it will take at least a year or more, to develop all the software. And yes, for this original Arcade Sim you do need to download MFME v20 from this site, and then also run the Updater found in its folder (as MFME is not open source). Again, in the future release of Arcade Sim (as part of the new Oasis software), all these issues will be solved so it will simply run out of the box, with no additional emulator installs or antivirus problems. If you have more issues, please tag my username, as otherwise I don't always see these posts
-
Cannot get Arcade Sim to take coins
johnparker007 replied to Tommohawk1705's topic in Arcade Simulator
Unfortunately the attract videos are quite demanding. In future there will be a simpler version that just uses cycling screenshots, but for now you'd probably be better disabling the videos from the settings menu. Linked in post above with steps that should get the fruit machines working properly. -
Cannot get Arcade Sim to take coins
johnparker007 replied to Tommohawk1705's topic in Arcade Simulator
This was the comment on that page that has the steps that should fix the issue (hopefully!) -
Ooh nice machines I spy a Test Pilot next door.
-
-
I did plan to do something like that at some point, may end up being hybrid so it can use MAME's existing database of cheat locations at least, but perhaps Oasis RAM controller to manage the cheats, via the Oasis Lua library that we use currently to control inputs... one day
-
You could use MAME's debugger to search for larger/smaller values (without needing to know precisely what they are). So you'd guess at a value type (prob an 8 / 16 /32 bit int). Start a search on a clean RAM on that value type. Then feed money in the machine, and try to burn through credits while winning absolutely nothing. After every say 10 credits, you'd then go into the debugger, and search for values of the value type that increased since your last search. Keep repeating the process. At some point if it then sprees (something like Sunset Boulevard I guess does that)... then take a few wins, and then continue the debug searches, but for values that have decreased, and do that. Hopefully you will end up with 1 or just a few addresses that match the pattern. Then you could try poking them with values, so see if it can control how 'ready' the machine is... might be a bit more to it, but prob worth a shot if you are interested in doing this sort of thing! Also - the values may instead decrease as the machine becomes more ready, rather than increase. Have fun - there's a rough video here on how to do it in MAME, if you search 'mame debugger cheat' on youtube there's a few videos, some showing searching for floats as well, though the older machines like Smash & Grab probably worked in fixed point math: Also, you could probably also use MFME and Cheat Engine to achieve similar results.
-
Thinking outside of the box for a future Oasis feature, I guess you could have something like an 'enhanced stacktrace analyser'. So then you could capture a stacktrace in Oasis (from the MAME backend)... and you could capture a start-> duration of spin sample, and then a duration of spin -> end of spin sample (on hotkeys/menu option). It could then filter each trace by subroutine jumps (so it'd capture say all the JSR instructions with accompanying RETs back to the calling PC). Then within Oasis, you could compare with a execution style diff tool, so that you could get a list of the unique function call addresses that were present at the duration/end of spin, that were not present at the start/duration of spin (as an example of what you could use this for). That would be very useful in trying to do an analysis like we mentioned above, where you want to see which subroutines are unique to the end of spin (or end of win animation) - i.e: finding the calls that update the compensator on whichever tech. MAME has a debugger, but it's command line based, and to be fair, much less user friendly that Chris's GUI debugger in MFME. A hybrid could end up being more user friendly than either of those, with built in 'Datel Action Replay' style functionality, such as tracking incrementing/decrementing values (that could hook into MAME's existing debugger cheat functionality I guess (https://docs.mamedev.org/debugger/cheats.html), though it would probably be better to have Oasis roll its own integrated system, rather than a mish mash of Oasis native vs MAME native functions for execution analysis). On some of these older techs like MPU4 they have so little RAM, it'd be like shooting fish in a barrel ...compared to say a Commodore Amiga (where I first used a Datel Action Replay) where the writable address space is orders of magnitude larger than MPU4 (I'm assuming Impact and maybe even Sc4 is similar). Interesting for future edits to MPU3 gamble blocks, compensator writes, and the like...
-
That was a very interesting read, thanks @edwardb and @Mort I'm not sure if this: ...means discrete levels (as opposed to algos with a fine-grained input); if it is discrete levels, then this from Smash & Grab makes a lot more sense: (5 Barcrest 'stabiliser' levels). Also, nice to read this: ritdav: "That was really interesting.First question coming up.Emptiers were they mainly badly written code or were they always deliberate.Reading the above they would have to be beyond the compensators to work .What were the legendry ones and were people fired over them.If you can't talk too much about them thats fair enough." Almost always mistakes. Never intentional apart from one guy at Ace who decide to try and make a few quid by putting an emptier in. He got caught in a pub, fired and prosecuted. I think he got 2 years for fraud. That was on an old SP-Ace club machine. There are lots of theories about at least some of the bugs being intentional, it sounds like that was actually quite unusual, if coders who got tempted to the dark side were getting hit for fraud, by including some spicy code, and then caught directly using it. However, I could still imagine that a coder might include a spicy 'believable' (but still exploitable) bug, if he had connection in the players scene (so they'd buy the bug, and he'd never actually use the bug himself in real life). The old adage of 'don't get your hands dirty'. So those ones would fly under the radar as innocent bugs... so there's still life in the theory yet! Fascinating stuff
-
Potentially, though I thought these machines could be set to discrete integer %ages between ~78% and 100%. This looks to be a much less granular 1-5 scale... it's something maybe interesting, but I don't know what! I'm not sure (from your above post) if Edward worked on Barcrest MPU4s so whatever code/logic/libraries etc could be significantly different between Barcrest MPU4s and other platforms/manufacturers. In terms of hacking runtime compensator values, I'd imagine it's very likely possible, though potentially a ball ache (to pinpoint values/routines)! So I guess you're saying, you'd want to take a Blue Moon (MPU4) or Indiana Jones (IMPACT) and then totally kill it with a big run of wins, but then hack some live values in RAM, and have it become 'ready' again, so you get more wins? It'd be doable, regrettably I'll have to decline the challenge, since when I get spare FME dev time, I need to work on Oasis really! But It would be doable I'm sure. There'll likely be a function with a calculation somewhere (unless it uses a 'blackboard' approach to perform the calc less frequently and refer to it, to avoid running the calculation too much, to avoid stutters/delays)... so that'd be what you'd want to hack. Edit: if you really wanted to go into this, one approach might be via 'pluggable' roms. I first learnt of these from @thealteredemu back in the day, I think it was early ROM revisions of a Monopoly machine. So the machines where they use the 'count up' alpha animation when you get a win, and the trick was to score a Jackpot, then plug it (or click it) while the win animation counted up. Machine would pay out on reboot due to battery backup, but it only processed the win from the overall running %age once the win anim had fully counted up. So, on one of those machine ROMs, you at least know, that the code/function call that ultimately adjusts the payout %age is called precisely at the end of that anim. So, you could use a debugger trace or something to try figure out what's going on during that phase of execution. It may be a standard function that adjusts the IN/OUT... or it could be that it calcs that revised %age to a blackboard. If I had to guess, I suppose I'd think it might be the IN/OUT adjust, then perhaps a blackboard refresh. And then for subsequent spins, I'd also expect the live value and/or blackboard to be adjusted. As presumably it doesn't go on money inserted, but money 'played'. So it might also take place at the start or end of each spin. Not sure if that helps, but that's some initial rum-fuelled thoughts lol Final edit : while this may sound pessimistic, if you found a way to do this on say a Barcrest MPU4, you'd probably then be able to search for that same code 'signature' on other Barcrest MPU4 ROMs. A lot of the code is simply copy/pasted between different games, for example the code that 'scrambles' the lights based on the Characteriser chip, it's just the exact same routine across a lot of the Barcrest MPU4 games (or variants of that code, again repeated). They weren't writing the machine's code for specific common functions (i.e: lamp scrambling, compensator or in/out tracking) from first principles for each new MPU4, and I'd imagine that extends to other manufacturers/platforms.
-
Well in this 1.0 ROM you have the almost 'standard' Barcrest message that I do like; NUDGE COCKUP Charmingly British! The other small block of strings that looks kinda interesting is; Which seems to hint at perhaps some engineer/test setting of 'generosity' that can go between: MEGA-GENEROUS (MEGA GEN) GENEROUS CENTRE MEAN MEGA-MEAN (MEGAMEAN) ...which appear to be 5 settings/live variables or states - perhaps related to the Nudges, perhaps related to a Playtest setting. There can sometimes be something simply in text that is 'secret' if you patiently go through the entire ROM
-
Sadly no, there generally isn't in these MPU4 ROMs (though I have seen it once or twice). I did a visual scan through the whole ROM, just the usual stuff; system messages/strings, alpha text, and the version you see on boot (SAG 1.0).
-
Not new coding dev, but man I swear the newer AI chat models are freakishly good! Just been brainstorming with ChatGPT-4o how to best tackle the future system for our Oasis online layout hosting/management - here's a snip from later in the convo where we're comparing Amazon S3 vs Backblaze: JP: Why did you recommend Backblaze over Amazon S3? ChatGPT: I recommended Backblaze B2 over Amazon S3 primarily because of cost-efficiency. Here's a detailed comparison to clarify why: 1. Pricing Backblaze B2 is one of the most affordable cloud storage services available: Storage: $0.005/GB per month, so 200GB would cost around $1/month. Download bandwidth: $0.01/GB, which would be about $1 per 100GB downloaded. Free uploads and free listing operations (like browsing your storage). Amazon S3, while widely used and feature-rich, has higher costs: Storage: $0.023/GB per month for standard storage, which makes 200GB cost about $4.60/month. Download bandwidth: $0.09/GB, which makes it roughly $9 per 100GB downloaded. Why Backblaze Wins: For 200GB of storage, Backblaze is significantly cheaper, costing $1/month compared to $4.60/month on Amazon S3, and its download bandwidth cost is far lower ($0.01 vs. $0.09 per GB). 2. Simplicity of Pricing Structure Backblaze B2 offers a more straightforward pricing model with fewer confusing tiers or added fees. You simply pay for storage and bandwidth. Amazon S3 has a more complex pricing model with different classes of storage (Standard, Infrequent Access, Glacier), which can make pricing less predictable and harder to manage for long-term projects, especially when download bandwidth is factored in. Why Backblaze Wins: If simplicity and predictability in cost management are important, Backblaze B2 makes things much easier to estimate. 3. Features & Usability Amazon S3 is known for its robust ecosystem and a broad array of features like versioning, replication, complex permission settings, and integrations with other AWS services. It’s incredibly powerful, but many of these features might be overkill for your use case. Backblaze B2, while more limited in some advanced features, offers the essentials for storing and serving large files. For hosting assets like PNGs, WAV files, and project data, it provides everything you need with an easy-to-use API, making it more lightweight and less overwhelming than AWS. Why Backblaze Wins: If you don’t need advanced cloud infrastructure features (e.g., machine learning integration, automated scaling, etc.), Backblaze provides a simpler experience, and for your project, it seems sufficient. 4. Performance and Reliability Amazon S3: It has a global network of data centers, meaning it offers better performance and redundancy for global users, with high uptime and excellent reliability. Backblaze B2: While Backblaze operates fewer data centers (mainly in the U.S.), its reliability and performance are generally strong, especially for non-critical, large-scale storage needs like your project. For an open-source project focused on collaboration, Backblaze should offer enough reliability unless your contributors are highly distributed globally and need faster, low-latency access. Why Backblaze Still Wins for You: Given the open-source nature of your project, where occasional latency may be acceptable, Backblaze provides reliable enough storage without the added cost of Amazon’s global performance features. Conclusion: Backblaze B2 is a far more cost-effective solution for your specific use case of hosting 200GB of data-heavy files (PNGs, WAVs, TTFs, etc.). It delivers simpler pricing and an adequate feature set without the complexities and higher cost of Amazon S3. Amazon S3 is more suited for projects that require advanced cloud services, distributed global access, or heavy integration with other cloud-based systems, which doesn’t seem necessary for your layout editor project. Given that you're focused on hosting large assets for a public project and keeping costs low, Backblaze B2 seems like the better fit. Let me know if you'd like more details on how to set it up!
-
Nice I just got my 4 year badge about a week ago!
-
I have just confirmed this on the 1.0 ROM, very satisfying! Along with nudges going into the permanent piggy bank rather than the 1 credit 'temporary hold' of the later ROMs, you can keep getting/retrying £3 opportunities with a high/full nudge bank until it gives you the 'GRAB'. I do really like this machine, it's a classic
-
Based on the filenames and dates, the ROMs in the layout appear to be the ones in the archive (time difference of exactly one hour)