In response to CaptFalcon33035
CaptFalcon33035 wrote:
Can you double-click those errors and post the blocks of code they are in? That might help.

By the way, I can't beleive it took so long to identify the src and usr part in giving the gold. Then Crispy finally comes and clears it up. Jp also gave some insight.

MobCall=shockwave_hit(),
list/MobCallArg=list(shockwave_hit()),

they're from the shockwave by yota
In response to Eurobusker
I'm looking at it, and I really don't get it. It seems like there is all sorts of abuse and such in there. usr abuse and stuff. And setting a variable to a procedure that doesn't return anything is pretty dumb.

What you want to do is edit that code so that when the shockwave object comes in contact with a mob, call that procedure, the shockwave_hit() one.
In response to CaptFalcon33035
Ive got a great idea, who cares if the shockwave when touching the mob makes them give money,
all I need to do is have them give random amounts when I click on busk and at the same time there is the shockwave which is there to look pretty

therefore the new plan.

my verb busk must trigger two procs
1 the shockwave
2 the mobs/npcs only must give random amounts if they have money.

could I use o view?

http://eurobuskers.free.fr/busking_source.zip
now on my above link is the new version, it makes a pretty bunch of notes only. just goto add the random bit
In response to Eurobusker
My dear fluffy poster,

If I'd be piratehead, I'd be rather rude now (No offence heady), and I think I'll still be, but REALLY now.
  • You're a help vampire.
  • You're asking questions that contain very little information
  • You're not trying to get something done YOURSELF.


Copy/pasting is never good. People giving bad advice ain't good either. In 1 post I've seen <code>src</code> in a global proc, AND <code>usr</code> in a global proc. Both of them don't exist, and <code>usr</code> would've been wrong anyhow.

PS; Clicky.

Also, seeing as you're giving out the sourcecode for whatever problem you have, I daresay this is a "testing" project. Well, not much "testing" when you fail to do anything, is it?
In response to Eurobusker
yes you can use oview().
In response to Dragon_fire6653
Mysame, be careful who you call a help vampire. This guy has had mostly this problem, from what I've seen. He's been using PHP, which means he probably doesn't have a great understanding of object-oriented development. PHP didn't even have objects avaliable for use until PHP 3 I think, and even now many PHP users don't bother with them.

I saw Eurobusker posted a proc a little while ago that had about 10 arguments to it, in a huge list. That's a classic case of inexperience with object code. That sort of thing is needed all the time in functional programming, for example, but is far less common in proper object-oriented projects since many variables are stored as object properties rather than passed as arguments all over the place.

So, I don't think he's a help vampire. He might benefit from reading the guide. And he would definitely benefit if numbskulls like Dragon_fire6653 would stay away from him awhile until he can discern a piece of [expletive deleted] block of BYOND code from something that is actually useful.

As for the little code snippet that I replied to:

That's a real bastardization of the original snippet that I posted. Let me try to clear things up, and explain where all this came from.

When I originally wrote the little thing, I was imagining an anthromorphic frog with a giant bag of gold getting hit by a shockwave, and gold flies everywhere. So, I created a gold object in the frog's location containg the gold that he lost, and removed that gold from his stock.

Now, it turns out that Eurobusker had a different idea. He didn't want a pile of gold, he wanted a direct transfer.

So, Crispy's code does exactly what he wants, in my best estimation. Please scrap the proc/whatever, and move to mob/proc/whatever (or go the other way around, but do ONE OR THE OTHER). Otherwise, this will continue being a really big confusion.

Eurobusker, you need to get a grip on the lexical scope of variables. It'll come to you sooner or later for sure, but until you understand it some things will really mystify you. Here's a little crash course:

var/foo = "bar"
mob/verb/test()
world << "foo = " + foo


This will run as desired, displaying "foo = bar" to the output window. The variable foo has a global lexical scope because it's defined at the root of the code.

mob
var
foo = "bar"
verb
test()
world << "foo = " + foo


That snippet of code will do the same, because though the variable foo no longer has a universal lexical scope, it still falls within the local lexical scope of all /mob objects. It's what we call a "mob var", because it exists for all mobs.

obj
var
foo = "bar"
mob/verb/test()
world << "foo = " + foo


That code will cause a compiler error that says "undefined variable: foo", because mob objects do not know what foo is. obj objects do, because foo is within their local lexical scope but foo is outside the scope for mob objects. One final example, here.

obj
var
foo = "bar"
mob
var
foo = "not bar"
verb
test()
var/obj/o = new
world << "obj's foo is " + o.foo
world << "mob's foo is " + src.foo


That will show that obj's foo is "bar", and mob's foo is "not bar". The variable is called foo in both cases, but since the two foo variables have different scopes, they are treated as totally different variables. They can have different types, different owners, etc. One can be a string, and one can be a number.

I hope this helps a little. Best of luck.
Page: 1 2