| 00:13.37 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-fqxrwhtjkeuktpvq) |
| 00:55.34 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 01:13.27 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 02:28.44 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 03:35.44 | Notify | 03BZFlag:Flak 18 * 9114 /Releases: improved display of releases |
| 03:40.26 | Notify | 03BZFlag:Flak 18 * 9115 /Comparison_of_map_objects: added another object |
| 03:44.38 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 04:08.11 | Notify | 03BZFlag:Flak 18 * 9116 /Map_making: /* Map Objects */ added another object |
| 04:15.45 | Notify | 03BZFlag:Flak 18 * 9117 /Map_making: /* Map Editors */ added wiki table |
| 04:16.31 | *** join/#bzflag Void7 (~nullified@205.157.147.198) |
| 04:30.43 | Notify | 03BZFlag:Flak 18 * 9118 /Map_making: /* Map Objects */ added wiki table |
| 04:33.49 | Notify | 03BZFlag:Flak 18 * 9119 /Map_Making: created redirect |
| 04:35.59 | Notify | 03BZFlag:Flak 18 * 9120 /Main_Page: improved wiki links |
| 04:39.51 | Notify | 03BZFlag:Flak 18 * 9121 /Category:Map_Making: content moved to wiki page (no need for a category to be used as one) |
| 14:14.40 | macsforme | it seems that we copy all of our preliminary .lib files to the output directory on windows... is that necessary? they are static libraries and the client starts up without them just fine |
| 14:24.06 | macsforme | and again, anyone know what odbc32.dll and odbccp32.dll do, and if we need them? from what I can tell, it looks like database or maybe registry stuff |
| 14:28.54 | blast007 | I don't know what odbc32.dll and odbccp32.dll are - were are you seeing those? |
| 14:29.35 | blast007 | and are you talking about bzfs.lib and plugin_utils.lib? |
| 14:34.43 | macsforme | odbc32.dll and odbccp32.dll are currently linked when building bzflag, bzfs, and bzadmin |
| 14:35.11 | macsforme | Properties->Linker->Input->Additional Dependencies |
| 14:35.42 | macsforme | the .libs I was referring to were the preliminary static libraries, like common, game, 3D, etc. |
| 14:37.10 | blast007 | so by "output directory" you're not talking about the bin_*_Win32 directory |
| 14:40.28 | macsforme | bzfs has a post-build step of "copy $(OutDir)*.lib ..\..\bin_$(Configuration)_$(Platform)\" |
| 14:41.20 | blast007 | yes, that's bzfs.lib and plugin_utils.lib, which we include with the installer so that users can compile plugins without needing to build bzfs |
| 14:42.22 | macsforme | okay... I guess with the way premake sets up its output directories, all of the static libraries are in one directory so it copies them all |
| 14:42.48 | macsforme | so I can just make it copy those two specifically, and those are the only two needed? |
| 14:43.47 | blast007 | yes |
| 14:44.59 | blast007 | (the NSIS script also pulls some .h files needed, specifically include/bzfsAPI.h and plugins/plugin_utils/*.h ) |
| 15:47.43 | blast007 | macsforme: no errors/warnings when I removed odbc32.lib and odbccp32.lib |
| 15:53.07 | macsforme | so they're safe to remove? I guess there should be a linker error if not |
| 15:53.31 | blast007 | yeah, I'm removing them here and will push it |
| 15:59.10 | macsforme | while you're at it could you apply 93d0dab3 to the Release configuration? I think I only applied it to Debug |
| 15:59.39 | macsforme | I guess the directory exists test wasn't actually necessary, but the quotes around the path are necessary |
| 16:11.52 | *** join/#bzflag Void7 (~nullified@205.157.147.198) |
| 16:37.46 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 16:43.28 | blast007 | sure |
| 16:47.45 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-swtmfulqoowjnvgg) |
| 16:57.41 | JeffM | macsforme: .lib files are never used at runtime, they are link libraries used by the linker |
| 16:57.52 | JeffM | only .exe and .dll files are loaded at runtime |
| 16:58.16 | macsforme | so they shouldn't need to be copied to the output directory |
| 16:58.32 | JeffM | DLLs make a small .lib file that includes all functions and classes that the DLL exports, so that the linker can make it load the DLL correclty at runtime |
| 16:58.36 | JeffM | no, they can stay in a temp dir |
| 16:58.41 | JeffM | they are just needed by the link step |
| 16:58.54 | JeffM | the ONLY lib that shoudl be shipped is BZFS.lib |
| 16:58.59 | JeffM | the API link library |
| 16:59.13 | JeffM | so that people can build plugins with out needing full bzfs sources |
| 16:59.50 | blast007 | JeffM: not plugin_utils.lib? |
| 16:59.52 | JeffM | the projects I made kept all the lib files in debug or release folders |
| 16:59.58 | JeffM | blast007: yeah that too |
| 17:00.10 | JeffM | forgot about that one |
| 17:00.25 | JeffM | any lib referenced by a plugin project |
| 17:00.31 | JeffM | should be only those 2 |
| 17:01.02 | JeffM | the native projects have a post build step to copy just the needed files to the output dir |
| 17:07.42 | *** part/#bzflag Void7 (~nullified@205.157.147.198) |
| 17:11.07 | *** join/#bzflag Void7 (uid197664@gateway/web/irccloud.com/x-cliieduvqizfolqj) |
| 17:16.08 | *** join/#bzflag KaadmY (~kaadmy@zlsadesign.com) |
| 17:17.21 | *** part/#bzflag KaadmY (~kaadmy@zlsadesign.com) |
| 17:32.45 | macsforme | when we are building an installer for release, does the fullbuild solution do everything, including packaging up the installer? |
| 17:35.03 | blast007 | yes |
| 17:35.25 | blast007 | just for the release build, not debug |
| 17:37.39 | blast007 | the "installer" project just has the BZFlag.nsi as a 'project file' (just to be able to edit it from the IDE) and has a post-build event on the release mode that runs the NSIS script |
| 17:38.22 | macsforme | okay, that should be easy enough |
| 17:40.57 | JeffM | yeah building in nsis is pretty easy to trigger |
| 17:48.54 | macsforme | "Plugin: bin_Debug_Win32\plugins\airspawn.dll found but does not contain bz_GetPlugin method"... am I missing an option when compiling it? |
| 17:49.58 | macsforme | I'm pretty sure it linked to bzfs.lib, because it was throwing a bunch of errors until I fixed that |
| 17:58.08 | macsforme | ah, it needs the .def file |
| 18:01.07 | JeffM | did you include the def file that generates the exports? |
| 18:01.14 | JeffM | yeah the def |
| 18:01.24 | macsforme | no, I'm trying to figure out how premake does that |
| 18:01.33 | JeffM | could rejigger the plugins to not require the def |
| 18:01.36 | JeffM | using declspec |
| 18:11.21 | macsforme | ah nice, you just add the .def to the list of project files, and premake creates the setting for it |
| 18:15.25 | JeffM | yeah there is only one thing you can do with def files :) |
| 18:20.23 | JeffM | it's probalby a good idea to get rid of the def files anyway |
| 18:20.28 | JeffM | less windows specific stuff |
| 18:23.03 | JeffM | it shoudl just be a minor modification to bzfs.API.h |
| 18:25.39 | JeffM | I belive all you'd have to do is replace #define BZF_PLUGIN_CALL in the #ifdef _WIN32 section with #define BZF_PLUGIN_CALL extern "C" __declspec( dllexport ) |
| 18:26.16 | JeffM | then you could get rid of the def files |
| 18:26.34 | JeffM | all the exported functions are prefixed by that define |
| 18:28.49 | JeffM | def files are a holdover from old old visual C++ |
| 18:30.04 | JeffM | Microsoft even says "In newer compiler versions, you can export data, functions, classes, or class member functions from a DLL using the __declspec(dllexport) keyword. __declspec(dllexport) adds the export directive to the object file so you do not need to use a .def file." |
| 18:30.24 | JeffM | by newer they mean "newer than VC6 " :) |
| 18:30.34 | macsforme | that sounds a lot easier |
| 18:31.47 | macsforme | then you could just create the directory and add your plugin source files, and everything else could be generated dynamically |
| 18:31.47 | JeffM | just change line 37 in bzfsAPI.h to #define BZF_PLUGIN_CALL extern "C" __declspec( dllexport ) |
| 18:32.02 | JeffM | and remove the defs |
| 19:20.07 | allejo | JeffM, enjoy my new bug reports <3 |
| 19:35.17 | JeffM | allejo: at least someone's using it |
| 19:35.27 | allejo | :D |
| 19:39.14 | macsforme | the rest of us let allejo work out the rough edges for us first |
| 19:41.48 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 19:41.48 | *** mode/#bzflag [+v spldart] by ChanServ |
| 20:44.25 | Notify | 03BZFlag:Flak 18 * 9122 /Versions: /* Released versions of BZFlag */ added Wiki table |
| 20:55.25 | JeffM | most of the reports are reasonable |
| 20:55.48 | JeffM | I need to check on #6, I belive I added all those features because they are actualy sent over the wire by bzfs |
| 20:56.00 | JeffM | maybe the map reader ignores them but they are in the data structure bits |
| 20:56.34 | JeffM | I'll work on them this weekend |
| 20:56.53 | JeffM | gotta go test drive a chevy Trax this afternoon |
| 21:00.27 | Notify | 03BZFlag:Flak 18 * 9123 /Texturing_how_to: /* See also */ improved display of content |
| 21:02.51 | JeffM | Yeah, so base totally has those options in the data strucuture. So even if they are not set by the BZW reader in bzfs, if they are in the binary cache file, they are set. https://www.irccloud.com/pastebin/UKcFX8Ex/ |
| 21:03.21 | JeffM | so does that mean an editor should be limited to what the bzw text format can do or what the actual binary data can do? |
| 21:04.55 | JeffM | void BaseBuilding::print(std::ostream& out, const std::string& indent) also supports it. |
| 21:05.03 | JeffM | so I'm going to say it's supposed to be there |
| 21:20.46 | Notify | 03BZFlag:Flak 18 * 9124 /BZW: /* Map Editors */ improved wiki link |
| 21:21.24 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 21:40.13 | macsforme | sounds like you'll be able to offer "exclusive" map features :) |
| 21:40.53 | macsforme | like drive-through bases! |
| 21:41.59 | blast007 | well, it sounded like the problem was that bzfs doesn't parse it from the BZW :) |
| 21:54.24 | JeffM | yeah, to me that's a bzfs bug not a map format bug |
| 21:54.51 | JeffM | even the map WRITER in bzflag writes it, so that tells me it's part of the data spec |
| 21:55.03 | JeffM | it's probalgby a stupid idea, but it's supported by the data |
| 21:55.37 | JeffM | I based my parser on what bzflag reads |
| 21:55.44 | JeffM | not what other map or map editors did |
| 21:56.29 | JeffM | blast007: techincaly I should be able to write out in the binary cache format direclty from the editor, so it would not need the bzfs parser |
| 21:58.17 | blast007 | bzfs still needs a matching BZW file regardless, so unless you're writing a new server, bzfs needs a change regardless |
| 21:58.27 | JeffM | ahh |
| 21:58.44 | JeffM | well I can remove it form the GUI if you guys don't think bzfs is going to get updated to do it |
| 21:59.32 | JeffM | or if you want to forcibly present it and just say the data is badly formatted for the specification. |
| 22:06.02 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:06.17 | JeffM | I will defer to your expertese if you want bases to have those props |
| 22:12.00 | JeffM | actualy no, BZFS reads them |
| 22:12.13 | JeffM | CustomBase derives from WorldFileObstacle |
| 22:12.30 | JeffM | it's read function reads in those flags |
| 22:12.36 | JeffM | https://www.irccloud.com/pastebin/Qe7pFpVw/ |
| 22:12.58 | JeffM | so to issue #6 allejo I say "suck it" |
| 22:12.59 | JeffM | ;) |
| 22:15.04 | JeffM | the other 2 are totaly things I can fix |
| 22:15.17 | JeffM | a bunch of stuff doesn't rebuild geometry after a change |
| 22:15.27 | JeffM | I have to manaly force it to rebuild |
| 23:22.02 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |