C3 now the operation logic is filtering. Is it possible to bind a single event table to a single ..

0 favourites
From the Asset Store
Very simple code without excess options (15 events for server and 11 events for client)
  • Further the idea would be that you can´t specify an object inside the event sheet, and the events always automatically reference the instance.

    This is the bit I don't get. What does "automatically reference the instance" really mean? As I described earlier, the way events normally run appears to already do this.

  • What I mean is that you do not set a specific object, like "Sprite2 on touched" but rather "this on touched" (kinda like in js). If you do it with Sprite2, copying between projects gets annoying. You can´t just copypaste because Sprite2 doesn´t exist, so you create it and then you wanna replace the object with a different one (say a Tiled background) and you can´t use the build-in replace object because it doesn´t allow replacing different types. So you might aswell recreate it from scratch anyway.

    By referencing the object as "this" it would be a generalized event that can be copypasted between projects and reused for different objects without much hassle. And as mentioned, it would be another step in the "plugin via events" direction.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • OK, so in a sentence, it's "self" for an object parameter?

    This seems to make more sense - it doesn't affect the way it runs events at all, it's just a placeholder to refer to the current object type.

  • Yeah, that's basically it.

  • There's a weird forum bug going on here which stopped my reply appearing until I added several other replies... and deleting them makes it disappear again :P So apologies for the spam and please ignore the intervening posts...

    Yes, I found this mistake, too.

  • OK, so in a sentence, it's "self" for an object parameter?

    This seems to make more sense - it doesn't affect the way it runs events at all, it's just a placeholder to refer to the current object type.

    That's it. he didn't [sift]. Through the event on instance, the object is manipulated directly through [this].

  • this is a pretty interesting concept, i am more curious how the binding will work, so you have a subset of event logic, (that is self contained) and has a special identifier that references the object that it is currently bound to (self)

    so this self needs to act like an object type, so when you are adding an action to this self contained event sheet, will it be smart enough to know about the object that it is currently bound to? like if you have an 8direction behavior on a sprite, and then you bind this set of events to that object, when adding logic will the 8direction ACES show up in the context of self?

    if thats the case then the 8direction behavior becomes a hard dependency on that set of logic, and you would not be able to reuse it unless the object you attach it to, has the 8direction behavior.

    this also gets a bit hazy with specific object types? like a sprite and an array have different exposed ACES, so will self know about these? so this seems like it hinders the reuseability of this set of logic. and force the set of logic to be reused with a very specific object type that meets the criteria of having specific behaviors.

    another interesting thing is, what if in your event logic you reference an outside object? like self colldies with B, now B has to be included in the project for this to work.

    it would be really interesting if that could be parameterized, like the set of events could expose Object type properties so when you bind it to an object you have to reference the other used instances as a parameter.

    this seems like a great concept, that could really help with event sheet maintainability and also help make thing resuable, but there seem to be alot of edge cases

  • I seem to be experiencing the forum bug Ashely mentioned as well, i do not see my most recent post??

  • What I mean is that you do not set a specific object, like "Sprite2 on touched" but rather "this on touched" (kinda like in js). If you do it with Sprite2, copying between projects gets annoying. You can´t just copypaste because Sprite2 doesn´t exist, so you create it and then you wanna replace the object with a different one (say a Tiled background) and you can´t use the build-in replace object because it doesn´t allow replacing different types. So you might aswell recreate it from scratch anyway.

    By referencing the object as "this" it would be a generalized event that can be copypasted between projects and reused for different objects without much hassle. And as mentioned, it would be another step in the "plugin via events" direction.

    This! You explained it in a very clear way, thank you!

    I think that a lot of what is in c3 can be redesigned to implement this idea. For example if we can make families that have a eventsheet attached to it and then restrain this event sheet to refer only to the family object attached to it. This way we would be able to copy event sheets with "behavior like" logic more easily between projects.

    Then, extending the idea we would only need a "family importer and exporter" that would be able to import/export a family and the eventsheet attached to it as a, let's say, ".family" file type inside c3 editor.

    Then people woud be able to import families created by the community to their project and then they would need only to assign their project objects to the families imported to give then some behavior like funcionality.

    This way the community would be able to create "sharable" families with behavior logic similar to behaviors like platform, sine, 8 direction, tiled-moviment, etc...

    And that's it, we pretty much achieved behaviors with events in construct that can be done and shared more easily by the community.

    Please Ashley make this happen!

  • If this is pretty much only "self" as an object type, then it sounds an awful lot like what the existing "Replace object" option does. If you want to swap SpriteA for SpriteB, "Replace object" lets you do that for a chunk of events in a few clicks.

    As piranha305 touched on there are tons of edge cases with this and it will probably be complicated and difficult to implement. Given we have hundreds of feature requests and limited development resources, I think it's hard to avoid the conclusion that if this is only like "Replace object" but with lots of extra of difficult and awkward situations that will be time-consuming to sort out, then it would be better to just use "Replace object", or find some other way to tweak "Replace object" to work conveniently with a new workflow.

  • I'd see the "this" feature as operating as a fusion of self and families - it has the self referential properties of self, however shares the ability to pass on behaviours from families.

  • In my opinion it should work like this.

    They should be family eventsheets and you should be able to create functions inside of them that can be call like this

    family.myFunction( parameter1, 2, 3, ... )

    or like this

    sprite.myFunction( parameter1, 2, 3, ... ) text.myFunction( parameter1, 2, 3, ... )

    It shouldn't be object eventsheets but family eventsheets because it avoids the problem of not having the same variable/behavior/object type/...

    adding spriteX to mySpriteFamily will automatically attach the family eventsheet to it.

    The scope of the functions would change and make it possible to have a function with the same name in each family eventsheet.

    spriteX.doSomething( parameter1, 2, 3, ... ) spriteY.doSomething( parameter1, 2, 3, ... )

    spriteX and spriteY are both in mySpriteFamily and inherited the family eventsheet with a function called doSomething. Every new sprite added to the family will get the doSomething function with the default code, but each sprite can overwrite it with their own code.

    As an example let's create a simple family eventsheet to control 2 different type of enemies.

    We have a sprite called zombie and a sprite called skeleton, they are both in a family called enemy, with a family eventsheet and the function "attack()" in it.

    We have another sprite called player with a line of sight behavior.

    We now want the enemies to attack the player in different situations and in different ways, the zombie attacks the player if he can reach him with a melee attack and the skeleton will shoot an arrow when he is at the right distance away from the player.

    We can use the normal eventsheet to check if the conditions are met and then call the same function in both enemies family eventsheets, for the zombie we call zombie.attack() on collision with the player and for the skeleton we call skeleton.attack() if he has line of sight to the player. In the zombie attack() function we trigger an melee attack animation and a "hurtbox" that deals damage to the player ( player.takeDamage(1) ) and in the skeletons attack() function we trigger a bow shooting animation and shoot an arrow in the direction of the player.

    Now after writing it all down, i think what i really want (♩ ♫ what i really really want ♪ ♬) is probably just object and family functions. But maybe I am missing something else that would only be possible or easier/cleaner to do with object/family eventsheets

    [Edit]

    There is actually already a similar idea posted for that here construct3.ideas.aha.io/ideas/C3-I-22

    I think a way of implementing it in editor could be to add another type to the instance variable drop down (Boolean,Number,String and now added Function) that would be the way to name the instance function, and to create the code for it you would (in normal eventsheet) have something like

    on spriteX myInstanceFunction -> do something

    on spriteY myInstanceFunction -> do something

    in the same way you right now have

    on function myFunction -> do something

    and you could define a default for an instance function with families

    on mySpriteFamily myInstanceFunction -> do something

    the code from this would only be executed for the sprites that have not overwritten "myInstanceFunction"

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)