Ruskul's Forum Posts

  • If it comes to it, I would much much much rather "supported engine internals", even if that means documentation isnʻt extensive or robust.

    Lol, A bigger issue I have is that there isnʻt enough internals listed :D

    So I def prefer a larger listed api over a smaller, but very well documented api.

    I mean... I do make api calls that arenʻt officially supported, because I donʻt feel like I have a choice. I need them, and figure since I am using them the same as some built in behaviors use them... should be okay... hopefully.

  • Ashley

    If it helps to know, construct is a great product. I was/am salty about the rent model, so I have most of my work still in c2, but Iʻve been doing more and more in c3 and the number of improvements is great. I know I complain alot.

    But c3 is a great product and I do recommend it to people. and I am rather astounded by how insanely productive you are. It takes me forever to get something out the door and I never have to make my tools stupid proof for the masses (Iʻm included in the masses too lol).

    Iʻm not being sycophantic - just trying to add context to all my complaining and poo pooing.

  • No no, I think you misunderstand me, the description is fine. I understand what it does and what it is for; But having a code example of it in use goes miles to help avoid making dumb mistakes and show it in propper context. and JS never tells you until you get the thing exported, plugged in, and it doesnʻt work. An example with the description makes it easy to see how it is implemented. I only brought up that particular item to show, like most entries, there is no example code.

    Iʻm not saying "why donʻt you make this like unity". That feels a little like a straw-man. Pretty much any api documentation I have ever seen includes at least a single code snippet of the item in use, which is fair. Iʻm using unity as an example because it perfectly illustrates "...what more there is to add." (namely code examples with comments). But if that still feels unfair, these other examples will do just fine and are made by solo devs.

    Here is documentation for a tool made by one person: ludiq.io/chronos/api/timekeeper.

    Documentation for another package made, originally by one person.

    corgi-engine-docs.moremountains.com/API/class_more_mountains_1_1_corgi_engine_1_1_a_i_action_jump.html

    Constructʻs api isnʻt insanely huge, so comparing the effort needed to maintain or build documentation in contrast to unity isnʻt fair either.

    On a favorable point, constructʻs documentation is well written, much better than gamemaker. And honestly, when it comes to the eventsheets, it is pretty much perfect, plenty of examples too. It just is missing examples for the api.

  • For example: Here is an entry from defining aces. When I compare the documentation here on c3, compared to game maker or unity, it really is... simple.

    -isStatic

    Normally, the condition runtime method is executed once per picked instance. If the condition is marked static, the runtime method is executed once only, on the object type class. This means the runtime method must also implement the instance picking entirely itself, including respecting negation and OR blocks

    That, compared to this:

    docs.unity3d.com/ScriptReference/Physics2D.Raycast.html

    I had several years in construct before learning unity. I picked up unity way faster and I still have trouble with the sdk here.

    Part of that is inconsistency between the sdk addon api, scripting api, and the way events sheets get used. The other part is that many default behaviors that would work as examples use undocumented api calls so they aren't the best learning tools. Many of those undocumented calls SHOULD be a part of the api but aren't for reasons. Lastly, unlike most other engines, auto complete only is half useful, so you can't crutch around using it as a tool to explore what you can and cant reference.

  • Lol thanks. Man, what the heck!. I did both a google search and searched the manual via the search tool on the website, it returned like 12 hits, but the first few didn't have it when I did a page search. Thanks for the link, I'll try harder next time before asking :/

  • It's because Fake Triggers which is used by the "On Timer" in the Timer Behavior actually check if they're true everytick as opposed to True Triggers So if you have a bunch of objects checking a bunch of On Timers it can be heavy.

    True Trigger on the other hand don't do anything every tick, they're just triggered when they're called (with a little overhead)

    Both approach have their own trade-offs as often in programming. Even if I admit I did tricks to avoid many "On Timer" Fake Triggers in my project

    (Ruskul, I think the comment of tunderrunz was about official behaviors not the Advanced Signals pack I made)

    Oh no, I understand why one runs slower, I think I meant why did Scirra choose to use a fake trigger at all on the timer, but then not on the tween.

    Imo, if there really is a need for a fake trigger (or perhaps they wont change it in order to not break projects) then why not add an option for a real one. Its a wash as far as I am concerned because I already copied the behavior, stripped out the fluff, and added a single "untagged" timer and reduced it to a simple true trigger alarm and a second timer for polling. If you need multiple simple timers you just add the behavior again and name it what you need.

    Simple Alarm. A behavior that solves 1 problem, and solves it in as performant a way as I can manage. Let me know if anyone wants to try it out.

  • Oh cool, right on!

  • Hello all,

    I was curious if there was any attempt at this yet?

    Honestly not sure how best to do it in c3.

    It honestly seems like the sort of thing that could eventually exist as a part of the editor and haves its own set of dedicated eventsheet style calls.

    I was thinking about just writing the behaviorTree as a JSON using particular keywords and then creating a plugin/behavior that reads a json file and executes the behavior, but imo that doesn't seem very elegant. Plus, writing behavior trees as a json file imo isn't fun. lol.

  • Hi all,

    Using the built in pathfinding behavior, is there a simple way to compute a path from an arbitrary position (such as the destination target)?

    Currently, the only way I know is to save the desired new target to an array, and then, on arriving at current target, fetch the next command and compute a path.

    It seems like a waste to not compute the path while en route. I thought to create an object at the current destination target and use it to compute the next path, but I don't see a way to share paths from one object to another. There are several features I need in pathfinding (like being able to edit node connections directly for teleporting, and a few other things related to the graphs construction and editing, that likely means I'll have to remake the behavior anyway...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hi everyone,

    I'm a bit confused by this.DispatchScriptEvent as used below. I looked through the manual and couldn't find any reference of it. I feel like I'm overlooking something obvious (is it part of some other JS library). The Timer behavior uses a false trigger as a condition for OnTimer so I'm not sure why an event is being dispatched anyway, unless this if for something else to hook into? I don't recall if the timer interacts with other behaviors. 

    Tick() {
			const dt = this._runtime.GetDt(this._inst);
			for (const [name, timer] of this._timers)
				if (!timer.IsPaused()) {
					timer.Add(dt);
					if (timer.HasFinished()) this.DispatchScriptEvent("timer", false, {
						tag: name
					})
				}
		}

  • Looping back to the original point of the post, I'm still confused why "OnTween" finished seemingly causes no reduction in fps, while "onTimer" does. Seems like timers are.... outdated? Tweens are nice and fast for all they do.

  • Overboy

    Sorry If I missed the answer elsewhere, but I wanted to ask about performance of your tools.

    For the custom signals and the like, do they perform better than c3 built in functions?

    I have a project where I need to call alot of functions, those functions call other functions, etc... Its in loops in order to achieve object picking,.

    I have alot of object that have large lists of buffs, effects, etc, that are all being passed around. And alot of those effects do something every tick. How is the comparable performance of your plugin compared to built in custom actions and functions?

  • I'm looking over the behaviors code, I can understand why one might want a fake trigger for order of events stuff. (Right, true triggers can fire at any time? Or is the order in the event sheet still protected?)

    That's my assumption too.

  • Also, to add, I have the other test where I mentioned you can read out the results to an array and verify the loop is running.

    And yes, I used the debugger in this case, and I know it has overhead. Are the results accurate? No. But I think they are good enough, and certainly mirror what I have been seeing in my project:

    Pure JS = fastest

    Pure Event sheet no functions (function inlined) = next best

    Eventsheet with c3 event functions = okay

    JS in JS blocks mixed in eventsheet = Awful

    I mean it all depends on what you are doing, and I am doing 1000 objects, which imo isn't much, but already requires careful attention to this stuff.

  • The obvious thing to do is if you need maximum performance, write the loop itself in JavaScript, and avoid mixing interfaces (in this case event blocks and JS). So why not just do that?

    I did that too, which I mentioned and is in the project, to compare and point out that was blazing fast. The TLDR was don't use JS blocks inside of big eventsheet loops, or eventsheet blocks that will get called alot, which I had been doing in my project and wondering why it was so slow.

    The reason you can't write the loop in JS is because you might be doing other things in that loop that you can't handle with JS, or should by recommendation of the SDK manual.

    But this isn't expressed in the manual, and everybody is like "Performance problems?" write a JS module or script. But it turns out this doesn't solve the issue at all, but makes it worse.

    Thus the only solution is AddonBehavior with sdk (tedious and laborious to write) or built in event sheet functions, but they have the overhead too.

    Which, leads me back to the issue about the insanity of manually in-lining construct functions in order to improve performance. Which is BAD for scalability, maintainability and general mental well being lol.