![]() |
An experiment in customizing your own tile definitions
3 Attachment(s)
Right now you can't customize your own tile layout. You have to use either type 0(pics1), which is very unorganized(and harder to organize tiles in) and cluttered, or type 1('era'), which wastes so much space on tile types you might not even use. There's no way to balance out tiles the way YOU want. I thought I'd experiment a little and see what I could make.
Originally I want to do it all serverside -- it's much more secure and automatic that way. You upload the template to your server, and use an RC command like /npc update tiledefs. TADA. However, there's no functions on the serverside to interpret image pixels... so I had to do it all clientside. This means the functions would have to be called by designated staff to update the tile data, and the image has to be downloaded. This is not what I desired, but there's a reason this is called an experiment. Anyways, here's the process: 1) Take this key and use it! It contains the color values that my script processes. Make sure you eyedropper these colors! Attachment 50196 2) Now you can either take two roads: The fullscale road, which is taking a fullscale tileset template and working with it there, or the smallscale. Fullscale each tile represents its 16x16 scale in game. Make sure you stick to this grid or it will mess up! Color the tiles with the key above for each type you want it to represent. Here is a fullscale representation of pics1 with my color format: Attachment 50195 3) If you did it fullscale, you'll need to shrink it so each tile ends up as one pixel(way smaller filesize, and easier to read data from). You can't do this successfully with MSPaint. You'll have to use another program that lets you input specific resize numbers, and where you can disable filtering(needs to be nearest neighbor!). The desired size is 128x32. Now, you can skip this whole process by editing it on the single pixel level instead of resizing the larger one. The large template is just there to make visualization easier. You should end up with something like this: Attachment 50194 This is the good stuff. Upload this onto your server where it's downloadable(aka where most image files go). Alternatively, you can just place it in your Graal folder and delete FILENAMECACHE.txt. This will cache it in your Graal folder, making scripts able to read the data. This can be more secure if you're the only person who needs to generate the tile data. Here is the core script. You can place this in a weapon like -TileData or something. Add it to yourself. On creation, or whenever it's updated/you log on, it will go through the tile data and upload it to a serverr.var. This is not good, but not much is how I desired and this is only for display purposes right now. Replace the this.templateimage var with the image of your template. PHP Code:
Tiles.onBlocking(x,y) -- returns if there is a blocking tile at the x and y Tiles.onBlocking2(x,y,width,height) -- returns if there is a blocking tile in the size given at the x and y Tiles.inWater(x,y) -- Just like the above functions, but with water Tiles.inWater2(x,y,width,height) -- ^^ Tiles.onTile(type,x,y) -- Checks for a specific type of tile at the x and y, as per the default tile types: 0 nonblocking 2 hurting underground 3 chair 4 bed upper side 5 bed lower side 6 swamp 7 lava swamp 8 near water 9 near lava 11 water 12 lava 20 throw-through (fences) 21 jumping stone 22 blocking tile onTile2(type,x,y,width,height) -- ... There are pros and cons to this. Pros: 1) DEFINE YOUR OWN STUFF, MAKE ROOM WHERE YOU WANT IT. Not much more than that, is there? 2) Functions like onTile make some checks more streamlined than default offers. Cons: 1) Serverside functions did not offer me the tools I needed to make my initial idea; it was much more simplistic and secure in that stage, and felt more like a tool for a server. 2) It's all gscript. That means functions like onBlocking2 are going to be slower than their default counterparts, because they have to loop through the large checks. 3) I couldn't figure an efficient way to store the tile data in a way that's easily accessible to scripts clientside and serverside. It's a lot of data to store, however if it was possible to do it how I wanted from the start I probably would have put a lot more effort into this. Server flags will be more than suitable for my explanations, however. 4) Default tile effects will still happen... swamp tiles will always show swamp images and such. However, you can use type 1 tileset instead if you'd like, or use a custom sprites.png image with those images cropped out. Be careful with things like bush tiles, though this is for custom movement so that shouldn't be a problem(though they will still respawn!). Here's a small script I threw together to show how it works. It's actually pretty shoddy as I couldn't be assed to put more effort into it: PHP Code:
|
Anyways, like I said this is not meant to be something that can be used at the moment. I wish it was! However, the current state renders it at a level where I think it'd be insecure to use. Tile data is important, and insecurities can lead to easy wall hacking and such. This is an experiment, a demonstration, and maybe inspiration to get something similar hard-coded.
|
Cool o,o I'd love this
|
Bravo dusty. This is actually pretty nice.. Cons aside this is pretty good and hard work done although i cant think of any uses like major ones but this still has some great potential. i say keep working on it.
|
Quote:
I really don't like the idea of having to use the client, and clientside image, to calculate such sensitive data, though. |
Maybe stefan will do something like that for v6. who knows because v6 seems to be holding alot of new ****.
|
All times are GMT +2. The time now is 09:54 PM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.