Tables unable to handle simultaneous changes to multiple cells?
Somebody said that when a table changes a value, they make a copy of the table and delete the old? Thus that imply only a single cell value can be changed at a time? And if you try to change two values at the same time, it will not go through?
During my testing, I noticed weird things like if two enemies are being hit, despite the actor for damage appearing over them, their HP value does not change? Very strange as the activation for the damage is no longer collision, but the switching on of a self-integer. I'm gonna do two more tests, involving the integers activation being from the row value being over 0, and another where it only destroys itself once it activates that self.integer.
My only other theory is that an enemy popped up when damage was being dealt, moving the rows around.
IF the table thing is true, then I'll just move the HP values to game.attributes, and use the table solely for the X,Y locating and identification. If using game.attributes, I would have to limit the total number of enemies to somewhere between 5-8 at a time, which is fine.
I noticed another thing, it appears that values all the way at the bottom of the game.attributes area don't make it in time for calculations done in 0.06 timeframe, while attributes near the top do make it in if in an equation. Maybe it's just I typed something wrong though. But it does appear that if you want game.attributes to be fast in their calculation, you need them near the top of the list, and leave those that don't need instant calcs at the bottom. Anybody can confirm this? It's just based on my limited knowledge about how things work.
EDIT: I manage to get the same actors bullets converge on a single target and destroy it for stacked damage, while if the enemy was just hit by 1 or 2 of the bullets at the same time, they would only receive partial damage equaling that total.
For this method, I just transmitted the row value to a game.attribute to identify the target. But if I want to make full use of this, I would have to make multiple game.attributes for multiple targets. Right now, just a single target can receive full shotgun damage. Any enemy that wasn't the initial target will receive no damage since only a single enemy can be identified at a time by the bullets. I'm thinking of just making this, and the gatling, the only two of the 27 attack techniques to have such a feature. Since the other attacks were built to work around the old limitation anyway.
EDIT: These latest tests suggest that perhaps tables can handle simultaneous changes? Perhaps something else is behind damage sometimes not registering. The HP on the table not changing becomes more apparent the higher the row number is and the more complex the damage formula is(in some versions, it was using two game.integers along with a self.integer, which would slow down the calculation speed.). I get guaranteed damage if I keep it a simple -x or -self.integer. But in some cases, the way an attack moves somehow interferes with the x,y registration of the enemy. I do remember putting in some special thing for a few attacks to do something to an enemy's x,y or some property of it that changes it? This is tough. Some of the attacks don't make sense in how they interfere with the prevention of table damage. Especially those that constrain themeselves to the actors x,y, since their own x,y has nothing to do with the way damage is detected or dealt, other than mere collision, and the presence of the damage actor upon collision makes it all the more perplexing, since its presence is meant to guarantee damage, but yet it's not dealt. Even the X,Y's it displays match up with the target X,Y, thus it should find the row of that enemy.
I've noticed when an enemy actor is newly created and the rows are at least around 10 that that is when damage starts to not register initially, but after a few tries will, then eventually after several enemies have been destroyed, some attacks can't register damage at all.
Comments
A "change table value" does not cause a new table to be created and the old deleted.
This only happens if you add or remove rows and memory needs to be reallocated.
Things never really happen at the same time in GS. Actors get processed sequentially bottom up according to their order in the scene layers, and the code inside them top down.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@hopscotch I appreciate the sharing of this information, thanks! The static table without the use of add row is starting to look appealing. Add row might be messing with the calcs perhaps.
Ah, I thought everything was top down with processing. Thank you again for this information. It will prove to be invaluable with the testing.