From nicolas.weeger at laposte.net Fri Jan 4 13:42:56 2019 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 4 Jan 2019 20:42:56 +0100 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[20646] server/trunk/server/player.c In-Reply-To: References: Message-ID: <201901042042.57371.nicolas.weeger@laposte.net> Hello. That change will break strict ANSI C conformance, as you can't declare variables except at the start of a block. Here "turn" is declared only when assigned. I'm fine with that change, of course, but then we should clearly state that ANSI C is no longer relevant :) Best regards Nicolas Le samedi 29 d?cembre 2018 05:42:49, Crossfire CVS repository messages. via Crossfire-cvs a ?crit : > Revision: 20646 > http://sourceforge.net/p/crossfire/code/20646 > Author: partmedia > Date: 2018-12-29 04:42:48 +0000 (Sat, 29 Dec 2018) > Log Message: > ----------- > Clean up > > Modified Paths: > -------------- > server/trunk/server/player.c > > Modified: server/trunk/server/player.c > =================================================================== > --- server/trunk/server/player.c 2018-12-29 04:42:41 UTC (rev 20645) > +++ server/trunk/server/player.c 2018-12-29 04:42:48 UTC (rev 20646) > @@ -3007,7 +3007,8 @@ > } > > /** > - * Player gave us a direction, check whether to move or fire. > + * Move player in the given direction. Can be called by a client through a > + * movement command, or by the server for some other reasons. > * > * @param op > * player. > @@ -3017,8 +3018,7 @@ > * 0. > */ > int move_player(object *op, int dir) { > - int pick; > - object *transport = op->contr->transport; > + object *transport = op->contr->transport; //< Transport player is in > > if (!transport && (op->map == NULL || op->map->in_memory != > MAP_IN_MEMORY)) return 0; > @@ -3029,7 +3029,6 @@ > return 0; > } > > - /* peterm: added following line */ > if (QUERY_FLAG(op, FLAG_CONFUSED) && dir) > dir = get_randomized_dir(dir); > > @@ -3036,8 +3035,6 @@ > op->facing = dir; > > if (transport) { > - int turn; > - > /* transport->contr is set up for the person in charge of the > boat. * if that isn't this person, he can't steer it, etc > */ > @@ -3044,7 +3041,7 @@ > if (transport->contr != op->contr) > return 0; > > - /* Transport can't move. But update dir so it at least > + /* Transport is out of movement. But update dir so it at least > * will point in the same direction if player is running. > */ > if (transport->speed_left < 0.0) { > @@ -3057,7 +3054,7 @@ > if (op->speed_left < 0.0) > op->speed_left = -0.01; > > - turn = turn_transport(transport, op, dir); > + int turn = turn_transport(transport, op, dir); > if (turn != 0) > return 0; > } else { > @@ -3076,7 +3073,7 @@ > } else > move_player_attack(op, dir); > > - pick = check_pick(op); > + int pick = check_pick(op); > > > /* Add special check for newcs players and fire on - this way, the > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > > > > _______________________________________________ > Crossfire-cvs mailing list > Crossfire-cvs at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crossfire-cvs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nicolas.weeger at laposte.net Fri Jan 4 13:38:16 2019 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 4 Jan 2019 20:38:16 +0100 Subject: [crossfire] Happy new year! Message-ID: <201901042038.21820.nicolas.weeger@laposte.net> Hello everyone :) Happy new year to all members of the list! :) May that year see even more improvements to Crossfire ;p Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kevinz5000 at gmail.com Fri Jan 4 16:12:26 2019 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Fri, 4 Jan 2019 16:12:26 -0600 Subject: [crossfire] [Crossfire-cvs] SF.net SVN: crossfire:[20646] server/trunk/server/player.c In-Reply-To: <201901042042.57371.nicolas.weeger@laposte.net> References: <201901042042.57371.nicolas.weeger@laposte.net> Message-ID: <024b95db-91e6-b2d2-0421-3e511aa1c5a3@gmail.com> Sorry, my fault. On this note, the C99 "//" comments, inline, atoll(), and probably other stuff need to be changed to be strictly ANSI C. On this note, can we have a temperature check on requiring C99? C99 is more convenient to use in places, especially where it improves readability and typechecking inline functions vs macros. It's also not that much work to get this back in strict ANSI C. If I remember correctly, it was the MSVC C compiler that needed C89 last time this issue came up. Has the situation on Windows changed? On 1/4/19 1:42 PM, Nicolas Weeger wrote: > Hello. > > > That change will break strict ANSI C conformance, as you can't declare > variables except at the start of a block. Here "turn" is declared only when > assigned. > > > I'm fine with that change, of course, but then we should clearly state that > ANSI C is no longer relevant :) > > > > Best regards > > > Nicolas > > > Le samedi 29 d?cembre 2018 05:42:49, Crossfire CVS repository messages. via > Crossfire-cvs a ?crit : >> Revision: 20646 >> http://sourceforge.net/p/crossfire/code/20646 >> Author: partmedia >> Date: 2018-12-29 04:42:48 +0000 (Sat, 29 Dec 2018) >> Log Message: >> ----------- >> Clean up >> >> Modified Paths: >> -------------- >> server/trunk/server/player.c >> >> Modified: server/trunk/server/player.c >> =================================================================== >> --- server/trunk/server/player.c 2018-12-29 04:42:41 UTC (rev 20645) >> +++ server/trunk/server/player.c 2018-12-29 04:42:48 UTC (rev 20646) >> @@ -3007,7 +3007,8 @@ >> } >> >> /** >> - * Player gave us a direction, check whether to move or fire. >> + * Move player in the given direction. Can be called by a client through a >> + * movement command, or by the server for some other reasons. >> * >> * @param op >> * player. >> @@ -3017,8 +3018,7 @@ >> * 0. >> */ >> int move_player(object *op, int dir) { >> - int pick; >> - object *transport = op->contr->transport; >> + object *transport = op->contr->transport; //< Transport player is in >> >> if (!transport && (op->map == NULL || op->map->in_memory != >> MAP_IN_MEMORY)) return 0; >> @@ -3029,7 +3029,6 @@ >> return 0; >> } >> >> - /* peterm: added following line */ >> if (QUERY_FLAG(op, FLAG_CONFUSED) && dir) >> dir = get_randomized_dir(dir); >> >> @@ -3036,8 +3035,6 @@ >> op->facing = dir; >> >> if (transport) { >> - int turn; >> - >> /* transport->contr is set up for the person in charge of the >> boat. * if that isn't this person, he can't steer it, etc >> */ >> @@ -3044,7 +3041,7 @@ >> if (transport->contr != op->contr) >> return 0; >> >> - /* Transport can't move. But update dir so it at least >> + /* Transport is out of movement. But update dir so it at least >> * will point in the same direction if player is running. >> */ >> if (transport->speed_left < 0.0) { >> @@ -3057,7 +3054,7 @@ >> if (op->speed_left < 0.0) >> op->speed_left = -0.01; >> >> - turn = turn_transport(transport, op, dir); >> + int turn = turn_transport(transport, op, dir); >> if (turn != 0) >> return 0; >> } else { >> @@ -3076,7 +3073,7 @@ >> } else >> move_player_attack(op, dir); >> >> - pick = check_pick(op); >> + int pick = check_pick(op); >> >> >> /* Add special check for newcs players and fire on - this way, the >> >> This was sent by the SourceForge.net collaborative development platform, >> the world's largest Open Source development site. >> >> >> >> _______________________________________________ >> Crossfire-cvs mailing list >> Crossfire-cvs at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/crossfire-cvs >> >> _______________________________________________ >> crossfire mailing list >> crossfire at metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire -- Kevin Zheng kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090 From kevinz5000 at gmail.com Sun Jan 6 16:00:41 2019 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sun, 6 Jan 2019 16:00:41 -0600 Subject: [crossfire] Plan for GTK Client 1.73.0 release Message-ID: <049c5b1a-b039-2813-5941-1b0bf0a450a6@gmail.com> Hi folks, I'm planning on tagging and releasing version 1.73.0 of the GTK Client in a couple of days. There aren't many changes, but enough to give package maintainers a new version: **Added** - Pass player and server name to client scripts **Changed** - Add text for blessed items in inventory views - Client window stays hidden until after player selection - Install sound files when SOUND is enabled - Show open containers in unlocked inventory view **Fixed** - Enable sound with older (< 0.25.3) versions of Vala - Fix delayed weight limit update when strength attribute changes If you use the GTK Client, please give current trunk (which will become the 1.73.0 tag) a whirl to catch issues before the release. Regards, Kevin -- Kevin Zheng kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090 From kevinz5000 at gmail.com Mon Jan 14 20:37:55 2019 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Mon, 14 Jan 2019 20:37:55 -0600 Subject: [crossfire] GTKv2 Client 1.73.0 release Message-ID: <634b062f-2a7d-a384-222a-6a8e09fbde5f@gmail.com> Hi folks, Crossfire Client GTKv2 1.73.0 is now available for download from SourceForge. Most notably, there is no separate distfile for sounds; sounds are installed by default if SOUND is enabled. A Windows build is not available at this time. **Added** - Pass player and server name to client scripts **Changed** - Add text for blessed items in inventory views - Client window stays hidden until after player selection - Install sound files when SOUND is enabled - Show open containers in unlocked inventory view **Fixed** - Enable sound with older (< 0.25.3) versions of Vala - Fix delayed weight limit update when strength attribute changes Regards, Kevin -- Kevin Zheng kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090 From norkthedork at gmail.com Wed Jan 30 14:10:59 2019 From: norkthedork at gmail.com (DraugTheWhopper) Date: Wed, 30 Jan 2019 15:10:59 -0500 Subject: [crossfire] Improving IRC availability with a chat bridge Message-ID: Hi all, In the IRC there's been talk of making it easier to join and contribute in the chat by setting up a bridge between the IRC channel and another chat service. Both Slack and Discord have been mentioned as possibilities. In the last 24 hours, I just set up a basic functional bridge, so we know its possible, and that it works relatively well. However, Nicholas pointed out (rightly so) that we should proceed with caution, and ensure we get everything down pat before we consider it finalized. The Freenode policies (freenode.net/policies) state that to "publish logs", we must follow several guidelines: "If you operate a service that scrapes internal channel content or publishes logs, always make sure to obtain permission from the channel owner or freenode staff before you start publishing logs or other data, and ensure that there is an easy way for projects to opt-out later and to request removal of previously published logs or data. You must respect the opt-out requests in a timely manner." There appears to be no other specifics about operating bots or bridges to other services. So, with that being said, I understand that mwedel is the "official" CF project manager, and Leaf is the IRC "owner". Could I get one or both of you to weigh in with thoughts on whether this is something that we want to do, and if so, what limitations should be imposed? In particular, some things that should be addressed: * Which bridge services should be acceptable * Chat history retention time * Either querying or notifying the "active people" on IRC to ensure they consent * Moderation and regulating access to the Discord (will there be a need to appoint moderators, for anti-spam or other reasons?) Of course, input from all others is welcomed as well! And now, my personal thoughts: I think that one of CF's greatest problems is that of attracting and retaining new players. After all, the bigger the community is, the more likely it is to survive, and have active development. Currently, there are several issues that make it more difficult for new players to pickup the game, enjoy it, and join in the community, but one of those issues is that communication is handled almost exclusively through ingame chat, IRC, and the mailinglist. Unfortunately, the mailinglist web server is down, and IRC is not a popular chat system these days, so new community members find it difficult to engage using either of those methods. Many people who play videogames are already familiar with other chat services, in particular Discord, so I believe it would greatly increase the ability for others to join if we had a bridge set up to such a service. There are other things that I think it would help too, such as those who do not have an IRC client running perpetually in a shell account, or or those who would like to communicate using their smartphones while away from their computer. For example, if my machine crashes, or I reboot and forget to relaunch my IRC client, I may miss some hours of discussions in chat, but with a service like Discord, I can access it from any device, and simply scrollback to see what I missed. There are certainly valid objections to be made, and so I would like to hear what everyone has to say. One of the biggest items is that of privacy, and rightly so. From my perspective, Discord as a company is minimally different from that of Freenode, I have to trust them to keep my chat history private, and to "not be evil". Some people may take offense at Discord's desktop app being a bloated Electron-style system, but remember, they also have mobile apps and a web interface as well. And besides, for those who prefer IRC, this is merely a bridge, not a replacement. Another common objection is that of stored history; IRC traditionally has the feeling of being rather ephemeral. I personally enjoy having all the scrollback on tap (and searchable), possibly more so because I never really assume privacy on the internet anyway. However, if the amount of material contained in the scrollback becomes a problem, then there are certainly some solutions available, depending on what chat platform we would be integrating with. Thoughts/comments/questions/concerns? --DraugTheWhopper From leaf at real-time.com Wed Jan 30 15:39:57 2019 From: leaf at real-time.com (Rick Tanner) Date: Wed, 30 Jan 2019 21:39:57 +0000 Subject: [crossfire] Improving IRC availability with a chat bridge In-Reply-To: References: Message-ID: <5e5dc0dd-17f0-0b5e-4b98-57bcd7507abd@real-time.com> Not forming an opinion yet, giving guidance, etc. - just sharing feedback and comments. This link was shared on the IRC channel by a user in regards to Discord. https://www.tomsguide.com/us/help-me-toms-guide-discord-permissions,review-5104.html From mwedel at sonic.net Thu Jan 31 23:47:42 2019 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 31 Jan 2019 21:47:42 -0800 Subject: [crossfire] Improving IRC availability with a chat bridge In-Reply-To: References: Message-ID: I should probably transfer ownership of crossfire to someone else - I haven't had much time to work on it lately, and seems unlikely that I'll find time anytime soon. But that wasn't really the question here. It is hard to argue about making the game (or chat channels) more accessible to more people. There are a few thoughts here: - Move chat to another system that is more widely used/available, with the understanding that it still needs to be accessible to linux users. So if there is a web interface, probably acceptable. If the only thing is a windows program, probably not. - Set up a gateway. As noted, this could have issues related to freenode policy. One thought there is to change the topic to clear state that there is a gateway being used. I'm not actually sure how messages would get attributed when moved between the 2 chats - I'd imagine there may be a forwarding agent string involved. And handling of private messages would need to be carefully done (if one replies to the forwarding agent privately, you probably don't want to that appear to all the users on the other chat system)