Unity3D - Discussion

[The Rizzler]

[QUOTE=KillaMaaki;44763640]Doesn't matter. Won't slow anything down, anyway.[/QUOTE]

excelleeeent so all that increases is the bake time right
then again baking probes usually takes about a second
How do I make sure the probes in different rooms don't 'leak' light into one another? (you can see a bit of this happening on that image, the probes in the first area leak all the way to the end)
Should I just extend my probes a little past the walls where the player can't walk so that the transition can't start inside the room?

[editline]15:44[/editline]

actually is the correct method to create seperate lightprobes for different rooms/areas rather than linking EVERYTHING together?

[Party Boy]

I'm making a HurtPlayer script that takes an amount to deal and the time between dealing damage.
It works but it only calls it once for every TriggerEnter. For example if I walk and stand on a fire it deducts 10hp, but it only deducts more once I leave the fire and go back onto it.
How can I make it do it while I'm standing on the fire

    void OnTriggerEnter(Collider collider){
        
        playerHealth = collider.gameObject.GetComponent<Health>();

        if(playerHealth != null)
            StartCoroutine(DealDamage());
    }

[KillaMaaki]

I'd make it so the fire trigger does this:

void OnTriggerEnter(Collider collider)
{
    collider.SendMessage( "EnterFire", SendMessageOptions.DontRequireReceiver );
}

void OnTriggerExit(Collider collider)
{
    collider.SendMessage( "LeaveFire", SendMessageOptions.DontRequireReceiver );
}

Now it's up to any scripts attached to said collider to do whatever it wants to with those messages.
Your player health script could, for instance, toggle an internal flag which says whether or not the player is currently on fire, and periodically deal damage as long as that flag is set.
Remember, the fire shouldn't care how the object reacts to being lit on fire. All it should do is tell the object it is on fire, and let that object deal with it.
This makes it easy to add, say, a wooden crate that is lit aflame and breaks apart, maybe a metal box that heats up while on fire, etc.

[HeatPipe]

Hello, I often find myself calculating with numbers with range [0-1]. Does this range does have a name?

[KillaMaaki]

[QUOTE=HeatPipe;44767528]Hello, I often find myself calculating with numbers with range [0-1]. Does this range does have a name?[/QUOTE]

Depends on the context. Could be referred to as "normalized" I suppose.

[Party Boy]

[QUOTE=KillaMaaki;44767515]I'd make it so the fire trigger does this:

void OnTriggerEnter(Collider collider)
{
    collider.SendMessage( "EnterFire", SendMessageOptions.DontRequireReceiver );
}

void OnTriggerExit(Collider collider)
{
    collider.SendMessage( "LeaveFire", SendMessageOptions.DontRequireReceiver );
}

Now it's up to any scripts attached to said collider to do whatever it wants to with those messages.
Your player health script could, for instance, toggle an internal flag which says whether or not the player is currently on fire, and periodically deal damage as long as that flag is set.
Remember, the fire shouldn't care how the object reacts to being lit on fire. All it should do is tell the object it is on fire, and let that object deal with it.
This makes it easy to add, say, a wooden crate that is lit aflame and breaks apart, maybe a metal box that heats up while on fire, etc.[/QUOTE]

Hmm, if I do it that way it seems I need to make new methods for each type of damage? I'm just trying to get a basic damage and wait system in for now.

[KillaMaaki]

[QUOTE=Over-Run;44767571]Hmm, if I do it that way it seems I need to make new methods for each type of damage? I'm just trying to get a basic damage and wait system in for now.[/QUOTE]

It's not that much extra work. Saving a few minutes now by having the fire directly damage the player could end up in headaches later when you want to change things.
It's always better to save yourself potential work later than it is to save a few lines of code now.

[Huabear]

If you want it so that it continues to damage anything inside the trigger, I'd use OnTriggerStay with some sort of bool switch which uses an InvokeRepeating. As a quick example which could probably be done better but should work:

[csharp]
private bool canHurt = false;

public float dmgRepeatTime = 3f;

void Start()
{
InvokeRepeating("CanDamageSwitch", dmgRepeatTime, dmgRepeatTime);
}

