From nicolas.weeger at laposte.net Mon Jan 3 13:04:31 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 03 Jan 2022 20:04:31 +0100 Subject: [crossfire] Happy New Year :) Message-ID: <2188512.XrZ49zVGuY@gros> Happy New Year everyone! May 2022 be The Year Of Crossfire On The Desktop :p Regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From mwedel at sonic.net Mon Jan 3 18:43:23 2022 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 3 Jan 2022 16:43:23 -0800 Subject: [crossfire] Happy New Year :) In-Reply-To: <2188512.XrZ49zVGuY@gros> References: <2188512.XrZ49zVGuY@gros> Message-ID: <7890c3de-932c-9371-042a-5ad42ee05dec@sonic.net> On 1/3/22 11:04 AM, Nicolas Weeger wrote: > Happy New Year everyone! > > May 2022 be The Year Of Crossfire On The Desktop :p That is a little old - shouldn't the focus be on mobile now? :) From nicolas.weeger at laposte.net Tue Jan 4 10:00:30 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue, 04 Jan 2022 17:00:30 +0100 Subject: [crossfire] Happy New Year :) In-Reply-To: <7890c3de-932c-9371-042a-5ad42ee05dec@sonic.net> References: <2188512.XrZ49zVGuY@gros> <7890c3de-932c-9371-042a-5ad42ee05dec@sonic.net> Message-ID: <2536039.eay4zRloIu@gros> > > May 2022 be The Year Of Crossfire On The Desktop :p > > That is a little old - shouldn't the focus be on mobile now? :) Actually we're in advance - we already wrapped around cloud, mobile, web 4.0 3D in more-than-real-time, mainframes, and back to desktop :D Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From shjohnson.pi at gmail.com Wed Jan 12 21:42:50 2022 From: shjohnson.pi at gmail.com (Steven Johnson) Date: Wed, 12 Jan 2022 22:42:50 -0500 Subject: [crossfire] File format In-Reply-To: <8825098.Opflf3RzsQ@gros> References: <2508620.GUJW4iZUuS@gros> <19776545.kCYg5WX4i7@gros> <8825098.Opflf3RzsQ@gros> Message-ID: I was curious how each format would look when using actual crossfire data. So, I made this webpage to show it! https://shjohnson314.com/cf/format-compare/ I show the following side-by-side: Current, YAML, XML, JSON, TOML using an example of formulae descriptions. I also included pros and cons for each (as objective as possible). If most people don't mind the whitespace dependency, then I most prefer YAML, otherwise XML. When creating the examples, I noticed the following problems with JSON: - Does not allow comments (as I said above, though Nicolas suggested including them as part of our data) In the example I show "data-comments" for the whole file and individual items. I also include regular comments that don't belong to a particular object (except in JSON). - Does not allow multiline strings This is what makes me dislike JSON for this use case. We can't include comments or "data-comments" that are more than one line (easily/nicely). Anything else that is more than one line (messages, books) would look bad too in JSON. Because of these problems with JSON, my next favorite would be XML. I included TOML only because it came up in comparisons between different file formats. It's simple but I couldn't get formula ingredients nicely formatted. TOML does not allow arrays with different types. If I got some pros or cons wrong please let me know. Steven H Johnson On Tue, Dec 21, 2021 at 12:08 PM Nicolas Weeger wrote: > Hello. > > > > Since XML is a subset (superset?) of SGML, I think finding and > > incorporating an XML parser is much easier than a SGML one. > > Probably, yes. > > > I think the biggest tug of war would be between JSON and XML. I would > > likely lean toward JSON, since it's more compact. > > Both are good enough in my eyes, so I guess it'll depend on who actually > writes the first code :) > > > > I think it's important that editing tools are more or less ironclad > > before making a big change. As hard as it is to learn to make and > > submit new/changed content, I'd hate to see it get more intimidating > > through adoption of new formats. > > Well, some people find modifying text files intimidating, I guess... Yes > tools > should be as ironclad as possible, but bugs happen... Besides, a good text > editor nowadays will handle JSON or XML without too much hassle, so > changing > manually would still be possible. > > > > Overall, I'll be sad to see a departure from the current flat files, > > though I acknowledge that the need for something more "standard" is > > legitimate. > > Well, you can always write a parser generator :) > > Given the flat text format definition (in what language?), a generator > that'll > write a parser (and writer) for it. > > Then we can keep the flat files :D > > > Best regards > > > Nicolas_______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > IRC: http://crossfire.real-time.com/irc/index.html > Discord: http://crossfire.real-time.com/discord/index.html > Project Site: https://sourceforge.net/projects/crossfire/ > Wiki: http://wiki.cross-fire.org/ > Website: http://crossfire.real-time.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinz5000 at gmail.com Thu Jan 13 12:18:56 2022 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Thu, 13 Jan 2022 10:18:56 -0800 Subject: [crossfire] File format In-Reply-To: References: <2508620.GUJW4iZUuS@gros> <19776545.kCYg5WX4i7@gros> <8825098.Opflf3RzsQ@gros> Message-ID: On 1/12/22 7:42 PM, Steven Johnson wrote: > I was curious how each format would look when using actual crossfire data. > So, I made this webpage to show it! > https://shjohnson314.com/cf/format-compare/ > > > I show the following side-by-side: Current, YAML, XML, JSON, TOML > using an example of formulae descriptions. Thank you, Steve, for putting this together. I think your arguments preferring YAML or XML over JSON are compelling. I'm not very familiar with the parser libraries that are available for YAML or XML parsing. I would find it useful if someone could comment on choices for C or C++ and Java YAML and XML parsers. (Java, because Gridarta is written in Java.) Is there an analog to XSD validation for YAML? Regards, Kevin From nicolas.weeger at laposte.net Thu Jan 13 13:45:13 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 13 Jan 2022 20:45:13 +0100 Subject: [crossfire] File format In-Reply-To: References: <2508620.GUJW4iZUuS@gros> Message-ID: <3425066.dWBPBnOGdb@gros> > Thank you, Steve, for putting this together. Big thanks indeed :D > I'm not very familiar with the parser libraries that are available for > YAML or XML parsing. I would find it useful if someone could comment on > choices for C or C++ and Java YAML and XML parsers. > > (Java, because Gridarta is written in Java.) I'd say there are good libraries for both, either parsing or writing. > Is there an analog to XSD validation for YAML? From what I gather, json-schema can be (ab)used for that, mostly, but I'll let people who know more confirm or invalidate :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From nkipps at gmail.com Thu Jan 13 18:59:27 2022 From: nkipps at gmail.com (Nathaniel Kipps) Date: Thu, 13 Jan 2022 19:59:27 -0500 Subject: [crossfire] MOTD requirements for servers on metaserver Message-ID: Hi all, I think I remember hearing once that the only rule for being on the metaserver is that your server must be more or less compatible with the CF protocol. However, I think it would be a good idea to codify any such requirement, as well as consider additional ones. In particular, I think it's reasonable to require that public servers include valid contact info, so players have a path to report abuse, appeal disciplinary action, or request support. Of course, a nice prelude would be for major servers to include this info voluntarily. Thoughts? --DraugTheWhopper From nicolas.weeger at laposte.net Sat Jan 15 02:46:21 2022 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 15 Jan 2022 09:46:21 +0100 Subject: [crossfire] Improving random maps Message-ID: <1865410.v5A2zb09tH@gros> Hello. For those not checking the tracker: https://sourceforge.net/p/crossfire/feature-requests/282/ Comments, ideas, flames welcome :) Best regards Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From pc-crossfire06 at crowcastle.net Sat Jan 15 09:44:33 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Sat, 15 Jan 2022 10:44:33 -0500 Subject: [crossfire] Improving random maps In-Reply-To: <1865410.v5A2zb09tH@gros> References: <1865410.v5A2zb09tH@gros> Message-ID: <1ab3d694-6bed-09f0-cd6a-993ee9b3c8da@crowcastle.net> On 2022-01-15 03:46, Nicolas Weeger wrote: > For those not checking the tracker: > > https://sourceforge.net/p/crossfire/feature-requests/282/ > > > Comments, ideas, flames welcome :) > That's an awesome idea. It might also be nice to have a new exit type of tile, so the maps tile instead of having traditional exits.  Whether you track the history of the map generation to avoid circling back over the old maps is an open question.  (There's nothing wrong with doing that, as it suggests that the floors are sloping up or down, but it's a little weird on the client.) Anything that adds new content is good for the game. From pc-crossfire06 at crowcastle.net Thu Jan 27 16:46:04 2022 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Thu, 27 Jan 2022 17:46:04 -0500 Subject: [crossfire] Modifying Multi-Square Objects Message-ID: <5a25cc99-095c-3d23-7b9f-085ac457635f@crowcastle.net> I'm having trouble working with a multi-square arch.  I'm trying to modify it so that one square that is normally blocked on the roof of a building is passable.  In the arch, it's split up into four separate objects, for example: Object guild ... end More Object guild_2 ... move_block all x 1 end More ... It's this second square that I want to modify, and I can't find a good way of doing it in the map like I can with single-square arches. To just remove the move_block from the second square, I tried using a different building's arch and changing the face to the one I wanted, but the face substitution doesn't seem to work.  Ideally I would like to be able to control other aspects like shifting the hp/sp fields by one to change where you enter (or even something really weird in some cases). If I could access the four parts of the image separately, then I could just use four one-square building arches with the face adjusted to look like one big building and get exactly what I want, but there doesn't seem to be a way to grab just one square of an image. Unless there's a trick I'm missing, the only thing I can think of is to create a custom arch just for this one building, and I would really prefer to keep these changes in one place if possible. Is there a trick here I'm missing?