R0J0hound's Forum Posts

  • It's a quirk or feature depending how you look at it with how created objects aren't generally pickable right away or how destroyed objects aren't destroyed right away.

    The logic behind it is under the hood the event system maintains four lists of instances of the objects. 

    sprite.all = []
sprite.picked = []
sprite.new = []
sprite.deathrow = []

    At the start of an unnested event picked is set to all the instances. Conditions after that will filter the picked instance list.

    When you create an instance the picked list will be set to only the new instance and that instance will also be added to the new list.

    When destroying an object it will be added to deathrow, but it won't actually be removed yet.

    So eventually the event engine has to do some bookeeping and update the all list by adding new instance to it and removing deathrow instances form it. Generally that occurs after each unnested event. However, trigger events that were called from another event don't follow that since they can be considered running in place where they were called.

    To illustrate that here is a simple example. 

    On click
-- create sprite
-- call function
-- sprite destroy

on function
-- create sprite

    Ok, now here is very verbose view of what is going on with those lists following those rules. Lets assume you started with one instance of sprite: A. 

    # all=[A] picked=[A] new=[] deathrow=[]
On click
# all=[A] picked=[A] new=[] deathrow=[]
-- create sprite
# all=[A] picked=[B] new=[B] deathrow=[]
-- call function
# all=[A] picked=[B] new=[B, C] deathrow=[]
-- sprite destroy
# all=[A] picked=[B] new=[B, C] deathrow=[B]
## bookeeping is done here
# all=[A, C] picked=[A, C] new=[] deathrow=[]

on function
# all=[A] picked=[A] new=[B] deathrow=[]
-- create sprite
# all=[A] picked=[C] new=[B, C] deathrow=[]

    You encountered another quirk of picking when you used the sprite.count expression in one of your examples. Basically, if there are no picked instances of an object all it's expressions will return 0. So you had the following in your example. Since you stated with no instances there will be no picked instances in the function so the expression is 0. 

    On click
-- create sprite
-- call function

on function
-- set text to sprite.count

    or verbosely: 

    # all=[] picked=[] new=[] deathrow=[]
On click
# all=[] picked=[] new=[] deathrow=[]
-- create sprite
# all=[] picked=[A] new=[A] deathrow=[]
-- call function
# all=[] picked=[A] new=[A] deathrow=[]
## bookeeping is done here
# all=[A] picked=[A] new=[] deathrow=[]

on function
# all=[] picked=[] new=[A] deathrow=[]
-- set text to sprite.count
# all=[] picked=[] new=[A] deathrow=[]

    There may be better ways to convey how that works, but generally I've found most don't really grasp it.

    As to the wait 0 solution that has it's own side effects. The main one is it delays the stuff after it from running till the end of the event sheet, which may or may not be a problem if you are relying on things to run in a specific order.

    Another way around the picking could be "pick by uid" like dop suggested, but I've found that mostly only useful in simple cases.

    What generally try to do to avoid the create/destroy shenanigans is to create objects in one event and do the picking stuff in the next, but that largely depends on what you're doing.

    It's not really useful with nested events but for simpler ones like above I duplicate the event and split the events between them. 

    On click
-- create sprite
-- call function

on click
-- sprite destroy

on function
-- create sprite
    On click
-- create sprite

on click
-- call function

on function
-- set text to sprite.count

    Finally a third way is to deal with the picking system as little as possible and deal with lists of objects in a more traditional programming fashion. That's many's motivation to use js for example.

  • I thought the unofficial discord is basically the official one. All an official discord would change is maybe moderation by Scirra staff instead of community members?

    Anyways, I suspect the reason they never made an official one is simply because they never made one, and there’s no point of making an official one now since the unofficial one is well established and an effective hub in all the ways you noted.

  • 3d is ambitious, especially for 8 year olds.

    Anyways, here are a few ideas to help debug it.

    Since it seems to have to do with loading chunks as you move around, you could just make the camera have a top view to help see what’s going on.

    If it’s leaving gaps moving one way then maybe it’s overlapping the other way.

    When creating the chunks are you creating them relative to the player or to fixed chunk locations? A collision will occur after some overlap which can get worse with lag. Maybe that’s something to consider.

    If nothing obvious stands out I’d consider redoing the chunk system from scratch. You can prototype it fast in a fresh project in 2d if you like. That would be much easier to debug and identify shortcomings. You could even do it in 1d, like a side view platformer to get the chunk idea working with minimal effort. I personally find that designing something on paper first makes it way more robust than doing it all in code as you go along.

  • You could create the objects with one event, or just place them with the editor.

    Then with a second event you could set the frames.

    Maybe: 

    start of layout
