[quote:3eohtosu]- Sorted Z order depending on Y position

I would like to request Z sorting based upon a variable, not just Y position.

Perhaps you mean "Sort by value"

So you could perhaps say "Sort Z by ".X", descending" (of course, descending/ascending would basically mean higher value means lower Z-order or higher order).

Oh of course the math would work better/faster than defining the collision by the sprite. It would also allow you to vary the amount of damage based on distance, among other things.

The explosion in Physbox Reversion uses this method.

If it overlaps the explosion sprite, then it gets the distance between the sprites center and the objects center and uses that distance to calculate force applied and damage. On top of that the explosion has a private variable, 'force' which is defined on creation (force is 4 from the explosive barrels) which also factors into both of these calculations. A force of 1200 in an explosion right on a barrel dealt around 2 million damage and blew the gibs so far out that it crashed several seconds later.

We don't hate people for showing if something's wrong with Construct - that's what beta is for, to find possible problems and try to fix them.

I for one would be interested in seeing said .cap, for insight on what others think is the 'wrong' way to combine events.

That would look awesome if we could actually make it use 3D boxes.

Haha! Victory is mine!

I have successfully made a loop that writes 1024 zeroes followed by 5120 3's followed by 1024 1's, all separated with commas. This is read from the array, so all that remains to do is cut off the bottom z-level that you can't access and we get 5120 3's (representing the 5 z-levels of walls below ground level) followed by the 1's (grass/open ground) then lots and lots of zeroes (the sky )

Anyway it is all read from the array. All that remains now is to make it not change areas until the loop is done (which for me takes about 80 seconds ) and make the loop to load areas and we have a functional save/load system. Albeit a slow one, it still works and only takes about 100kb of space or something like that.

It's kind of funny how the Array save function writes almost a megabyte in less than a second but this writes a tenth of the data in one and a third minutes. I'll look into that more later, right now it's time to sleep.

In fact perhaps a halving of the z-space is in order. That will theoretically cut the loop down to 30-40 seconds (still far too slow). And also half the filesize.

Uhh... okay. Well, I made area save/load work fine. That was the easy part.

I was thinking of making a looping 64x64 grid of areas. I did that, then I checked the filesize of an area save.

One area is 772kb.

So, that makes a total 3088mb if you go to every single area.

Hell, even a 16x16 grid makes 193mb of space.

So I guess making out that you're on a small planetoid is kind of gonna take a lot of space, huh.

Well anyway the good news is that it works, the better news is that it makes the areas as you step into them (and saves them when you leave), so anywhere you haven't been won't be saved.

I'm going to work on this system a bit more (I could maybe make a custom save/load function that just reads data from a string (like 1,1,1,3,2,2,2,3,0,0,0,3,2,2,2,etc. parsing that into the array with a loop).

The question is, will that use less space than the array save/load function? If it does (I plan to do it anyway because I'm pretty sure it will) I'll implement it properly and then we can all rejoice in the possibility of a looping grid of stacks of grids.

I haven't updated it yet though. I'm going to get a version of that parsing system done before I do.

I have an E-MU 1820 soundcard, highly recommend it

My new motherboard has onboard 7.1, I don't think I'll need a soundcard soon.

Do you also love Dwarf Fortress? This is cool.

I had to delete my Dwarf Fortress saves last week. My folder was over 400mb because of all the saves

Updated .cap download and added .exe download (here).

Changes:

[Fixed] Stairs not able to be half removed to create half functional sets

[Fixed] Walls overwriting non-space tiles on level above

[Fixed] Walls in starting terrain generation loop work correctly now (sometimes the floor-on-wall loop stopped at row 4, fixed)

[Added] Z-levels now kind of display the level below, including player (sort of odd, needs some fixing up)

[Added] Dynamic stairs. Basically they respond to stairs above or below them and change animation correctly. Also eliminates another bug with stairs (jumping over z-levels when moving between a two-way and non-two-way set) that arrived with two-way stairs, as stairs are now one terrain type with multiple animations.

[Added] Z: Jump! Something you never see in roguelikes (it's distinctly unroguelike, I know, but I thought it could be fun)

[Added] Player falls down empty space tiles

[Added] About 34mb more RAM usage (I dunno, it just jumped up from 23mb to 57mb usage last time I ran it and it seems to stay about there - please report on this)

[Added] Clear: Clears current z-level selection to empty space and clears level below to floor (if it's a wall, otherwise unaffected)

[Changed] Camera follows player up/down z levels only if player is on same z-level at the time

[Changed] Q -> Shift for climbing stairs (Shift+Up/Down Arrow)

I'm enjoying this. Don't fall down any holes now!

Now experimenting with: Array Save/Loading and things like that. If these features work, I'll make map export/import soon

Right click->Save As/Save Target As/Save Link As

There's the .cap. Mostly uncommented but it is organized into groups (mostly).

.exe Download!

I bothered to compile it.

Windows buttons are temporary.

Okay, what is it? Grid based game. Or, grid based engine, with falling down stuff, walls/blocking, a moving player thing, and z-levels, which you can move the camera or player up and down as you wish (well, you need stairs to move the player up and down).

Anyway, the controls/how to work it:

Arrow keys: Move player.

Shift+Arrow Up/Down: Climb up or down stairs.

Click a grid tile: Place object (working on some things here). Click a button (Wall/Floor/Stairs) to select an object. Floor and Wall can be dragged.

Shift+Q/A: Move camera up/down Z-levels.

Click the Random/Clear buttons to reset the level to all random or flat grass.

Known issues:

Note to self: Write problems here & bill community for update

I plan to implement a lot of things over the next few days to this, as I genuinely enjoy working on it. Right now, it's just a glorified level editor really.

Have fun, suggest stuff, give feedback, flame needlessly, go off and offend an old lady, whatever. I'm going to sleep

You could, to prevent this on your own, add a condition that "Object (Wall) does not overlap Player.ImagepointX("gun"), Player.ImagepointY("gun")" to the shoot condition (of course, filling in correct object and image point names). I think that should fix it, until a proper Construct fix to catch the error.

Shell Control object would be kind of handy.

Something to call keystrokes, mouse X/Y position setting (or movement interpolation), replicate mouseclicks, etc.

And being able to use the tilde and F1-F12 keys in the Mouse&Keyboard object.

This problem is because of Newton Dynamics, the engine that Construct uses for Physics. It has a 'world space', outside of which the physics tend to stop being calculated.

I encountered this with Phys-Box originally, but it didn't really bother me much as a bug because I'd already heard about Newton's world space.

It gives you something like a 4000x4000 space to work with anyway does it not? That should be far large enough for most any platformer level, and you can easily enough link multiple layouts together.