Object().

Post reply
0 favourites
  • 10 posts
From the Asset Store
Building Hidden Object Browser Games
$9.99 USD
This is a single chapter from the "Construct Starter Kit Collection". It is the Student Workbook for its Workshop.
PBMCube's avatar
PBMCube

  • Ashley you said:

    Sprite(0).X gives you the first picked sprite instance's X, Sprite(1).X gives you the second picked sprite instance's X, and so on.

    But I don't see that happening to picked objects. Sprite(0).x always gives the first index.

    Not that a expect a change at this point in time.

    construct3.ideas.aha.io/ideas/C3-I-1178

    And a project to explain what I'm seeing:

    dropbox.com/s/8mhjqpky6imlokm/spriten.c3p

  • Huh. I always assumed object(iid) let you use values from any object, not just the ones that were picked (which is what is currently happening). Also I didn't see the manual specify that IID list changes based on picked instances (then non picked instances wouldn't have an IID during picking?). Clearly IIDs can get changed as instances of any given object get created and destroyed, but I didn't think that would happen during picking.

    But based on Ashley's comment this doesn't seem to be intended... Maybe just slipped his mind about how index based expressions were set up? Just checked the earliest version of C3 that still worked and C2 and the current behavior is consistent across them, so changing this would decidedly be a breaking change... and the suggestion was talking about something else anyway.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yeah I'm not sure what he means here.

    It would be cool if we had something like that, but yeah it would break things if it did this as described.

  • The "Pick Nth Instance" system condition works as described, picking only out of currently picked instances. So we kinda do already have it.

    The object(n) expression does not seem to care about picking, but can reference the full instance list of that object.

    The suggestion is about referencing UID in an expression. But its probably more of a quality of life niche case type of thing, as picking by UID can already be done by condition as well. Might save a few events here or there. The example Tacker gave could simply be done with a For Each player instead, or add an instance variable to narrow the scope by picking as normal.

    The ability to specify only picked IID's (they call them SOL ID?) in expressions might facilitate the whole "how to I refer to and manipulate two instances of the same object colliding or otherwise interacting" without resorting to the common object and family workaround though! Maybe. That would be the fireball part of Tacker's example, and that's where I would be really interested. But that is what Ashley dismissed as already existing, which doesn't seem to be the case, so it's probably good to call attention to it.

  • I just checked, and... I was wrong, Sprite(N).X does index within IID ignoring all the picked instances. Oops.

    I think that is the wrong decision and the feature should not work like that, but it's probably too late to change now for backwards compatibility reasons. This is kind of a mess. I'd rather not touch it, and rather not add any more features that extend the mistake any further.

  • Actually its quite useful to be able to reference an object that's not in the SOL, and not wind up having it being put into it. Although it might be a nice feature to have one day, just one that works in a different method.

    Thank you for clearing that up.

  • I think that is the wrong decision and the feature should not work like that, but it's probably too late to change now for backwards compatibility reasons.

    This is one C3 flaws. Why not give users a way to make small changes and make it somehow work. Any other engine, js or some other library, developers would give correct code snippets or a possible solution, so others can change behaviors. But not in C3, why sooo ? 

    	ExpObject(...args) {
 const objectClass = this._objectClass;
 const instances = objectClass.GetCurrentSol().GetExpressionInstances();
 const len = instances.length;
 if (len === 0)
 return this._returnsString ? "" : 0;
 const index = WrapIndex(this._owner.GetSolIndex(), len);
 this._eventStack.GetCurrentStackFrame().SetExpressionObjectClass(objectClass);
 return this._func.apply(instances[index].GetSdkInstance(), args)
 }
 ExpObject_InstExpr(instIndex, ...args) {
 const objectClass = this._objectClass;
 const instances = objectClass.GetInstances();
 const len = instances.length;
 if (len === 0)
 return this._returnsString ? "" : 0;
 const index = WrapIndex(instIndex, len);
 this._eventStack.GetCurrentStackFrame().SetExpressionObjectClass(objectClass);
 return this._func.apply(instances[index].GetSdkInstance(), args)
 }

    If those two case fail, why not give users correct code snippet and they can paste it in, when having such case for example.

    C3 full of such cases: random behaviors, cannot change anymore, half-baked stuff. Which in core aint hard to change, but cannot modified because backwards compatibility, someone might still use it or what not.

  • I was thinking one way to perhaps do this without digging in to the C3 codebase would be to do it via a behavior. You add the behavior to an object, and if the object is picked you can reference it's picked index in the sol something in a form like you can with the iid or Sprite(0), but instead using the behavior Sprite.myPickBehavior(0)

    I don't know enough about code to say if that's even possible, but it would be pretty slick.

    Then again I don't know what else the behavior could do, other than perhaps work as some class type of thing such as Solid did in Construct Classic, minus the solid physical aspects.

  • I am not talking about the idea to know how to code.

    I mean i don't know what scirra codes does, but one does not need to. Lets say there is a case. Something picks or behaves wrongly.

    Scirra does not want to change it or do alternative way for it, because then they have to maintain 2 case. But possible solution for it, is some 2-3 lines of code.

    Then in this case, there should be possible solution, so users can easily modify it and Ashley can give user the code snippet.

    Sprite(0) picks from all sprites.

    But if user inserts Sprite(0,0) then engine is able to pick picked list with error.

    Difference between is 2 lines. Not sure if the first is even used, but this is just example.

    First has: const instances = objectClass.GetCurrentSol().GetExpressionInstances();

    Second has: const instances = objectClass.GetInstances();

    Without knowing code. You could swap them around. Lets assume, they say correct is XYZ and then users can use that, even if it fails somehow.

    Now if They give the snippet and it stops working and enough ppl used it, it's sign someting like that is needed and should get official stable support.

    You can see there is objectClass.GetInstances(); Which lets assume get all instances.

    You swap it with objectClass.GetCurrentSol() you get different list. It's like swapping events. I think original idea wanted IID,UID etc. then you change it a bit and it works like you want, even if some cases bug. Like what does'nt.

    I know something like that can get messy rly fast, but there could be official plugin that corrects code paths n such, if they change or rename them.

    Maybe it all doesn't work like that, but if they make it work, it sure would be nice.

  • All software has to deal with backwards compatibility considerations, including libraries and frameworks. In many cases it's very easy to change something, but will break a huge amount of things dating back many years, causing on-going problems for lots of users for years to come. If it's that disruptive, normally the conclusion is it's not worth the trouble. As I said, this affects all software - imagine Windows removing support for Win32 apps in favour of only .NET apps. It would be absolute chaos and they'd be forced to reverse the change, even if you could prove .NET apps were far superior in various ways. Microsoft can foresee this, so they're unlikely to ever make such a radical change, even if it would make the product much better. So in that situation they're also stuck with a system that is maybe not ideal, but is better than causing a massive amount of disruption.

    One of the big mistakes with C2 was people could modify the plugins and behaviors. This might seem like a useful thing to be able to do, but it caused awful, awful compatibility problems. It was a total nightmare. In some cases you couldn't even open the same project in two different versions of C2 if you had modified addons. If you did a fresh install of C2 maybe your old projects would no longer open. We could not offer any kind of support at all, on the forum, by email, or in bug reports, if anyone had changed so much as a single line of code in C2, since they could easily have broken things themselves. A bunch of people went ahead and did it anyway and then got upset at the consequences and ended up begging us in support to fix all the problems they ended up with, such as corrupt projects, and so sometimes we got dragged in to supporting them anyway. It was so bad that this is absolutely categorically not an option for C3.

Post reply
  • 10 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)