For each sprite ordered by random(1)
— compare: loopindex=0
— — sprite: set frame to A
— else
— compare: loopindex<=2
— — sprite: set frame to B
— else
— — sprite: set frame to choose(C,D,E,F)

    Or you could use an instance variable to mark the sprites as unset and have a series of events to pick a random instance of the unset ones, and set it and set a frame.

    A third way to look at it is to make a list with an array or text variable, and populate it with on A, two B’s, and n amount of a random cde or f’s. Then you’d shuffle them before setting the frames.

  • This will loop over each of objB and pick any objB with a variable that matches B's uid. If you only have one instance of objB you can omit the loop. 

    for each objB
objA: variable=ObjB.uid
-- do something

    If no instances of objA are picked the event won't run. However, you can utilize else for the case when nothing is picked. Mind the indention that represents nested events: 

    for each objB
-- objA: variable=ObjB.uid
-- -- do something if 1 or more A's are picked
-- else
-- -- do something when 0 are picked

    Extending on that you can know how many instances are picked with the .pickedCount expression. But again, bear in mind that an event won't run if no instances are picked so you still need to utilize else. 

    for each objB
-- objA: variable=ObjB.uid
-- -- text: append objA.pickedCount&" instances picked"&newline
-- else
-- -- text: append "0 instances picked"&newline

  • Probably a bug then. Perhaps it’s not really used often enough to be noticed before.

  • You probably can get some more info about what didn’t work by looking at the browser console. Shift+ctrl+ i in chrome and edge.

    There are loads of limits and restrictions with web stuff. Generally i think iframes prefer urls with the same origin as your games url. If the url has a different origin then there may be a different set of rules and restrictions for that. Google could even block itself from loading from inside an iframe i’d imagine. It’s all likely very similar to the limit of loading images from different origins (CORS).

    You can refer to the mdn site for details or stackoverflow for some more specific solutions perhaps.

    In the case of Google supposedly this link would work based on someone on stackoverflow, but I haven’t tested.

    "https://www.google.com/webhp?igu=1"

  • Ah, I’ll pull the link for now then.

    Edit:

    Updated link to work with your example too. I should have tested more.

    If files are reported as missing in the generated c3p I'll keep the link striked out for now. I haven't seen errors like that, but I may just need to test on a heavier project. If it's an issue with the jszip library then maybe switching to zip.js (which c3 uses) would be an option.

  • What if you use normal blending instead of additive and mess with the opacity a bit?

    Or maybe use an off white for the background?

    You could also try staying with additive and placing the fire on its own layer, then make that layer black and not transparent, and finally add an effect like “screen” or something to the layer.

  • dop2000

    I wanted to experiment with modifying zip files, and the idea of cropping rle data sounded interesting so here's something similar to your script that runs on c3p files directly using a js zip library.

    To use you select a c3p file, it crops all the tilemaps, and finally downloads a modified copy. yourGame.c3p -> yourGame_tilemaps_cropped.c3p

    https://www.dropbox.com/scl/fi/bq5x4pphbsdil2p16ox6t/c3p_tilemap_cropper.c3p?rlkey=jsag5662smgxbpl2leos633hy&st=9je4x6p0

    Edit:

    Pulling for now since there are issues beyond my testing.

  • What’s amiss with the image? I’m not able to follow what you see as an issue.

    Should both gears have their own outline instead being outlined as if they were merged first? That would mainly be a matter of adding the effect to the objects individually instead of the layer.

    Otherwise I’m not sure what you’re describing.

  • It should be automatic to just crop when resizing. If they want to preserve the outside tiles in case of accidental resizes it should be part of the undo stack or strictly temporary instead of never cropping smaller ever.

  • I don’t think that it’s something that can be debugged from videos or even screenshots of events. Generally, more events means it takes more effort to get familiar with what you’re doing before even being able to debug it.

    Since it sounds like it’s become complex and is hard to debug you could rewrite it from scratch after working out on paper exactly what you want it to do. Then just do a bunch of tests to verify it’s working as expected as you actually add the events. That’s my usual strategy when making stuff.

    Or you could outline how you want it to work and I’m sure there are lots of users that would give suggestions or examples how they would do it.

    Personally I’d make such an inventory with sprites instead of arrays. I’d make two sprites: slot and item. Then I’d place instances of the slot sprite all over and place items on top of them. You could indicate if slots are occupied or not and the number of items with some instance variables.

    Then with minimal events you could place items into slots, or swap out the item you’re holding with the one in the slot. But ultimately it’s up to you how you want to go about it.

  • Kudos for finding the cause of your projects running out of memory.

    Can’t it just be reported as a bug so it gets fixed? Seems like an oversight that space gets reserved for the biggest we’ve resized a tilemap instead of only storing the visible ones used.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I haven’t had this issue but hopefully it’s investigated to some degree. If it works most of the time then the glitch could be something we are never able to find repeatable steps for.

    Maybe it’s too much to expect, but I’d hope that sometimes the codebase is combed over to find issues instead of only addressing repeatable issues as they come up from users.

    I’m probably a bit salty about bugs because of some unleaded software that I’m forced to use that seems to deteriorate more with every update.