It looks like our disagreement here stems from a difference in taste. I think everything that needs to be said has been said, from both sides of the argument, so I'll allow myself to withdraw from this conversation. This is what constructive criticism I had to offer, in any case. I liked the demo otherwise, and look forward to your future demos (have you considered making another game too?).
Another part of the issue that I didn't really want to mention, is that the more I provide the more people might expect to be handed to them. I don't want to open the door to requests (how do I do this or that?)

Toadfish wrote:
I liked the demo otherwise, and look forward to your future demos (have you considered making another game too?).

I find it's easier to start on a game, quit, and turn it into a demo. So while I have a game in the works, that probably means that I really have another demo in the works =)
With this snd some maps,monsters etc you could probaly create a mario like game.
Awesome demo. I edited it up a bit to work for a 64x64 game, but it works a little weird.
CockroachJr wrote:
Awesome demo. I edited it up a bit to work for a 64x64 game, but it works a little weird.

What exactly is being weird?

I didn't write it with larger icons in mind, but it'll probably work if you change every place where it says "32" in the demo to "64" or "world.icon_size"
Forum_account wrote:
What exactly is being weird?

I didn't write it with larger icons in mind, but it'll probably work if you change every place where it says "32" in the demo to "64" or "world.icon_size"

I changed everything to 64, which didn't work and I had to adjust it a bit. It works, but the bounding box seems weird, and sometimes it feels that the inside proc doesn't work correctly.
CockroachJr wrote:
I changed everything to 64, which didn't work and I had to adjust it a bit. It works, but the bounding box seems weird, and sometimes it feels that the inside proc doesn't work correctly.

The bounding boxes are determined by pwidth and pheight. In the demo these were both 24 for the mob, make sure they're set correctly too. The inside proc uses pwidth/pheight, so if they're not set correctly that could be causing the problem.
Forum_account wrote:
The bounding boxes are determined by pwidth and pheight. In the demo these were both 24 for the mob, make sure they're set correctly too. The inside proc uses pwidth/pheight, so if they're not set correctly that could be causing the problem.

Ah, a mistake on my part. Accidentally set the bounding boxes for turfs to 32/32, so it was acting a little weird. On another note, I tried using your demo for my pixel projectile system too, however i failed(not even sure why, it called the inside proc even though i spawned the projectile outside of my range). Do you plan on creating a pixel projectile demo as somewhat of a continuation of this?
CockroachJr wrote:
Ah, a mistake on my part. Accidentally set the bounding boxes for turfs to 32/32, so it was acting a little weird. On another note, I tried using your demo for my pixel projectile system too, however i failed(not even sure why, it called the inside proc even though i spawned the projectile outside of my range). Do you plan on creating a pixel projectile demo as somewhat of a continuation of this?

I'm pretty sure the demo only checks for mob-turf collisions. You would need to change that if you're expecting that projectiles (objs or mobs) could hit other mobs/objs.

The inside proc will be called even if the object is outside because it has to verify that it's outside. You know it's outside but the program doesn't, it has to check =)
Forum_account wrote:
I'm pretty sure the demo only checks for mob-turf collisions. You would need to change that if you're expecting that projectiles (objs or mobs) could hit other mobs/objs.

The inside proc will be called even if the object is outside because it has to verify that it's outside. You know it's outside but the program doesn't, it has to check =)

Yea, I changed the demo to check for any dense atom, and is there a way to "trick" the program to thinking the projectile is outside?=x, having a lot of trouble with that.
CockroachJr wrote:
Yea, I changed the demo to check for any dense atom, and is there a way to "trick" the program to thinking the projectile is outside?=x, having a lot of trouble with that.

You can tell the projectile who its creator is. When the projectile checks for collisions it can skip checking its creator.
Sweet, I just checked if t was the owner, and if it was to end the loop, and now it works for the most part. thanks man :)
CockroachJr wrote:
Sweet, I just checked if t was the owner, and if it was to end the loop, and now it works for the most part. thanks man :)

You probably don't want to end the loop entirely, you just want to ignore that particular collision. You can do that like this:

for(var/atom/a in view(2,src))
if(a == owner) continue
// check for collision


The continue statement skips the current iteration of the loop and starts the next one, so you skip the collision check when a is the owner.
Alright I've encountered 2 new problems. :(
When I shoot, the projectile goes in front of me, then behind me,then in front of me again and shoots normally.
{ http://i28.tinypic.com/qsa0eq.png ;
http://i27.tinypic.com/2aj9yqe.png ;
http://i28.tinypic.com/1iettz.png }

Also, when I shoot diagonally, along with that problem, the projectile sometimes goes left, then right, then left, and repeats.
{ http://i27.tinypic.com/1zdod1j.png ;
http://i27.tinypic.com/xm8qco.png }
If you think you know what the problem is, I'll post the code.
Page: 1 2 3