If you need a cool goody load-out selection screen, maybe I can reciprocate with that.... (although the code probably looks horrendous compared to what you'd create!)
Not sure what that is but I'm a big supporter of contributions to the community! Let me know how you get on with the project - you can be a guinea pig to see how ready for release it was!
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,170
So there is a debug console behavior. you could use that for now, but I agree that it would be nice to have watchers that allow you to view debug data / expressions. So I'm gonna sound like I'm on repeat, but be sure to post the feature request to bugs.gamesalad.com.
Here's my suggested flow:
1) Post your feature suggestion here since people are watching.
2) If there's some agreement, make a feature request on http://bugs.gamesalad.com
3) Start a new thread and post a link to the feature. Also post a link back from the feature to the forum thread. That way if the community comes up with good info in the thread, we can look it up before we work the feature. Putting a forum thread lets people talk in a more natural area (rather than discussing in the Feature Request system).
This helps make sure stuff doesn't get lost and lets everyone communicate more naturally about features!
@adent42 Yeah, I've used the debug console output quite a lot, but if you're trying to get a feel for what the state of a table is, it's gonna take a lot of (or loop logic etc), debug statements, so while I do use debug for certain stuff, and I get you on this, I don't think it's really workable for complex multi-table checks... :frowning:
Suggested flow sounds good, but atm I'm still wary of investing time trying to officially raise something, create threads, cross-link etc, without seeing a few existing long-standing 'biggies' attacked and worked on...
@Japster said: @adent42 - Just had an absolute NIGHTMARE trying to keep track of table values in a really complex selection routine, even trying Stormy's util, so I have to say, some kind of debug window which shows a real-time view/window into the contents of a table or tables, would be seriously helpful guys
Feature suggestion , to spawn more than one actor from one spawn behavior , it gets messy when i want to spawn 5-10 actors together in one rule. If its possible or easy to do , it would make things organised.
Something like this maybe . ( i didnt add "relative to" but just to get what i mean )
@Icebox said:
Feature suggestion , to spawn more than one actor from one spawn behavior , it gets messy when i want to spawn 5-10 actors together in one rule.
I always thought there should be a number field in the Spawn behaviour that sets the number of actors to be spawned, for example Spawn X actors at . . . .
While you guys are at it: something I miss dearly in the spawn behavior is the option to set attributes for the newly spawned actor on creation. That would make a lot of stuff easier and more dynamic. Right now you need to spawn on a certain position and in the spawned actor you need rules to check the starting position and react to that and so on to come close to this functionality. And of course this method has its limits.
@Japster said: @adent42 - Just had an absolute NIGHTMARE trying to keep track of table values in a really complex selection routine, even trying Stormy's util, so I have to say, some kind of debug window which shows a real-time view/window into the contents of a table or tables, would be seriously helpful guys
Yeah I know! That's what I meant with using the position. I use this method and the proposed functionality is nowhere near as important as dozens of other features. But still - the possibility to simply change like 5 attributes to a value on creation would speed up my workflow by quite a bit and make things a bit easier.
@birdboy said:
. . . the possibility to simply change like 5 attributes to a value on creation would speed up my workflow . . .
Numbers have unique qualities, so you could use those qualities to extract information from the number other than its absolute value.
An obvious example would be odd and even numbers, they are clearly different (we can use modulo to check the number's parity).
So . . . from that simple example we can see that we can easily pass two pieces of information from the spawner to the spawned actor, the original number and its parity.
Is the number 14 ? Yes. Then do X
Is the number divisible by 2. Yes. Then do Y
Is the number divisible by 7. Yes. Then do Z.
14° would give us X, Y and Z
28° would give us Y and Z
21° would give us just Z
16° would give us just Y
19° would give us nothing.
. . . and so on.
You can extend this idea indefinitely as far as I can see (I'm pretty sure that's the case), extracting 5 unique values ("the possibility to simply change like 5 attributes") from a number shouldn't be too hard.
tl;dr . . . innate in a number - smuggled in through the angle of the spawned actor - are lots of unique qualities that can be used to communicate more that one value.
That's an impressive way of working with the passed number @socks!
Another solution that's probably not ideal in terms of extra workload parsing it (but hey, you only write it once, right? ), is that I also figured you can use the tried and trusted method of splitting the number up by flooring and/or flooring then subtracting...
Say you want to pass a flag for a weapon/shot type, whether it tracks you, etc, you can use a single actor for different types, and pass in the values in the largest number allowable - ie. if limited to 360 (though I think rotation angle can be set much, much higher, so more digits available (see below!) - but I digress... ie. a value 237 could be used to pass in both 2 (Maybe shot type) and 37 (maybe speed of lining up, etc, etc), or 23 and 7, etc, and if a donor attribute can be high enough, you can even populate X amount of digits for info, eg, integer fields might give a few numbers at a time - 2 billion or so is a lot of digits, just cutting them into say, 3 at a time if you need numbers 0 to 999, 4 at a time if you need numbers 0 up to 9999, etc...
...and if you want to maintain the same amount of digits, you can always use the highest digit, and set it to 1, eg:
1,423,456,302 could be used to send in (ignoring the '1' at the begininning) 423, 456, and 302, or.... 42, 34, 56, 302, or 4,234 , 5,630, etc etc...
Not ideal in terms of getting your head around it, but if you designate some set digits of each section of the number, for the value you're passing in, it should work fine?
@birdboy said:
Yeah I know! That's what I meant with using the position.
Using the position (X,Y) values can lead to problems if you are not careful. E.g. if you passed a large number, which would spawn the actor more than 500 pixels outside the scene size, then the spawned actor would automatically get destroyed by GS's housecleaning before you could change its position.
Using the direction field has a similar trap, as the number can only be in the range 0 to 359.
If you need to pass large numbers, or multiple values, it is best to use the decimal places.
As @Socks says, there are many ways in which you can pass numerous combined values just in the rotation/direction field.
E.g. create a structured number...
0.4075003
where the first digit (0) indicates enemy's direction
the second digit, first digit after the comma (4) indicates enemy type
third to fourth digits (07) indicate its level
fifth to seventh digits (500) indicate its health pool
eighth digit (3) indicate its color
In the spawned actor, just use the textSubStr function to pick out the pieces.
Another thing i would really love to see , is to access scene attributes without unlocking the actor. would be really beneficial in many cases . We wouldn't need to keep track of player's (position /velocity/rotation ..etc ) or create game attributes at all ( except for saving) . It will save alot of memory and calculations in our games. If its possible please consider it
@Icebox said:
Another thing i would really love to see , is to access scene attributes without unlocking the actor. would be really beneficial in many cases . We wouldn't need to keep track of player's (position /velocity/rotation ..etc ) or create game attributes at all ( except for saving) . It will save alot of memory and calculations in our games. If its possible please consider it
I suppose that would only be limited to the default scen attributes and not attributes you add? I might be wrong here but having access to scene attributes that we create outside that specific scene would end up being a nightmare since each scene has different attributes. Game attribute end up being the easier/same choice. Unless of course your're referring to the default scene attributes. (I hope I made sense)
@fmakawa I mean to access layer actors , the most common example would be to track player x and y.
instead of creating 2 real game attributes and constrain them to self.position x and self.position.y.If we had access to current scene attributes we can use the position of the player on any other actor , so we wouldn't need to add these 2 constrains and create game attributes in the first place.
I've just realised, as much as custom colliders are great, another great feature would be to have SIZEABLE standard colliders - eg - I have star-shaped bonuses, with circle colliders, and so these colliders are too big to nestle the buttons as close as I need them...
So.... I'm having to try and create custom colliders (and for some reason, PBE didn't allow me to create a circle shape collider last time I tried (maybe it's something I'm doing!)), whereas a simpler, MUCH faster option would be to set the standard collider radius / width/height (absolute, or percentage of actor size - 70% / 110% etc) - ie. smaller circle, smaller square, larger circle, etc...
Would remove a LOT of the current need for more creation of custom colliders just for the simpler items and actors which would just benefit from having a smaller 'hit box'.... (Bullets, ships, bullet grazer shmups, etc)
Just a thought - might be a simple change to add at some point!
It is painful to change the camera size and maintain HUD actors size and position. We need an easy way to zoom in/out without effecting the HUD layer or specific actors , maybe a lock to maintain its scale. If anyone thinks its a useful feature please vote .
@Hopscotch said:
Using the position (X,Y) values can lead to problems if you are not careful. E.g. if you passed a large number, which would spawn the actor more than 500 pixels outside the scene size, then the spawned actor would automatically get destroyed by GS's housecleaning before you could change its position.
I think if you spawn an actor even 10000 past the scene size, as long as it just sits there and has no move behaviour active, it actually doesn't get destroyed by GS automatically.
That said, I usually use structured numbers in the angle for passing on attributes.
@birdboy said:
While you guys are at it: something I miss dearly in the spawn behavior is the option to set attributes for the newly spawned actor on creation.
The general problem with this is that GS has no idea what the user-made attributes in that actor are, unless they put in some sort of 'scanner' for that purpose. I agree it would be great, but it is probably quite unlikely due to the complexity of such a feature.
@adent42 these are the things I'd love to see fixed while you are at it.
BUGS TO FIX:
-- Text behaviour does weird stuff when turning on/off with Visibility, ultimately one Display Text shows more than one text, overlapping, unreadable. http://bugs.gamesalad.com/show_bug.cgi?id=1274
-- If you are changing the scene camera size in-game, mouse.position stops reporting the position you are touching on device, breaking game logic. http://bugs.gamesalad.com/show_bug.cgi?id=408
-- The one where touch is not registered on devices on the first 10% or so of the screen's left edge. This can be really bad if important UI elements are close to the left edge, as they will not respond properly to user touch! I didn't submit a bug report for this personally, but I think one of the Team might have, this was discussed through ChatBubble.
-- The one where the scene camera is always 0.5y and 0.5x off-centre.
NEW FEATURE HOPED FOR:
-- iCloud sync, at least for tables. Great for playing across multiple devices or when you get a new phone, to continue playing without losing score/progress. http://bugs.gamesalad.com/show_bug.cgi?id=962
i really hope the new game salad browser thingy will work broader with the variety of android devices.
Across my games I get the occasional 1 star rating because the game doesn't start properly, or crashed after a while of playing and always remains in the start screen frozen.
Thats nothing new its within my app reviews since 2+ years and only affects android/google play versions. Not on iOS.
@pHghost
You can use Appformative or Gamesparks for Cloud saving even cross-platform which is better i think, beside the extra register/login step for the user.
I use cloud saving since the last weekend and works nicely
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
@pHghost said:
I think if you spawn an actor even 10000 past the scene size, as long as it just sits there and has no move behaviour active, it actually doesn't get destroyed by GS automatically.
I just tested this and an actor beyond about 500 pixels outside of the scene gets destroyed whether moving or not.
@pHghost said:
I think if you spawn an actor even 10000 past the scene size, as long as it just sits there and has no move behaviour active, it actually doesn't get destroyed by GS automatically.
I just tested this and an actor beyond about 500 pixels outside of the scene gets destroyed whether moving or not.
You can't spawn an actor more than 500 pixels beyond the edge of the scene, but you can place actors there, for example 'change x position to -50,000' will work fine, the actor will move there as long as it doesn't move once it's there.
tatiangMember, Sous Chef, PRO, Senior Sous-ChefPosts: 11,949
@Socks said:
You can't spawn an actor more than 500 pixels beyond the edge of the scene, but you can place actors there, for example 'change x position to -50,000' will work fine, the actor will move there as long as it doesn't move once it's there.
@Socks said:
You can't spawn an actor more than 500 pixels beyond the edge of the scene, but you can place actors there, for example 'change x position to -50,000' will work fine, the actor will move there as long as it doesn't move once it's there.
Those actors sure are finicky! Good to know.
It's even weirder than that, you can (depending on the position you start your actor) move your actor with a timer ( every A, move B ), so something starting on x600 can be moved with a timer, every A seconds, by B pixels . . . . for example
Every A
--Change X to X-2000
. . . and it will continue to move left without any issues, display its position in the middle of the screen and you will see it continue on its way.
But change the start position to something like 627 and the actor will be killed (indicated by the Display Text behaviour disappearing from the screen) somewhere around -x850px (rather than the standard -x500px)
Comments
Not sure what that is but I'm a big supporter of contributions to the community! Let me know how you get on with the project - you can be a guinea pig to see how ready for release it was!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
So there is a debug console behavior. you could use that for now, but I agree that it would be nice to have watchers that allow you to view debug data / expressions. So I'm gonna sound like I'm on repeat, but be sure to post the feature request to bugs.gamesalad.com.
Here's my suggested flow:
1) Post your feature suggestion here since people are watching.
2) If there's some agreement, make a feature request on http://bugs.gamesalad.com
3) Start a new thread and post a link to the feature. Also post a link back from the feature to the forum thread. That way if the community comes up with good info in the thread, we can look it up before we work the feature. Putting a forum thread lets people talk in a more natural area (rather than discussing in the Feature Request system).
This helps make sure stuff doesn't get lost and lets everyone communicate more naturally about features!
@adent42 Yeah, I've used the debug console output quite a lot, but if you're trying to get a feel for what the state of a table is, it's gonna take a lot of (or loop logic etc), debug statements, so while I do use debug for certain stuff, and I get you on this, I don't think it's really workable for complex multi-table checks... :frowning:
Suggested flow sounds good, but atm I'm still wary of investing time trying to officially raise something, create threads, cross-link etc, without seeing a few existing long-standing 'biggies' attacked and worked on...
@Japster -- meanwhile, here is a project from the spare code thread that might help:
http://forums.gamesalad.com/discussion/comment/504291/#Comment_504291
Feature suggestion , to spawn more than one actor from one spawn behavior , it gets messy when i want to spawn 5-10 actors together in one rule. If its possible or easy to do , it would make things organised.
Something like this maybe . ( i didnt add "relative to" but just to get what i mean )
I always thought there should be a number field in the Spawn behaviour that sets the number of actors to be spawned, for example Spawn X actors at . . . .
While you guys are at it: something I miss dearly in the spawn behavior is the option to set attributes for the newly spawned actor on creation. That would make a lot of stuff easier and more dynamic. Right now you need to spawn on a certain position and in the spawned actor you need rules to check the starting position and react to that and so on to come close to this functionality. And of course this method has its limits.
Thanks @RThurman, appreciated! - Sorry, thought I'd liked and responded to this already, but I was mistaken... :frowning:
@birdboy yes it would be nice.
But here is an easier workaround I use all the time:
http://forums.gamesalad.com/discussion/comment/596989/#Comment_596989
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Yeah I know! That's what I meant with using the position. I use this method and the proposed functionality is nowhere near as important as dozens of other features. But still - the possibility to simply change like 5 attributes to a value on creation would speed up my workflow by quite a bit and make things a bit easier.
Numbers have unique qualities, so you could use those qualities to extract information from the number other than its absolute value.
An obvious example would be odd and even numbers, they are clearly different (we can use modulo to check the number's parity).
So . . . from that simple example we can see that we can easily pass two pieces of information from the spawner to the spawned actor, the original number and its parity.
Is the number 14 ? Yes. Then do X
Is the number divisible by 2. Yes. Then do Y
Is the number divisible by 7. Yes. Then do Z.
14° would give us X, Y and Z
28° would give us Y and Z
21° would give us just Z
16° would give us just Y
19° would give us nothing.
. . . and so on.
You can extend this idea indefinitely as far as I can see (I'm pretty sure that's the case), extracting 5 unique values ("the possibility to simply change like 5 attributes") from a number shouldn't be too hard.
tl;dr . . . innate in a number - smuggled in through the angle of the spawned actor - are lots of unique qualities that can be used to communicate more that one value.
That's an impressive way of working with the passed number @socks!
Another solution that's probably not ideal in terms of extra workload parsing it (but hey, you only write it once, right?
), is that I also figured you can use the tried and trusted method of splitting the number up by flooring and/or flooring then subtracting...
Say you want to pass a flag for a weapon/shot type, whether it tracks you, etc, you can use a single actor for different types, and pass in the values in the largest number allowable - ie. if limited to 360 (though I think rotation angle can be set much, much higher, so more digits available (see below!) - but I digress... ie. a value 237 could be used to pass in both 2 (Maybe shot type) and 37 (maybe speed of lining up, etc, etc), or 23 and 7, etc, and if a donor attribute can be high enough, you can even populate X amount of digits for info, eg, integer fields might give a few numbers at a time - 2 billion or so is a lot of digits, just cutting them into say, 3 at a time if you need numbers 0 to 999, 4 at a time if you need numbers 0 up to 9999, etc...
...and if you want to maintain the same amount of digits, you can always use the highest digit, and set it to 1, eg:
1,423,456,302 could be used to send in (ignoring the '1' at the begininning) 423, 456, and 302, or.... 42, 34, 56, 302, or 4,234 , 5,630, etc etc...
Not ideal in terms of getting your head around it, but if you designate some set digits of each section of the number, for the value you're passing in, it should work fine?
1,423,456,302
1423456302
-|--|---|--|--|
x11223344x
42
34
56
30
('x's = unused in example)
Easier to explain without the comma's I guess...
Zzzzz.... I'm off to bed now!
Exactly !
Using the position (X,Y) values can lead to problems if you are not careful. E.g. if you passed a large number, which would spawn the actor more than 500 pixels outside the scene size, then the spawned actor would automatically get destroyed by GS's housecleaning before you could change its position.
Using the direction field has a similar trap, as the number can only be in the range 0 to 359.
If you need to pass large numbers, or multiple values, it is best to use the decimal places.
As @Socks says, there are many ways in which you can pass numerous combined values just in the rotation/direction field.
E.g. create a structured number...
0.4075003
where the first digit (0) indicates enemy's direction
the second digit, first digit after the comma (4) indicates enemy type
third to fourth digits (07) indicate its level
fifth to seventh digits (500) indicate its health pool
eighth digit (3) indicate its color
In the spawned actor, just use the textSubStr function to pick out the pieces.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Another thing i would really love to see , is to access scene attributes without unlocking the actor. would be really beneficial in many cases . We wouldn't need to keep track of player's (position /velocity/rotation ..etc ) or create game attributes at all ( except for saving) . It will save alot of memory and calculations in our games. If its possible please consider it
I suppose that would only be limited to the default scen attributes and not attributes you add? I might be wrong here but having access to scene attributes that we create outside that specific scene would end up being a nightmare since each scene has different attributes. Game attribute end up being the easier/same choice. Unless of course your're referring to the default scene attributes. (I hope I made sense)
@fmakawa I mean to access layer actors , the most common example would be to track player x and y.
instead of creating 2 real game attributes and constrain them to self.position x and self.position.y.If we had access to current scene attributes we can use the position of the player on any other actor , so we wouldn't need to add these 2 constrains and create game attributes in the first place.
Guys... when will a web version of GameSalad be ready lol.... I really wish there is one asap...
I've just realised, as much as custom colliders are great, another great feature would be to have SIZEABLE standard colliders - eg - I have star-shaped bonuses, with circle colliders, and so these colliders are too big to nestle the buttons as close as I need them...
So.... I'm having to try and create custom colliders (and for some reason, PBE didn't allow me to create a circle shape collider last time I tried (maybe it's something I'm doing!)), whereas a simpler, MUCH faster option would be to set the standard collider radius / width/height (absolute, or percentage of actor size - 70% / 110% etc) - ie. smaller circle, smaller square, larger circle, etc...
Would remove a LOT of the current need for more creation of custom colliders just for the simpler items and actors which would just benefit from having a smaller 'hit box'.... (Bullets, ships, bullet grazer shmups, etc)
Just a thought - might be a simple change to add at some point!
heeh
It is painful to change the camera size and maintain HUD actors size and position. We need an easy way to zoom in/out without effecting the HUD layer or specific actors , maybe a lock to maintain its scale. If anyone thinks its a useful feature please vote .
http://bugs.gamesalad.com/show_bug.cgi?id=1851
There are few html5 bugs ,
http://bugs.gamesalad.com/show_bug.cgi?id=1852
http://bugs.gamesalad.com/show_bug.cgi?id=1853
http://bugs.gamesalad.com/show_bug.cgi?id=1854
I think if you spawn an actor even 10000 past the scene size, as long as it just sits there and has no move behaviour active, it actually doesn't get destroyed by GS automatically.
That said, I usually use structured numbers in the angle for passing on attributes.
The general problem with this is that GS has no idea what the user-made attributes in that actor are, unless they put in some sort of 'scanner' for that purpose. I agree it would be great, but it is probably quite unlikely due to the complexity of such a feature.
@adent42 these are the things I'd love to see fixed while you are at it.
BUGS TO FIX:
-- Text behaviour does weird stuff when turning on/off with Visibility, ultimately one Display Text shows more than one text, overlapping, unreadable.
http://bugs.gamesalad.com/show_bug.cgi?id=1274
-- If you are changing the scene camera size in-game, mouse.position stops reporting the position you are touching on device, breaking game logic.
http://bugs.gamesalad.com/show_bug.cgi?id=408
-- Up/Down button position isn't consistently recognised by GS, breaking game logic.
http://bugs.gamesalad.com/show_bug.cgi?id=1568
-- The one where touch is not registered on devices on the first 10% or so of the screen's left edge. This can be really bad if important UI elements are close to the left edge, as they will not respond properly to user touch! I didn't submit a bug report for this personally, but I think one of the Team might have, this was discussed through ChatBubble.
-- The one where the scene camera is always 0.5y and 0.5x off-centre.
NEW FEATURE HOPED FOR:
-- iCloud sync, at least for tables. Great for playing across multiple devices or when you get a new phone, to continue playing without losing score/progress.
http://bugs.gamesalad.com/show_bug.cgi?id=962
i really hope the new game salad browser thingy will work broader with the variety of android devices.
Across my games I get the occasional 1 star rating because the game doesn't start properly, or crashed after a while of playing and always remains in the start screen frozen.
Thats nothing new its within my app reviews since 2+ years and only affects android/google play versions. Not on iOS.
My Apps
https://itunes.apple.com/de/artist/david-zobrist/id733552276
https://play.google.com/store/apps/developer?id=David+Zobrist&hl=de
@pHghost
You can use Appformative or Gamesparks for Cloud saving even cross-platform which is better i think, beside the extra register/login step for the user.
I use cloud saving since the last weekend and works nicely
My Apps
https://itunes.apple.com/de/artist/david-zobrist/id733552276
https://play.google.com/store/apps/developer?id=David+Zobrist&hl=de
I just tested this and an actor beyond about 500 pixels outside of the scene gets destroyed whether moving or not.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
You can't spawn an actor more than 500 pixels beyond the edge of the scene, but you can place actors there, for example 'change x position to -50,000' will work fine, the actor will move there as long as it doesn't move once it's there.
Those actors sure are finicky! Good to know.
New to GameSalad? (FAQs) | Tutorials | Templates | Greenleaf Games | Educator & Certified GameSalad User
It's even weirder than that, you can (depending on the position you start your actor) move your actor with a timer ( every A, move B ), so something starting on x600 can be moved with a timer, every A seconds, by B pixels . . . . for example
Every A
--Change X to X-2000
. . . and it will continue to move left without any issues, display its position in the middle of the screen and you will see it continue on its way.
But change the start position to something like 627 and the actor will be killed (indicated by the Display Text behaviour disappearing from the screen) somewhere around -x850px (rather than the standard -x500px)
?
