Loop attribute name

ryast

Hey!

I have 5 scene attributes named like so:

Note1 (integer)
Note2 (integer)
Note3 (integer)
Note4 (integer)
Note5 (integer)

Then in my actor I have a bunch of Rules that is something like:

scene.Note1 = 1
{do something}

scene.Note1 = 2
{do something else}

scene.Note1 = 3
{do crap}

scene.Note1 = 4
{do some crap!}

scene.Note1 = 5
{do mega crap!}

Then the same thing for Note2 and Note3 and Note4 and Note5

As you can imagine those are a LOT of rules (it's actually 25 notes and 25 possible combinations for a total of 25x25!)

now to break it down and lessen my load by 25 times what I thought I could do was have an attribute called "counter" that would be equal to 1.
Then I simply loop over something like this:

scene.Note.counter = 1
{do something}

counter=counter+1

but I can't do the "dynamic attributes" thing listed above... so is there some other way of doing it or am I stuck with 600+ rules?

(Tables are out of the question, I did it via tables and tableCellValue(game.NotesTable, game.counter, 1) and I had performance issues)

Ideas?

Thanks!

tatiang

Tables are out of the question

That's unfortunate. I'm not sure why you had performance issues with table vs. attributes but I would definitely use tables for something like this. And yes, you would increase a counter attribute and use that for the row number of the table or just use the Loop over Table behavior.

Then again, why can't you "do the 'dynamic attributes' thing listed above"? What's preventing you from using a loop and including a counter attribute in your rules?

It seems like the problem here isn't tables or attributes. It's the fact that you have 625 rules. Can you explain why that's necessary? There are often ways to reduce this sort of thing. The last person who said "I need 1000 rules" was surprised to learn that he could reduce everything to two behaviors. In a single rule. I'm not saying that's the case for you, but why not crowd-source a solution?

ryast

I'm still new go GS... about 2 months so I totally accept that I could be doing something wrong (hence me writing here hoping some of the GS gurus will shine their light on me ) but this is how I was doing it with tables:

actor Spawner (on scene load)
run a loop over table and enter 25 random values (between 1 and 25) into the table TBL_Notes
(so now we have 25 rows that each contain a random number between 1 and 25)
save the table
set attribute flag_load_notes = true

actor: musicalNote (RULE flag_load_notes = true)
self.musical_note = tableCellValue(game.NotesTable, game.counter, 1)
self.position = game.counter
change table value self.position
change table value self.value
save table
set attribute flag_load_notes = false
set attribute flag_load_on_music_staff = true

Actor: MusicalStaff (RULE flag_load_on_music_staff = true)
Here I have rules 1 to 25 like so:
RULE numeric expression, tableCellValue(game.NotesTable, game.counter, 1) = 1
spawn actor musicalNote
position tableCellValue(game.positionsTable, game.counter, 1)

The above were the three main parts and I think number of calls to the tables up and down were a little too much and I was getting weird issues tilI put two of the actor's code in a timer of 0.6 seconds, if no timer or timer less than 0.6 (sometimes 0.7) it was getting screwy.

tatiang

@ryast said:
I think number of calls to the tables up and down were a little too much

You shouldn't notice table performance when doing something as simple as changing a table value 25 times in a loop. At 25,000 times I might expect a slowdown.

There's something else in your rules that's causing that but I'm not sure what it is based on what you posted.

I don't know how your game is supposed to work but you also might consider not spawning actors but just changing their alpha value to make them appear/disappear and then constraining certain attributes to the table values. Or you might still spawn them but not use any rules... just change/constrain behaviors. For example, a spawned actor might use a game attribute value as its row and set all of its self attributes based on that. It's hard to explain without having a better understanding of your setup but it can simplify things a lot.

ryast

I can send you the game if you want, it's pretty simple and in the early stages so pretty buggy but... a work in progress

tatiang

That would be fine. I sent you a private message also.

ryast

Replied to your PM

tatiang

A couple quick things I noticed about your project file:

1. It's best not to unlock actors (e.g. your spawner actor) unless you have a very specific reason for doing so. Unlocking an actor creates an instance with unique rules that differ from the prototype actor in the Inspector. I also find it a pain to edit them, but that's just me!

2. In a Loop over Table behavior, the index attribute is incremented automatically. No need to change game.loopindex to game.loopindex+1. If you add a Log Debugging Statement to that loop and open the Debugger window, you'll see that your value goes from 2 to 26 instead of from 1 to 25. The notes are repeating because you're choosing a random value from 9 to 17 each time and then storing that in a table cell. The random() function has no memory for its previous values... you might get 9, 9, 9, ...9, 9, 9 once. Or not. It's all probability! If you don't want it to repeat notes then you have to choose a "random" number from a table. So you'd make a separate table with a unique value (1 to 25) in each row. Each time you Loop over Table in your spawner actor, you'd choose a random row from that second table using random(1,tableRowCount(tableName)), grab the value in that row, and then delete that row so there are no duplicates.

ryast

In a Loop over Table behavior, the index attribute is incremented automatically.

Ah! Didn't know that, first time I had used this behavior. Was quite happy with myself for figuring it out... now it seems I only half figured it out

If you add a Log Debugging Statement to that loop and open the Debugger window,

No idea I could do that, already learned something new

It's best not to unlock actors (e.g. your spawner actor) unless you have a very specific reason for doing so.

I too prefer doing that but can't remember why exactly I used an instance except I know that I ran into some problem...

The notes are repeating because you're choosing a random value from 9 to 17 each time and then storing that in a table cell.

The notes repeating, eg: 9 9 9
is fine, the note repeating and covering the last note is a problem.
The only way to see this is to see the numbers on top of the note's overlap...

Open the file I sent you and you will see it happens only with the first 2 or 3 notes, the get spawned right on top of each other (occupying the same space - that should not happen but it does)
Like I said, it happens only on the first notes and if the timer is lowered from .6 to .2 it happens even more...

tatiang

There are two reasons for making an actor into an instance: to access scene attributes (especially camera values) and to modify a prototype actor in some way (e.g. a different color, size, self.Health, add or remove a few rules, etc.).

Ah, sorry, I misunderstood the repeating part. I see what you mean now about the actors overlapping.

tatiang

As I said in my private message to you, you'd be better off with a table system for the spawned actors' positions. You have quite a few redundant rules that could be merged into a single rule where the only thing that changes (and is taken from the table) is the X/Y position of the spawned actor. With as many rules as you have now, it's going to take a careful eye to figure out why the overlap is happening... I suspect you just missed somewhere where there are duplicate values.

ryast

Yep, the whole thread was to fix that overlapping thingy
as you can see the rest is not really pretty... but it's do-able

ryast

I suspect you just missed somewhere where there are duplicate values.

Will give it a go over again after a cup of coffee but it still does not explain why it happens when the timer speed is high compared to when the timer is firing slowly...