| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 00:35 | |
| Zehra | Agatha: BZFS parses bzw files, BZFlag doesn't. (Ironically BZFS can read bzw, BZFlag itself can't, but it can output .obj, which modeltool can read and output .bzw, IIRC) | 01:04 |
|---|---|---|
| Zehra | But check in "playing.cxx" for "static void loadCachedWorld()" for some insights. | 01:06 |
| Zehra | Also, blast did mod BZFS at one point to read a cached world. | 01:09 |
| Zehra | Is there an easy way to solely compile BZFS? (Linux system.) | 01:36 |
| Zehra | Since I am looking to modify/update some things for testing/patches, but I don't wish to compile BZFlag/BZAdmin programs, nor compile the plug-ins. | 01:38 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 272 seconds) | 02:09 | |
| blast007 | the client can output both .bzw and .obj | 02:17 |
| blast007 | /saveworld whatever.bzw or /saveworld -o whatever.obj | 02:18 |
| Juest | Zehra: blast said earlier that bzfs has the logic to read bzw and bzflag has the logic to write bzw | 02:37 |
| Juest | Agatha: did you find what you were looking for yet? | 02:37 |
| Zehra | Juest: My phrasing was bad, it seemed to perhaps imply that bzflag couldn't output bzw. And it seems to imply modeltool can read and rewrite both bzw. | 02:40 |
| Juest | errata: only bzflag has logic to write and bzfs only has logic to read | 02:41 |
| Zehra | ^ | 02:41 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 02:41 | |
| Zehra | And modeltool can write bzw. But modeltool can read .obj. BZFlag can output .obj. | 02:42 |
| Juest | cool | 02:45 |
| Zehra | We still need some backports to modeltool though. | 02:46 |
| Zehra | And I do hope to take advantage of it, if it does come. | 02:46 |
| Juest | why not a standalone utility that takes parts of bzfs so we can salvage cached worlds? | 02:47 |
| Juest | much like what blast modded | 02:47 |
| Juest | but instead put in a standalone utility | 02:47 |
| Juest | very useful | 02:47 |
| Zehra | Anything can be done, it's merely a question of if someone will do it. | 02:47 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 02:48 | |
| Zehra | We got some programmers who can do it. We got the know how of how to do it. But if no one does it, it's merely a theory. | 02:48 |
| Zehra | But if anyone wants, I'll share enough data for nearly everything. (Opus Magnum.) | 02:49 |
| Agatha | (Juest: I was trying to find what order bz does transformations, because nothing I try seems to work consistently. However, the problem also became moot.) | 03:36 |
| Juest | oh... | 03:37 |
| Zehra | Is this related to the textures/materials in bzw? | 03:38 |
| Zehra | Or the creation/handling of meshes? | 03:38 |
| Zehra | Since it may be viable in some cases, to simply generate one set of objects purely for the visuals, while the other for the physics/collision detection. | 03:41 |
| Zehra | This is what I'm looking into for city/world generation, as my recent attempt with bzwgen, resulted in decent buildings, but the texturing was incorrect and had issues. | 03:42 |
| Zehra | Possibly this is me simply attempting at over-engineering something. (Which I'm rather known at.) | 03:45 |
| Agatha | Meshes. Specifically I was trying to load Two Tanks in a custom piece of software, and wasn't getting the right transformations so the geometry was bungled. It might be because I don't know what I'm doing in general, but I figured checking the transforms in bzflag itself would be the right place to start. | 03:56 |
| Zehra | Are you using bzw parsing or using the .obj's from bzflag? | 03:59 |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 04:04 | |
| Agatha | parsing bzw | 04:08 |
| Juest | bzfs has the parsing logic | 04:54 |
| *** FastLizard4 is back | 05:34 | |
| *** FastLizard4 is now away: IN-GAME - Starfield | 05:36 | |
| BZNotify | 2.4 @ bzflag: atupone pushed 1 commit (https://github.com/BZFlag-Dev/bzflag/compare/961caa81f017...6549d6f1ecbd): | 07:35 |
| BZNotify | 2.4 @ bzflag: atupone 6549d6: Avoid crashing during sort (probably never called) (https://github.com/BZFlag-Dev/bzflag/commit/6549d6f1ecbdcf86b737a9292a1f960ca285b18a) | 07:35 |
| *** spldart <spldart!~spldart@2601:2c7:4100:2cb0:3210:b3ff:fef0:93af> has quit IRC (Ping timeout: 258 seconds) | 08:46 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:51 | |
| *** spldart <spldart!~spldart@2601:2c7:4100:2cb0:3210:b3ff:fef0:93af> has joined #bzflag | 09:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 10:02 | |
| *** FastLizard4 is back | 10:05 | |
| *** FastLizard4 is now away: AWAY from keyboard | 10:38 | |
| cods | > /j #rust | 10:39 |
| cods | oops | 10:39 |
| *** FastLizard4 is back | 10:55 | |
| *** FastLizard4 is now away: AWAY from keyboard | 11:21 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 11:39 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:52 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 12:56 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 14:43 | |
| *** SpringTank is now away: No clients connected to this core right now. | 15:52 | |
| *** SpringTank is back | 15:52 | |
| *** FastLizard4 is back | 18:10 | |
| *** FastLizard4 is now away: AWAY from keyboard | 18:20 | |
| *** FastLizard4 is back | 19:14 | |
| *** FastLizard4 is now away: AWAY from keyboard | 19:49 | |
| *** FastLizard4 is back | 21:36 | |
| *** FastLizard4 is now away: AWAY from keyboard | 22:06 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!