Yxxe

@Marsh: > Good luck. > > You have but barely skimmed the surface of what you need to do. +1\.

@Harrie: > What exactly does it do? :) It does what it says on the tin.

Unfortunately, it's published by Webzen, who have the extreme knack of cocking things up. Let's hope it doesn't happen with this. D:

@Marsh: > Lightning won with origins. 

-> New tile attribute, "Ledge". This works as a dynamic directional block tile, rendering order handler (decides whether the player is above or below the ledge) and calculates the upper bound elevation, depending on the tile directly 'underneath' it. (x is the same, y + 1) As the ledge will always be a fringe tile, this tile check will always retrieve the correct upper bound elevation. This solves the problem, and will support the range and water systems. Why you asked me to post this here, Azk, I don't know. ;]

The top-left tile [ (0,0)px to (32, 32)px ] needs to be completely filled with that pink you are using.

@Fuu: I got it, it just wasn't funny.

@Fuu: > HAHAHAHAHAHA. > > Thats what it should have said. 

:]  EDIT: The above it just a test map, just showing off the improved lighting. xD

They're most likely using a modified client and injecting the memory used by your game to change the WALK_SPEED and RUN_SPEED. (The variables are called something like that) You would need to add some server-side checks to make sure they aren't getting ahead of where you want them to be. If they do, then just reset their position to where they should be.

@SnowStorm: > but s33ing 4s y0u 4r3 the nub that m4k3s you shutting yours3lf upz? > what is up wid d@? AHHH MY BRAIN

_…blows cobwebs off of source code._ Server > modServerLoop > Sub ServerLoop. Look for the call to "UpdateMapLogic". Underneath it, there will be this line of code: ``` tmr500 = GetTickCount ``` Change the '500' to a smaller number. Be warned though, this speeds up all NPC movement, seeing as pets are implemented as NPC's on a map.

Started off the lighting system. At the moment, in the map editor there is just one light source with a fixed radius. That's all working, so I may add varied radii later on. Please note that I just used a basic tile gradient to demonstrate the effect. **Light source merging** >!  **Lighting on a test map** >! 

@Azkanan: > Map editor is working fine 

(Width of screen / 2) - (Width of text / 2)

@ZoSo: > You guys are really mapping those many maps :P? > Sheeesh, anyway looks interesting. Hope it makes it out someday. I'm not, Azk is. He said he's happy to do it all himself. xD

@Anna: > Banned and expect criminal acts for displaying property owned by Enterbrain, Inc. :o

Updated map editor. 5k * 5k "Regions" just over 1GB, but split into 50x50 "segments", at 108 kilobytes a piece. Obviously, these can be loaded and unloaded whenever necessary, but I also aim to use memory mapping to make everything a bit more efficient (thanks for the links, Stephan! :D). It also means no large client downloads are needed! :D Below is an image or the map editor, again, but this time with the new file system, which has brought 4 separate segments together. (The grid is just there because Azk wanted it). The code still needs a bit of cleaning up, but I should have the a working version for Azk to start mapping on either tomorrow or Saturday.  Peace, Lightning

@Anna: > -snip- I'm not sure if you know, but I'm using C++, not VB. Therefore, I can send the big map in the smaller required chunks, which can then be patched over the existing data range in the client files.

@Jeff: I like that idea, its sort of a compromise between both options. Low memory usage in-game for the client, while the server is not pumping out data. I think I'll go for that, thanks! @Azk: I'm on my phone. ;-)

@Miguu I don't need a constant stream of data, the map just needs to be updated whenever a change is made. The threads purpose was more along the lines of which of the two methods people would prefer, as I was unsure. As it sounds, people wouldn't mind downloading a larger client, so I will most likely go ahead with that. If anyone can find any other viable advantages to option 1, it would be great to hear them before I start. :-)

Real-time player modification, yes. The caching method you also mentioned could replace the chunks method in option 1, but the updating rate would still be a bit of an issue.

@Rusher: > Not to forget I don't like the Cons of either options. That's the main reason I posted. I figured whatever the potential players wanted the most I would go with. ;]

@Marsh: > I would say put them client side. Though i am not sure why your maps are so big. Each map is 2500x2500\. ;]

Well, it's time for me to start doing the map rendering for Project Terra, and I've stumbled upon a dilemma. As maps are updated frequently, (player housing and other map events) I've come up with two options, and I'd like you to decide for me which one I should do, down to your personal preference. The poll will only be up for a few days at the most, so vote quickly. Vote only once, and please post the reasoning behind your response if you can, thanks. **Option 1** All map data stays server-side, and "chunks" of map data (around 50x50 tiles) are sent to the client when a player crosses the X or Y "halfway point" in the map. Data is requested from the server, old data is removed from the map cache and the new data is appended. Pros: -Reduced client size. -Lower memory usage in-game. Cons: -Server could potentially be sending map data every 1/2 second or so. -Drawback on server performance. **Option 2** Map data is stored client-side, and frequent update requests are sent by the client after so many steps in one direction. Pros: -Better server performance than Option 1. -Map data will be sent out at less-frequent intervals, depending on if the map data client-side matches the server map data. Cons: -Higher memory usage in-game. -Client data size exceedingly larger. (Each geographic map is 262MB). Thanks for your time, Lightning