| 06:00.28 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 06:00.28 | *** topic/#bzflag is BZFlag Support and Development || Latest version: 2.4.18 || https://www.bzflag.org || https://www.bzflag.org/help/ || https://www.openhub.net/p/bzflag || https://logs.bzexcess.com/freenode/%23bzflag/ || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 06:00.28 | *** mode/#bzflag [+v infobot] by ChanServ |
| 07:36.28 | macsforme | Delusional: I take it you no longer need that? |
| 12:22.22 | Delusional | macsforme I was not able to compile v1.99 as of yet. |
| 12:37.46 | Delusional | this is 1.99 source https://sourceforge.net/p/bzflag/code/HEAD/tree/branches/experimental/v2_99continuing/bzflag/tools/modeltool/modeltool.cpp |
| 12:41.31 | Delusional | this is the older version I posted. Modeltool v1.8.4.2 https://sourceforge.net/p/bzflag/code/19540/tree/branches/v2_99_net_branch/tools/modeltool/modeltool.cxx |
| 12:44.34 | Delusional | the modeltool in todayâs distributed BZFlag,app looks like itâs from BZFlag 2.0, not 2.4 |
| 13:17.50 | blast007 | 2.99* |
| 13:18.25 | blast007 | the 2.99 modeltool could be backported to 2.4 for the next release |
| 18:30.54 | blast007 | oh noes! I've been killed! |
| 18:56.38 | *** join/#bzflag blast007[m] (blast007ma@gateway/shell/matrix.org/x-ehrvdelicyxqsscc) |
| 18:56.44 | *** join/#bzflag GeneralPurpose[m (generalpur@gateway/shell/matrix.org/x-makasrilvdfptxtw) |
| 19:30.14 | Flash | does modeltool need to be part of bzflag, or should it be separated? |
| 20:03.54 | blast007 | Flash: currently it makes use of the TextUtils class from BZFlag |
| 20:08.11 | BulletCatcher | modeltool uses its own SimpleTextUtils and doesn't seem to have any actual dependencies outside its directory. |
| 20:08.12 | BulletCatcher | It could be split out if we had a place to put it. |
| 20:09.29 | blast007 | BulletCatcher: the one in 2.99 doesn't |
| 20:11.16 | blast007 | we also currently install modeltool with the macOS .app |
| 20:11.20 | blast007 | include* |
| 20:13.59 | blast007 | I guess the SimpleTextUtils was a recent-ish change |
| 20:37.53 | Flash | a project as old as BZFlag has a lot of "utils" that should be retired in favor of standards-based solutions, at some point |
| 20:55.15 | blast007 | certainly :) |
| 20:55.40 | blast007 | some of the stuff in TextUtils is pretty specific to our use though, such as the tokenize method |
| 20:55.59 | blast007 | it's not something a regex would replace |
| 21:11.03 | JeffM[m] | Replace bzw with an XML scene format that references obj files and you don't need model tool anymore |
| 22:08.05 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:23.43 | blast007 | glTF may be a viable replacement for BZW |
| 22:27.51 | Zehra | For a moment I thought giFT was going to be used... :p |
| 22:49.01 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:59.10 | blast007 | blender can import/export glFT, Assimp (a C++ library) can import |
| 22:59.40 | blast007 | might need a custom extension for some of our map properties like teleporter links, so that may complicate things a bit |
| 22:59.57 | blast007 | I'm not sure if you can add functionality to a Blender plugin with another plugin |
| 23:03.27 | Zehra | I wonder if it is possible to remove teleporter links and instead add some form of a teleporter attribute or something? |
| 23:04.08 | Zehra | There's the zone object and there is also custom zones, so not sure how that is handled. |
| 23:04.51 | Zehra | I'm guessing something similar could be done, since technically it is. "If tank moves through here, tank's position is moved to here". |
| 23:06.13 | Zehra | Teleporter becomes a "classic style" object, but it might not line up with the current vision of increasing consistency in game. |
| 23:07.30 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 23:07.30 | *** mode/#bzflag [+v spldart] by ChanServ |
| 23:09.22 | Zehra | Or wait, would zone objects be supported at all even? I'm thinking along the lines of teleporter links can be supported the same way zones could be. |
| 23:12.50 | blast007 | we'd have to investigate |
| 23:12.58 | blast007 | I don't know much about the format |
| 23:16.55 | Zehra | Same. |
| 23:18.06 | Zehra | I'm only assuming that all objects which have no physical and rendering properties aren't supported by default. (Mainly zones.) |
| 23:18.24 | JeffM[m] | it's node based, you can put anything in a node |
| 23:18.25 | Delusional | last week allejo made a small change to the /saveworld -o logic, so that teleporter names are exported the obj file, allowing my .bzw file and what I see in wings3d to match up. It would be really nice if ALL object names were exported, but I donât think that object names are even sent to the client. So that would be a pretty big change. |
| 23:19.24 | blast007 | yeah, I don't think we really make use of object names |
| 23:20.00 | blast007 | /saveworld is really just a hackish feature, so it's not gonna work perfectly |
| 23:20.04 | Delusional | currently working on a map with 52 named teleporters⦠i really needed that |
| 23:20.08 | blast007 | if you want the world, get the BZW from the server |
| 23:22.26 | Delusional | but still.. it would be nice that after I make my mapâs rough draft by handâ¦. then I export to .obj for a 3d editorâ¦. all the object names are correct, instead of bzbox1, bzbox2, bzbox3 |
| 23:24.28 | Delusional | you can partially get around that by using groups |
| 23:25.15 | blast007 | can Wings3D import BZW, or just export? |
| 23:26.18 | Delusional | it will import obj files, and export bzw |
| 23:26.33 | Delusional | cannot directly import bzw |
| 23:27.19 | Delusional | and the bzw export is part of their project, itâs a menu itemâ¦. done by a guy named optigon a long time ago. |
| 23:28.37 | Delusional | at the time, we were having a problem with bzflag not computing the inside of mesh objects reliably, thus the export has the option to include an âinsideâ tag to all objects |
| 23:29.21 | Delusional | but BZâs logic was improved long ago, âinsideâ is no longer needed |
| 23:30.53 | blast007 | it isn't? |
| 23:31.26 | blast007 | Don't flags still spawn inside mesh objects if you don't have an inside point? |
| 23:31.58 | Delusional | I donât see that on my maps |
| 23:34.11 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 23:35.01 | blast007 | might depend on the object. I've seen it on Rat's Nest before. |
| 23:36.29 | Delusional | but i donât really do it that way⦠what I do is make the map out of BZ objects, then place invisible materials on all of that⦠then make a copy of it, texture it, convert to drawinfo, and lay the drawinfo on top of the original BZ objects |
| 23:37.05 | JeffM[m] | then all your collision objects are convex not concave and you don't need inside points |
| 23:41.05 | Delusional | if youâre going to have tanks driving on your mesh, you have to be extremely careful that every face is planar, not just the top face, and thereâs zero âisolated verticesâ |
| 23:41.30 | Delusional | if a tank just touches a non-planar face, it gets stuck every time |
| 23:41.55 | Delusional | even on the side of an object |
| 23:42.32 | blast007 | (oh, I guess Assimp can both import *and* export glTF) |
| 23:46.06 | allejo | i did a thing |
| 23:46.38 | Delusional | with the âisolated verticesâ I think thatâs tied in with the floating-point-bug, where you canât drive from a mesh onto a BZW object⦠different processors compute the same point to be in a slightly different position., because they handle the math slightly differently. |