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
closed
Casus belli messages are somehow not including the tile link.
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
Updated by Lexxie L about 3 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.
Updated by Lexxie L about 3 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
Updated by Marko Lindqvist about 3 years ago
Was this freeciv-web only problem? Are desktop clients already handling this?
Updated by Marko Lindqvist about 3 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.
Updated by Lexxie L about 3 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.
Updated by Sveinung Kvilhaugsvik about 3 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.
.