Ruskul's Recent Forum Activity

  • A huge issue, is that when a feature is missing, there is no way to work with Scirra to get it added. no matter how simple or complex. There is no roadmap, no dialogue or discussion, and it has to be "popular", regardless of arguments to its necessity.

    I always figured that if you could argue that a missing feature was absolutely crucial in order to do x, y, or z, and not just a nice to have item, that Scirra would add it, but they don't necessarily do so or it takes years. Even if you have the code to do it.

    I would add, I would be totally psyched if the interal API broke because Scirra decided to modernize the architecture, add extensibility, and provided better eventsheet abstraction, and modularity. But simply breaking the internal api to obfusicate it, for the stated reason to avoid users getting hurt is so fundamentally backwards it hurts.

    The only reason users engage in internal api calls and other hacks is because of a fundamental lacking on the part of c3.

  • Ashley,

    True or false, A or B. You owe this to all paid users. Please directly answer the question in 1 word.

    Will you/Scirra intentionally obfuscate the internal api without first making available a comprehensive and reasonable alternative?

    Yes? No?

    I absolutely need to know, because it isn't possible for me to make my game without the internal api at the moment.

    I would say if you are going to ignore that warning, the only responsible way is to have a plan in place for what you are going to do if the thing it warns you about then happens, so then you can fall back on plan B. But then in that case I would say, just do plan B first, and you won't have the trouble with undocumented stuff changing or disappearing

    You do understand what option B is, right? And are you really telling your users that?

  • Basically what the title asked. I would like to create an interface that automates some behavior linking and allows me to "add" some tools to the scripting side. ;)

  • Do not do this. See the warning in the addon SDK documentation. If you refer to undocumented engine internals, your project will be unsupported and could permanently break at any time.

    "Permanently"?... or just until I can understand what changes were made and why and make a fix?

    Or is it that there is a plan to obfuscate all internals at some point?

  • brushfe I would also add that because construct effects (still) doesn't have the ability to choose/load an image through the editor, creating Table lookups has to be applied to a sprite that covers the screen whose texture is the table lookup, meaning it can't be applied as a full layer effect, and you can't get smooth lerps from one lut to the next.

    I have asked for the ability to have images as an effect property several times starting 10 years ago, and here we are.

  • github.com/Scirra/Construct-feature-requests/issues/184

    Convenience aces exist for "Move at angle", "Move Forward", etc...

    But more commonly I tend to simply whish to move an object by its x,y components. This is simple enough, but a "Translate" action would further speed up event-sheet authoring and is the obvious counterpart/twin action to Move at angle. The former operating in Cartesian space while the latter is in polar coordinates.

    But more complicates is translating an object relative to another's angle (such as a parent's)

    I propose that we include several new common aces:

    "Translate" (x,y)

    "Translate by angle" (x,y)

    "Relative Translate" (obj, x, y)

    When you need to move an object in relative space, you have to do some laborious math, but a relative Translation Ace would solve that fast and easy:

    Current way alternatives:

    //Move obj in relative space according to its parent's angle

    Set Position to (self.x + distanceX*cos(parent.angle) , self.y + distanceY*sin(parent.angle)

    //Translation

    Set Position to (self.x + distanceX , self.y + distanceY)

  • I think you know the answer. It's likely not part of c3 because it wasn't deemed an internal priority or requested in high demand. Though I believe someone recently made a great plugin for it.

    But what does getting on your high horse accomplish? Do you think this will be added because you were shocked? Or by telling Scirra just how 'wrong' they are for not including it?

    Wouldn't it be far more productive, and more positive, to put this energy into a feature request?

    Nobody votes on those anyway, and when they do, Scirra mostly ignores it and adds something else. I just expected more to have happened in 10 years, especially since now we have to pay annually.

    Getting saltier by the day about that.

  • I'm a little shocked. I'll accept that I had to create this effect 10 years ago with c2, but now? Frankly, its time to get up on a high horse here and soap box.

    Bloom and color grading, if no others, are basically in every game for the last 10 years. I understand having to author particular effects, but pretty much EVERY game uses color grading and bloom, and to not include either in a game engine when you have 20 other useless effects is astounding... Indie to AAA, color grading is absolutely nec. Even if you are making a nes game clone, you need palette swapping and the easiest way to achieve that on modern hardware is with a table lookup. And bloom... Well... I mean, video games have been trying to fake it since the 90s and now we are post hdr by about 20 years.

    glow vertical + glow horizontal still equals absolute rubbish. It did 15 years ago, and it still does now.

    It's wrong if you like math.

    It's wrong if you like details.

    It's wrong if you have an any sense of aesthetics (unless your game is going for a chip on its glow's shoulder, but then so is everyone else in construct)

    And it's so easy to author a bloom and color lookup table, how is this not in c3?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Update -

    Updating positions for children isn't an issue since they can be set not track. When not tracking, there is basically 0 impact. However, the issue of not being able to set an array/dictionaries to hierarchies is still a problem, as you have to create a linked pair.

    I use Overboy's data+ behaviors, so the issue is mitigated. Alternates include using containers which (doesn't work with families) or uid standard linking.

    -----

    Hey all,

    Iʻm still mucking about trying to create a truly flexible, scalable, event sheet pattern that can handle dynamic and arbitrary inter-object relationships at runtime. Event sheet is key.

    Hierarchies are very useful in this, as they provide a way to traverse a parent/child pattern. You canʻt create such a system with families, as the links can only travel 1 layer deep before you have to have another family to track additional children. For example, you could have a family for top parents called System, their children are Components, the children of those are called modules, etc... Needless to say, using families, this pattern is not scalable. The family route requires repeating boiler plate logic for each additional type added.

    Great for hierarchies... but....

    Hierarchies demand that all objects are iworldinstances. Once again, construct has a neat feature that makes core assumptions about the use case of that feature, without considering all the applications that the feature could have had, had it been left open and singular in responsibility.

    Hierarchies, in principal, should have no need for position. Simply put, they define relationships between nodes.

    The reason this is important: Many times components define behavior in a system, and as such, using an object with position (that has to be calculated and updated) is unnecessarily bloated, increases overhead, and is performance degrading for no reason.

    While the issue of creating n-number of nodal relationships is solved with hierarchies, the constraint becomes component count. Ideally, modules solve a singular problem. You could break down the functioning of a single weapon on a tank into a dozens of modules. Multiply that by every engine, weapon, ammo box, and piece of armor on the tank. Thatʻs not good if every module now has to describe a position and is updated every tick.

    Back to the drawing board.

    ----

    If you donʻt understand why a component system is useful, consider the following - Lets say you are making a game where the player pilots customizable mechs. If the customization is knowable to the programmer, and the number of combinations is limited, its likely that hard coded solutions are acceptable. But lets say you can start with a frame, and add any number of components to it. Engines, batteries, fuel-cells, ammo, communications, sensors, thrusters, weapons, and so on.

    Even the weapon is customizable, the the player defining the magazine size, reload systems, triggering systems, barrels, etc...

    A tank is simple, until you consider that the player could put 5 canons on one turret, and a flamethrower on front, and bow and stern machine guns, and wings, because why not.

    If you can solve this problem in a flexible, scalable way, nothing the designer throws at the programmer will be a problem to add.

  • I like that way, but not if it needs to be used regularly in events through a single js block...

    Lets just say its fine, but if you have performance woes, avoid jsblocks inside loops at all costs. As a replacement for a custom action, for example, in a foreach obj loop, calling the function via js is like 300x slower than by event, as far as the raw overhead goes.

    On the other hand, if you have a function call from within a jsblock that is doing the iterating, that will be faster.

    TLDR is don't loop outside of a js block.

  • I believe instances are ordered and processed by their z-index. So A with the lowest z-index will be moved to B with the lowest z-index, and so on.

    Do you know why it is ordered according to z? Seems like it would be easier to leave in unordered from a performance/lazy standpoint.

  • I think many people have said they prefer c2 functions over c3 and for me personally that is because we cannot simply call a function from a string without it being first pushed through a router function.

    Router functions are nice for certain patterns, but sometimes you simply need a good old function pointer.

    Why canʻt we call a mapped function by string directly, and choose to send it parameters?

    The current implementation is unnecessarily rigid and overly complicated, and makes it impossible to have a 100% flexible function call.

Ruskul's avatar

Ruskul

Member since 23 Nov, 2013

Twitter
Ruskul has 2 followers

Trophy Case

  • 10-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • x6
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies