| *** OkinaMatara <OkinaMatara!~Yukari@user/yukari> has quit IRC (*.net *.split) | 00:00 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-71-182-149-43.pitbpa.fios.verizon.net> has quit IRC (*.net *.split) | 00:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (*.net *.split) | 00:00 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has quit IRC (*.net *.split) | 00:00 | |
| *** cods <cods!~fred@82-65-232-44.subs.proxad.net> has quit IRC (*.net *.split) | 00:00 | |
| *** cods <cods!~fred@82-65-232-44.subs.proxad.net> has joined #bzflag | 00:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 00:00 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@pool-71-182-149-43.pitbpa.fios.verizon.net> has joined #bzflag | 00:01 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 00:02 | |
| Zehra | Come to think of it, isn't some form of plugin_utils a better solution? | 00:14 |
|---|---|---|
| Zehra | a.k.a. if we see it done in like 5 plug-ins, add to API or plugin_utils? | 00:15 |
| *** bzLem0n <bzLem0n!~kcrook@69.11.106.139> has joined #bzflag | 00:28 | |
| blast007 | no, I don't see how that would help | 01:42 |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 04:35 | |
| *** Agatha <Agatha!~agatha@user/agatha> has quit IRC (*.net *.split) | 05:31 | |
| *** allejo <allejo!~allejo@user/allejo> has quit IRC (*.net *.split) | 05:31 | |
| *** SpringTank <SpringTank!~quassel@69-154-138-57.lightspeed.rcsntx.sbcglobal.net> has quit IRC (*.net *.split) | 05:31 | |
| *** moriah <moriah!~quassel@user/kierra> has quit IRC (*.net *.split) | 05:31 | |
| *** SpringTank <SpringTank!~quassel@69-154-138-57.lightspeed.rcsntx.sbcglobal.net> has joined #bzflag | 05:31 | |
| *** Agatha <Agatha!~agatha@50.38.40.200> has joined #bzflag | 05:32 | |
| *** kierra <kierra!~quassel@104.243.40.186> has joined #bzflag | 05:32 | |
| *** allejo <allejo!~allejo@104.243.40.186> has joined #bzflag | 05:32 | |
| *** ChanServ sets mode: +v allejo | 05:32 | |
| *** bzLem0n <bzLem0n!~kcrook@69.11.106.139> has quit IRC (Quit: Konversation terminated!) | 05:43 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has joined #bzflag | 05:57 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 248 seconds) | 06:37 | |
| tupone | Flash: the answers probably are already there, but 1) no need to rebuild plugins. 2) interaction of plugin with bzfs is more under control (you cannot use use other interfaces then the one provided). 3) will be easier to merge plugin in the world file (if we would like to do) 4) we could plugin also the client injecting python code (I don't know if we want it) 5) we can use tons of python code to do things | 06:40 |
| tupone | like web serving html or images ... | 06:40 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 06:42 | |
| Flash | I don't question the value of adding scripting to plugins, just commenting on the last PR "Rewrite some plugins in python". That seems questionable | 06:47 |
| tupone | Well, I am writing code to add python interface to bzfs and I'm testing with the old plugin code (well rewritten in python). | 06:59 |
| tupone | the plugin code that I know is the one in the source tree, and I'm checking that at least those functions are supported | 07:00 |
| BZNotify | bzflag: atupone edited pull request #306 "Add plugin system in python" (https://github.com/BZFlag-Dev/bzflag/pull/306) | 08:37 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 10:41 | |
| blast007 | I *am* questioning the value of adding it | 11:02 |
| blast007 | who is going to make it work on Windows and macOS? or is this just gonna be some Linux-only feature? | 11:06 |
| blast007 | "no need to rebuild plugins" that a very minor benefit "interaction of plugin with bzfs is more under control (you cannot use use other interfaces then the one provided" in theory, thaat's what this could do as well for the C++ API: https://gcc.gnu.org/wiki/Visibility | 11:10 |
| blast007 | that's a* | 11:10 |
| blast007 | again, one of the big downsides I see would be the much worse debugging capabilities of a Python plugin | 11:19 |
| blast007 | not that it would be any different with other scripting languages | 11:20 |
| tupone | for windows/macos, maybe I'm wrong, but the python API interface is the same, so it should work. Maybe I should lower the python version to accomodate the issue with python released with windows | 12:03 |
| blast007 | are you aware that Python dropped support for Windows 7? | 12:22 |
| blast007 | or is that what you're referring to? | 12:22 |
| blast007 | I believe Python 3.8 is the last version to support Windows 7 | 12:23 |
| blast007 | that goes end of support in October 2024 | 12:23 |
| tupone | yes, | 12:36 |
| tupone | about the clean interface between plugin and bzfs, I think that in linux, unless you carefully select what is visible or not during the link phase, the plugin can call whatever they want. So you cannot tell what you can change or not in the bzfs code, without affecting plugin | 12:40 |
| tupone | well, for the debugging capability, I normally have a stack trace for python when things are not good | 12:41 |
| tupone | Imagine there's a world written in python with programmed, or random, building and capability | 13:13 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 13:52 | |
| BZNotify | bzflag: atupone synchronized pull request #306 "Add plugin system in python" (https://github.com/BZFlag-Dev/bzflag/pull/306) | 18:23 |
| tupone | is that DSO visibility applicable also to the main program, or only to the shared library? Seems interesting. | 18:33 |
| blast007 | I believe the idea is that you tell GCC/Clang to not export anything by default, and then you export specific things | 21:27 |
| blast007 | that's how Windows does it | 21:28 |
| blast007 | I had tried to implement it with GCC but it didn't see to have any effect... I could still call internal bzfs functions | 21:28 |
| blast007 | seem to* | 21:34 |
| macsforme | https://imgur.com/a/iMnecif | 23:13 |
| macsforme | any initial suggestions on this? the idea was to transform the 3D view to the side, so you could have a larger radar without it getting in the way (especially on screens with wider aspect ratios)... but it kind of looks off to me | 23:15 |
| macsforme | that's 16:10 right now... I feel like the center of the view (and HUD) should be in the middle of the half side (so 75% over), but then that leaves very little 3D view on that side... and probably move the notifications... or, maybe the whole idea is not great | 23:25 |
| blast007 | are we wanting to put that much focus on the 2D view? | 23:52 |
| blast007 | I always just tend to run at the default radar size.. | 23:53 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!