Upgrading our Current Logic Boxes |

Deleted
Deleted Member

Posts: 0

Upgrading our Current Logic Boxes Sept 30, 2014 0:11:43 GMT 1 De Lírios and Ag like this

Quote

Post by Deleted on Sept 30, 2014 0:11:43 GMT 1

I suggest that instead of adding a bunch of new Logic Boxes, we should work on improving our current boxes first.

Object Enabler

It is an "Object Enabler", not a "Model Enabler". I suggest living up the the name of the cube, and adding more functions.

• An Object Enabler should be able to attach to the Oculus blueprint. This makes it so that the Oculus can disappear, unable to move or interact with the rest of the world... When the Oculus reappears, it should reappear at it's original "spawnpoint".

• An Object Enabler should be able to attach to Ghost bueprints. This will have an effect similar to when the Oculus blueprint is attached to an Object Enabler.

• An Object Enabler should be able to attach to Sentry orbs. This would make the orb and the health bar disappear when the Object Enabler is turned off.

• Object Enablers should be able to attach to all pickups, except for the Collectible pickup.

• The yellow output orb on an Object Enabler needs to be edited. Unlike the other input/output orbs, the Object Enabler's orb doesn't have a shine to it, in fact it just has a solid yellow color to it.

TNT

The TNT Box should have a "hide" function for the dynamite model.

Spawnpoint

There should be only one spawnpoint in the inventory, not four. Instead, there should be a settings menu for the spawnpoint that allows you to change the team color and the team name. There should also be a "clone" function for spawnpoints.

Water

Water Boxes should have input orbs, allowing off them to be turned off, allowing for a different Water Box to activate. This will allow for water levels and colors to be changed in-game.

Skybox

There should be an option to replace the sun graphic with a moon graphic, allowing for games that take place in the night to be far more realistic.

Smoke & Fire

The Smoke and Fire Boxes should have settings menus allowing for the color and size of the smoke/fire to be changed. The Smoke Box should have an additional setting that allows a user to replace the default smoke graphic with the graphic emitted by a defeated Sentry.

RoundCube

Now this is the Logic Box that might have the most potential...

• RoundCubes should have the "reach highest altitude" and "reach lowest altitude" winning states again.
• RoundCubes should have a "deathmatch" winning state (similar to the one that used to be on the test server). This winning state will make it so that once the time runs out, the user with the most kills wins.
• RoundCubes should have a "race" winning state, which will require a flag to be placed. This winning state will allow for up to three players to capture the flag before the game is reset. The first, second, and third players to capture the flag will be announced afterwards.
• RoundCubes should have an output orb, which will allow for logic to be activated once the time runs out, or the game is reset... You never know what players want to build these days.

Jatsu
Titan

Posts: 842

Upgrading our Current Logic Boxes Sept 30, 2014 6:16:44 GMT 1

Quote

Post by Jatsu on Sept 30, 2014 6:16:44 GMT 1

That post was hard to read... Here's my thoughts:

Object Enablers

Depending on the design of a circuit, an enabler function in computer science essentially determines if the device can actively function or not. In some cases, a circuit can be designed so that it is enabled when power is supplied (seems kind of obvious). In other cases, a separate enabler variable can be introduced to determine the device's activity while power is already supplied. Enabler functions are even present in programming, but exists mostly as variable states. Why am I trying to explain this? Because having a concrete definition of an enabler is important.
So what should an enabler be in Kogama? An enabler would be a function that either turns a logic box, blueprints, and pickup's activity on or off. In essence, an enabler function would give creator's a higher level of control over any object's activity. For example, moving platforms would have stop and go functions. For NPCs like oculus and ghosts, they would lie dormant (not invisible). For logic boxes, it would determine if the box would output a signal, regardless of any active inputs current connected to it. And for pickups, they could become unable to be interacted with.

How should an enabler be implemented in Kogama? Nara once suggested that enabler functions could be implemented as a separate prong on every object, and thus be integrated based on logic signals. Another possible implementation could be a separate Object Enabler logic box that has an output prong that can connect to anything, including blueprints, and thus also be logic integrated and enable objects that way. The difference between these two versions of implementation is where enabler prongs exist. In the latter implementation, it would mean all prongs be located on a logic box instead of an object, and thus leave each object's appearance in edit-mode less complicated to look at. Thus, it's possible that it could be simpler and quicker to use. A possible pitfall could be confusion of valid objects, such as how it would connect to other logic boxes (perhaps the entire box itself?) or to blueprints that consist of both objects and models.

While either implementation could potentially work depending how they're executed, there's already precedent for enabler functions in Kogama. If you examine Turret NPCs, then you will notice there are already enabler prongs sticking out of the orbs themselves. These prongs control whether or not the Turret NPC is active and fires upon nearby players. This precedent confirms that enabler functions already exist and Kogama, albeit in a limited scope, but could potentially be expanded upon in the direction of the possible implementations discussed above.

TL;DR: Enabler functions already exist in Kogama, but are limited to only Turret NPCs currently. If the feature is expanded, I would vote for it being a separate logic box that can connect its enabler function to any valid object - be it other logic boxes, blueprints, and pickups.

I'd like to be more thorough and give feedback on every point, but I fear it would end up being too long. If you're interested in my other thoughts, or would like to discuss something in particular, feel to bring it up. I like to talk about the logic system. For now though, all I can offer is a look at a list of (incomplete) suggestions that was compiled several months ago here. Some of my thoughts about logic can be found on page 2.

Last Edit: Sept 30, 2014 7:15:51 GMT 1 by Jatsu: ProBoards doesn't allow shortened links? Interesting...

DrVista
Ninja

Wassup?

Posts: 460

Upgrading our Current Logic Boxes Sept 30, 2014 13:51:28 GMT 1

Quote

Post by DrVista on Sept 30, 2014 13:51:28 GMT 1

Sept 30, 2014 0:11:43 GMT 1 @seirios said:

Object Enabler

It is an "Object Enabler", not a "Model Enabler". I suggest living up the the name of the cube, and adding more functions.

• Object Enablers should be able to attach to all pickups, except for the Collectible pickup.

My Opinion ^_^
The Object Enabler being attached to a Collectible Pickup isn't actually not that bad..It could be useful for puzzle games

Last Edit: Sept 30, 2014 13:52:08 GMT 1 by DrVista

FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS FABULOUS