cow_trix

Apologies for bringing this old thread up, but I can't figure the plugin out.

It takes three parameters, Seed/Min/Max.

If I set a seed and a Min/Max range, it should produce a persistent number for that seed, shouldn't it?

It doesn't, however. It produces random numbers within the range. Doesn't this defeat the point? My interest is in persistent seeded world generation.

Also, if I set min 10 and Max 100, it doesn't give me numbers from 10-99 (isn't that what the range is about?)

What am I missing? (running C2 r132)

Is there a new way to do this since then?

Is it best to use scirra.com/forum/plugin-seedrandom_topic60194.html ?

Oh thank you DW, I just saw this.

I will definitely use loops instead of deep recursion. This was an exercise for a procedurally generated graphics project. I just wanted to understand recursion.

thank you ashley

Link to .capx file (required!):

dl.dropboxusercontent.com/u/28087823/Construct%20Examples/recursionBug/recursionbug.capx

It's a simple test of recursion, it ought to calculate the sum of all integers up to the value I put into the function call parameter0

Steps to reproduce:

1. run the layout

2. press the calculate button

3.

Observed result:

About half the times, for values over 40 in the function call, it gives me this message:

*Javascript error!

too much recursion

localhost/Function_plugin.js, line 192 (col undefined)

This is either a bug in Construct 2 or a problem in a third party plugin or behavior - please report it to the developer"

If I press the "calculate" button again, it DOES provide the correct calculation

Expected result:

It should provide the correct calculation without first giving me an error message.

Browsers affected:

Chrome: yes ( for values over 1000 )

Firefox: yes (for values over 40)

Internet Explorer: ?

Operating system & service pack:

windows 7

Construct 2 version:

128.2 (32bit)

newt That's so clever! You can paste *into* canvas!! I finally understand the whole thing.

Thank you so much for the .capx, it's super illuminating

7Soul R0J0hound

Thank you!

How do I take a snapshot of a *portion* of the screen?

And how do I replace the background gray with transparent?

I saw somewhere on the forums a plugin that added text to a sprite.

Is it possible to do the following?

<img src="https://dl.dropboxusercontent.com/u/28087823/Construct%20Examples/AddToSprite/test.png" border="0" />

1. Start with a simple sprite

2. make Z number of duplicates with a small X,Y offset in one direction (creating "depth")

3. take a snapshot of the bunch of sprites, converting the snapshot into a new sprite, and delete all the original overlapping sprites.

I thought it would be doable through the system->"snapshot" command, but I'm missing the following functionality:

1. at runtime, crop the sprite containing the snapshot, to specific coordinates

2. replace the background color of a sprite with transparent color

Hmm thanks to some very clever code by R0J0hound, I managed to solve one problem.

Here is the .capx

I now have a spawner sprite that spawns rooms and connects them using a door.

All rooms from 1-4 are KeyLevel 0, which means they can be traversed freely, without a Key.

In order to go to Room#5 (Rooms 5-10 are designated KeyLevel 1) and beyond, you need Key#1, which will be generated in one of the first 4 rooms.

You can mouseover on rooms to see which KeyLevel they are designated to.

I've been reading up on procedural Zelda-like puzzle generation (i.e the Binding of Isaac) and I found this:

bytten.net/devlog//2012/11/30/lock-and-key-puzzle-generation

I'm probably mathematically challenged, but I can't think of a simple way to implement this logic in Construct2, in order to make the graph/map

Can anyone point me to a direction towards implementing nodes and edges?

Arrays? Bitwise tile generation?

Ashley Tarsul As I understand it, the collision algorithm is pixel-perfect (and even sub-pixel perfect as I understand) and absolutely brilliant, you can make a pixel-quantized and pixel-precise engine with it with relative ease (check out my .capx above, you can use it if you like).

The built in platform movement still uses the pixel-perfect collision algorithm for its collision detection, but handles the result of the collision in a non pixel-quantized, non-pixel-perfect way. The visual outcome is that very small pixelart appears to either float or sink.

As Ashley suggests, you *may* be content to just set the bounding box for your sprite half a pixel inward (check out previous photo on this thread).

Also, for larger sprites, the problem is not noticeable at all.

The built-in platform movement has this huge advantage that it is great for prototyping. If you need more control, you can just make your own engine.

zenox98 & Ashley No no, I don't think it's shameful to discourage convoluted custom engines. I understand it, why create confusion and potential buggy behavior?

But on the other hand, I have been testing and comparing the built-in engine to my own custom engine, and I can't get the former to do what I want it to do, so I don't see any compelling argument against using the latter. It's consistent, bug-free, doesn't require fiddly bounding boxes, the logic behind the code is sound and its been fairly rigorously tested. I won't hesitate in building my game with it.

ASHLEY. No this will not do. Ok, I will refrain from posting this anywhere else, thank you.