| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 00:03 | |
| bz-next | the game needs exclusive hats to fund development | 02:01 |
|---|---|---|
| SpringTank | Hah! | 02:07 |
| Zehra | I need a baseball cap, a hardhat, and a sombrero. :P | 02:10 |
| bz-next | cha ching | 02:10 |
| Zehra | bz-next should have forum rank of Opus Magnum! | 02:16 |
| bz-next | there needs to be loot boxes too, it wouldn't necessarily interfere with the open source nature of the project | 02:23 |
| Zehra | gacha-game mechanics | 02:23 |
| Zehra | people need to have SSR flags and common flags, otherwise it's too predictable and boring. :P | 02:24 |
| bz-next | yeah. basically, you don't need to drive the tank anymore, you just click an image of a tank on your phone and a shiny key appears and opens a box full of tank-themed goodies | 02:24 |
| bz-next | then you can sell those in the online marketplace for tokens. you can buy tokens with real money | 02:25 |
| bz-next | the money gets used to degenerate the game more | 02:25 |
| Zehra | the microtransactions will support development and make it easy to manage the whole project | 02:25 |
| Zehra | Not to mention, nobody will be able to cheat as easily in this new model of the game | 02:25 |
| bz-next | sure you can start your own item server, but all your friends are on the main server and you want to impress them, so | 02:26 |
| Zehra | people will easily be able to associate the game by stunning visuals and game lines and catch phrases too | 02:26 |
| bz-next | yes tanks should make witty audio remarks when you get a kill, like family guy catchphrases | 02:27 |
| bz-next | that is what the people want | 02:27 |
| bz-next | if you need gameplay to keep ppl addicted just add a bz-themed bejeweled minigame in there or something, whatever | 02:27 |
| Zehra | the mini games added will help improve replayability, as additional games can be easily added | 02:28 |
| *** FastLizard4 is now away: AWAY from keyboard | 03:46 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Leaving) | 04:08 | |
| *** FastLizard4 is back | 04:13 | |
| bz-next | I think I will integrate modeltool from the 2.99 branch into the map viewer / editor | 04:30 |
| bz-next | Because I kinda want to make a map and I don't want to have to fiddle with copy and pasting stuff around a bunch | 04:31 |
| Juest | ehhh | 04:31 |
| bz-next | you don't think it's worthwhile? | 04:32 |
| Juest | what zehra said is silly lol | 04:32 |
| Juest | its not the spirit of the game | 04:33 |
| bz-next | it was facetious | 04:33 |
| * Juest shrugs | 04:33 | |
| Juest | why not straight port the modeltool features instead? | 04:34 |
| Juest | i guess thats what you meant by integrate | 04:34 |
| bz-next | I was just thinking, some ugly dialog that lets you select some .objs and then just churns them through modeltool | 04:34 |
| bz-next | then pastes them into the current file | 04:35 |
| Juest | why use the original when you are doing a rewrite anyways | 04:35 |
| bz-next | laziness | 04:36 |
| Juest | go supersede the original | 04:36 |
| Juest | i guess it'll do for now but eventually it'll obsolete it | 04:36 |
| bz-next | that is fair, it might be best to just keep it decoupled as a separate tool | 04:36 |
| bz-next | I am very conflicted on what to do with the editor, since it needs some more investment to not suck as an editor | 04:38 |
| bz-next | because it's just slapped together using internal bzflag code it's not super structured on the inside and that is kinda annoying | 04:39 |
| bz-next | which is why it has the kinda dumb edit->reload workflow it has now | 04:40 |
| Juest | :/ | 04:43 |
| Juest | maybe fix that laziness | 04:43 |
| bz-next | I don't want to dig into the internal representation to figure out how to change an already loaded world, and I don't want to rewrite a new representation from scratch because that's duplication | 04:43 |
| bz-next | since it's all text at the end of the day one solution would be to link world objects to lines of text in the bzw file on world load, so that the corresponding lines could be changed when you edit something | 04:44 |
| bz-next | that would be nice because it'd preserve comments and stuff, but it feels a bit... hacky? | 04:44 |
| Juest | seems error prone in a way | 04:45 |
| Juest | sounds* | 04:45 |
| bz-next | yeah exactly, it sounds like a mess | 04:45 |
| bz-next | but since it's text, it might be the way to go about things... | 04:45 |
| Juest | maybe amend the bad consequences then? | 04:45 |
| bz-next | howso | 04:45 |
| Juest | analyse the cause of the consequences and work on improving that | 04:46 |
| bz-next | What I'd like to avoid is the classic editor thing of a program that digests a map and spits out a new logically equivalent file that's been internally mangled | 04:48 |
| bz-next | since people like to be able to edit maps by hand too | 04:49 |
| bz-next | so, like, if you add a box, it should just append a box to the bzw file. If you edit a material, it should just add the new properties to the existing material in the file | 04:50 |
| bz-next | the classic workflow of map -> internal representation -> manipulation -> output would completely mangle a map file | 04:51 |
| Juest | i understand | 04:56 |
| bz-next | so maybe, when reading a bzw, the reader could make a mapping like object->[first line, num lines] and add spacer objects for whitespace/comments in between | 04:57 |
| bz-next | and object["property"] would just be the offset of the property in the object | 04:57 |
| bz-next | then there's some sorta classic algorithm about dealing with lists of lengths like this that'd speed up updating all the various offsets, I forget what it is but I know it exists, so if that is even needed it'd be possible | 04:58 |
| bz-next | since most maps only have <100k lines and most of those are encapsulated in objects I don't think it'd be a big deal to just update offsets on change | 04:59 |
| bz-next | for rendering, you'd need a separate render call for each object and set ObjectID in the shader for user interaction. I think it's possible to pack objectID into a buffer too but since objects would want to be moveable it's probably simplest to just render them serially | 05:05 |
| bz-next | the trouble is, that would get you a lot, but there would still be so much work in getting something really full featured GUI wise. Is it worth it? Would anyone even use it ever? | 05:07 |
| bz-next | I don't want to waste time making something that nobody will use | 05:08 |
| bz-next | I'd rather do just enough that it meaningfully improves the state of things and then move on to the next problem | 05:10 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 05:17 | |
| bz-next | laziness is really about prioritization in my case. I don't want to end up stuck deep in some corner building castles that nobody will really care about, I'd like for the work to be impactful | 05:20 |
| bz-next | Otherwise a project can kinda spiral in on itself and nothing useful gets done | 05:21 |
| bz-next | Currently I see the roadmap as [basic tank rendering] -> [architecturally supporting multi-phase rendering] -> [shots? lasers? lighting? better shaders? better materials?] | 05:23 |
| bz-next | but if there is actually demand for a map editor I will do it. I just don't know if there is | 05:23 |
| *** FastLizard4 is now away: AWAY from keyboard | 06:17 | |
| *** FastLizard4 is back | 08:01 | |
| *** FastLizard4 is now away: AWAY from keyboard | 08:29 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 11:25 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 11:30 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 11:34 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 11:41 | |
| *** cods <cods!~fred@tuxee.net> has quit IRC (Ping timeout: 246 seconds) | 16:18 | |
| *** macsforme <macsforme!~macsforme@rahab.fairserve.net> has quit IRC (Quit: ZNC - http://znc.in) | 18:56 | |
| *** macsforme <macsforme!~macsforme@rahab.fairserve.net> has joined #bzflag | 18:57 | |
| *** ChanServ sets mode: +v macsforme | 18:57 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 20:34 | |
| blast007 | would it be enough to lock an authentication token down to a specific hostname, or should it be a hostname:port combination? | 23:15 |
| blast007 | the client code currently sends the host:port combination, but that hasn't made it into a release yet | 23:18 |
| blast007 | I'll likely end up making the client use the GETTOKEN action as well, since currently it fetches a full server list when it wants to grab an authentication token | 23:19 |
| blast007 | (one reason it did that was because it could use the token you received from fetching a server list, so it saved a request if you fetched the server list, selected a server, and joined before the token expires) | 23:19 |
| blast007 | (but, with the change to locking tokens down to the target host or host:port, instead of the player IP, the token from the list won't be useful in most cases) | 23:20 |
| *** FastLizard4 is back | 23:22 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!