Can't do file I/O in monkey.

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|718\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> On Topic -> Can't do file I/O in monkey.
Sun, 17 Nov 2013, 06:46
steve_ancell	What am I doing wrong? \|!!ARGH\| and why the Nat-King-Cole didn\'t BRL include comprehensive code examples with monkey? \|ARGH!!\|, I keep getting the message \"Identifier \'FileStream\' not found\". Strict Import mojo Import brl Class MyApp Extends App Method OnCreate:Int() SetUpdateRate 60 Local file:= FileStream.Open(\"file_test\", \"u\") For Local i:Int = 0 To 9 file.WriteInt(i) Next file.Close Return 0 End Method OnUpdate:Int() Return 0 End Method OnRender:Int() Local file:= FileStream.Open(\"file_test\", \"r\") While Not file.Eof() Print(file.ReadInt()) Wend file.Close SetAlpha(1.00) DrawText(\"AAA\", 0, 0) Return 0 End End Function Main:Int() New MyApp Return 0 End --v
Sun, 17 Nov 2013, 06:50
steve_ancell	Those backslashes in my filepaths are not really there, that stuff was magically added when I submitted my post.
Sun, 17 Nov 2013, 06:56
Jayenkai	Indeed, they're everywhere.. Hmm.. Will look into the code. As far as file-access is concerned, I've personally tried to stay clear of it until Mark's locked everything down permanently. Last I checked, he was still messing about with it. -=-=- ''Load, Next List!''
Sun, 17 Nov 2013, 06:57
steve_ancell	And I promise that the DrawText("AAA", 0, 0) bit is not one of my excentric insanity moments, it was just me evaluating the make sureness that I can use that command for future reference.
Sun, 17 Nov 2013, 06:59
steve_ancell	Jayenkai As far as file-access is concerned, I've personally tried to stay clear of it until Mark's locked everything down permanently. Last I checked, he was still messing about with it. Phew!... I thought it was just me having a brainfart for a moment there.
Sun, 17 Nov 2013, 07:01
steve_ancell	Thing that puzzles me, how are other developers loading their levels and stuff if the file fuctions are on the blink?.
Sun, 17 Nov 2013, 07:09
Jayenkai	Most dev's seem to be using Monkey to code for one or two specific targets. People seem content with the "Well, it works on GLFW!" setup, and will happily ignore the fact that it can be quirky elsewhere. I'm not. If it isn't going to work on ALL targets, then I tend to stay clear of it. The only thing I've done that is Target Specific is iOS's GameCenter stuff, but even that simply wraps around all my other standard stuff. I don't even have to touch it, it just sort of does it's job. If you're going to do a specific target, keep fiddling and I'm sure the file stuff will come together, but if you intend to get your game running on multiple targets, I wouldn't recommend it until Mark's got everything down to a T. Or rather, if you DO, be sure you've got ample fall-back code, just incase it buggers up. I'm currently using two methods. Method 1. Compress the data as small as you can get it, and cram it into a big "Select : Case : Return" thing. Method 2. Pseudo-Random Generated Data FTW!! -=-=- ''Load, Next List!''
Sun, 17 Nov 2013, 07:13
steve_ancell	I was planning on monkeyfying Mutant Monty so that I can stick it on Android for mobile and on HTML5 so that I can shove it on facebook, hence the need for file functions.
Sun, 17 Nov 2013, 07:21
Jayenkai	You shouldn't need file functions, just shrinkify everything down to a nice small amount of data. Grab all the data you have, and try to replot it into a smaller, more neatly packaged form. IIRC, you currently have the screen layout, then the list of enemies, and their paths and things. Consider redoing it with the enemy types stored as single ascii characters, and placing them directly in amongst the level data. If you can cram it nice and neatly, you should be able to get each screen down to a single ascii string. -=-=- ''Load, Next List!''
Sun, 17 Nov 2013, 08:27
steve_ancell	Do you mean like "hard-code" it into the source code?, yeah!, that makes sense. I just got some info on the monkey site, I was told to use Import brl.filestream. It seems to be working on the GLFW target but I really need to target HTML5 also, so I guess that your advice would be the right path to take.
Tue, 19 Nov 2013, 02:56
caffeinekid	It's annoying that Monkey doesn't (as far as I can tell) have DATA and READ commands(??) -=-=- www.tcksoft.co.uk www.retroremakes.com
Tue, 19 Nov 2013, 03:23
rockford	It does seem strange nowadays not to have those. GLBasic didn't have them either for a long while, but at least it did have good I/O commands for loading and saving data into/from arrays.
Tue, 19 Nov 2013, 03:23
Jayenkai	Building my framework was a good learning experience. Having to do everything myself, instead of grabbing off the shelf, ready made functions and libraries, meant that I learned a whole lot of do's and don't's along the way. My final framework is available online, and works lovely, but you'll miss out on figuring a lot of things out yourself. IMO : Ignore all frameworks, and DEFINITELY ignore everyone on the Monkey forum, desperately trying to tell you to use their library for this, and another library for that. Monkey is "As feature complete as it needs to be". It has the ability to load pictures and sounds, do controller input, and then feed those back to the user. It's a language, not an engine, and as far as languages go, it's pretty much exactly what you need. OnRender is Drawing OnUpdate is Logic OnUpdate, do the game, and inside a big stack/array/list/whatever, feed your drawing instructions into there, then OnRender blast through the list and plop it all onto the screen. During that, scale everything so it fits onto the current display. From there, try fiddling with different asset resolutions, then work on controllers and menus and other bits and pieces. It sounds like a lot, but really it isn't. It just takes a little bit of time to get into the swing of things. For what it's worth, I don't use "WebMonkey", "Diddy", "Autoscaler", or.. Anything.. All I use is Monkey and My Framework. And because I built it all, the second something goes wrong, I'm about 99% sure exactly what and why, and can generally fix it in a jiffy. It's more about understanding the core of what you're using, and if you're grabbing oodles of off the shelf components, you can never truly be sure which bit's broken! -=-=- ''Load, Next List!''
Tue, 19 Nov 2013, 03:47
rockford	It's a language I've never seen (up until GLB) a language that doesn't at least have READ and DATA storage commands. Even Speccy BASIC has that. It might be feature complete in that it can spit out stuff, but that doesn't mean that it's "complete" in any sense of the word. User functions can indeed make it more complete but that doesn't necessarily make it easier for the end user to start with. monkey was aimed at Blitz users - and Blitz users are/were used to having certain things within the language as standard, which aren't in monkey. I haven't had a really long play with monkey (due to one thing or another I haven't had the time), but when I grabbed the demo, I was shocked how different everything was and how lacking it appeared (and how little documentation there was for it). But I could still see massive potential. However, I agree that it is up to the user to add required functionality to the language so that, like your framework, they can tinker and tailor it to their own design. The problem comes though with potential updates that incorporate new features or make existing ones non-functional. But, if you know the language (and your additions), you should be able to quickly and easily fix any problems. To this day I have a sets of functions that I use with GLB (and used with Blitz too), even though GLB now has similar functions. It never used to and I believe mine are both easier to use, more adaptive, has more control and are faster.
Tue, 19 Nov 2013, 06:19
caffeinekid	You must admit Jay, you have had problems with level data that comes from the limitations and differing machines/platforms too. Is READ, DATA and RESTORE too old fashion and BASIC now? I guess I'm going to have a big 100 entry long select/case for level data which is annoying -=-=- www.tcksoft.co.uk www.retroremakes.com
Tue, 19 Nov 2013, 07:03
Jayenkai	Oh, I'll admit that, definitely. In fact, I'm still rather pissed off about the fact that certain Android devices give incorrect pixel data when doing ReadPixels. That completely fucked up my idea of using .pngs for level storage... and music!! But because it was MY code, I was immediately able to go "Oh, well that's knackered, then!" and scrap it for something else. If it were a "Image Data Library", I might've spent a good few weeks battling with it, asking on the forum, and getting sarcastic answers like "Well it works on mine!!" and "Do you even know how to code!??!" before other people eventually came to the same conclusion that "Oh, it doesn't actually work.. huh!" sigh Learn the limits, and work around them instead of desperately attempting to get something working that ultimately doesn't. And aim for multiple targets, even if you're not going to use them. You never know when you might change your mind, and if that requires you to rewrite half the code, you've kinda missed the whole point of using Monkey!! -=-=- ''Load, Next List!''
Tue, 19 Nov 2013, 09:46
rockford	In fact, I'm still rather pissed off about the fact that certain Android devices give incorrect pixel data when doing ReadPixels. It's not just Android devices that do that - you'll sometimes get different values from pcs due to graphic card differences too. "Well it works on mine!!" The most helpful response EVAH!