[PLUGIN] GridTree (0.2)

GridTree.PollGrid(Name, X, Y, Data Type, Max)

Sorry, but I'm somewhat confused at whats going on with the expression.

I get name, and x,y... although an x,y for every x,y is blowing my mind, but Data Type needs a bit more of an explanation.

The Data Types "BubbleX", and "ColorR", etc, are um, I dunno...

Are they labels you made up, or are they undocumented system expressions?

If they're plugin specific, that's fine, but users need some sort of reference to all of them.

Thats kind of like loumu's dungeon plug using keywords like wall, and rock without an indication of of value.

Also, on "BubbleX", isn't that a reference to an object being created within the same action?

Thanks

GridTree.PollGrid(Name, X, Y, Data Type, Max)

Sorry, but I'm somewhat confused at whats going on with the expression.

I get name, and x,y... although an x,y for every x,y is blowing my mind, but Data Type needs a bit more of an explanation.

The Data Types "BubbleX", and "ColorR", etc, are um, I dunno...

Are they labels you made up, or are they undocumented system expressions?

If they're plugin specific, that's fine, but users need some sort of reference to all of them.

Thats kind of like loumu's dungeon plug using keywords like wall, and rock without an indication of of value.

Also, on "BubbleX", isn't that a reference to an object being created within the same action?

Thanks

As far as X, Y's within X, Y's goes. That's the nature of the plugin. It's hard to comprehend sometimes, even for me. Just remember that when you Poll Grid you want to make sure that you've set your current position for every grid above the current one. You don't need to set your position on the grid you are polling, because that's what X and Y are for in the expression. Of course it wouldn't hurt to set the position anyway, but for large amounts of polling that might be processor intensive for reasons that would take a while to explain. That's why you can poll along a grid without setting position.

The data type is specific to the plugin, but it isn't explicit. There is no list of them - you can make up any data type you like. You could set it to "badjfo9a8d789dabfiausd" or " "fnord" and it would still behave the same.

What that actually is is a numeric seed for a type of data, but to make it easier to understand I had it accept strings. The string is then hashed and the hash is used to seed the data type. So basically it is anything you want it to be, as long as you always use that specific word to reference whatever you are trying to look for. Because that word/string/hash/value is used to modify the GRID seed - which allows you to poll for multiple things within the same grid. Does that make sense? Think of each point in the grid like a set of gym lockers, and the data type is the locker you are selecting. You are not drilling down into the next grid - merely specifying that you are checking out something different on the current one.

So notice how I poll for R, G, and B, all within the same grid - at the same locations - and with the same maximum values. Since this is persistent - technically R G and B should all be the same number. That's what data type does. You specify a unique identifier for what you are looking for - and that identifier can be anything you like - and it splits your grid up into clones with different sets of data. Pretty nifty eh?

I won't have time to check this until much later today (again), but I just wanted to post to say thanks.

I've been looking forward to this.

As I said in another post, I've been using seeded randoms to create my world space, and I've had to develop a system to make sure everything was connected to the original seed, etc, but this looks like it will do all that for me, and more.

So I'm more than happy to rewrite my code to use this, because in the long run, it'll be much more flexible for what I need.

Not enough hours in the day.

Krush.

this is so awesome arsonide. already checked out the example cap. this sets the timeline for the world editor I'm making after my character editor way forward. you've really outdone yourself, this time. perlin used to be my favorite 3rd party plug.

[quote:2eu3i45n]What that actually is is a numeric seed for a type of data, but to make it easier to understand I had it accept strings. The string is then hashed and the hash is used to seed the data type.

Wow, had no idea it could be that flexible.

So are those values generated when the seed is named, or is that also generated from the root seed?

The grid seed is dependent on the root seed, and the data type "fudges" it a bit, so the hash itself isn't dependent upon the root seed, but after it fudges the grid seed, the result is. Technically. The hash is generated at runtime when you poll for data.

With Void Runner I found myself defining a bunch of constant variables simply to reference the TYPE of data I wanted from the tree. So the start of every file would look like this:

#define PLANET_EXISTS 0
#define PLANET_TYPE 1
#define PLANET_DEFAULT_COLOR 2
#define PLANET_WATER_LEVEL 3
[/code:2ab29jsv]

...and so on. These were then used to "fudge" the grid a bit, by modifying the Mersenne Twister slightly. The data type is to prevent you from needing to do something similar to this with variables in Construct - while at the same time making your data easier to read.

