[MAP ISSUE] Downstairs->NoCharacter->CTRL+G = Black Screen.

[darkshin]

Hello Guys!!!!!

I was with this issue at a Global Map sometime ago, but then I started mapping one for my own and suddenly two sets of stairs at the same location but one brings -1 and other +1 both are with this bug. When you move into the stair you lose the control of your character and if you relog u get a black screen.

Anyone can help?

 

[darkshin]

Well, just put the 10.76 .spr, .dat, and .otb into the 10.55 folder for your remeres. (lazy way of making sure)

You ALSO need a 10.76 .otb in your items folder for TFS.
I actually had this happen to me yesterday. I went back to one of my older servers, and I had changed certain items in the .spr and .dat, but the older server did not have an updated .otb file in the items folder. So every time I went on the screen with that item, my client would crash or bug out.

Well, I used an earlier version from Remere and sucessfully saved the map to 10.76. Then I replaced the items.otb o TFS with the one used in remere's. And it's still bugging. Maybe if I lower the map version it could behave different, but the only thing that don't make me think this way and what I don't get is: Why when I use x-8 and y-6 it don't bug?

Also, do you want to test my map ? I can send it to you.
Or login into my server?

 

[Flatlander]

Well, I used an earlier version from Remere and sucessfully saved the map to 10.76. Then I replaced the items.otb o TFS with the one used in remere's. And it's still bugging. Maybe if I lower the map version it could behave different, but the only thing that don't make me think this way and what I don't get is: Why when I use x-8 and y-6 it don't bug?

Also, do you want to test my map ? I can send it to you.
Or login into my server?

That's easy. When you use 8x6, you are getting a 18x14 screen.
When you increase the screen size, the bugged area is now included.

You could always try to DECREASE screen size and see if it happens. (try 7x5, or 6x4, etc)

 

[darkshin]

That's easy. When you use 8x6, you are getting a 18x14 screen.
When you increase the screen size, the bugged area is now included.

You could always try to DECREASE screen size and see if it happens. (try 7x5, or 6x4, etc)

I see, I will test it later. But ins't also true that if I'm walking at the floor of the bugged area and walk nearby enough to my screen loads it, shouldn't my client bug also?

Or this happens only when the screen loads, like when changing floors, maybe?

 

[darkshin]

~News~

I've tried a lower resolution as you suggested @Flatlander and at first I've got some random bug, like I was walking and my character name dissapeared and the client lost the creature. But then I relloged and everything was working fine. So It can be a bug map as you think. Ill post some screens from the editor here and Ill also use a different version from the one I was using.

 

[darkshin]

@Flatlander Hey Flat, I've tested my map and it's nothing wrong with it. I mean, It can be something related to black squares around the map. But it's nothing related to the map itself, but to the communication between OTClient and TFS. My point is: there's no code at OTClient that enables a support for a larger screen. Or a large request of "GetMapDescription" or "GetFloorDescription" at the same time, and somewhere in this huge demand, the OTClient or the servers loses some bytes and the character in the meanwhile. If you take a closer look at protocolgame.cpp from TFS and protocolgameparse.cpp from OTClient, you will see that the functions that are related with the map are not directly assigned to each other, like others are. I'm just a begginer and I have no idea if what Im talking about is true but this is my last idea to this issue.


Look at this function from OTClient that has nothing from TFS assigned to it:

void ProtocolGame::parseChangeMapAwareRange(const InputMessagePtr& msg)
{
    int xrange = msg->getU8();
    int yrange = msg->getU8();

    AwareRange range;
    range.left = xrange/2 - ((xrange+1) % 2);
    range.right = xrange/2;
    range.top = yrange/2 - ((yrange+1) % 2);
    range.bottom = yrange/2;

    g_map.setAwareRange(range);
    g_lua.callGlobalField("g_game", "onMapChangeAwareRange", xrange, yrange);
}

 

[darkshin]

@Flatlander New lead Flat.. just found something new and unexpected. I've added all over sendMoveCreature function that send messages to the server when the a function is called, and I've found out that the moveUP or moveDown creature aren't being called when you use a ramp/ ladder/ stair/ whatever. What is beign called istead, is a Teleport Function. So, I've been looking for what is turning the bool Teleport true from the function:

void ProtocolGame::sendMoveCreature(const Creature* creature, const Tile*, const Position& newPos,
    uint32_t newStackpos, const Tile*, const Position& oldPos, uint32_t oldStackpos, bool teleport)

And I've found this 3 other functions that calls sendMoveCreature:

void Teleport::addThing(int32_t, Thing* thing)

ReturnValue Game::internalTeleport(Thing* thing, const Position& newPos, bool pushMove/* = true*/, uint32_t flags /*= 0*/)

ReturnValue Game::internalMoveCreature(Creature& creature, Tile& toTile, uint32_t flags /*= 0*/)ReturnValue Game::internalMoveCreature(Creature& creature, Tile& toTile, uint32_t flags /*= 0*/)

I've opened an issue case at forgotten server github. If you have any further ideas about it, please let me know.