Messages

1

Ask a Question / Re: HTML5

« on: September 27, 2011, 08:46:13 am »

I mean , if there is an update , that will affect the development of the game, should we create a new file and work everything from scratch?

As I understand it, if you do not use any platform-specific things (that is, code blocks), your game is written in "Stencyl block language" and as thus is exportable to new platforms with a single click. Even now it is always exported to SWF when run / uploaded / etc. But people that are more inside may correct me.

2

Ask a Question / Re: HTML5

« on: September 27, 2011, 08:19:10 am »

Is there any rough ETA?

3

Ask a Question / HTML5

« on: September 27, 2011, 06:59:32 am »

Is HTML5 & Co. considered among the target platforms? I have searched the forums, viewed the roadmap but I am not much more informed than if I didn't. Thanx.

4

Completed / Re: visit URL block for POST

« on: September 21, 2011, 01:15:21 am »

I'll see if we can fit it into StencylWorks 1.2.

Ok. I'll just mention the (blueprint of) the solution without needing to make the code generator context-dependent (it seems to me the generator always generates each block by itself, without checking nearby context):

Code: [Select]

// this is generated in place of visit URL block, with slightly changed visitURL to return the context
var _$visitURLContext = visitURL(....);
// this is generated in place of "when failed" block
(function (ctx) {
  var callback = function(type, eventOrError) {
    ...
  };
  if (ctx.error) {
    callback("Error", ctx.error);
    return;
  }
  ctx.loader.addEventListener(IOErrorEvent.IO_ERROR, (function(event:Event):void {
    callback(IOErrorEvent.IO_ERROR, event);
  }));
  ctx.loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, (function(event:Event):void {
    callback(SecurityErrorEvent.SECURITY_ERROR, event);
  }));
})($_visitURLContext);


5

Completed / Re: visit URL block for POST

« on: September 20, 2011, 05:24:12 am »

Sorry for BUMP, but it seems as if this has slipped attention. Thanx for the answer.

6

Shared Resources / Re: JSON manipulation pack

« on: September 09, 2011, 06:46:24 am »

OK. Clever, but aren't you worried that it will break when they "change things"

It will. Hopefully there will be an option to include external libraries in normal way, so true JSON could be there by then... blocks will work with any of them, and the code was just a workaround to be tossed away when real solution comes.

7

Shared Resources / Re: JSON manipulation pack

« on: September 09, 2011, 05:37:18 am »

Dirty tricks. JSON from this pack is not the usual as3corlib JSON, it's the merge of as3corlib version with Stencyl code block public class. Read first three posts in this thread and look into the JSON code block to find the details.

(not that I am proud of the dirty tricks, but Stencyl itself is restrictive, and any restrictions are only good for making people angry and forcing them to devise workarounds :-) )

8

Shared Resources / Re: JSON manipulation pack

« on: September 09, 2011, 02:11:37 am »

Uploaded again.

Use global custom block.

9

Shared Resources / Re: JSON manipulation pack

« on: September 08, 2011, 06:30:33 am »

There is a new version uploaded, with two enumerators, one simpler, one more complex.

10

Completed / Re: visit URL block for POST

« on: September 08, 2011, 05:48:08 am »

I've just updated to 1.1. Thanks for the POST block.

But there is one more thing which I see at least as important for web blocks to be usable, and it is the error handling. Yes, I can use timeouts, but it is strange - I can get them too small and the page gets loaded anyway or too long which will delay unnecessarily, not to say it is hard to make it bulletproof.

Would you consider a stackable (like else is to if) "on communication failure" block (which will contain the error handler) for get and post web blocks?

11

Shared Resources / Re: JSON manipulation pack

« on: September 08, 2011, 05:31:44 am »

The pack doesn't appear to have a block to easily do that, but it would be a nice suggestion.

Yes. Iterator is nice suggestion.

The problem is lack of object ("struct" object, I'm not talking about classes with methods for now, just plain data holders) manipulation in Stencyl. No structures (beyond lists). This complicates using nested JSON structures, too. If above-mentioned thing was there, JSON code would only need one decode and one encode... the existing JSON manipulation pack does both - encodes and decodes, but as well lets you to somehow navigate the structure as well... the latter is not entirely its responsibilty, but it must do it when there is no way to read (at least) "struct" objects directly in Stencyl (write, too, of course).

12

Shared Resources / Re: JSON manipulation pack

« on: September 08, 2011, 05:23:49 am »

for example, how would I parse:


{
   "glossary": {
        "title": "example glossary",
      "GlossDiv": {
            "title": "S",
         "GlossList": {
                "GlossEntry": {
                    "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                        "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
                    },
               "GlossSee": "markup"
                }
            }
        }
    }
}

This was a quick implementation for simple structures. You can use "as json" trick to get more that two levels deep:

set glossdiv to ((json source at glossary / GlossDiv) as json)
set glossentry to ((json glossdiv at GlossList / GlossEntry) as json)

... etc.

13

Shared Resources / Re: JSON manipulation pack

« on: September 08, 2011, 05:17:36 am »

It might also be possible for JSON data to use the same identifier multiple times, and I'm not sure what the Stencyl code would do with { "ip":"1.1.1.2", "ip":"1.1.1.3"} when looking for "ip"

I'm not sure it is possible do use multiple identifiers... anyway, JSON code just reuses existing AS3 JSON implementation, so the Stencyl blocks do what as3corlib implementation does.

14

Shared Resources / Re: Multiplayer made possible

« on: July 05, 2011, 08:23:10 am »

You rock, dude! I just gotta figure out how I can use this...

Read the whole thread, there are some answers already.

15

Shared Resources / Re: Multiplayer made possible

« on: July 04, 2011, 02:47:19 am »

1) Develop Stencyl specific multiplayer functionality
Pro: No license fees to other companies, tailored for Stencyl strengths
Con: Unending development, poor functionality compared to commercial systems
2) Commercial Extensions
Pro: Robust multiplayer, shorter development time
Con: User fees (maybe Stencyl could negotiate a user discount?)

The best of both worlds would probably be to use a mature opensource multiplayer system like Red5. But Stencyl users would still need a host.

Maybe we should have a poll asking users who needs multiplayer, what features they need (ie number of total users, simultaneous connections) and how much they are willing to pay for it. Then Stencyl devs would have a better idea to pursue home grown vs. commercial extensions.

And again, great work! 

As I stated with previous post, I want to communicate with anything. Not just another flash game. So I want thing Stencyl agnostic, and also Flash agnostic. Lightweight and standard is the utmost concern to me. That's why XMLStream, AMF etc. are out of the way (it is not hard to write XMLStream analogy of the nginx+http_push_module, in node.js for example). My aim is to have flash client for ... virtually anything I want to.
With this solution, I can communicate with anything. I can even communicate with plain bash scripts. It is just the matter of a curl and some options.

So I would definitely vote for homegrown based on standardised communication paths (http(s)) (or existing one based on such paths, if it exists). But I fear the majority would rather adopt specialized solution.

And thanks.