After trying the .cap and reading latest posts my head started to hurt. I'll finish it later, just wanted to say thanks.

Now I've finally spent some time with this, I'm blown away.

This takes so much of my current code away, and really streamlines the process.

Over the next couple of weeks, as I try to implement this into my existing project (don't worry, I've backed that up ), I'll let you know if I come across any bugs.

So far, I've had no problems with either performance or functionality, no matter how many levels I go down.

Excellent work mate.

Krush.

Now I've finally spent some time with this, I'm blown away.

This takes so much of my current code away, and really streamlines the process.

Over the next couple of weeks, as I try to implement this into my existing project (don't worry, I've backed that up ), I'll let you know if I come across any bugs.

So far, I've had no problems with either performance or functionality, no matter how many levels I go down.

Excellent work mate.

Krush.

Just keep in mind that this

is

alpha, and I do plan on patching up some things. (There's an extremely small chance that I may just move it up to release status as is, if nobody reports any bugs, but I doubt that will happen.) If I patch it, it may integrate seamlessly with whatever you've done, there's a chance that it may not however. So just keep track of everything you are doing, so if you have to redo it at some point it'll be easier.

I'm glad you haven't run into any problems so far though! It worked pretty good for us, I'm hoping more people will find uses for it.

Yeah, my middle name is "backup". (not really )

UPDATE: I have released a new version of this plugin with some exciting new, slightly experimental options. There are four new actions that will assist you in changing the GridTree. Allow me to explain.

Imagine you have a grid representing a forest of trees, but your player wants to chop one down. Before, you'd have to keep track of this change the player made, save it somewhere, and overlay it on top of GridTree's procedural data. Now, GridTree can do all of this for you.

There are two actions: set value at, and revert value at. These actions will ask you what grid you're referring to, what data type you're referring to, and what position you are referring to. If you set the value there, GridTree will now output that value that you set there instead of it's procedural data. This will allow you to "cut down a tree" so to speak. If you want to revert the change, that action is there as well.

There are two more actions available as well that save the entire GridTree to a file, including all of your manual changes...and another to load this file into the GridTree.

This expands the possibilities of the plugin quite a bit. I hope you guys like it. There is a new "advanced" example in the zip that shows off these features, with comments and stuff. The example actually is a procedural forest with trees you can chop down. Keep in mind this is still in alpha, but is now back in active development. Please reply with any gripes, complaints, or praise, or bugs, or whatever. It will help me as I continue to develop this.

The download link in the original post has been updated. Here is a short video showing the changes. They're kind of hard to recognize, but they're there: video. There is a known "bug" in which after you load a file in the example cap, the editbox doesn't update to show the new seed. The seed changes internally, it's just the editbox. I'll update again soon with a new expression to fix this.

SIDE NOTE:

I am appending this message at the end of all of my threads. A recent discussion with a friend has led me to a conclusion.

Many of you know that my girlfriend went through a very rare form of cancer this year. One which only manifests in 1% of cancer patients, and is four times more likely to kill you. She survived it somehow, but recently the treatment center she was treated at has lost some rooms. If it weren't for that treatment center, she'd be dead right now. We are getting married in two weeks.

A combination of things, including my readings into Buddhism, and my discussion with this friend, has led me to the conclusion that any further donations to any of my plugins are going directly to cancer charities.

Most of you have noticed a few patches recently, and that will continue. I'm patching up the plugins I released this year, and then I'm releasing MUSE. After MUSE I am going to develop a toolkit cap designed to help people make roguelikes much easier, by utilizing all my plugins, as well as helper functions and examples. You can also bet your ass that I'm going to port all of my plugins to Construct 2 when it gets an OpenGL runtime.

So your donations will encourage this further development, and assist in cancer research. The link is in the original post. That is all I have to say.

Holy jesus. I just discovered a way to linearize the calculation costs of GridTree.

Basically, at the moment, GridTree does a lot of looping. Generally the larger your grid, the more looping it's going to do. This can cause some slowdowns in ambitious programs. I found a way to get rid of the loop entirely, so that every calculation GridTree does is nearly instantaneous regardless of how large your grids are. I'll be playing with this method in the coming days, but expect an update.

I'm extremely excited to see the update. From what I can tell your current file only works in the first Construct (unless I am missing something?). Keep up the great work!

Well I would hope so - this is the forum for the first Construct. <img src="smileys/smiley4.gif" border="0" align="middle" />

I gathered that. :) Is there a release for C2?