@jeffreyrb03-gmail My iframe embed over at my site now has “&autoPlay=true&btnOptions=none” at the end of it
Group Details Private
Best Forum Helpers
This group is for users who have assisted others by answering or helping with at least 5 situations. Eligible users may request to join the group.
Member List
-
RE: Feature request: more control over project embeds
-
RE: WOC Update Log
@tyller_ Here is the testing room link:
https://play.creaticode.com/projects/67b60b7a40002631c45cd8ab
Everything should work smoothly. There still might be occasional bugs, mostly consisting of the second bot (the second bot is annoying, I might nerf his attacks stats from 1 dmg 0.5 dmg. -
RE: WOC Update Log
@011830-0a42ef84 yeah, my idea is to use a list queue for broadcasts, the issue with my method is that the broadcasts call a bunch, so those variable parameters get called within the same frame and out of order, thus leading to the arbitrary order of what clone takes priority (this is called a race condition). I am actively very much debating how it would work, but I think the general idea I have is listed below:
- A list named “action queue” that is added to each time a sprite wants to broadcast something
- it adds formatted text to the list, in the format of “{clone id}|{broadcast}” (This works because my method only broadcasts what clone/ai the sensors are for, if other broadcast parameters were added it would need to slightly change)
- it then broadcasts the actual broadcast (no parameter cus that stuff is now in queue since parameters cause race conditions)
- the actual ai clone would now start handling stuff (before it was the sensor doing stuff), when it receives a broadcast it checks the queue list to determine if it was queued for that broadcast
- if it finds its id for that broadcast, so “{clone id}|{broadcast}”, it will run the code for that broadcast
Here’s an example for the 5th clone (so clone id is 5 or “ai&5” but their interchangeable so it doesnt matter which way I decide to handle the clones) handling the broadcast “behind player”:
- the sensor detects the player and needs to broadcast “behind player”
- It adds “5|behind player” to the “action queue” list
- It broadcasts “behind player”
- All the clones of the bot receive “behind player”
- They check if the broadcast is for them or if they have a broadcast queued since it could be trying to handle multiple broadcasts in the same frame, they do this by checking if “action queue” contains the result of joining their clone id and “|behind player” (so join(clone id)(|behind player) in the editor)
- If that broadcast is for them (or they have one queued) then they do what they do for the “behind player” broadcast
- They delete that line from “action queue” with teh delete value of list block
If this doesnt make sense I can try an example, I jsut wanted to list out my thought process
-
RE: WOC Update Log
@tyller_ That sounds good, after I stabilize everything in my test room I will let you implement it. Is that okay with you?
-
RE: WOC Update Log
@011830-0a42ef84 I’m going to mention something, the clone system I had should work but I think I know a way to fix it and not make broadcasts conflict, though there’s a chance it could be a bit hard to understand, tell me if you want to try to implement it and make it in a readable way
-
RE: WOC Update Log
@sirbots I believe I have fixed the second bot, although you can look through my code to see if anything is wrong or buggy.