Graal v4.03 revision 5 released
 

New versions for Windows and Linux have been uploaded. Download them by connecting to the login server.

Changes:
Graphics engine (Windows):
- Improved initialization of textures to make it work on more graphics card
- When there is no hardware graphics acceleration the game continues to work but displays a message in the F2 window
- Several errors that were spamming the F2 window before only display one time now (like 'Error drawing image bubble.png')

Installer (Linux):
- It's installing the offline levels now, so offline mode should work now

Scripting:
- Fixed findareanpcs(x,y,width,height) on gmaps on clientside
- Improved support for projectiles with different gravity (this will not be enabled until v2 is disabled though)

Can you define what player.join() is supposed to do with the clientside part of the script? I assumed it would behave almost like a weapon, but it does not...

Only clientside parts of npcs and weapons and affected by a serverside join

Yay. Thanks Stefan :D.

Can you post the exe (windows)? For some reason the setup is having the same problem that revision 4 was having.

EDIT: See this for details.

Explain, what kind problem ?

hooray! now all I need is some dontblock() detection. Only thing that detects it right now, as far as I know, is onwall/onwall2. And in that case it doesn't detect it, but ignores the NPC altogether.

Stefan, as for a read-only bool for detecting if an npc is blocking or not, I need to know whether or not you'll add it to see what direction I'm going here (if you do it will be nice, if you don't it will be a nightmare that will probably last a month or two).

What exactly do you need added ?

npcs[i].notblocking;
Anything else that I might have needed wouldn't really matter in my movement system since Master Storm had already rescripted push/pull to be independent NPCs, and had made a liftable objects class, etc. Although, with my movement system, liftable objects won't have to call the system to be lifted. However, it would still be good if there were bools for canbelifted(), like npcs[i].liftable == 1.

Mostly it would make it less of a hassle to convert NPCs for the custom movement system because right now it's impossible to accomodate a lot of command functions with a custom movement system. I'm just having trouble with dontblock because I'm trying to upgrade my movement system (beyond onwall2) to be a bit more dynamic, though mostly in the sense of players. To accomodate that, however, you need to be able to test tiles, players, and NPCs independently. Tiles was easy, players are more controlled and easier to optimize around, but NPCs are very dynamic. That's why I needed access to findareanpcs(). However, I still can't test whether or not an NPC is blocking, and that's pretty much the last thing before I can start removing the onwall code and start worrying about determining when a player blocks and when a player doesn't block (and we have more control over players, so it shouldn't be too much of a problem).

Hmmm Should be quite sinmple to add, will do in the next version
May be also some objtiletype(x,y) and objonwall(x,y) and objonwall2(x,y,w,h) functions

Well I see you've contemplated the work-arounds I could have used too :P.

While you're at it, you might want to think about adding a canbejumped() function along with a bool var for it. I was going to do that with my movement.

Hmm... I also think player.reading doesn't work for serverside signs.

Also, is there any way to lift a script other than by default movement?

Jumping? Use setshape2 and tiletype 21, even works with classic movement.

Player.reading cannot be checked on serverside, but it is setting the pause mode.

Lift a script?

yea, but it's simpler to use isJumpable. Not difficult for me to add to my movement, so this wouldn't matter to me.

Well, there is an event handler "wasthrown". But you can't really use it in custom movement. In fact, storm's movement just fires a projectile. Although considering that objects thrown should always travel a constant distance, we don't really need to use shoot for throwing carried objects. Having access to wasthrown would help bomb scripts make more sense, but you can't do it unless you know what NPC your carrying, and that NPC's script. Something like that.

Well, I guess I should be testing for paused then :P.

Using projectiles for thrown objects is the preferred way, not sure why you want to mess with the deprecated classic system.

Just seeing if I can make Classic's new systems easier for incoming scripters to understand. First, they're very hard to come by. I lucked out with Yen applying, he has a decent understanding of scripting. Kronan still needs some training, and everyone else I've hired has been fired for doing stupid things.

Oh, I failed to mention, and since I can't find the edit button, shoot really needs a bit of work.

1. Clientside-Serverside Consistency:
This is what drove me away from playing Graal Kingdoms, the blockiness of it all.
2. More options:
No wall blocking, but instead solely object blocking, is what Classic players are really interested in. I'm pretty sure that the way it is now and with enough toiling, we can turn arrows into fire arrows when they go through explosions, fix the arrow endsprite to old Classic style, and so on. Perhaps the best approach would be tiletypes? like, it might be interesting to block tiletype 22 but not tiletype 21 in certain instances. Fire arrows are important to detect walls, that kindof sense.
3. oh god... this floor is way too loud to concentrate right now. Drunken idiots.

Okay, quieter now. Another thing... My movement actually supports opposite boots and gravity boots with ease (remember the old really bugged ones?). Anyway. There are some things that are a hassle with the opposite boots.
1. level links require you to be facing them? (signs should of course).
2. playertouchsme only works if you're facing the npc?
3. (only somewhat related) It would be extremely, extremely very, very, very nice if there were an onCollision event handler... where either an NPC touches a player or a player touches an NPC. I can't stress this enough. It would significantly improve baddy scripting. With serverside damage scripts, you don't want to call the server a lot. It creates unneccessary usage. However, what if you wanted to create an area in a level, that if the player enters the player would get hit. The only good way would be to have a clientside timeout and trigger the server if the player enters the range of coordinates. I've wanted to do this in the level for my Water Quest miniboss. This could be easily accomplished with an onCollision function and an NPC that has a serverside setshape.

I would like to know where I could download the guigreen* files.

?
Right, do setshape and use onPlayertouchsMe()

Stefan, onPlayertouchsMe() only works when:
1. the player moved in the direction of the npc
2. the player's 2x2 shape offsets or overlap the NPC
3. the playerdir is facing towards the NPC or sideways away from that.

Problems:
1. no way to reciprocate it when an NPC moves to touch the player
2. the player might be moving backwards.

Level links present the same problem as Problem #2, except more exclusively they only link when the player is facing them.

I'm happy that I've at least seen some great improvements in playertouchsme.