Project

Profile

Help

HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Bug #874228

Casus belli messages are somehow not including the tile link.

Added by Lexxie L about 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Freeciv-web
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I got this while testing #874199 but have seen it before also. Screenshots for:

1. a casus belli from a pillage

https://gyazo.com/70834fef4cf0e166312f3f9c825243f5

2. a casus belli from a nuke
https://gyazo.com/7936bdaf0d4634e1ed78395a66858fbb

History

#1 Updated by Lexxie L about 2 years ago

update: I looked at the packet coming back, it does have <l tgt=\"tile\" x=0 y=11 /> in the packet. Therefore not a server issue but FCW client, it seems.

#2 Updated by Lexxie L about 2 years ago

Was caused by server side using ... /> and no closing tag.
Putting those in on server side breaks other things that are apparently dependent on the "malformed" tile_link not having a closing tag.

Had to fix it on client side by reconstructing a well-formed link. :(

https://gyazo.com/029866ed845a866a1fc8521195961f53

https://github.com/Lexxie9952/fcw.org-server/commit/0e9847d1646adff096d201108ae77b1514f2c4b4

#3 Updated by Lexxie L about 2 years ago

  • Status changed from New to Resolved

#4 Updated by Marko Lindqvist about 2 years ago

Was this freeciv-web only problem? Are desktop clients already handling this?

#5 Updated by Marko Lindqvist about 2 years ago

  • Tracker changed from Task to Bug
  • Category set to Freeciv-web
  • Status changed from Resolved to Closed
  • Assignee set to Lexxie L
  • Sprint/Milestone set to 3.1.0

Oh, reread what you wrote. So it was not server sending actually broken tags, but web-client not being able to handle the form the valid link was in.

#6 Updated by Lexxie L about 2 years ago

Well, I don't know what to call it, a bug or a design issue or what. But usually, if it's done right, a it would be like this:

<link element=val>content</link>

This is what most of the links on freeciv do obey.

However, this tile_link(ptile) function does this:

<link element=val />content

I have not tested other clients on this. There is some chance they don't work. There may be some special reason they did it this way. Because when I tried "fixing" it on the server to be traditional way, it didn't like it and crashes the server.

I'm just reporting what I found out here. FCW is working by having to do ugly solution of intercepting these links and reconstructing them. It's ugly but it works. If someone figures out this should be different and adjusts it, please make sure I know. I'd love to take out the ugly code in FCW client ;)

Cheers.

#7 Updated by Sveinung Kvilhaugsvik about 2 years ago

Marko Lindqvist wrote:

Was this freeciv-web only problem? Are desktop clients already handling this?

This is not a problem in mainline Freeciv. Freeciv-web patches the server side code to send messages as HTML or something similar.

Lexxie L wrote:

If someone figures out this should be different and adjusts it, please make sure I know. I'd love to take out the ugly code in FCW client ;)

I have had plans for a while to implement parsing for regular Freeciv messages to upstream Freeciv-web and drop the patches (and/or patch fragments) to the server that changes the message format.

Would this be something you would be interested in doing? That way you can learn how to do a patch without having to change from the familiar Freeciv-web environment to the Freeciv environment. So only one new thing to learn at once.

Also available in: Atom PDF