void CanDamageSwitch()
{
canHurt = true;
}

void OnTriggerStay(Collider c)
{
if(canHurt)
{
c.gameObject.SendMessage("Damage", SendMessageOptions.DontRequireReceiver);
canHurt = false;
}
}

[/csharp]

Now this is just thinking code and I havent tried it in Unity. In theory it should send a Damage message to all colliders inside the frame that canHurt is set to true, then canHurt instantly gets set back to false. The only thing I'm not sure on is if the SendMessage will get called for more than 1 frame before canHurt is set to false;

[KillaMaaki]

[QUOTE=Huabear;44768575]If you want it so that it continues to damage anything inside the trigger, I'd use OnTriggerStay with some sort of bool switch which uses an InvokeRepeating. As a quick example which could probably be done better but should work:

[csharp]
private bool canHurt = false;

public float dmgRepeatTime = 3f;

void Start()
{
InvokeRepeating("CanDamageSwitch", dmgRepeatTime, dmgRepeatTime);
}

void CanDamageSwitch()
{
canHurt = true;
}

void OnTriggerStay(Collider c)
{
if(canHurt)
{
c.gameObject.SendMessage("Damage", SendMessageOptions.DontRequireReceiver);
canHurt = false;
}
}

[/csharp]

Now this is just thinking code and I havent tried it in Unity. In theory it should send a Damage message to all colliders inside the frame that canHurt is set to true, then canHurt instantly gets set back to false. The only thing I'm not sure on is if the SendMessage will get called for more than 1 frame before canHurt is set to false;[/QUOTE]

I still think the job of interpreting what the fire should do should be the concern of thing being lit on fire rather than the fire itself.

[Huabear]

But how would what you suggested fix the issue of the fire burning as long as the object is inside. As of now it just send on enter or exit only which is one message to the object. The object itself would need code to continue to apply damage every x seconds.

[KillaMaaki]

[QUOTE=Huabear;44768793]But how would what you suggested fix the issue of the fire burning as long as the object is inside. As of now it just send on enter or exit only which is one message to the object. The object itself would need code to continue to apply damage every x seconds.[/QUOTE]

Well, yes, that's exactly what I'm getting at - the fire just tells whatever object that enters and exits that it has started being ignited, or stopped being ignited. The fire doesn't care what the object does with that information.
The object being ignited should keep track of whether or not it is on fire, and act on that.
Your player character would light on fire and apply damage on a timer. A crate would ignite and then break apart. An oil drum would explode. A metal box would perhaps heat up over time. Etc etc you get the idea. The fire shouldn't have to care about any of those details.

[HeatPipe]

[QUOTE=KillaMaaki;44767549]Depends on the context. Could be referred to as "normalized" I suppose.[/QUOTE]

Oh dooh! Normalized range :). Thanks.

Now I have name for my variables, thanks:)

[Falez]

Also fire is not the only thing that is capable of doing DoT effect. A game could have a electrified water or a poisonous cloud as a DoT zone. In terms of appearance they look different, however what happens when the player goes into the zone is the same: deal damage to the player over time.

So with that you just need one script for DoTTriggerZone. If you make damage and ticks serializable, you have more variety for your DoT. Fire might deal 20 damage over 4 ticks per second, while Electrified might deal 30 damage per tick and only do 1 tick per second.

To make Trigger management easier, make sure you utilize tags. A bullet that hits a wall doesn't need to check if the wall has a Health Component (unless the wall is destructible).

A DoTTriggerZone responsibility is to check time and say yes or no if the time is right. In this case: request Health to reduce its currentHealth. Its up to Health whether to oblige the request or go "no fuck you this guys invulnerable yo".

[Party Boy]

Yeah that's what I was thinking, I'll only need the 1 script.
I attach the script to something and then set the damage and the countdown between dealing damage, so whenever it hits the player it can deal damage straight away or whatever.

The main bit of trouble I'm having is that It damages me, waits for the timer and then it does loads of damage continiously. It seems the CoRoutine I start in OnTrigerWait doesn't work right. The coroutine just does:

yield return new WaitForSeconds(TimeToWait);

