Timestamps are in GMT/BST.
| 01:17:16 | | mollie has joined |
| 01:17:21 | mollie | hi |
| 01:17:37 | mollie | hello |
| 01:39:36 | | mollie Quit (Quit: Page closed) |
| 02:19:57 | | mollie has joined |
| 02:20:04 | mollie | hi |
| 02:20:45 | | kodaws Quit (Ping timeout: 265 seconds) |
| 02:23:52 | | mollie Quit (Client Quit) |
| 03:55:48 | | zoomber_mbp has joined |
| 04:01:30 | zoomber_mbp | hi |
| 04:01:45 | zoomber_mbp | hi raptor |
| 04:01:52 | zoomber_mbp | oh, i just said hi |
| 04:01:53 | zoomber_mbp | ooohkay |
| 04:02:16 | zoomber_mbp | hey raptor, did Koda ever get involved in the bit fighter code? curious |
| 05:02:56 | sam686 | hi |
| 05:15:08 | | zoomber_mbp Quit (Quit: zoomber_mbp) |
| 05:17:44 | | zoomber_mbp has joined |
| 05:42:11 | zoomber_mbp | i guess sam is tired of hellos |
| 05:42:12 | zoomber_mbp | hi |
| 05:42:12 | sam686 | hello (this is an automatic message) |
| 05:43:49 | | zoomber_mbp Quit (Quit: zoomber_mbp) |
| 05:55:04 | | raptor Quit (Remote host closed the connection) |
| 05:55:21 | | raptor has joined |
| 05:55:22 | | ChanServ sets mode +o raptor |
| 05:55:42 | sam686 | hi |
| 05:55:49 | raptor | hi |
| 05:55:50 | sam686 | hello (this is an automatic message) |
| 05:55:57 | sam686 | and bye (its like nidnight already) |
| 05:55:59 | raptor | hi automatic message |
| 05:56:03 | raptor | good night! |
| 05:56:07 | sam686 | and i put an auto message for my client |
| 05:57:59 | raptor | hi Zoomber: koda never did get directly involved other than answering some Mac questions I had (he is the Mac guy for his game, hedgewars) |
| 06:01:30 | | sam686 has left |
| 06:28:25 | | raptor Quit () |
| 07:00:49 | | Watusimoto has joined |
| 07:11:20 | | Watusimoto Quit (Ping timeout: 252 seconds) |
| 07:53:10 | | watusimoto has joined |
| 07:53:10 | | ChanServ sets mode +o watusimoto |
| 10:20:31 | | Watusimoto_ has joined |
| 11:47:11 | | Watusimoto_ Quit (Ping timeout: 276 seconds) |
| 15:05:44 | | watusimoto Quit (Read error: Operation timed out) |
| 15:43:39 | | raptor has joined |
| 15:43:39 | | ChanServ sets mode +o raptor |
| 15:52:06 | | kodaws has joined |
| 15:53:33 | | Watusimoto has joined |
| 15:54:02 | | kodabbws has joined |
| 15:57:48 | | kodaws Quit (Ping timeout: 265 seconds) |
| 16:17:16 | | watusimoto1 has joined |
| 16:20:15 | raptor | sorry i ran off yesterday... I was the unwilling recipient of a migraine (a real one) |
| 16:21:59 | raptor | And I am looking for ways to alleviate them in the future, but no one seems to have any good ideas... |
| 16:46:51 | watusimoto1 | vodaka or bullets. luckily I've never had one; hope you are feeling better. |
| 16:47:02 | watusimoto1 | I'm heading home, so later! |
| 16:51:56 | | watusimoto1 Quit (Ping timeout: 265 seconds) |
| 17:10:05 | raptor | bye |
| 18:02:16 | | kodabbws Quit (Ping timeout: 246 seconds) |
| 18:19:00 | | LordDVG has joined |
| 18:56:24 | | kodaws has joined |
| 19:01:05 | | kodaws Quit (Ping timeout: 260 seconds) |
| 19:06:57 | | LordDVG Quit (Remote host closed the connection) |
| 19:29:02 | | kodaws has joined |
| 20:22:27 | Watusimoto | hi |
| 20:22:31 | raptor | hi |
| 20:27:34 | raptor | i need to try your latest changes.. |
| 20:29:02 | raptor | Fatal error running Lua code: . Possibly out of memory? Shutting down Bitfighter. |
| 20:29:19 | raptor | that was with pressing Ctrl + ; |
| 20:29:30 | raptor | in the editor to bring up the arc plugin |
| 20:29:50 | raptor | oh oops, forgot to copy over new scripts.. |
| 20:30:30 | raptor | ah, that fixed it.. |
| 20:30:42 | | sam686 has joined |
| 20:30:42 | | ChanServ sets mode +v sam686 |
| 20:32:35 | raptor | mazegen works nicely now |
| 20:35:26 | sam686 | when i tried the latest changes last night, my level gen looks broken (especially for non-bitmatch) as if it is unable to read the arguments the level have |
| 20:35:45 | raptor | yes, i think Watusimoto made main() mandatory |
| 20:37:38 | Watusimoto | no, main() is not mandatory, I don't think |
| 20:37:42 | Watusimoto | though |
| 20:37:45 | Watusimoto | and this is a big one |
| 20:38:19 | raptor | i think it's mandatory now because of a 'return true' that was changed to 'false' somewhere... |
| 20:38:30 | Watusimoto | all code outside of main() is executed and cached and shared amongst all bots |
| 20:38:37 | Watusimoto | of that same script |
| 20:38:56 | Watusimoto | so if you do some bot-specific initializations outside of main, you are probably asking for trouble |
| 20:39:17 | raptor | bubble bubble toil and trouble |
| 20:39:29 | Watusimoto | just put everything in main |
| 20:39:41 | Watusimoto | except possibly general variable delcarations |
| 20:39:49 | Watusimoto | but |
| 20:39:59 | Watusimoto | which levelgen is it, I can make sure it;s working |
| 20:40:41 | sam686 | http://sam686.maxhushahn.com/bitfighter/levels/ the 6357.levelgen, and one of 6357 .level |
| 20:40:54 | sam686 | mostly, the non-bitmatch one |
| 20:41:39 | raptor | i use 6357core |
| 20:41:50 | raptor | it draws nice random walls now... |
| 20:41:54 | raptor | but nothing else |
| 20:54:18 | Watusimoto | does it even work the first time? |
| 20:54:21 | Watusimoto | probably not... |
| 20:55:12 | Watusimoto | boy, that levelgen has a lot of "unwrapped" code! |
| 20:55:29 | Watusimoto | which is almost certainly the problem |
| 20:56:19 | raptor | it does not the first time - i believe the problem is that main() is mandatory |
| 20:57:13 | Watusimoto | no, it isn't |
| 20:57:17 | Watusimoto | at least not always |
| 20:57:34 | Watusimoto | but... why should I argue with you? always use main()! |
| 20:57:46 | raptor | i agree |
| 20:57:55 | Watusimoto | it makes the code much easier to follow |
| 20:58:13 | sam686 | just to let you know, i coded that back on, in bitfighter 015 |
| 20:58:17 | Watusimoto | anything that can be compiled and cached, like a data structure, can be done outside main |
| 20:58:44 | Watusimoto | sam686: not picking on you -- my own stuff (little of it there is) is probably even more broken |
| 20:58:50 | Watusimoto | for the same reasons |
| 21:01:23 | Watusimoto | actually, I'm not sure if what I said about running stuff outside main is actually correct |
| 21:01:35 | Watusimoto | ok, main may be mandatory |
| 21:02:06 | raptor | i think you made a minor change to the main() check function that made it mandatory a week or two ago... still trying to find it |
| 21:02:14 | raptor | but i think we should always use main() anyways |
| 21:02:25 | Watusimoto | ok. well we can all assume it is and everything will be fine |
| 21:02:45 | raptor | that was the plan anyways, right? 017 main() not mandatory, 018 mandatory? |
| 21:03:29 | Watusimoto | was it? well, it's the plan now! |
| 21:03:39 | raptor | haha |
| 21:10:34 | sam686 | there is another problem with catched script: making changes to the script and it errors, fix that error in script, and the catched script won't reload the new, modified script, having to restart bitfighter to get it to see the new script |
| 21:10:58 | raptor | yes - Watusimoto suggested maybe disabling caching for editor testing... |
| 21:12:17 | raptor | or maybe we could be smart? like calculate a cksum for the file real quick and comparing it with one we have cached: if different, reload |
| 21:12:44 | sam686 | maybe it can check the modified date and compare (maybe don't check if modified if there is already one or more robots) |
| 21:13:03 | raptor | i guess that'd be even faster... |
| 21:16:15 | raptor | i wonder, do we have modification checking capability already written somewhere? |
| 21:18:57 | sam686 | i don't think there was one on bitfighter for file checking modified file (date, file size, and other checks to see if modified)... |
| 21:20:58 | raptor | i wonder if dirent.h has something... |
| 21:22:46 | sam686 | http://sam686.maxhushahn.com/upload/6357.levelgen a quick modify to put everything in main, I wonder how it works? Somehow it creates global variables inside a function main(), that can be used anywhere, like "sizex", something that can't be done on c++ |
| 21:23:23 | raptor | i'll be back in a bit... |
| 21:23:26 | | raptor Quit () |
| 21:39:24 | Watusimoto | my idea was no caching in the editor, and a /disablecache option in the game for dev purposes |
| 21:40:01 | Watusimoto | by caching you avoid the cost of loading the file |
| 21:41:00 | Watusimoto | if the vars are in main, when the script executes, the "globals" are written to the function's environment table |
| 21:41:17 | Watusimoto | each instance of the script has a private environment table that acts like a global environment |
| 21:41:31 | Watusimoto | it's all a bit confusing, which is why it took years to get it figured out |
| 21:42:33 | | raptor has joined |
| 21:42:34 | | ChanServ sets mode +o raptor |
| 21:43:13 | Watusimoto | so sam686 -- did you mods fix the script? |
| 21:43:41 | sam686 | i jsut changed my 6357.levelgen script to fix |
| 21:43:50 | Watusimoto | did it work? |
| 21:43:52 | sam686 | but other levelgens might be broken? |
| 21:43:57 | Watusimoto | probably |
| 21:43:58 | sam686 | yes, it works for my levelgen |
| 21:44:13 | Watusimoto | mazegen was fixed a few releases back |
| 21:44:52 | Watusimoto | I don't know about any others |
| 21:45:00 | raptor | s_bot works |
| 21:45:11 | raptor | arc script works |
| 21:45:20 | raptor | so no one created editor plugins yet... |
| 21:45:35 | raptor | did we not advertise that? |
| 21:46:02 | Watusimoto | who's going to create plugins? |
| 21:46:16 | Watusimoto | the whole plugin dev community is in this chatroom |
| 21:46:17 | raptor | those myster lua programming bitfighter fiends we talked about... |
| 21:46:26 | Watusimoto | oh right |
| 21:46:58 | Watusimoto | the next step in plugins is let them have access to selected items |
| 21:47:09 | Watusimoto | so you can write a script that manipulates items |
| 21:47:19 | raptor | so item IDs |
| 21:47:23 | Watusimoto | oh yes |
| 21:48:01 | Watusimoto | what about them? |
| 21:48:13 | sam686 | other scripts i have works without main, only because it does not depend on having to have arguments, but in editor, missing walls when a level generates walls without main() |
| 21:48:40 | raptor | that's how you get them to manipulate items? by ID, right? |
| 21:48:55 | raptor | or i may be misunderstanding you... |
| 21:50:04 | sam686 | well... the walls in editor that came from levelgen without main() does appear, only after pressing ctrl + i |
| 21:50:21 | sam686 | ctrl + i is slow for levelgen that creates lots of walls |
| 21:53:18 | Watusimoto | right now, ID serves no purpose whatsoever |
| 21:57:09 | Watusimoto | sam686: do any of your levelgens depend on gridsize at all? |
| 21:57:38 | raptor | thinking of getting rid of it? |
| 21:57:48 | Watusimoto | I'd like to |
| 21:57:53 | sam686 | mostly no, the level itself does the grid size, and the levelgen which adds barriers and such will automatically scale to grid size |
| 21:57:56 | Watusimoto | I think its an unnecessary complication |
| 21:58:09 | raptor | i know _k loved it because it allowed dimensional scaling with scaling the items... |
| 21:58:14 | raptor | *without |
| 21:58:20 | Watusimoto | we can still have the parameter in the levelfile |
| 21:58:30 | Watusimoto | but levelgens shouldn't need to worry about it |
| 21:58:54 | Watusimoto | it's really more of a kind of "spread factor" |
| 22:01:06 | sam686 | i can probably do levelgen:addLevelLine("GridSize 250") to change grid size from level editor (but, it only changes for new items that get added, not existing objects) |
| 22:01:13 | Watusimoto | ok, trying to push a shared_ptr through Lunar |
| 22:01:18 | sam686 | and, i can make use of passing arguments from level to levelgen |
| 22:02:15 | Watusimoto | of course, you can just multiply levelgen coords by whatever factor to mimic the effect directly |
| 22:02:16 | raptor | good luck! |
| 22:02:38 | Watusimoto | lots of errors |
| 22:03:17 | Watusimoto | because I used shared_pointer instead of shared_ptr |
| 22:03:23 | raptor | heh |
| 22:03:39 | raptor | i was working on something recently... ijust have to remember |
| 22:03:47 | Watusimoto | if this works, it will save a lot of work and simplify our design |
| 22:05:29 | raptor | oh yeah - bot body shapes... did we really want those? |
| 22:06:08 | Watusimoto | I think we do |
| 22:06:30 | Watusimoto | I my kids were getting all amped up over this stupid driving game today because they found the custom bodies |
| 22:07:03 | Watusimoto | it's a little different, in that registered (i.e. paying) players could design their own, which is not what we're proposing, but nonetheless... |
| 22:07:25 | Watusimoto | you already did one, right? |
| 22:07:56 | raptor | yeah, a klingon bird of prey |
| 22:08:11 | Watusimoto | so let's try that and see how it works |
| 22:08:36 | Watusimoto | try making all bots use it (for the moment) and see if you like it |
| 22:10:14 | raptor | i remember the problems i was having: some ship rendering is done in Ship, other in gameObjectRender |
| 22:10:28 | raptor | and i was having quite the time trying to pull it all together... |
| 22:10:32 | Watusimoto | what a mess |
| 22:10:45 | Watusimoto | you could start by consolidating all the code |
| 22:10:52 | Watusimoto | I've been doing it bit-by-bit |
| 22:11:00 | Watusimoto | there is no reason for it to be spread out |
| 22:11:11 | raptor | exactly |
| 22:11:12 | Watusimoto | could all be in gameObjRenderer |
| 22:11:17 | raptor | now to find my diff... |
| 22:11:23 | Watusimoto | so that would be good regardless of what bodies we use |
| 22:18:31 | raptor | oh no |
| 22:18:33 | raptor | layerIndex |
| 22:18:36 | raptor | ok |
| 22:18:43 | raptor | tell me what layerIndex is really for? |
| 22:18:58 | raptor | rendering in a specific order in a for loop? |
| 22:20:15 | Watusimoto | some items get rendered above or below others |
| 22:20:37 | Watusimoto | layerIndex controls what gets rendered when |
| 22:20:44 | raptor | in Ship::render() it only allows -1 and 1 |
| 22:20:48 | raptor | for layerIndex |
| 22:20:56 | raptor | are there three layers then? |
| 22:21:04 | Watusimoto | probably |
| 22:24:12 | raptor | doesn't opengl natively support layers? |
| 22:24:23 | raptor | being 3d and all... |
| 22:25:41 | Watusimoto | yes; sam uses them in a clever way |
| 22:26:11 | Watusimoto | don't know if we can use them instaed of multiple passes and levelindex, but it owul dbe cool if it worked |
| 22:26:16 | raptor | ah ha! found the layers |
| 22:26:31 | raptor | ClientGame.cpp:1846 |
| 22:27:15 | | sam686 Quit (Ping timeout: 245 seconds) |
| 22:28:07 | | sam686 has joined |
| 22:28:07 | | ChanServ sets mode +v sam686 |
| 22:34:47 | raptor | I think Ship has got to be one of the most complicated classes... |
| 22:37:57 | raptor | oh as a side note, how is SDL2 working for you guys on windows? |
| 22:38:14 | raptor | any other quirks yet? (except for my blindly coded mouse wheel direction) |
| 22:39:24 | sam686 | cracatoa seems to complain about the fullscreen displays dock in mac, and clicking dock minimizes bitfighter (i guess bitfighter 017a is not SDL 2.0) |
| 22:39:58 | raptor | yeah, it's a temporary solution on mac |
| 22:40:04 | raptor | but at least it doesn't crash anymore... |
| 22:40:19 | sam686 | sdl 2.0 does appear to work just as good (probably better with all that stupid hide mosue pointer bugs) sdl 1.something |
| 22:40:31 | raptor | haha |
| 22:40:33 | raptor | ok good |
| 22:46:10 | | BFLogBot - Commit 76edac7bfe11 | Author: buckyballreaction | Log: Remove some debugging |
| 22:53:57 | raptor | i cannot seem to find where the ship contrails are being rendered... |
| 22:54:13 | sam686 | ship.cpp ship::render ? |
| 22:54:25 | raptor | that's where i'm looking... |
| 22:58:03 | raptor | ah, mTrail |
| 22:58:09 | raptor | interesting... |
| 22:59:12 | raptor | ha!: FXTrail::render() |
| 22:59:21 | raptor | hard-coded to the ship's dimensions... |
| 23:01:02 | raptor | wait, maybe not... hmm.. |
| 23:52:14 | | sam686 Quit (Ping timeout: 245 seconds) |
| 23:53:29 | | sam686 has joined |
| 23:53:30 | | ChanServ sets mode +v sam686 |