Rehashing some old ideas...
 

*img layer -1: I don't suppose we ever got transparency in the pics1.png area such that you could show images BELOW the Tile layer, did we? That'd be nice:
- tile a pit and showimg the pit's contents (moving in paralax, kinda like in Zelda3) instead of a black void,
- tile a mountain rising to the sky and instead of houseroof blue with imgs of clouds, show a panorama that moves with the player, like in the old sidescrollers
- tile a house with a less-than-perfectly-square roof and, instead of having a Corner For Grass, a Corner For Snow, a Corner For Dirt, just have a corner on which the backdrop is transparent and teach an NPC (maybe even a system NPC) to showimg a 16x16 tile of grass behind it...so it uses one tile instead of 4. Apply this also to fences, Bomy statues, graves...

There were more, I'm sure of it...just getting writer's block...

Oh yeah, and key configuration. Since each server adds a few unique keys (I believe the example given was W for Whistle vs WASD for movement), is scripting support in place/planned to either move the server's keys through serveroptions to F1, or move the F1 keys through a new variable into scripting (ie, CONFIG_WHISTLE="W" in serveroptions puts another box in F1's Key Configuration or if(key(0)=="W") setstring player.whistle,E; or something)

Layering would definitely be the best addition ever. It would open up so many possibilities it's unreal.

I mean, there's a way to script it - you showimg the background as 0, then showimg pics1.png over that, in 64x64 (4096) pieces...but that hardly seems efficient. You could also TRY to cut the background into pieces that are the exact right size (per the level's Transparency Mask), but that might even be more work. Although...perhaps this is a job for the particle engine (cutting round corners on dynamically generated square images)?

But I'm talking to myself again...I don't have a tendency to make myself any clearer in so doing.

Oh yeah, and a Backup function for NPCServers. Just so we can back up all our scripts once a week or so (not even necessarily on our own computers - that'd be nice, but I can see the danger of Private GServers in the hands of unscrupulous ex-admins) and restore them. Also handy for when you need to move a really complicated NPC from an old server to a new one. Could also be used to make a Template Server and preload it onto blank PWs - so if someone wants a Classic Style Server, poof, here's one with movement and GMap Bombs and Baddies all scripted already, just add GMAP...

I love the whole layer idea and the NPC Server backing up it gets tiring to back up every day on my computer even though my computer has a fairly large ammount of space to do it the other ideas are very interesting. ;)

As long as we're on the topic of old ideas, I'd like to re-suggest the multitude of Graalshop improvements that have been said multiple times:
Make sprites easier to add. Add a sprite sheet viewer that allows you to simply highlight the part of the sprite you want to add then add it.
Individual direction frames. It should be an option on the side if you want individual frames for individual directions. Lets say that I want 7 frames for the left and 2 for the right.
Loop settings. If I want my loop to only loop twice, or a certain amount of frames, I should be able to make it do so.

This would greatly contribute to the awesomeness of Graalshop.

Hear hear!
On the topic of Graalshop - if it can't use the particle engine, it SHOULD. Last time I made a GANI I was stymied by the fact that body.png only has so many arm angles, well less than is needed to actually express such simple concepts as waving (I bodged something together, sure, but only barely) - if you can actually rotate it freely, it becomes turbo-awesome.

Also, if light effects and rotating were to actually show up in Graalshop, it'd become ultra turbo-awesome.

It'd certainly soften the effect of us being without a GS2 Editor, if we can at least make GANIs on the road...

Couldn't you just use setTimer(blah); then when it's looped twice put back to idle or whatever gani you want? x.x :whatever:

While that IS a workaround, it's imperfect - if there's any lag (including a delay in downloading part of the gani) at all on anyone watching, it's likely to cut out midstep, whereas if you could tell it to walk 3 steps then setbackto idle, even if it lags it knows what it's supposed to do.

Nice idea's, although you can do the layer's using images. It just depends on how far you'll go. Era tends to use alot of layerd images, we use setshape2 to get the effect of walking under it too.

...you've lost me. While I'll grant a horizon or a square hole would be easy enough to setimgpart to fake "Hey look, I can see the next room through this hole in the floor!", it's a lot tougher to part out a circular hole. Unless you put a circular hole image over a square moving image, in which case there's still the "Layer 0, Layer 0.1" problem...unless you can finally put stuff on imagelayers aside from 0,1,2,3,&4...

Oh, and float layers. Instead of showimgs on layer 0,1,2,3,4, you could show one on 0.5, 1.2, etc. for when you have to show two images, both under the player, one on top of the other, and you can't use the one-starts-lower-than-the-other trick.

Another thought:
serverside variable (read only)
int TriggerRecieved
Useful for calculating questions of timing: it returns one of those extensive integers (I forget, the one for Server Time), so the server can (when necessary) do the math itself for "I sent it the trigger at 12345678, I got the response at 12345680, 12345680-12345678=2" instead of "The client says he responded in 2, so I'm sure he did". It'd still be a passive 'command', so it's not like it'd generate any more serverside traffic, just one more serverside FLOP when it's used to calculate in a serverside action.

Might tighten security, who knows?

I have not played Classic since Com013 quit and whoever rewrote the whistle thing afterwards did not bother to make W configurable :mad:

Normally triggers are processed immeditially on serverside when using the new scripting engine, so you would just need to check for timevar2 I guess.

's a good point.
Anyone got an idea how we could do the layers/paralax thing though? I got an idea for a tile overlay (so you can use the same Wall tiles for a stretch of wall, then overlay the "Cracked Bricks" light to it - but only to the tile layer, not other drawunderplayer/imglayer 0 images), but it doesn't seem Graal supports it...

Don't know if this was ever actually added:
A return to Sprite access.
So you can show a gani starting at frame 32, or perhaps Only showing frame 32. Make things seamless with a minimum of additional files - you're walking, midstep you swing your sword so it throws in a transitional frame out of the big Walking_Swinging gani, does the sword-swing-animation, then throws in another transitional and you resume walking...as a rather poor example, but hopefully it gets the point across. Really I want to use it so I can have a few options for ganis with all the rotations I need for ANOTHER gani and call the roto-ganis from within the main gani...so your character is walking, and his hands are RotoGani_[Param1], Sprite 1, etcetera...no matter what he's holding.

's a thought.

Another half-baked security suggestion that may already be implemented:
Allow the serveroptions to determine what data is sent from player to player. For instance, there might be a server where the player's X, Y, and level ought not be visible - for instance, a Ninja server where hiding is everything - if such data was being sent and the client's system was set to ignore it, it'd be trivial for some trainer somewhere to override that and make some clientside script to draw a big bullseye on the erstwhile rogue...but if the Server says the victim's under no obligation to tell the hacker where he is, the hacker never recieves the packet saying "You are in level13.graal. Victim is in level13.graal, at (32,32), using walk.gani, has a head0.png, his colors are red/green/blue/black/white..." in the first place.
Counter problem - hackers could then refuse to send packets, I suppose.
Solution - the server checks every once in a while. "Victim, did you see Hacker while you were in level13? No? Hmm, bump him up a threat level..."

"Hacker, did you see victim while you were in level13? No? BAN!"

*shrugs* As per usual, you have to weigh the evidence. If NOBODY'S EVER seen Hacker in Any level EVER, it's a bit odd and deserves some investigation, but if Hacker's never reported seeing anyone ever, that's odd too. Admittedly, there's always room for packet droppings and so forth - AOL's firewall, DNS errors, I wouldn't say banhammer everyone who vanishes. Just log 'em.