Why do Blitz staff never reply?
BlitzMax Forums/BlitzMax Beginners Area/Why do Blitz staff never reply?
| ||
| Several times now I've desperately wanted to learn BlitzMax inside out with the intention of writing a BlitzMax manual/game dev book, but the questions I write to the Blitz developers always go ignored. The help for BlitzMax is woeful, I mean...Superstrict? What the hell does it do? The manual says, "Sets superstrict mode"! Thats great isn't it? So I write to blitz and ask for some insight but again the email goes ignored. I wouldn't mind but the lack of documentation is killing their product, I would love to write a manual for it but they seem to have no interest. Things like error messages too, it would actually help if they made any sense or had an explanation. BlitzMax is a great, great language but you get a real feeling of abandonment using it. Why won't they help me? |
| ||
| So far I didn't have any problems with one exceptions which mainly happened because a tag added when talking to sales part first caused the automatic sorting to make it take longer than it would have without it. |
| ||
| Superstrict means you aren't allowed to mess around and fubar your code. You'll need to declare your stuff with military precision. So, no bla=CreateTimer(3) but bla:TTimer=CreateTimer(3) etc. Superstrict also requires your to whistle the national anthem while eating a banana. I always have superstrict on.. :P |
| ||
| Why won't they help me? If they haven't found the time to write better documentation for everyone, they're probably not going to do so in email where it will benefit only one person. Instead of sending emails, ask your questions in the forums provided where one of many experienced BMax users will be able to help. It may not be your idea of perfect, but you will get answers. In answer to your ( somewhat unasked ) question about SuperStrict, it's the same as Strict except that you have to explicitly declare variable types for your variables as well. Strict means that you cannot use a variable without declaring it. Variables are not automatically created when they are first used. But you probably already know the latter, as Strict is properly documented. |
| ||
| I wouldn't mind but the lack of documentation is killing their product, I would love to write a manual for it but they seem to have no interest. It's their product, so they're entitled to kill it any way they chose. You are not entitled to write a manual for it, nor are you entitled to e-mail support. In either case Blitz3D was released in 2001 and we only recently got a manual. By my reckoning we'll have what you consider decent documentation for BlitzMAX by 2010 in a best case scenario. Things like error messages too, it would actually help if they made any sense No offense, but if you don't understand what the error messages mean, you're probably not the best suited person in the world to write documentation. Why won't they help me? It's not their job? So, no bla=CreateTimer(3) but bla:TTimer=CreateTimer(3) etc. Actually you forgot about scope declaration so it's Local bla:TTimer=CreateTimer(3) :o> |
| ||
| The BlitzMax docs do stink, but really you can't expect to get email support every time you have a query about a Blitz command... not at these prices! : ) If you want to learn Max inside-out, use the docs and these forums when you have a query...come on you have only made 6 posts. How many e-mails have you sent to support?! The syntax errors I get are pretty straightforward. What errors are you getting that are not making sense? |
| ||
| In either case Blitz3D was released in 2001 and we only recently got a manual. Not strictly true....  |
| ||
| Yup, Blitz3D has shipped with a manual since shortly after day 1. It was download-only at first. You might wanna blank off your BUID in that image, Rik. ;) |
| ||
| Not strictly true.... Just because something has the letters "MANUAL" printed on the front does not mean it's a manual. Yours doesn't look to have been opened much more than mine. Which would be never. In either case, I could have sworn I qualified it with "decent" and/or "useful" in that earlier post. Must be getting old. |
| ||
| Lets face the truth: At least B3D docs and BM docs are somewhere up to date. They might not be the best, especially out of the professional programmer view. But in the end we get what we pay for and at 60-80$ you definitely do not pay for a technical writer who does documentations I fear. (yeah I know there are exceptions but to be fair: lets see how BM docs will be 4-6 years after release ;-) ) |
| ||
| They might not be the best, especially out of the professional programmer view. Name one (non-OpenSource) program that ships with decent documentation. In my experience there are two types of software documentation. Little to none (Windows), or ridiculously much (ABB 800xA for instance ships with over 2000 A4 pages of main documentation and an unknown amount of supplemental or reference material). |
| ||
| I hope BRL will forgive, but compared to PureBasic docs, BRL docs look like pre alpha docs meant for internal tester with quite some experience and 6th sense. But PB is an exception in many ways after all. But thats the only exception I've come over in programming. (engine / creation environment wise I would have to point out TGB as a shiny example of how documentations targeted at indies and design kind of users should look like) |
| ||
| ...or ridiculously much... Yeah... StreamServe documentation takes up a whole cupboard here. I think Informix found a good balance, with 3 programming reference books, and 2 for the database admin. I'm sure the BlitzMax documentation will improve over time. I for one was happy to help with the Wiki which was slowly working up to something useful. |
| ||
| While I appreciate these forums as much as the next guy. I must agree however that the documentation for BM just isn't good enough. The IDE contain documentation for some of the commands, but as far as I can see not all of them. Claiming that B.R. "Don't have to do anything" is fair enough, but for B.R.'s sake I hope the value their customers a little higher. BM is (in my view) a great language, but the lack of proper documentation (either included or to buy) is holding it back. Even the original BlitzBasic on the Amiga had a proper printed manual listing every command with a simple example of usage. |
| ||
| That's strange, my post has disappeared. Anyway, thanks for the advice. I will crack on with my manual/reference guide anyway. Nick: I bought BB2 on the Amiga too purely for the manual, and it was great, like you say *every* command had an example and it was a massive help. I am doing the same on mine. I just love BlitzMax! |
| ||
| BRL is a small team, I dont think they have the time of man power to write a really good user manual. But then again, there is a free workforce of people in the community more than willing I would imagine to help them out. BRL, setup a wiki manual page for BM, then let us add our examples and descriptions, it would not take long for it to fill out. All you would then need to do is put a disclaimer on the docs and shove them into the next update, saying that the docs are community supplied and may not be tested etc... |
| ||
| Yavin, that's a good idea - but there already seems to be a Wiki for BlitzMax (see http://www.blitzwiki.org/index.php/Main_Page) although I've never seen it running. Does anybody here know when it will become operational? By the way: I never had problems with people from BRL responding to posts in this forum - they may have trouble with their email (mail may get lost, or classified as SPAM) but they are active forum members. And (being a software developer myself) I know well, how much man power it takes to respond to people's requests individually! |
| ||
| Writing a manual is an art on its own, here're some things that can go wrong: * if you let 20 ppl write pieces of a manual you get 20 different writing and example styles. For a beginner a consistent style is important. * examples are often incomplete or only give a single solution. The best example is polling vs events. I think one should use events, it's how the OS works, and it's so very convenient (and not harder to learn than polling I'd say). Yet, a lot of examples use a polling technique. While I'm not saying to drop polling-based examples, event-based examples should be included as well. * examples might be huge and bloated. Freedom from choice is what a beginner wants, if there are 10 new things in an example source, how do you want the beginner to identify the single new thing the example was meant for? The best example is one that's as small as possible, but not smaller. It should focus purely on the command for which it was written * examples are often explained in context of a game, they should rather be explained more generic, or at least also with a GUI/application mindset. In addition, it might be a good idea to include design patterns into the manual and generic programming guidelines. Yes, design patterns are explained on normal wiki, but those examples are not really aimed at Blitz or beginners. I actually don't know whether all those examples actually work in BMax. |
| ||
| I agree that making a good/great manual is probably a fairly large task. However, as of the moment I've been made aware of some of the commands in BlitzMax purely by chance. I've been reading through the Blitz 3D manuals and tried my luck with some of these commands but not always succesfully. Just yesterday I discovered the ImagesColide2 purely by chance... A simple alphabetic-list of available commands and their syntax would be a great starting point, just to get some idea of the possibilities... |
| ||
| A simple alphabetic-list of available commands Do you mean other than the command index or something printed? I could have done with better documentation and ranted constantly about it. After a while (rightly or wrongly) it becomes less of a hassle. Couple of suggestions. Get Assari's .chm for searchable command lists. Get HotDocs... well worth it. |
| ||
| I think if you are going to write a manual it should be that you are sharing information that you have discovered yourself through your expertise, otherwise you are merely acting as a freelance manual-writer for BRL which they are not interested in. |
| ||
| Interested or not thought does not prevent anyone from writting a reference book / booklet, right? :) |
   |