Oh, I did forget a step: after you've set the position of the Cursor, set the Mouse.PrevX/Y to Mouse.X/Y

Try teleporting the cursor.

Don't post again without a CapX.

https://chilly-durango.itch.io/level-ge ... ucing-evie

It doesn't explain why - but I guess why not? <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> Her name is Evie - she can write music, poems, novels, dialog, make up location or character names - you name it.

But she's also such a fat cow she won't fit through the usual download channels...

You can simulate this by simulating a cursor, the result therefore only working within the game and circumventing the above security issue.

Add a Cursor sprite.

Have variables which track the X and Y of the Mouse. Call them MousePrevX & MousePrevY.

Every tick:

-> Set Cursor X to Self.X + ( Mouse.X - MousePrevX )

-> Set Cursor Y to Self.Y + ( Mouse.Y - MousePrevY )

Don't forget to use the Cursor's position rather than the Mouse's when judging things like what's being clicked on etc. Good luck!

I'm working on a Markov chain generator that handles quite large amounts of data. Once the JSONs get larger than 1MB, I can't get them to download using the [Dictionary>Download] action. [Browser>String download] option produces the same result: 'Download failed: server error.'.

Any suggestions?

All you need to do is have your code specify a specific instance. Usually the best option is using the 'Pick nearest' condition

You can make something a little like Trials Fusion, which has very similar controls and mechanics to ExciteBike. This is a fantastic tutorial I've followed in the past:

https://www.scirra.com/tutorials/240/physical-bike

Toolkit: https://chilly-durango.itch.io/level-generator-toolkit

Sample output: https://imgur.com/a/IRKBQ

[quote:33fqt4q6]The Level Generator Toolkit comprises of a bucket of functions (currently 23, including a few diagnostic functions) which can be used to create all kinds of procedurally-generated environments. The Toolkit is designed to help developers understand the contextual potential of all sorts of different algorithms and processes.

Any questions, I'd be happy to answer. I love discussing this project, and procgen in general <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

These are referred to as 'prefabs'. They're used a lot in roguelikes, and the community over at reddit.com/r/roguelikedev recently had a Q&A on this very subject, it's well worth a read here ( https://www.reddit.com/r/roguelikedev/c ... p_prefabs/ )

Your shopping list should be:

1. A way of writing prefabs to storage

It depends on how you want to build your world. If you can use tiles to build your world, brilliant - you can use a multi-line string to represent your prefabs. If not, you're in for a rockier ride which will likely involve writing a basic level-editor to save the correct metadata for you.

2. Storage device for holding your prefabs in your project

Again, assuming a tile-based world, I would use an array for this. Fill the array with a different prefab on each Z-index from (1).

3. A way of stitching them together into rooms

In its simplest form, this would probably look a lot like Primm's maze generating algorithm. ( https://en.wikipedia.org/wiki/Maze_generation_algorithm ) Essentially you start from a given point, and continue adding prefabs into vacant spaces in the world until it's large enough for you. As you go, connect each new prefab to an existing prefab placed before it. Et voila.

I am aware this is a vast over-simplification, but a full explanation would be... lengthy. Good luck!

I would say it's easier than people think - but only once you've gotten your head around arrays! You might find one of my templates useful, or for inspiration you can try this demo I released on Scirra Arcade recently:

https://www.scirra.com/arcade/other-gam ... lkit-16330

It's a bit broken, as you can't easily use multi-line displays on the Arcade - however, you can paste into the input panel on the left from your notepad of choice.

That would be a Proof-of-Concept at best.

Personally, I think that a proof of concept is absolutely enough. We know, as HTML5 devs, how quickly you can iterate, how easily you can bug-stomp and test new features, and open up your work to new platforms. Scirra are now working with the same advantage we've always had. I don't think it will be long before we see all of C2's features carried across to C3, and more.

I also think that what's 'enough' for the team to produce is entirely up to them. It's up to us as consumers to vote with our wallets, and produce useful feedback where we can.

But we are testing pretty much C2 on browser.

That is expressly what we are testing, yes. Read Isn't that really enough, for now?

On launch, C2 didn't include an image editor, a physics engine, tilemapping, social media integration, complex collision polygons, multiplayer, not even half the exporters or publishing plugins, web-font support, lighting, positioned audio, LOS, debugger or profiler... the list goes on. I know a lot of these things are missing from C3 at present - but this team is no slouch! Have a little faith.