Main Menu is on a layer, that is then inherited across all layers (above base layers on other layouts). I've had issues with modal layouts.

No worries, I fixed it all, one has to remember that invisible objects remain interactable! I thought I'd share this. If this does belong to help section, then I apologize. I wasn't sure at the time at posting.

Think I'll go with destroying and creating; at least it'll keep the amount of objects minimal.

... that doesn't mean it is not clickable. I discovered that when I was getting activity when I clicked around randomly, then I realized that the 'invisible' menu was there and its buttons were registering clicks.

I did a workaround by adding a condition check for 'is visible?", but well, shouldn't invisible stuff stop interacting with visible objects? Or is there a way to disable them altogether?

Thank you very much for the example I'm going to use this solution. I intend to implement a fully expandable tag ystem and hashtables are ideal for that.

Awesome, that is what I needed! Thank you very much, David

Now to implement this into a fully functional and expandable solution... Oh joy!

Thanks, that was quite an amusing demo And yes, it made things clear.

I understand what you mean by small steps, however I want to make such steps that I can expand on. Private Variables are potentially something that is going to stab me back in the future.

I've been experimenting with Hashtables, but I've stumbled into a few problems... Eh, sometimes we gotta take a step back in order to move forward.

How do I determine whether among all instances there exists an instance with key set to specific value? It has to be a condition. Like this:

NEGATIVE (Exists? Hashtable("Key")="Test")[/code:2ckfbmej]
I would like a clean and simple solution rather than having to devise a bulky workaround.

I suppose you could use the Image Manipulator to load those sprite sheets and crop desired tiles, then copy them to sprites.

So, yeah. Excuse my laziness, but perhaps this would bring certain -much- needed features to spotlight.

Image Box

Like a regular box, only that its content is filled with the image. Unlike sprite or tiled background, however, this contains only a non-tiled image and by option a border. Very simple image container.

Table Object

An object that would create a table - rows, columns, cells etc.; it should have a method of directly outputting the Array or Hashtable entries.

Text input

The windows control is too rough around its edges; it is not quite customizable and looks ugly. A DX9 alternative would be nice; moreover, it would be able to have an ever-so handy PV.

Menu Objects

For DX9 runtime, please, not the horrid application controls. Highly customizable and an important ability to have a PV. Buttons, simple controls for manipulation etc.

Identifier

We need some sort of an attrutibe, an Identifier, which would mark DIFFERENT objects and instances to be pickable. For example I'd use an identifier named "GUI" and eventually when I press a button I want all objects with that identifier to disappear - i.e. become invisible - no matter the object type.

TL;DR: Scroll to bottom.

Okay, so I've been plotting the mindmap out and brainstorming about the cogs and springs of my RPG project. I realized that I will have to use some sort of '"tags", variables, which define behavior in context or an attribute. These tags would have to be dynamic, any character/npc/monster/enemy object would have a variable amount of different tags, such as allegiance (PlayerFaction, neutral factions, enemy factions), race (and its related tags such as BIPEDAL/QUADRIPEDAL)... basically, all of the tags would be BOOLEAN and the RPG engine would process them as needed within context.

As there is going to be a lot of variables (several races, four genders (HERMAPHRODYTE and UNISEX in addition to MALE and FEMALE), age (INFANT, CHILD, ADOLESCENT, ADULT and AGED), race (HUMAN, DWARF, ELF, ORC etc.) and so on), I figure I would have to break everything down into categories and tags, then as an entity is created, it is assigned tags.

Categories would be super-classes such as BODY, PERSONALITY, ABILITIES and TALENTS, further expanded into sub-categories (HEAD would have eye, ears, nose, mouth, jaw and such tags... a pig would have SNOUT instead of NOSE). ABILITIES would cover abilities one has, such as a dragon would have an FIRE_BREATH... an INFANT dragon would have NO_FLY tag, as it can't fly yet, but ADOLESCENT dragon would have FLY ability, so don't go poking it, lest it takes off and breathes fire from above. FLY can be either magical or physical, thus requiring WINGS of some sort, which can be damaged or crippled to limit the ability to fly.

Complex, eh? However if I manage to implement such a tag system, I could create a detailed RPG environment (combat, diverse entities and abilities) and most importantly expandable engine without having to dig through heaps of code. Just make ON Crippled WINGS > NO_FLY when it checks for damages and you've grounded the dragon! When its wings are healed, however, the FLY tag is restored.

Expandability also offers high replayability value; create a procedurally generated environment and characters (much akin to Nethack) and embark onto the epic journey that may end just round the corner or in deepest pits of the hell!

And best of all, tags offer customizability. Remove ones you don't want and your game will play without them, so basically you could have a realistic historical setting with only humans and physical weapons, no magic or fantasy creatures. Awesome, isn't it?

Now, if you have managed to read this far (an epic feat, I must admit), the question is... how should I go about implementing the tags system? Through attributes? Can they be created and set in run-time? Can they be checked for in conditions? Sould I use the alias function for tags?

This is why I am posting here. I am looking for ideas on implementation of the system described above. They all are boolean, they must be usable in expressions and conditions, they must be clear (hence capitalization) and they must be categorizable. They also can be static (given at creation of object, can't be changed) and dynamic (can change during course of adventure or a single encounter).

Oh joy, this makes me so excited!

Yes, fractals. The possibilities are practically endless!

A six-pack of unconditional love goes to the one who develops a plugin or some mean of embedding fractal support within Construct.

Yes.

Here are the potential uses:

• images - for background, etc, whatever
• dynamically generated maps
• dynamically generated sprites (big bad bosses at end of the level in a retro shooter)
• movement pattern
• dynamic masks (for textures or special effects)
• visualization

And more.

Edit: Er, okay, guess I confused procedural generation and fractals. Still, the idea stands.

Conditions! Check if mouse X or Y is greater than right and bottom edge (layout size, such as 640x400) or if it is smaller than left and top edge (0). If the condition is met, you can execute an event to make the mouse enrage and swallow the user whole. Or simply keep focus on the edge where mouse left the layout and wait until it comes back into the game.

But I think an enraged mouse is fun.

Ahh, here we go, all registered! And to think I thought myself to be lazy and dumb because I couldn't register...