I'm trying to make all the players teleport back to a position if they touch the "lava", but it seems like only the player that touches it, and SOMETIMES both teleport back.
[code]
public class CollisionEnemy : MonoBehaviour {
GameObject player;
void OnCollisionEnter2D(Collision2D coll) {
if (coll.gameObject.tag == "Lava")
{
player = GameObject.FindGameObjectWithTag ("Player");
player.transform.position = new Vector3(-19f, -8f, 0f);
}
}
}
[/code]
[QUOTE=Persious;45691162]I'm trying to make all the players teleport back to a position if they touch the "lava", but it seems like only the player that touches it, and SOMETIMES both teleport back.
[code]
public class CollisionEnemy : MonoBehaviour {
GameObject player;
void OnCollisionEnter2D(Collision2D coll) {
if (coll.gameObject.tag == "Lava")
{
player = GameObject.FindGameObjectWithTag ("Player");
player.transform.position = new Vector3(-19f, -8f, 0f);
}
}
}
[/code][/QUOTE]
You need to use FindGamesObject[u]s[/u]WithTag, which returns an array
[QUOTE=Persious;45691162]I'm trying to make all the players teleport back to a position if they touch the "lava", but it seems like only the player that touches it, and SOMETIMES both teleport back.
[code]
public class CollisionEnemy : MonoBehaviour {
GameObject player;
void OnCollisionEnter2D(Collision2D coll) {
if (coll.gameObject.tag == "Lava")
{
player = GameObject.FindGameObjectWithTag ("Player");
player.transform.position = new Vector3(-19f, -8f, 0f);
}
}
}
[/code][/QUOTE]
First of all, you don't need to the "GameObject player;" line at the top of the script, the player variable can just be defined inline.
Second of all, you're only teleporting the FIRST player you find (FindGameObjectWithTag returns the first object with that tag)
[code]
void OnCollisionEnter2D(Collision2D coll)
{
if (coll.gameObject.tag == "Lava")
{
GameObject[] players = GameObject.FindGameObjectsWithTag( "Player" );
for( int i = 0; i < players.Length; i++ )
{
GameObject player = players[ i ];
player.transform.position = new Vector3(-19f, -8f, 0f);
}
}
}
[/code]
Oh, I see, didn't know that existed, let me try that.
[editline]14th August 2014[/editline]
[QUOTE=KillaMaaki;45691220]First of all, you don't need to the "GameObject player;" line at the top of the script, the player variable can just be defined inline.
Second of all, you're only teleporting the FIRST player you find (FindGameObjectWithTag returns the first object with that tag)
[code]
void OnCollisionEnter2D(Collision2D coll)
{
if (coll.gameObject.tag == "Lava")
{
GameObject[] players = GameObject.FindGameObjectsWithTag( "Player" );
for( int i = 0; i < players.Length; i++ )
{
GameObject player = players[ i ];
player.transform.position = new Vector3(-19f, -8f, 0f);
}
}
}
[/code][/QUOTE]
That kind of did do the trick, but due to me having a hard time fixing the lag on movements (The video), and I couldn't get the synchronization to work, I think that might conflict?
Not really sure how to look for folks to program with, but.
I was wondering if anyone here would like to be my game dev buddy?
I'd actually quite enjoy having a partner to bounce ideas back and forth with.
At thought it seems like a relatively rudimentary function, but trying to code it has proved arduous.
I am trying to move an object along the x-axis as progress increases. Although, I abandoned Unity's game objects and am drawing everything with OnGUI. The variable, progress, increases as time advances, and it handles most of the functioning. Instead of the position of objects moving, the position should be calculated from the progression.
I haven't been able to solve this issue, so I am asking for assistance. For anybody willing to help, here are the relevant variables:
[I]initialSlide [/I](Where the object begins within the progress.)
[I]progress [/I](Increases slowly as the level progresses, and the limit rises as the level does.)
[I]totalLength [/I](The overall width of the level, should also increase as the level does.)
Here is a little diagram:
[thumb]http://i.imgur.com/Pki5ElX.png[/thumb]
[QUOTE=James0roll;45691867]At thought it seems like a relatively rudimentary function, but trying to code it has proved arduous.
I am trying to move an object along the x-axis as progress increases. Although, I abandoned Unity's game objects and am drawing everything with OnGUI. The variable, progress, increases as time advances, and it handles most of the functioning. Instead of the position of objects moving, the position should be calculated from the progression.
I haven't been able to solve this issue, so I am asking for assistance. For anybody willing to help, here are the relevant variables:
[I]initialSlide [/I](Where the object begins within the progress.)
[I]progress [/I](Increases slowly as the level progresses, and the limit rises as the level does.)
[I]totalLength [/I](The overall width of the level, should also increase as the level does.)
Here is a little diagram:
[thumb]http://i.imgur.com/Pki5ElX.png[/thumb][/QUOTE]
x = anchorPosition + ( progress% * lengthOfBar )
anchorPosition = where the bar starts
progress% = float representing the progress from 0f to 1f
lengthOfBar = how wide the visual bar should be on screen
Ah, looks like I've done enough for an update now.
Spent a little while uploading the thing to a repo, so now I actually have version control! (Bloody finally...). Also means other people can work on it, which is sort-of-happening slightly. Eh.
I shall call this update; "The Annoyance Update"
[video=youtube;SAWL-lBQs9I]http://www.youtube.com/watch?v=SAWL-lBQs9I&feature=youtu.be[/video]
There were a lot of minor changes, so here's the big ones.
- Started to get rid of the sounds found across the internet, meaning that I've had to replace them with me doing funny noises (for the time being)
- Added Oxygen, and a global level which will eventually effect the player.
- Added Oxygen pumping stations.
- Oxygen pumping stations contain a certain amount of oxygen that they release into the environment (in the video, for test purposes, this was set to 100% of total oxygen).
- Made fog react to oxygen levels, giving a visual indication of it.
- Added some logic stuff to let the player become oxygen deprived (HOORAY TEMPORARY BRAIN DAMAGE).
- Added "THE DRAGONFLY" enemy.
- Added "THE SHADOW BOMB" item
- The Dragonfly spawns randomly and flies around to objects that you've repaired, trying to blow them up with shadow bombs.
- Begun work on an indicator to show you that a Dragonfly is blowing up your hard work (and where it's happening).
- Added "THE COMBOBULATOR" weapon.
- The Combobulator can push away Shadow bombs, and reset their explosion timer
- The Combobulator can aggro Dragonflies, making them come after you instead of repaired objects.
- The Combobulator has a charge meter that limits it's use, so it doesn't become OP.
- Radio towers can now kill Dragonflies.
- Updated the Hand Drill model.
- Added a weld-trail effect on the Hand Drill, in preparation for a future gameplay mechanic...
- Added some residential buildings (heavy WIP, no furniture for them yet).
- Added "THE POWERSTATION" location (heavy WIP, only the outside done).
- Begun work on the cutscene-type-thing that starts the game, sort-of (not shown yet!)
- Added a bunch of misc animations boy-you-betcha.
I think that's it. I think. Going to try and gear up for a demo at some point in the future.
[QUOTE=Jcorp;45692984]Ah, looks like I've done enough for an update now.
Spent a little while uploading the thing to a repo, so now I actually have version control! (Bloody finally...). Also means other people can work on it, which is sort-of-happening slightly. Eh.
I shall call this update; "The Annoyance Update"[/QUOTE]
You have some z-fighting on the windows (does the window mesh have side faces?)
Looks awesome. And what does OTC G stand for?
[QUOTE=Pelf;45693094]You have some z-fighting on the windows (does the window mesh have side faces?)
Looks awesome. And what does OTC G stand for?[/QUOTE]
Hah, yeah, noticed that when I was editing the video. A few hours of editing normals on models means you overlook some things, I guess :v:
And "OTC G" are the initials of one of the two names I'm considering for it: "On This Cracked Ground". The other one is "Windfall"
Cheers for the compliment!
Undo-redo system
[video=youtube;p3O0WSc3OVM]http://www.youtube.com/watch?v=p3O0WSc3OVM[/video]
This editor has really taken shape. I think it's mostly done now and I'm really happy with how it turned out. Now I'm gonna change my level loading/playing backend to use my custom level files/a single scene instead of many unity scenes.
On a side note, how can I compress my video without WMM shitting on the quality? (the ui is the worst)
Or maybe capture it in a compressed format?
[editline]e[/editline]
i also discovered a strange gravity situation while messing in the editor:
[video=youtube;K7p245hY9ic]http://www.youtube.com/watch?v=K7p245hY9ic[/video]
What's the best way to cull faces that can't be seen?
[QUOTE=Garrison;45693942]What's the best way to cull faces that can't be seen?[/QUOTE]
For backfaces, that's already done for you by the graphics card.
But if you mean like polygons that are occluded by other polygons... well, that's actually a very computationally difficult problem.
[editline]14th August 2014[/editline]
Made a post on why strings are objects in .NET, which I learned while working on a virtual machine in Unity
[url]http://forum.unity3d.com/threads/c-lesson-why-is-string-an-object.262455/[/url]
[QUOTE=Jcorp;45692984]
[video=youtube;SAWL-lBQs9I]http://www.youtube.com/watch?v=SAWL-lBQs9I&feature=youtu.be[/video]
...[/QUOTE]
This reminds me of the mod in Minecraft that allows you to build lots of stuff.
PS: This looks better than Minecraft due it's terrain and graphics.
I know it's a simple question but I can't find a solution for it and I tried lots.
I want to fade out a text color slowly.
I am using style.normal.textcolor = new Color(1,1,1, <can't find what to use here>);
I did tried lerp but the problem is that it fades out instantly.
[code]
Mathf.Lerp(1,0,Time.time) I think I also tried Time.deltaTime.
I saw all those projects you posted and gosh, I feel like a fucking loser.
[QUOTE=BoowmanTech;45697230]I did tried lerp but the problem is that it fades out instantly.
[code]
Mathf.Lerp(1,0,Time.time) I think I also tried Time.deltaTime.[/QUOTE]
The third parameter for Lerp is 0-1. Time.time is going to be much larger than one so it will just go to the second value (in your case, 0).
You want something like[I] ( Time.time - startTime ) / fadeDuration[/I]
[QUOTE=Pelf;45697322]The third parameter for Lerp is 0-1. Time.time is going to be much larger than one so it will just go to the second value (in your case, 0).
You want something like[I] ( Time.time - startTime ) / fadeDuration[/I][/QUOTE]
Oh shit, this makes a lot of sense.
Looks like I'll be writing a custom-built pathfinding solution for my game.
I'll probably be using somewhat old-fashioned waypoint graphs (at some point, I'll figure out how to auto-generate them, presumably by voxelizing the level and placing nodes on walkable surfaces or something like that)
[IMG]https://trello-attachments.s3.amazonaws.com/531f98267ecdfc646126d4a3/53ee27747e03e119cdf555ca/1124x685/38ead41afd4abd5f685909890351b94e/PathGraph.png[/IMG]
One of the things in this implementation is that waypoint nodes are multipurpose (not just for pathfinding). On the one hand, at design time I bake approximate cover data onto each waypoint node, in a similar fashion as was done in the first Killzone game for PS2. See below for one such waypoint:
[IMG]https://trello-attachments.s3.amazonaws.com/531f98267ecdfc646126d4a3/53ee27747e03e119cdf555ca/1124x681/86e5c5f8a3c91d97a1afd95dc45e20f5/CoverApproximation.png[/IMG]
The idea is that this allows me to quickly and efficiently determine whether a node provides cover against a given position using nothing more than simple arithmetic (no raycasts whatsoever). I can also use the same calculation to speed up line of sight tests (if this node provides cover, then I know the point definitely does not have line of sight, without having to perform an expensive raycast).
I can also use these points for when an AI decides it wants to throw a grenade at the player. It can essentially query for nodes that are within some radius around the player, discard any that it does not have line of sight to, and then assign a cost to each one with increasing distance from the player, then pick the one with the lowest cost to throw a grenade at. That then allows my AI to throw a grenade *near* the player, rather than just directly at the player.
I can also use these points for when an AI is in cover, and wants to pop out and shoot at the player. The AI can trivially pick a cloud of nodes near them, discard any that don't have line of sight to the player, and pick the nearest one to pathfind to.
AIs can also "claim" nodes, by setting a GameObject reference on the node to itself. That will make other NPCs disregard that node in pathfinding, and they will also not choose that node if they need cover. That way, NPCs never fight for cover.
All of these calculations can also be used during pathfinding, as was also done in the first Killzone. So my AI might decide it wants to move through cover, so therefore it will pick a point to move to, and during pathfinding assign a higher cost to any node that does not provide cover.
[QUOTE=KillaMaaki;45693955][...]
Made a post on why strings are objects in .NET, which I learned while working on a virtual machine in Unity
[url]http://forum.unity3d.com/threads/c-lesson-why-is-string-an-object.262455/[/url][/QUOTE]
Fairly accurate, however it's only true for variables. Other uses of string wouldn't [I]have[/I] to be on the heap since their size wouldn't change in their lifetime.
I think the actual reason is that strings tend to be long and duplicated and so using references keeps memory usage low.
Would like some advice if anybody's got it...
So, clearly pathfinding should be done on another thread (or several), so that as pathfinding jobs become available a worker thread snaps it up, processes it, and passes the result back to the main thread.
That's not hard at all, but here's where I'm having issues.
I also need AI agents to be able to individually evaluate nearby waypoints based on the AI's current goals and a number of criteria (like waypoint provides cover, has line of sight, near AI, near player, etc). This must all be done on the [I]main thread[/I], as it in many cases involves querying the state of the world (and as Unity is not thread-safe, this can't be done on any other threads). My question is, how should I accomplish this?
I suppose I could have an agent assign a score to all waypoints prior to calculating the path, but I could easily envision this taking up a lot of memory (particularly if I have to store a cost value per waypoint per agent, with 20+ agents and several thousand waypoints.... ick)
EDIT I suppose I could get away with only storing cost per waypoint per thread (as each thread only processes one path at a time), but that could still be a lot of memory.
EDIT 2: If I have 4 worker threads (which should be plenty!), and I impose the range 0-255 on custom cost values assigned by AI agents (which should be a perfectly reasonable cost range) then I could just store one byte per threads, 4 bytes, not more than a single int or float value. That should be reasonable, although there's the question of how expensive it would be to evaluate node cost on the main thread...
[editline]15th August 2014[/editline]
[QUOTE=Tamschi;45698869]Fairly accurate, however it's only true for variables. Other uses of string wouldn't [I]have[/I] to be on the heap since their size wouldn't change in their lifetime.
I think the actual reason is that strings tend to be long and duplicated and so using references keeps memory usage low.[/QUOTE]
Well, yeah, that's another good point. If you were to pass strings by value, then it would result in a stack push per character every single time. Whereas passing the string by reference is only a single stack push (the pointer).
I wouldn't say it's [I]the[/I] actual reason, I'd say it's [I]one of the many[/I] reasons ;)
Well, and actually there's another thing. The compiler always keeps track of how many bytes a function's parameters will take, at compile time (that way it can pop those parameters off of the stack after a function call). This would not be possible with strings if they were passed by value, as you could pass a string with any length.
[QUOTE=KillaMaaki;45698890][...]
Well, yeah, that's another good point. If you were to pass strings by value, then it would result in a stack push per character every single time. Whereas passing the string by reference is only a single stack push (the pointer).
I wouldn't say it's [I]the[/I] actual reason, I'd say it's [I]one of the many[/I] reasons ;)[/QUOTE]
That's even more inaccurate than before :v:
Single stack pushes can be a lot larger than that, but it's true that at some point the efficiency drops when passing parameters by value.
Characters are a slightly fuzzy concept too, since they don't actually refer to text elements but arbitrary 16bit chunks in .NET.
There are different functions you should use when cutting text in order not to destroy parts of the information. Same with counting characters for human readable output.
It's all speculation anyway as nobody actually does put strings on the stack. It's true that you can push more than one byte at a time (so, I suppose on a 32-bit CPU you could push four ASCII characters or two UTF characters at once - but that's still not going to be terribly efficient).
[QUOTE=KillaMaaki;45698890]Well, and actually there's another thing. The compiler always keeps track of how many bytes a function's parameters will take, at compile time (that way it can pop those parameters off of the stack after a function call). This would not be possible with strings if they were passed by value, as you could pass a string with any length.[/QUOTE]
That's not true, it's about as easy to just keep a pointer to the previous frame around for jumping back.
I think in .NET you do need to have stack depth 0 to exit a method though, so it's reasonable to require fixed-size argument frames.
[QUOTE=Tamschi;45699114]That's not true, it's about as easy to just keep a pointer to the previous frame around for jumping back.
I think in .NET you do need to have stack depth 0 to exit a method though, so it's reasonable to require fixed-size argument frames.[/QUOTE]
It's possible, but it's not how it's done. This is what happens when you call a function in standard x86 assembly:
1.) Function parameters are pushed onto the stack in right-to-left order
2.) The program counter is pushed onto the stack
3.) Execution jumps to the function
4.) EBP is pushed onto the stack
5.) ESP's value is copied to EBP
6.) Any registers that the function will modify are pushed onto the stack
7.) ESP is modified to allow space for local variables on the stack
8.) <function body executes>
9.) ESP is modified again, to de-allocate space which was allocated for local variables
10.) Any registers that were pushed onto the stack are now popped back off of the stack
11.) EBP is popped off of the stack
12.) The program counter is then popped off of the stack, returning to the previous point of execution (now we've gone back to the code which called the function)
13.) Now that we're back to the calling code, there's still a bunch of parameters on the stack. The calling code's job is to then clean those up by either modifying ESP (adding the number of bytes which were allocated for parameters), or by popping the values into a don't care register (which one is done seems to depend on the compiler). In either case, the number of bytes which must be added to ESP or popped off of the stack is determined statically at compile time.
EDIT But anyway, the bigger issue is that passing strings by value would mean lots of memory copies, and that stacks are limited in size by design so strings would absolutely chew up your available stack space.
[URL="http://www.boltengine.com/#purchase"][B]Bolt Networking is 50% off![/B][/URL]
[URL="http://www.boltengine.com/#purchase"]AND it just got updated to 2.1.4![/URL]
Edit* Matt's just rating shit dumb, he's being an ass.
[QUOTE=sarge997;45701774][URL="http://www.boltengine.com/#purchase"][B]Bolt Networking is 50% off![/B][/URL]
[URL="http://www.boltengine.com/#purchase"]AND it just got updated to 2.1.4![/URL][/QUOTE]
Ahhhh I so wanna buy it but this month I barely went to work so I have no money :(
[QUOTE=BoowmanTech;45701813]Ahhhh I so wanna buy it but this month I barely went to work so I have no money :([/QUOTE]
I really urge you to try and get the cash, I had to do that when it was full price, and it's sorta a bitch. But it's worth it.
Fuck me, starting to work again this monday and now it's on 50% off, fucking hell.
Sorry, you need to Log In to post a reply to this thread.