| 00:20:30 | | JeffMB Quit (Quit: Page closed) |
| 00:51:06 | Nothing_Much | oh darn |
| 01:02:57 | | fordcars Quit (Quit: Page closed) |
| 03:02:26 | | Watusimoto has joined |
| 04:53:30 | | Destroyerimo has joined |
| 04:55:52 | | Destroyerimo_clo Quit (Ping timeout: 264 seconds) |
| 05:01:32 | | Watusimoto Quit (Ping timeout: 245 seconds) |
| 05:42:21 | | Darrel Quit (Read error: Connection reset by peer) |
| 05:42:37 | | Darrel has joined |
| 07:09:40 | | Destroyerimo Quit (Ping timeout: 264 seconds) |
| 07:45:56 | | Darrel Quit (Ping timeout: 264 seconds) |
| 07:46:20 | | Darrel has joined |
| 10:02:44 | | Darrel Quit (Ping timeout: 245 seconds) |
| 10:03:01 | | Darrel has joined |
| 12:02:04 | | raptor has joined |
| 12:02:05 | | ChanServ sets mode +o |
| 12:12:17 | raptor | good day! |
| 12:47:26 | | Invisible has joined |
| 13:34:12 | | watusimoto has joined |
| 13:34:21 | watusimoto | hello |
| 13:34:34 | | ChanServ sets mode +o |
| 13:34:34 | raptor | hi |
| 13:35:34 | sam686 | http://sam6.25u.com/bitfighter/leveltest/ level vs levelgen on speedzone rotation, which one is less laggy? |
| 13:37:12 | raptor | to be honest, i think rotating speedzones have rarely added value to a level - the only exception was that first level you made called 'rotating speed zone' |
| 13:37:26 | raptor | I almost think that it should be removed from the game |
| 13:39:41 | sam686 | i think the main problem with doing such rotating and moving anything in a levelgen is LAG |
| 13:40:36 | sam686 | well, not only lag, but also not very smooth, take the bobdaduck zone stuff in levelgen for example |
| 13:42:36 | sam686 | the DnD stuff i was talking about too |
| 13:47:04 | sam686 | also... parts of http://sam6.25u.com/bitfighter/leveltest/z_speedzone_rotate.levelgen really works when multiple objects have the same ID, something that editor itself tries to prevent |
| 13:47:55 | sam686 | editor prevents duplicate id then typing a new ID, but creates duplicate ID using copy paste |
| 13:50:10 | watusimoto | why would the scripting be any more laggy than the native object? Or does the rotation happen on the client without input from the server (sorry, I don;t have the code in front of me) |
| 13:50:40 | watusimoto | the script could take a list of ids and rotate each item on the list |
| 13:51:59 | sam686 | well then, why does the editor prevent entering duplicate IDs? |
| 13:52:32 | sam686 | native rotation on Speedzones happens on client side without continuously sending the position, like the levelgen does |
| 13:58:22 | watusimoto | The idea is that ids should be unique |
| 13:58:37 | | Invisible Quit (Ping timeout: 245 seconds) |
| 13:58:39 | watusimoto | that's what makes ids ids :-) |
| 13:59:08 | watusimoto | one advantage is that it is harder to mess up by giving duplicate ids when you don't really expect to |
| 13:59:41 | watusimoto | since there is no good way to figure out what ids are already used, if we allowed dupes, it would be really hard to avoid them if you didn't want them |
| 14:00:28 | sam686 | although, often easy to make the levelgen look for a range of id anyway... |
| 14:01:13 | watusimoto | I like the idea of moving speedzone rotation to scripts, as they seem a real specialty item; however I think we need a way to let the server send code to the client to avoid the lag. However, from a security POV, this makes me nervous. |
| 14:02:31 | watusimoto | but letting the server run code on the clients would also open the doors to lots of things -- custom renderers, for example |
| 14:03:33 | sam686 | for non-levelgen rotation, the rotation is sent though pack/unpack once, then the client uses the global timer from gametype to rotate itself |
| 14:03:44 | sam686 | thats without continously sending the postitions |
| 14:04:53 | sam686 | without levelgen, i was kindof thinking of "rotate points" that rotate a range of IDs of any objects around this point object, or similar.. or chain rotate point with another rotate points and we get crazy rotation |
| 14:06:10 | sam686 | scripts may be powerful, but can have flaws... there was so many flaws to web browser javascript in the history... |
| 14:06:49 | sam686 | it also complicates levelgens too.. |
| 14:13:24 | sam686 | levelgen may be sandboxxed to avoid running most commands that may be dangerous.... |
| 14:13:44 | sam686 | there is still one problem with levelgen: FREEZE with endless loop http://sam6.25u.com/bitfighter/leveltest/freezegame.levelgen |
| 14:17:41 | | Invisible has joined |
| 14:19:27 | raptor | wow lots of discussion! |
| 14:19:33 | raptor | 2 things: |
| 14:20:37 | raptor | 1. client-side prediction is better for speedzone rotation, and to have that in a levelgen requires some complexity that I don't think I want to code (involving matching up server/client levelgen script time indices, etc..) |
| 14:21:16 | raptor | 2. bobdaduck heavily used the ID on multiple objects to make his scripts simpler - maybe we need to add the concept of a 'class' ? |
| 14:22:42 | sam686 | I have did some class-like stuff on LUA, on Slot Machine level http://sam6.25u.com/bitfighter/levels6/slotmachine.levelgen |
| 14:23:18 | raptor | oh, haha, i meant 'class' in the HTML sense of the word |
| 14:23:58 | raptor | so an object would have an ID: LoadoutZone!1.5 (means ID 1, class 5) |
| 14:24:16 | raptor | or LoadoutZone!1$5 |
| 14:27:04 | | Invisible Quit (Ping timeout: 264 seconds) |
| 14:28:29 | sam686 | http://sam6.25u.com/bitfighter/levels/snow_chimney.level |
| 14:28:29 | sam686 | http://sam6.25u.com/bitfighter/levels/snow_chimney.levelgen |
| 14:28:45 | sam686 | one of my levels, this one, have like a range of IDs |
| 14:29:35 | raptor | lunch time! watusimoto, i'd be curious about your thoughts of having a 'class' for objects in addition to an ID (see above) |
| 14:29:47 | sam686 | rather then 200 300 600, it could be 2.0 3.0 6.0 maybe |
| 14:31:32 | sam686 | but it cause a small confusing with 2.1 vs 2.10 when counting up.. |
| 14:33:43 | sam686 | by the way, blinking with changing teams is network light, while moving/rotation is network-hungry/lag |
| 15:05:18 | | Watusimoto_ has joined |
| 15:10:08 | | Watusimoto_ Quit (Ping timeout: 265 seconds) |
| 15:11:03 | watusimoto | if we did a class/id thing, perhaps the classes should have string names (rather than ints)? |
| 15:11:13 | watusimoto | or would that open too many doors for typos? |
| 15:12:15 | raptor | depends on how we'd handle it in the editor |
| 15:12:41 | raptor | also... there's a funny bug with IDs in Lua - |
| 15:12:46 | raptor | fordcars found it |
| 15:12:55 | watusimoto | if we normalized case (or ignored it), and stripped leading/trailing spaces, and collapsed multiple spaces into one, it might work |
| 15:13:05 | watusimoto | or made spaces an invalid character, which might be better |
| 15:13:27 | watusimoto | I'm not opposed to classes per se |
| 15:13:39 | watusimoto | if we really have a use case |
| 15:14:29 | raptor | if you did this: bf:findObjectById(25) it works |
| 15:14:37 | raptor | but if you did this: var id = 25; bf:findObjectById(id) it fails |
| 15:15:10 | watusimoto | how odd |
| 15:15:24 | raptor | it's because Lua's internal type is always a Number (float) |
| 15:15:28 | watusimoto | well, that's a bug, in any event |
| 15:15:40 | raptor | so a float gets passed to our method, which is looking for an int |
| 15:15:58 | watusimoto | interesting |
| 15:16:05 | watusimoto | well, that should be easily fixed |
| 15:16:31 | watusimoto | read a float and round it ot an int |
| 15:16:54 | raptor | i should add that as an issue |
| 15:17:15 | raptor | i'd say classes should not have spaces |
| 15:17:29 | watusimoto | agreed |
| 15:17:31 | raptor | and for that matter - would we allow IDs to be strings, too |
| 15:17:33 | raptor | ? |
| 15:17:46 | watusimoto | no, I don't think so |
| 15:18:00 | watusimoto | but... it's all arbitrary on some level |
| 15:18:13 | raptor | integers would be simplest, I think |
| 15:18:17 | watusimoto | we could allow strings, and translate them internally to integers |
| 15:18:27 | sam686 | is doing "local id = 25; bf:findObjectById(id)" work? if yes the problem is the "var" part |
| 15:18:29 | watusimoto | but I don't think we have a problem with the current system |
| 15:18:44 | raptor | sam686: sorry, yes, use 'local' |
| 15:21:04 | sam686 | IDs isn't shown while playing bitfighter, its only used for levelgen, even though the ID itself can be entered into editor |
| 15:21:45 | watusimoto | yes |
| 15:22:35 | sam686 | strings is slower then integer, not sure how much slow down it can be.. |
| 15:22:53 | raptor | you can tell i've been working with too many programming languages today... |
| 15:24:25 | watusimoto | let's stick with integer ids unless we have a compelling reason not to |
| 15:25:29 | raptor | i agree... should we do classes, too? |
| 15:25:46 | watusimoto | Do we have a use case for classes? |
| 15:26:14 | raptor | manipulation of several objects at once without having to program each id |
| 15:26:17 | raptor | in levelgens |
| 15:26:24 | raptor | people are already using the IDs for that purpose |
| 15:26:31 | raptor | and i honestly don't know why it works |
| 15:26:36 | watusimoto | could objects have multiple classes? |
| 15:26:48 | raptor | oh yuk |
| 15:27:07 | raptor | uhh |
| 15:27:17 | raptor | LoadoutZone!1$5,6,7,19 |
| 15:27:30 | watusimoto | let's worry about the level representation later |
| 15:27:31 | raptor | ^^ like that? where $ means class |
| 15:27:37 | raptor | good question |
| 15:27:53 | raptor | i can't think of a use case for multiple ones at the moment, but i'm sure the levelgeners will |
| 15:27:55 | watusimoto | classes should probably be strings |
| 15:28:17 | watusimoto | ok, I agree... if we go down this road, items should ahve multiple classes |
| 15:28:46 | watusimoto | maybe we should add some "tags" to levelcode lines |
| 15:28:47 | sam686 | i think just a single integer is fine, it worked for my snow chimney for grouping sequence of IDs http://sam6.25u.com/bitfighter/levels/snow_chimney.levelgen |
| 15:29:15 | watusimoto | so we could add: class=firstclass,second_class id=123 |
| 15:29:18 | watusimoto | to the end fo the line |
| 15:29:47 | sam686 | classes and IDs as string, may results into having to do a slow string combining or conversion from int to string |
| 15:29:53 | watusimoto | rather than trying to add them to the object as we do ids |
| 15:30:21 | watusimoto | internally we can convert strings to ids if we want |
| 15:30:22 | raptor | all this end-of-line stuff... |
| 15:30:32 | watusimoto | ma |
| 15:30:42 | watusimoto | maybe we really need to finally revamp levelcode |
| 15:30:49 | watusimoto | into xmlish |
| 15:30:51 | sam686 | although, bf:findObjectById alone may be slow as having to find that ID by cycling through a lot of objects.. |
| 15:31:29 | watusimoto | we can always add a map to make the lookup faster |
| 15:34:23 | raptor | yaml |
| 15:34:44 | raptor | xml-ish |
| 15:34:55 | raptor | not yaml |
| 15:35:00 | raptor | that requires whitespace |
| 15:35:12 | raptor | json? |
| 15:36:22 | raptor | maybe yaml - then we would *really* be discouraging people to open up their level files for editing.. |
| 15:36:31 | | Watusimoto_ has joined |
| 15:38:50 | watusimoto | xml would probably be best, due to easy of reading |
| 15:38:59 | watusimoto | and flexibility |
| 15:40:06 | | Darrel Quit (Ping timeout: 265 seconds) |
| 15:41:04 | | Watusimoto_ Quit (Ping timeout: 245 seconds) |
| 15:41:13 | | Darrel has joined |
| 15:41:43 | raptor | what about rolling our own hybrid... |
| 15:42:18 | raptor | that way we wouldn't have to have an XML parser... |
| 15:42:46 | raptor | we could embed robot/levelgen code, too |
| 15:43:48 | | Watusimoto_ has joined |
| 15:56:25 | raptor | watusimoto: here's something i whipped up quickly: http://pastie.org/pastes/9828226/text |
| 15:56:40 | raptor | although now that i look at it, it's still using indentation of a sorts like YAML |
| 16:05:09 | | Watusimoto_ Quit (Ping timeout: 264 seconds) |
| 16:11:11 | | Invisible has joined |
| 16:18:36 | | raptor Quit (Remote host closed the connection) |
| 16:27:31 | watusimoto | not having an xml parser is a disadvantage, imo |
| 16:27:49 | watusimoto | if we use xml, we don't need to write a parser |
| 16:28:47 | watusimoto | that is a bit of work we can delegate to an external lib |
| 17:08:28 | | Invisible Quit (Ping timeout: 264 seconds) |
| 17:31:34 | | Invisible has joined |
| 17:44:13 | | Invisible Quit (Ping timeout: 264 seconds) |
| 18:03:38 | | Watusimoto_ has joined |
| 18:28:22 | | raptor has joined |
| 18:28:23 | | ChanServ sets mode +o |
| 18:29:17 | raptor | yes, but another library == another dependency on all platforms + larger deploy |
| 18:29:32 | sam686 | quertzy lab designed by raptor horribly lagged when i was shooting burst at the resource items the whole time... |
| 18:29:53 | raptor | did i design that? |
| 18:30:23 | sam686 | well, a map lagged in priages server |
| 18:34:31 | sam686 | its this map http://sam6.25u.com/upload/download_quartzy_bug.level |
| 18:34:51 | sam686 | the level id points to a id of 194 which i don't seem to find it on preiages |
| 18:35:06 | raptor | oh... pleiades |
| 18:35:50 | raptor | i remember that one - was the lag because of server collision processing (taking too much CPU) or because of network load? |
| 18:36:31 | sam686 | no, its because of using Burst, and the server has to do way too many calculations from people using burst to make thousands of resource items move |
| 18:37:11 | sam686 | also, just loading it takes quite a long time, about 5 seconds compared to other maps |
| 18:43:00 | sam686 | when profiling that map, 83% of time is spent in Zap::DatabaseObject::setExtent |
| 18:43:50 | sam686 | mostly at griddb.cpp line 923 |
| 18:51:48 | | fordcars has joined |
| 19:19:22 | raptor | quad-trees! |
| 19:19:29 | raptor | heading home |
| 19:19:32 | | raptor Quit () |
| 20:05:18 | | Watusimoto_ Quit (Ping timeout: 245 seconds) |
| 20:54:31 | | Invisible has joined |
| 21:51:36 | | watusimoto Quit (Quit: Leaving.) |
| 22:06:17 | | Invisible Quit (Ping timeout: 265 seconds) |
| 22:25:47 | | BFLogBot Commit: 057e80290b | Author: sam8641 | Message: Allow turning off Vsync in bitfighter.ini (SDL2 only) |
| 22:25:48 | | BFLogBot Commit: 0c276cb0bc | Author: sam8641 | Message: TNL thread: Added some checks when thread fail to create |
| 22:25:50 | | BFLogBot Commit: ba93b24c71 | Author: sam8641 | Message: Much faster setExtent and removeFromDatabase with over 1000 objects |
| 22:25:51 | | BFLogBot Commit: 3e774412ba | Author: sam8641 | Message: Merge, some conflicts on gridDB and config fixed |
| 22:41:28 | | BFLogBot Commit: 7b6d8165fb | Author: sam8641 | Message: Fixed syntax error, merge/rebase fail... |
| 22:42:39 | sam686 | i may need to go for tonight, later.. |
| 23:15:38 | | watusimoto has joined |
| 23:15:38 | | ChanServ sets mode +o |
| 23:39:38 | | raptor has joined |
| 23:39:40 | | ChanServ sets mode +o |
| 23:41:08 | raptor | sam686: I'm really worried about that extents change for the 019 stuff... |
| 23:43:00 | raptor | can you explain the changes you made... if i'm reading this right, then it should be *really* fast compared to before |
| 23:45:48 | raptor | also, the merge was a bit messy... i need to fix some stuff |
| 23:46:07 | raptor | I think when merging back into 020, you need to switch to the 020 branch first, then merge in |