Tiles

Have you read the tags of the tile and ensured that they are in fact, still tagged as solid? Have you tried setting the flags _right before_ a collapse? This kind of thing hasn't been tested very extensively, so it's likely there's a bug, but if you can figure out a workaround, that'll provide some hints into what might actually be broken and help us get a fix for it - or in the worst case, just clarify your misunderstanding and help you get a working implementation :)

edit: oh, also, there's 2 separate implementations which I guess might be the bug, actually-

versus


Checking the impl

It looks like this is indeed the problem. I'll stick it on the list of stuff to be fixed, thanks! (it's the weekend here so I'm not gonna look into it now but it should be pretty trivial)

(again, in the meantime for you, it might be easiest to take the trench run approach and use blobs for the collapse rather than the inflexible built-in collapse system)

 

(should be fixed next build, which looks to be some time next week)

 

It's entirely hardcoded. You could do similar with an onRender hook in rules or map, iterating visible tiles (probably want to cache the relevant ones in a tick function, and maybe do it iteratively) and drawing the effect by hand.

 

You'll have to do some "hacks" for this to work. The tiles do not support collision filtering. We use blobs for platforms in KAG. Classic had custom code in the tilemap for platforms.

Most obvious one I can think would be disabling collisions vs the map and then having some manual collision handling vs other tiles until you escape the platform, but that's not easy!

There was also a point of time in classic where the platforms actually would "unsolid" (they would enter "trap" mode) to let you go through. You could replicate that instead.

You cant. Classic fakes this with extra tiles like "ladder on castle background" "ladder on dirt background" and so on. When you do this for all types of "2 layer" tiles, it quickly adds up (you need 3x the tiles, 4x if you support wood background, more if you want to support partly broken background tiles...) and is a huge pain to manage.

KAG now uses blobs to avoid complicating the tilemap like that; workshops and ladders and platforms and spikes are blobs.

 

There's a cheat in the tile rendering code for changing what is displayed, and rendering 2 tiles at once. The combined tiles use that to save manually exporting it, but we used to just manually combine them before that system existed.

No blobs in classic. The sparkly gold is done in a specific routine just for that, bolted onto the tilemap - i think it's still operational? but it's hardcoded, not configurable at all.
The leafs layer and a few other things used a system called "imposters", which basically allowed positioning a sprite somewhere on the tilemap. Imposters are not used in current-day KAG.
The gold shiny

A routine scans the map (a few tiles at a time); if it finds an empty tile, with a tree top below, or a tree stump tile, it grows a new tree piece and changes the piece below it to tree trunk.

Is legacyTileDestroy true? server_onTileHit is only called for non-legacy tiles (>255) if it is.

 

As usual with this stuff (old hacks): no, it's not exposed to the scripting side of things.

This can already be done. There's no reason this has to go "in the tilemap" - you can have an external store of data and look it up by tile offset in the stuff that needs to know about it. Just store it in the rules data store.

Here's some untested example code to sketch out what I mean:

Code:

///////////////////////////////////////////////////////////
//TilemapExtraInfo.as

shared class TilemapExtraInfo {
    //info needed per-tile
    shared class ExtraInfo {
        u16 id_who_placed;
        ExtraInfo() {
            id_who_placed = 0;
        }

        CPlayer@ player_who_placed() {
            if(id_who_placed == 0) return null;
            return getPlayerByNetworkId(id_who_placed);
        }
        void player_placed(CPlayer@ p) {
            if(p is null) id_who_placed = 0;
            else id_who_placed = p.getNetworkID();
        }
    };
 
    //all stored in a big array just like
    //with the actual tilemap
    array<ExtraInfo> info_map;
    u32 width;
    f32 tilesize;
    TilemapExtraInfo() {
        info_map.resize(getMap().tilemapsize);
        width = getMap().tilemapwidth;
        tilesize = getMap().tilesize;
    }

    //get the info out of the map
    ExtraInfo@ get_info(u32 offset) {
        if(offset >= info_map.length) {
            return null;
        }
        return @info_map[offset];
    }
    ExtraInfo@ get_info(Vec2f pos) {
        pos.x /= tilesize;
        pos.y /= tilesize;
        u32 offset = (int(pos.x) % width) + (int(pos.y) / width);
        return get_info(offset);
    }
};

//needs to be called when a new map is loaded
//or the tilemap will be the wrong size
//crules onInit and onRestart is a good place for this
TilemapExtraInfo@ rebuildTilemapExtraInfo() {
    getRules().set("tilemap_extra", null);
}

TilemapExtraInfo@ getTilemapExtraInfo() {
    TilemapExtraInfo@ tme = null;
    getRules().get("tilemap_extra", @tme);
    if(tme is null) {
        getRules().set("tilemap_extra", new TilemapExtraInfo());
        return getTilemapExtraInfo();
    }
    return tme;
}

//(could also have accessors here to cut down on typing since
// getTilemapExtraInfo().get_info(pos).player_placed() is a bit wordy!)

///////////////////////////////////////////////////////////
//ManageTilemapExtraInfo.as

void onRestart(CRules@ this) {
    rebuildTilemapExtraInfo();
}

void onInit(CRules@ this) {
    onRestart(this);
}

//(build your command-handling system here)

If you need it synced then probably commands are the way to go and write helper methods for the server to sync it out as needed. Write one command type (to avoid eating lots of cmd ids) with a few "sub-commands" (just another u8 id that lets you know what you need to run)... Let me know if you need clarification on that.

This can already be done with the various hooks. We have totally custom tiles in TR. You can react to the collapse callback; return false to prevent the built-in collapse block from spawning and do whatever you want from there (play sounds, spawn particles, run your own custom simulation...).

These are called "eggs" in the old classic codebase. The material "lumps" also use them. Characters are called "runners" in classic. Blobs were invented to unify those concepts somewhat and add a (misguided) component architecture.

 

I laughed

Glad you got it working :)

Hook their collisions and check if they're moving fast enough and colliding anything that they should hurt. Simple check for being the same blob is comparing names. You probably want to figure out a way to make them settle or destroy themselves on hitting the map.

Don't forget to destroy them as appropriate after hurting.

 

Looking v cool, Golden. Definitely an inspiration for me to try and fix my laptop and poke some code.