I want to change my tileset

How do I get this to work?

if (playerenters) { setbackpal pics1snow.png; }

It finds the image, it changes the tiles… but the screen is all corrupted. WTF is wrong with this thing?
Please tell me we can get this working without errors, custom tiles are a HUGE life saver when doing tile work. Some things are just not possible or good looking with pics1.png.

Using pics1.png

Using pics1snow.png

if(playerenters) addtiledef pics1.snow.png,0,;

Thank you,
It works!

So I was barking up the wrong command. I always figured that’s what backpal was for. With the correct term I found another topic with a more correct form of the command.

if (playerenters) { removetiledefs; addtiledef pics1snow.png,,0; }

While you’re right, you’re also wrong. Back when GR had a playing population as such we had a problem with people not including prefixes and tilesets clashing in between servers.

So it’s advisable you name your levels in such a manner as they can be uniquely identified from other servers levels.
For example, if your levels start with classic-snowvil_level1.nw,classic-snowvil_level2.nw,etc… your prefix is obviously classic-snowvil_
and thus your tile definition statement will be

if (playerenters){
  addtiledef pics1.snow.png,0,classic-snowvil_;
}

And then you wont need to use removetiledefs; as you’re not over-riding any previous definitions such as the definition with no prefix.

Am I limited to the original size / scope / and space of pics1.png, or can I add to it? I only ever thought we were limited to replacing the existing tile space.
Moreover… the type of tiles, how the game interacts with them, is hard coded by location is it not? If I add new space to pics1snow.png, Graal wouldn’t know what to do with them.

I’ll be conducting some experiments to try and prove to myself, or push past the expected limitations.
Further guidance on advanced tile replacement would be much appreciated.

You cannot make the tileset larger.

You may however use addtiledef2 to add new tiles on top of the current ones for certain prefixed levels.

Right, so there’s nothing advanced to learn. It’s just tileset replacement.

addtiledef2 has no height or width. Does it get those from the image, or is it hard coded to be a single tile (16x16) at X, Y?

It inserts the image at the coordinates.

First, where I currently stand:

Using pics1
Using pics1desert

if (playerenters) {
  removetiledefs;
  addtiledef pics1desert.gif,westgraal,0;
}

While working, this effort has presented itself with some major challenges.

1: The tiledefs are to be applied on “map” levels. Ergo, they are visually connected, allowing the desert tiledef to corrupt the visuals of nearby levels that are close enough to be on screen. I had hoped making it only apply to “westgraal” levels would solve the issue, allow Graal to choose on a per level basis, but Graal does not work that way. Everything is rendered using the same tiledef, even for levels next door that are not meant to have that specific tiledef. Sad panda.

My solution would be to replace odd tiles that you’d never see in the desert. (Hello snow tiles!), but this leads a multitude of other problems. They’d look like jibberish in the editor, and in levels next to the desert. I’d have the same problem of pics1 snow tiles being visible in the desert before you enter the desert to change tiledefs. Bugger me. Even with this solution I’ll need an entire level wide cushion between the tiledef being changed - and when I actually use those tiles.

None of this would be an issue without multiple tiledefs sharing map connected levels…

2: The editor is buggy and problematic when it comes to displaying custom tiledefs. I had to open up training mode just to stop getting a black screen. Doesn’t seem to work when I open the level from windows explorer.

Is there anything I can do to help the editor function?
Am I totally screwed by having tiledef changes on visually connected maps?

if (playerenters && !isweapon)toweapons -tileloader;
if (playerenters && startswith(desert_,#L)) {
addtiledef pics1desert.gif,0;
}else if(playerenters)addtiledef pics1.png,0;

Interesting idea, thanks, but it does not address the issues of the editor failing to load the tiledef image, or the need to apply it without seeing the change on the level next door.

Upload the map image to the server. (Press M in editor with map loaded for image)

Speaking of the map…? No, that’s misdirection.

The map is not a problem, tiledefs are the problem. Carefully handling them so that they do not reveal themselves as either sudden, or appearing on the wrong level. I mentioned the map because, obviously, those things do not occur unless you can see multiple levels at once. It’s a problem, perhaps, born from a stubbornness to ensure everything is connected and nice looking. With Graal’s limitations those are actually two contradictory goals. Seeing levels connected causes problems such as the one I’m now wrestling with.

I’m afraid few people are knowledgeable on the particular specialty of managing tiledefs on connected levels… and I’m even more afraid that their solutions are as terribly messy as the ones I’m considering.

I’m considering buffer levels between major changes. Between pics1 and pics1desert… I’d throw in changes to tiles not ever used outdoors. Or at least ones I can ensure are not used near my desert. Then further inside I can swap out the grass and everything else that’s green… but I’ll need buffer levels without ANY of those tiles in them before I can switch them… but then I’ll need a level per side to switch the tiledefs a screen away… guh… this is a two level buffer that’s required. Not feasible to place such a design on something expecting to fit nicely on the main world map.

Even if I leave the grass and other normal tiles alone, I cannot let players see the small changes before the new tiledef loads. Still a minimum of one buffer level between setting the change, and using it. :bang:

Seems we lack the tools to do what I really want.

Yeah buffer levels sounds like the only solution. Or request players to turn off level connections.

OTOH, a buffer is only truly needed if I change tiles that don’t belong. The desert is largely going to be a color swap…aside from that everything else should look normal…

Could it be considered artistic license to have that desert color appear suddenly when you enter the desert, even if the level behind you changes with it? Not what I want… but just giving in to it may not be the worst thing in the world.

Best idea I can come up with is different maps for these different regions, but I could easily understand why you wouldn’t really want to do that either. I was thinking of something with transitions, and a timer detecting playerx and playery to determing when to transition the tileset… but that didn’t really fix the issue either. Would still have the grassy area turn into a desert suddenly.

The Graal tileset huge and full of useless tiles. Consider just replacing those with your desert tiles so you just have one tileset. That is if you haven’t already made a ton of your desert levels.

Useless tiles, across an entire server? Surely some of them are used somewhere. I can only presume and control that they’re not used in certain areas, such as around the desert.

Presently my solution will be artistic license to employ what appears to be a color swap in the desert. We’ll see how it ends up, I can always change it. As for already made, nope, it’s still a clean slate. I’ve been messing with some of the border levels and toying around with weapons. Funny thing is, it’s not placing tiles that’s the effort behind level creation. The real trick is what you’re making, its purpose, its layout, content creation is the burden. It would be pretty easy in comparison to just remold already made levels with new tiles later.

Speaking of tiles, I figured out that opening graal levels with GraalEditor.exe is pointless. As I can open them with Graal_222.exe and my tiledefs images can then be viewed properly. So at least that problem was solved.

On Zolderon, each location had its own map, tiles and music.