but it seems it just damages me every frame rather than waiting. Any ideas?

[bunguer]

Saw this [url=https://googledrive.com/host/0B3n1sS2Im_HhZW83ak9TWHFMWFU/full%20resolution.html]demo[/url] using [url=http://forum.unity3d.com/threads/235027-Lux-an-open-source-physically-based-shading-framework]Lux[/url] shaders, and it looks quite good and the performance is very good as well.

[amgoz1]

[QUOTE=KillaMaaki;44754747]Spaces also feel a fair bit cramped. It's difficult to maneuver around, and I also get frequently spawn camped by the AI ;-;
Otherwise, a very neat concept IMHO. Polish it up, get some decent art in there and a copy of Pro, and make it awesome (throw in some PBR, maybe motion blur, dirty lens effects, you get the picture).[/QUOTE]
Working on a better level:
[thumb]http://imgur.com/vUu7ktd.jpg[/thumb]
[thumb]http://i.imgur.com/xMP6A5q.jpg[/thumb]
[thumb]http://i.imgur.com/7G3aQkX.jpg[/thumb]
Want to add interesting weapons but I can't come up with anything I haven't seen 100 times before.

[KillaMaaki]

[QUOTE=Over-Run;44771180]Yeah that's what I was thinking, I'll only need the 1 script.
I attach the script to something and then set the damage and the countdown between dealing damage, so whenever it hits the player it can deal damage straight away or whatever.

The main bit of trouble I'm having is that It damages me, waits for the timer and then it does loads of damage continiously. It seems the CoRoutine I start in OnTrigerWait doesn't work right. The coroutine just does:

yield return new WaitForSeconds(TimeToWait);

but it seems it just damages me every frame rather than waiting. Any ideas?[/QUOTE]

It must be starting a new coroutine every frame?

[Kuddie]

[QUOTE=amgoz1;44778000]Working on a better level:
-images-
Want to add interesting weapons but I can't come up with anything I haven't seen 100 times before.[/QUOTE]

Raise the roof abit, to make the rooms feel abit more spacey.

[Richy13]

With inheritance, whats the correct way to have both the parent and the child class have a start/update/... method?
Should the child class override start and just call Base.Start()?
Or is that not needed and you can just do:

public class foo : MonoBehaviour{
    void Start(){
        print("foo class");
    }
}

public class bah : foo{
    void Start(){
        print("bah class");
    }
}

If I then created a bah instance, would it print?
[quote]
foo class
bah class
[/quote]

[editline]11th May 2014[/editline]

And, seeing as this is happening [url]http://darkgenesis.zenithmoon.com/get-prepared-for-unity-5-the-dreaded/[/url] would it be beneficial to have a base class like:

public class NewBaseBehaviour MonoBehaviour{
    Rigidbody rigidBody;
    Collider collider;
    Renderer renderer;
    //Any other somewhat useful component

    void Start()
    {
        renderer = this.GetComponent<Renderer>();
        collider = renderer.GetComponent<Collider>();
        rigidBody= collider.GetComponent<Rigidbody>();
        //...
    }
}

And just have everything inherit from it rather than from monodevelop?

[Perl]

[QUOTE=Richy19;44779720]With inheritance, whats the correct way to have both the parent and the child class have a start/update/... method?
Should the child class override start and just call Base.Start()?
Or is that not needed and you can just do:

public class foo : MonoBehaviour{
    void Start(){
        print("foo class");
    }
}

public class bah : foo{
    void Start(){
        print("bah class");
    }
}

If I then created a bah instance, would it print?

[editline]11th May 2014[/editline]

And, seeing as this is happening [url]http://darkgenesis.zenithmoon.com/get-prepared-for-unity-5-the-dreaded/[/url] would it be beneficial to have a base class like:

public class NewBaseBehaviour MonoBehaviour{
    Rigidbody rigidBody;
    Collider collider;
    Renderer renderer;
    //Any other somewhat useful component

    void Start()
    {
        renderer = this.GetComponent<Renderer>();
        collider = renderer.GetComponent<Collider>();
        rigidBody= collider.GetComponent<Rigidbody>();
        //...
    }
}

And just have everything inherit from it rather than from monodevelop?[/QUOTE]

The base function is only automatically called on constructors (if the constructor is parameterless, otherwise you have to explicitly declare the call with base( ... ))

[Party Boy]

[QUOTE=KillaMaaki;44778083]It must be starting a new coroutine every frame?[/QUOTE]

Yeah your right I think. How could I fix it?

[Richy13]

If your building a tool to extend the editor, is there anyway to have it not create an empty game object?
Im following this [url]http://code.tutsplus.com/tutorials/how-to-add-your-own-tools-to-unitys-editor--active-10047[/url]

[KillaMaaki]

The correct way to do inheritance is this:

public class MyClass : MonoBehaviour
{
    public virtual void Start()
    {
        Debug.Log( "foo" );
    }
}

public class MyOtherClass : MonoBehaviour
{
    public override void Start()
    {
        base.Start();
        Debug.Log( "bar" );
    }
}

[Party Boy]

Anybody have some good dungeon type models and textures? Need to crack on making maps for my demo

[amgoz1]

added more weapons and a less shitty level
[unity]https://dl.dropboxusercontent.com/u/3983801/unity/Adapt/adapt.unity3d[/unity]

[Tamschi]

[QUOTE=amgoz1;44784409]added more weapons and a less shitty level
[unity]https://dl.dropboxusercontent.com/u/3983801/unity/Adapt/adapt.unity3d[/unity][/QUOTE]

It would be better if, instead of just slow turning, you had a fast crosshair limited to a small circle/whatever and the ship would just follow that so you wouldn't have to reposition the mouse when flying in loops.

[editline]12th May 2014[/editline]

Or medium-sized circle, whatever you want to allow for the independent aiming of the weapons.

[editline]12th May 2014[/editline]

Garry, please make quoted Unity tags at least [I]a bit[/I] smaller.

[Huabear]

[QUOTE=Tamschi;44784705]Or medium-sized circle, whatever you want to allow for the independent aiming of the weapons.

[editline]12th May 2014[/editline]

Garry, please make quoted Unity tags at least [I]a bit[/I] smaller.[/QUOTE]

Just don't quote it :P

I still feel the roof isn't high enough, and maybe Q & E should rotate the ship, would feel more natural. R & F could be Up / Down with some other button being assigned to some other button (like MMB), of cause these would eventually all be configurable.

Looks great so far though.

[crazymonkay]

Terrain Toolkit is awesome
[IMG_thumb]http://imgur.com/lXEu3dy.jpg[/IMG_thumb]
For being 100% randomly generated having mediocre assets, and made in 10 minutes it doesn't look half bad. I was actually in the Appalachian mountains this weekend and it looks almost exactly like that.
[img_thumb]http://imgur.com/zBnZ9Hc.jpg[/img_thumb]

I've come a long way from pretty much the first thing I made in Unity just over a year ago:
[IMG_thumb]http://imgur.com/Wew8z5w.png[/IMG_thumb]

[DarKSunrise]

how is the performance on that?

does it use unity's terrain objects or is the terrain just a mesh?

[amgoz1]

[QUOTE=Tamschi;44784705]It would be better if, instead of just slow turning, you had a fast crosshair limited to a small circle/whatever and the ship would just follow that so you wouldn't have to reposition the mouse when flying in loops.

[editline]12th May 2014[/editline]

Or medium-sized circle, whatever you want to allow for the independent aiming of the weapons.
[/QUOTE]
That worked well in Freelancer. Might try that.

Turning not being fast and snappy enough plus the AI being too good at evading attacks also makes the game way too difficult. Even the lowest skill bot is hard to beat.

[QUOTE=Huabear;44786179]Just don't quote it :P

I still feel the roof isn't high enough, and maybe Q & E should rotate the ship, would feel more natural. R & F could be Up / Down with some other button being assigned to some other button (like MMB), of cause these would eventually all be configurable.

Looks great so far though.[/QUOTE]
The current controls aren't optimal. Best replacement so far seems to be:
W/S - up/down
A/D - left/right
Ctrl/Space - forward/reverse