Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Max White]

It is just a pointer to the original map. If the map changes, it changes for all Mobs looking at it.

[Aqizzar]

It is just a pointer to the original map. If the map changes, it changes for all Mobs looking at it.

This changes everything I know about instantiation, method calls, and memory management.  Good God, I wish I knew that sooner.  I always figured it was top-down memory-bucket only, and when you tell an object "this element is this" it created a new element and stored it inside the object.  Well then.

[Max White]

Not... Everything.
Primitives (E.g. ints and strings) themselves are copied over to a new location, while only the location of objects are copied over. For example.

Spoiler (click to show/hide)

Code: [Select]

class Program
{
static void main(string[] args)
{
int myInt = 3;
Foo(myInt);
Console.WriteLine(myInt);
}

static void Foo(int myInt)
{
myInt = 4;
}
}

Would output 3, not 4. This is because the value was copied, not the location. For objects, the value is the location.

There is, however, a way to make it copy over the location for primitives, and that is with a new keyword, 'ref'! For example...

Spoiler (click to show/hide)

Code: [Select]

class Program
{
static void main(string[] args)
{
int myInt = 3;
Foo(ref myInt);
Console.Writeln(myInt);
}

static void Foo(ref int myInt)
{
myInt = 4;
}
}

Would in fact output 4.

[Darvi]

IOW, myInt gets used as a local variable inside Foo and doesn't affect anything outside of said method.

Or maybe I am totally misunderstanding what you are talking about. Again.

[Max White]

Nope, you got it.

[Aqizzar]

For objects, the value is the location.

Thank you for the vital clarification, which is exactly why I always though Objects were a value in themselves, because I knew how Primitives worked, and figured Objects were the same way.

And I always wondered why "this" was considered an important term by the IDE.  I figured it was just some common Foo thing people wrote as examples that held no programing weight.  Turns out, an Object can internally reference itself.  I had no idea you could that.

This will make everything even easier too, since this way when a Mob wants to move around, it can just call its Map's mobList for collision detection.  Damn, this is all unfolding so well now - my biggest hangup before was just pondering how to make every element of the program talk to other parts.

[Gatleos]

The day I figured out how pointers and references worked and realized the implications and possibilities, formerly unfathomable vistas of knowledge exploded within my brain like an atom bomb. It was like touching the programming equivalent of the Monolith or something.

[Darvi]

The day I figured out how pointers and references worked and realized the implications and possibilities, formerly unfathomable vistas of knowledge exploded within my brain like an atom bomb. It was like touching the programming equivalent of the Monolith or something.

That happened literally a month ago for me.

[nenjin]

I'm still waiting on that. I get the premise, but the applications haven't yet really occurred to me. Which makes me think I still don't understand the premise.

[Max White]

This will make everything even easier too, since this way when a Mob wants to move around, it can just call its Map's mobList for collision detection.  Damn, this is all unfolding so well now - my biggest hangup before was just pondering how to make every element of the program talk to other parts.

Just one thing, because I know you will run into this at some point in your life, I did, my neighbor did, and he's dog did, and it was painful for all of us until we whacked ourselves in the head with a copy of 'Programming for dummies' for not realising instantly what was wrong.

When you go through the list of Mobs, remember that list also contains the Mob that was asking for the list, so if you check if the tile that the Mob is currently standing on is occupied, then the answer is yes, it is occupied by itself.

[Aqizzar]

When you go through the list of Mobs, remember that list also contains the Mob that was asking for the list, so if you check if the tile that the Mob is currently standing on is occupied, then the answer is yes, it is occupied by itself.

Yeah, the infinite recursion of the mob being able to find itself in itself did occur to me (but making the Mob's Map private obviously).  I'm wracking my brain for a way to make the mob realize that its looking in the mirror, besides just hard-coding the AI functions to make sure it never checks its own location for a mob.  I suppose an internal ID number could help, but that seems kludgy to me.  Any tips?

[Darvi]

I'm still waiting on that. I get the premise, but the applications haven't yet really occurred to me. Which makes me think I still don't understand the premise.

It enables methods to access variables that aren't defined inside the method itself.

Considering that until recently my only OOP experience was with python and pascal, it's no wonder I didn't know that was even an issue.

[Levi]

Yeah, the infinite recursion of the mob being able to find itself in itself did occur to me (but making the Mob's Map private obviously).  I'm wracking my brain for a way to make the mob realize that its looking in the mirror, besides just hard-coding the AI functions to make sure it never checks its own location for a mob.  I suppose an internal ID number could help, but that seems kludgy to me.  Any tips?

Just an == might work, it'll probably use the memory location as the comparator. 

[Max White]

Yeah, the infinite recursion of the mob being able to find itself in itself did occur to me (but making the Mob's Map private obviously).  I'm wracking my brain for a way to make the mob realize that its looking in the mirror, besides just hard-coding the AI functions to make sure it never checks its own location for a mob.  I suppose an internal ID number could help, but that seems kludgy to me.  Any tips?

Didn't you just say you were starting to understand the value of the 'this' keyword? Trust me, it rocks.

Spoiler (click to show/hide)

Code: [Select]

class Mob
{
void someMethod()
{
foreach (Mob mobster in map.Mobsters)
{
if(this != mobster)
{
doWhatEverTheFuck();
}
}
}
}

[Aqizzar]

Yeah, I realized it as soon as Levi mentioned it.  For a second I asked myself, "Can you use an operator on two objects, as is?", and then I realized that yes, you can, because their comparative value is their memory location.  Which is essentially a primitive in itself.

Holy crap, I almost sound like I know what I'm talking about.  This is certainly a lot more sensible now than it was when I was a teenager, now that my critical thinking skills have developed a bit and I know a little more about how computers actually work.