lunpa's problem of the week
 

w00t...
Is there a way to prioritize the drawing height of a showimg over another at the same screen layer? I mean, other than its x/y/z coordinate... unless there is a way to get, say, z to be the priority rather a y axis modifyer...

for example, lets say I use a polygon to blacken the screen. how can I make it so some stuff actualy draws over it, and still be in the middle of the screen?:megaeek:

Other than drawing at a "higher" layer, no. At least nothing that I know of.

Commands for layering, for level npcs:

NPC Code:

---

drawoverplayer;

drawunderplayer;

drawovertrees;

---

I have no idea what 'drawovertrees' does.

Commands for images, used in showimg, showtext, and showpoly:

NPC Code:

---

chageimgvis index,vis;

---

'vis' is a number between 0 and 5
0 and 1 = Under player
2 = Same height as player
3 = Over player
4 = On the screen, images will be drawn on the screen instead of the level, usefull for GUIs
5 = Same as vis 4, but is drawn over the images with a vis of 4.

Question:
Is it possoble to have a vis higher than 5? Such as changeimgvis 200,6;?

Yes.

Lance is right.

But there is a limit I believe... max 20-30, or somewheres around there. I can't remember exact though.

huzzah! thats just what I was looking for. thanks again :D

Also, I have another small question...

Is there a way to convert keycode into its character value? or is it just a one-way conversion from char to keycode?

#K(value)

before...

NPC Code:

---

if ((strtofloat(#p(0))>=65&&strtofloat(#p(0))<=90)||(  strtofloat(#p(0))>=321&&strtofloat(#p(0))<=346)) addstring client.lunpatexttestis,#p(0);

---

after...

NPC Code:

---

if ((strtofloat(#p(0))>=65&&strtofloat(#p(0))<=90)||(  strtofloat(#p(0))>=321&&strtofloat(#p(0))<=346)) addstring client.lunpatexttestis,#K(#p(0));

---

o.O Are you sure thats right? Now it won't return anythign...

#K(strtofloat(#p(0)));

or just #p(1) ?

Or not? #p(1) is a string, not a float value. The #K() code wants a float value.

Besides, when did he even mention #p(1)?

You know what #p(1) returns, right?

Isn't it obvious that I know what it returns by what I last posted?

Not really. #K is unnecessary and out of the equation if you use #p(1). Think about it, dude.

#p(1) is the parameter sent, and in this case, returns the key character when the event keypressed is called.

Uh... what if the parameters were sent in ASCII code? In that case, #p(1) would be a NUMBER in string form, not the actual character. :/

newfeatures2002.txt

Um, okay. Ramirez, it's clear that he's using the #p() codes as arguments from keypressed. In which case #p(0) holds the keycode (in string form) and #p(1) holds the ascii character to which it corresponds. So #p(1) is identical to #K(strtofloat(#p(0))).

It may be easy to ASSUME that's what he's using, but you still don't know that for certain until he verifies it himself.

Besides, you guys are going an extra step by saying it's unnecessary to use #K(). Sure, it may be if he's using keypressed, however, that is NOT what he asked for. He asked for a way to convert ASCII codes into actual characters, and I gave it to him. Then he put a string inside of the #K() code when it requires a float value. Instead of assuming it was for keypressed and not something else, I gave him the solution that worked in the way he was using it, rather than trying to change his script for him.

*sigh* *waits for the Argument Duo to continue on*

Nah - the #K(strtofloat(#p(0))) method makes everything uppercase, and behaves differently when symbols (e.g. semicolon) are pressed.

My fault, I should've been more explicit. They're identical in terms of the range of values in use here (ie: only letters). I dunno about the upper-case thing, I've never experimented with that. If it is true then Ramirez' solution is inadequate.

Are there any other realistic explanations for him processing single-character params and filtering for letters, then appending one-by-one to a string?

That turns out to be true, but only because Graal is weird with keypressed. Instead of returning 65 to 90 for uppercase letters, and 97 to 122 for lowercase letters, it returns 65 to 90 for lowercase, and 321 to 346 for uppercase letters, strangely enough. It would seem extending beyond the normal 255 range just wraps around, like directions do.

...too bad all of this is still assuming it's for keypressed.


Why does it have to be realistic? What says he's using some method that you would think of as being used the most? Who's to say he doesn't have some weird script triggeractioning the chat text of the player to another NPC? There's no reason to assume it's keypressed just because that's the most likely thing. He did not ask for his script to be optimized, he asked why #K(string) didn't work.

lol, I got what I needed.

I didn't realize that #p(1) returned the actual character of the pressed key :eek:

still its good to know that I have to convert #p(0) into ascii before it can be used in #K()

:) thanks again!

See? Now he TOLD US himself it was keypressed. In that case, #p(1) is better to use, as was already mentioned. Now you also know that #K() exists and that you can't use a string value in #K(). ;)

heh, anyway, I have a new question, wich would be, is there a serverside command to change the head of the rc?
and are there any events like 'rcchats' (an equivalent to playerchats) and posibly a message code to obtain the rc chat text?

Yes. Use with () on the index of the person on RC and use setplayerprop to change the head image.

The only one I'm aware of is the "rcchat" event. This is triggered when someone on RC uses the command /npcText params. #p(0) is "Text", and #p(1) and up are the parameters. I might be wrong about that, but I'm pretty sure I'm not. Oh... and I also believe it can only be used in the Control NPC.

:) I'll try it out. thanx!

oh, and for some reason I can't open the script of one of my weapons. Could it be that its gotten too long? Its one of my longer scripts

When our server flags on Classic get too long, we can't view them. So that could very well be what's happening there, though I've never had it happen to myself.

oo, any idea how I can retrieve the script?

I don't know how you would, but maybe someone else will. I know classes are stored in scripts\, but I have no idea if weapons are stored somewhere like that as well.

yah, since classes are, I'd say its only logical that the weapons are. I dug through the ftp the best I could, but to no luck.
Say... could someone with a different kind of access to the ftp (like a different program or something) posibly retrieve it? I know that to have a larger tileset put on the server, you need stefan to upload it. Maby he can help? (so, now I have to figure out the best way to contact him...)

I don't really get why everyone is so... interested in changing the RC head, it's an administrative tool, not a play tool ;(

Forum PMs usually work.

thanx, Ramirez, I'll try that.

as for Python
You have an intresting point, but you're making it sound as if graal itself is not a play thing.

Our objective in this matter is to provide him with the help he needs in solving his problem. You'll note that he never specified that he was working in GScript, so you were wrong to suggest that he use #K! Wrong! Foolish! Assumptions!

We deduce that he is using keypressed, because of the overwhelming evidence pointing in that direction. As it turns out, we're right. Wasn't this path more productive, then?

Is arguing about this being productive?


I have no intention of posting again in regard to this "debate" or whatever you want to call it, as it's completely pointless. I would hope that you would do the same. It's only making us both look like idiots for continuing on mindlessly.

Is it supposed to be?

Debate is only pointless if you do not gain anything from it.

Btw, lunpa, Gannondorf, whatever you prefer to be called, I want to apologize for going on with the stupid argument as long as I did. You shouldn't have to read through that garbage to find what you're looking for.

Anyway, you got your answers, so I guess that's all that matters. :)

Get off the high horse, man. You were the source of all this, through your failure to identify his problem and inability to accept your mistake.

I'm still trying to figure out how you can conclude that I made it sound like graal isn't a play thing when all I said is an administrative tool shouldn't have the ability to change their head.