[PLUGIN] Zack0Wack0's Construct 2 Plugins

0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • You know, this community happens to kick a lot of ass. This is amazing.

  • Hopefully this helps:

    To get the time passed for this tick, use

    ar dt = this.runtime.getDt(this.inst);

    dt is the time, in seconds, that the physics simulation should advance. That should keep the speed steady no matter the framerate.

    To get a callback when an instance is destroyed:

    I just remembered there's already a function for this, because other parts of the runtime need it. Call

    untime.addDestroyCallback(function(inst) { alert(inst.toString()); });

    and it will alert the instance ID whenever something is destroyed.

    To get a callback when an instance is moved or rotated:

    There's nothing for this right now, but for the next build I've added a method for instances:

    nstance.add_bbox_changed_callback(function(inst) { alert(inst.toString()); });

    This will alert the instance ID whenever its bounding box is changed (x, y, width, height or angle is changed). Try to only add one callback and only for instances that really need it, because otherwise it'll add unnecessary overhead.

    Hope that helps, let me know if there's anything else you need!

    Thanks!

    Yep, I already have that code. See the problem is, at least as far as I can see (it might be my logic, who knows) is that currently construct does logic inside the same thread as rendering. So this is what happens:

    1. Engine renders the frame.

    2. The instance triggers the behavior's tick (which at the moment is a bit hacky, I forgot to mention this, is there a way to have a behavior .tick callback rather than an instance .tick callback?) and every instance increments the behaviors ticking count. When the ticking count is equal to the amount of instances with the behavior, the box2d world steps.

    3. As the gap between frames starts to get bigger, the delta between frames increases. Because I'm stepping the box2d world by this amount, it's stepping further in the physics world because the delta is larger.

    You should add an onDestroy callback sometime as well. It'd be a lot more easier. But thanks for that anyway.

    I'll be adding the callback to any instance with the rigidbody behavior. This is so I can move the body in the box2d world whenever you move the sprite's position by events, or rotate, etc.

  • 3. As the gap between frames starts to get bigger, the delta between frames increases. Because I'm stepping the box2d world by this amount, it's stepping further in the physics world because the delta is larger.

    That sounds like the correct way to do it - you want to step the physics world further when more time has passed since the last tick. I guess there must be a bug in the way you handle ticks.

    I remember having a similar problem with the Physics behavior in Classic: the world needs to be ticked once per tick no matter how many instances there are. The solution is to keep a tick count in the behavior of the last tick number that the world was ticked. runtime.tickcount in C2 gives you the number of ticks that have passed so far, so your tick code per instance is something like:

    if (this.behavior.lastTicked < this.runtime.tickcount)

    {

    tickTheWorld(); // whatever function to advance the physics simulation

    this.behavior.lastTicked = this.runtime.tickcount;

    }

    This way no matter how many instances you have, the entire behavior is only advanced once per tick. I bet it speeds up when you add more instances because more than one instance is advancing the physics.

    ou should add an onDestroy callback sometime as well. It'd be a lot more easier. But thanks for that anyway.

    Isn't that exactly what addDestroyCallback is? Or do you need something else?

  • I mean there's onCreate functions on the instances so it'd make sense to have an onDestroy one as well.

  • Ah, I see, I'll try and get that added too.

  • Holy crap that is awesome! The new plugin system does what others could not of done. Which i think is awesome. I have one suggestion for networking support Pubnub. Ill see if i can learn how to make a plugin ;)

  • First off, thanks to Zack0Wack0 for building the WebSocket plugin, I'm new to this engine so it would have been really tedious to get that working.

    As some context to my question, I'm experimenting with using Construct 2 for a client-server type of game.

    I've run into a couple issues that limited what I could do with websockets and was curious if anyone had solutions:

    1) The event sheets don't seem to have any functions for parsing/manipulating string data so processing incoming data seemed impossible. (e.g. splitting "chat:Player says hi!" into the message type of "chat" and payload of "Player says hi!")

    2) I then looked to build a plugin that would do all the parsing, and it would expose events and expressions to the event sheets via that. That worked well except that from what I could tell, the events can't take parameters, and instead the event handler is expected to query state expressions (e.g. Socket.LastDataReceived in Zack0Wack0's plugin). Where this fails is that you could receive multiple messages from the socket before the next AI tick, and since each message just updates LastDataReceived it would result in only the most recently received message's data being available to the event sheet.

    Is there some existing functionality I could use? Or am I just trying to do something with Construct 2 that it's not currently designed for?

    Thank you!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • In fact, your question 1 is resolved by the context of your question 2. ^^

    As you are making a plugin, there will soon be a parsing system if you distribute it (post it on this forum for the community) once it is done.

    Events can take parameters. Check out other plugins' edittime.js at the "section" Conditions. Each condition, before the AddCondition() function has several lines to add parameters (check text plugin for example, or mouse).

    The "multiple messages reception" part could be resolved by a reception pool.

    Theory would be (I can't download the plugin now, the link seems dead/off):

    Add an array to your project

    Add a global variable "step"

    Socket=>"on reception" (something like that, I can't have the plugin under my eyes)

    ..array. Set at X (where X is global step), value Socket.LastDataReceived

    ..array. Set size to X=step+1 ,Y=0,Z=0

    ..step. Add 1 to step

    Then you wouldn't get the datas to parse from Socket.LastDataReceived but from your array (array.get(x)).

    Once parsing is done, you'd remove the data from the array and substract 1 to step.

    Again, that's the theory.

  • Thanks for the plugins :D

  • Add an array to your project

    Add a global variable "step"

    Socket=>"on reception" (something like that, I can't have the plugin under my eyes)

    ..array. Set at X (where X is global step), value Socket.LastDataReceived

    ..array. Set size to X=step+1 ,Y=0,Z=0

    ..step. Add 1 to step

    This wouldn't solve anything since the problem comes from the plugin itself. I don't know anything about websocket, their implementation or anything, but I think the plugin should use a stack to store received messages instead of a simple string variable. That way, you could add an event like "While the messages stack is not empty, pop a message, parse it and do whatever needs to be done".

  • This is the purpose of the array stuff as there isn't a receiving stack (or pool) within the websocket plugin.

    Any message received in the websocket is directly transfered to the array and later processed by the parsing process instead of being processed on reception with the risks of string change during processing.

    Nevertheless adding a reception stack to the websocket plugin itself is indeed a good idea and hopefully will be considered by Zack0.

  • There is no way to tell if the plugin received more than one message during one tick. Storing them in an array is pointless, since you can process them punctually as they arrive. This is a kind of things that needs to be done internally.

  • I've managed in finaly downloading the plugins.

    I only have firefox 5.0 on my computer, and so the plugins won't work.

    But I took a look into the code.

    here is no way to tell if the plugin received more than one message during one tick. Storing them in an array is pointless, since you can process them punctually as they arrive. This is a kind of things that needs to be done internally.

    Whenever there's data incoming, "on data received" will be shot.

    Internaly to the plugin, the processing will be the same, and still revolve on a trigger.

    This is the way the API is designed.

    This mean that each tick, the socket listen to see if it receives any message.

    .. If true trigger "On data received"

    Collecting to an array in C2 or within the plugin is equivalent.

    It will be better/more user-friendly once embedded in the plugin, but my "hack" should work at equal as an embedded version for now. (there only gonna be one set of data received per tick when there is data to be received)

    Anyway the support of websocket from a browser to another is random. When there will be a common support (understand firefox6 for me), i'll worry about stacking received datas. ^^

  • I, too, checked the code. But it seems you didn't see things as I did. When the plugin receive a message, indeed the trigger happens, but the "lastData" variable also gets overridden with the new message. So in the unprobable (but possible) event of two messages received between two C2 tick, only the last message is returned via the "LastData" expression. As I said, storing them in an array via C2 WON'T help, and there is no workaround except by implementing stacks (or queues, or any other data structure) inside the plugin.

  • Thanks for the ideas.

    I implemented it in a plugin as a message queue with a MessageQueueCount expression to get the number of queued messages (for convenience with using a Repeat loop), and then a Dequeue action which will update a Data expression with the data received on that message, and it works perfectly. I'll submit it as a revision to Zack0Wack0's git respository when I get a chance.

    So now my event sheet looks something like:

    Message Received

    + Repeat Server.MessageQueueCount times => Dequeue Message

    + if (Server.DataPart0 == "messageX") => Do Stuff

    + if (Server.DataPart0 == "messageY" && Server.DataPart0 == "blah") => Do Other Stuff

    + etc.

    There still doesn't seem to be a good way to do string parsing using the existing Construct2 functions, so I also made the plugin split the data received into parts based on a delimiter, and providing a bunch of expressions to get DataPart0 to DataPartN. Not that elegant but it does the trick.

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