| 00:08.18 | *** join/#bzflag rodgort (~rodgort@68.ip-149-56-14.net) |
| 00:19.24 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:19.24 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.14 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19953 |
| 00:19.24 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:50.32 | JeffM | <PROTECTED> |
| 00:56.53 | blast007 | or fix it.. that works too :) |
| 02:23.39 | *** mode/#bzflag [-v Foo_man_choo] by ChanServ |
| 03:38.21 | JeffM | ok, I got boxywarz to download from my linux vps server in 1.6 seconds |
| 03:38.25 | JeffM | that good enough? |
| 03:42.27 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hvnyxdhokthgztag) |
| 03:42.27 | BZnotify | [13bzflag] 15JeffM2501 pushed 2 new commits to 06master: 02https://git.io/vhcuJ |
| 03:42.27 | BZnotify | 13bzflag/06master 1469410f6 15JeffM2501: send more chunks at a time.... |
| 03:42.27 | BZnotify | 13bzflag/06master 1440d3475 15JeffM2501: don't check if the buffer is too big, check if the data we need to SEND is too big... |
| 03:42.27 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hvnyxdhokthgztag) |
| 03:43.01 | JeffM | so that should be at least as fast, and possibly faster than fastmap |
| 03:43.13 | JeffM | since it doesn't have to base64 encode the map blob |
| 04:30.17 | *** join/#bzflag allejo (~allejo@bzflag/developer/allejo) |
| 04:30.17 | *** mode/#bzflag [+v allejo] by ChanServ |
| 04:30.50 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-jqeuxolvgrvutpqz) |
| 04:30.50 | BZnotify | [13bzflag] 15JeffM2501 pushed 1 new commit to 06master: 02https://git.io/vhcgU |
| 04:30.50 | BZnotify | 13bzflag/06master 1419f34be 15JeffM2501: remove HTTP connection system and API. |
| 04:30.50 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-jqeuxolvgrvutpqz) |
| 07:47.39 | *** join/#bzflag kierra (~quassel@unaffiliated/kierra) |
| 07:47.39 | *** join/#bzflag FastLizard4 (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 07:47.39 | *** join/#bzflag Void7 (~Void7@2604:a880:1:20::1315:3001) |
| 07:50.47 | *** join/#bzflag JeffM (sid48618@gateway/web/irccloud.com/x-yhnkbajjargyajyr) |
| 07:50.47 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 09:02.21 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 09:02.21 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 14:06.24 | *** join/#bzflag DTRemenak (~DTRemenak@2605:e000:141f:c028:f475:631d:cd15:748d) |
| 14:06.24 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 14:06.24 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 15:13.25 | JeffM | blast007: so that last commit techincaly broke binary compatiblity for plugins that used the HTTP system. I can maintain it if you want by stubbing the functions, but really the only plugin that did that was fastmap |
| 15:19.34 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-kqaecicwuiuzzojz) |
| 15:19.34 | BZnotify | [13bzflag] 15JeffM2501 pushed 1 new commit to 06master: 02https://git.io/vhC4E |
| 15:19.34 | BZnotify | 13bzflag/06master 14f3c7c5e 15Jeffery Myers: remove fastmap, the new map transport system is just as fast. |
| 15:19.34 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-kqaecicwuiuzzojz) |
| 16:43.29 | JeffM | blast007: so re https://github.com/BZFlag-Dev/bzflag/issues/24 is the specificaction of GM that the lock is part of the shot or a property of the tank? |
| 16:43.41 | JeffM | should a tank be able to relock with out the flag? |
| 16:44.10 | JeffM | this is important as part of my plan to redo shot IDs. |
| 16:44.41 | JeffM | as in if the server fires a GM for a player, does the player have the ability to control that GMs lock with out the flag? or is the locking ability tied to the flag? |
| 16:58.37 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
| 17:10.56 | tupone | JeffM: I think is linked to the flag |
| 17:11.26 | JeffM | that's how I'd like to see it, but there is evidence in that issue, that you can relock shots in flight with out the flag |
| 17:11.37 | JeffM | so I want to know how it's SUPPOSED to be, not how it is |
| 17:11.48 | JeffM | also I want to move GM to the server |
| 17:11.51 | JeffM | so the rules must be solid |
| 17:12.37 | tupone | I guess that if it is not linked to the flag you could aim GM and shot laser too ? |
| 17:12.51 | JeffM | a very valid question |
| 17:13.36 | tupone | what do you think anout glm ? should/can we use it ? |
| 17:13.44 | JeffM | what is glm? |
| 17:14.03 | tupone | header for gl mathematic on CPU |
| 17:14.21 | JeffM | like CL stuff? or for rendering? |
| 17:15.03 | tupone | to prepare vbo for instance, with glRotate and all the stuff |
| 17:15.10 | JeffM | ohh |
| 17:15.35 | JeffM | I'd wait for whoever is going to do the openGL changes for that |
| 17:15.35 | tupone | https://glm.g-truc.net/0.9.9/index.html |
| 17:15.38 | JeffM | see what they want to do |
| 17:16.03 | JeffM | in the current GL 1.x code there is probalby no real advantage |
| 17:16.35 | tupone | nope, but to prepare the matrix for shader you need it, or some alternative |
| 17:16.46 | JeffM | sure, let the people that do the shaders decide that |
| 17:17.01 | JeffM | no need to force them into glm if for some reason that can't be seen today it won't work |
| 17:17.19 | JeffM | glm seems a fine tool to use WHILE that work is being done, but I would not do it before |
| 17:18.03 | JeffM | that's a solution in search of a problem. |
| 17:18.33 | tupone | In my own repository I want to remove all the list (if I can) and I need that tool :) |
| 17:18.47 | JeffM | for what reason? |
| 17:19.24 | tupone | glList are dprecated on new. I want to do vbo for what I can. maybe some glList remains |
| 17:19.36 | tupone | for the moment |
| 17:19.42 | JeffM | but even the VBOs will be removed for GL3 right? |
| 17:19.47 | tupone | nope |
| 17:20.08 | JeffM | so why not just do the work to convert to GL3 in your branch? |
| 17:21.40 | tupone | I'm doing what I can. Move to vbo, remove glBegin/glEnd, list .... |
| 17:22.05 | JeffM | then just pick that lib and be done with it |
| 17:22.19 | JeffM | guess I won't be replacing tank drawing |
| 17:22.24 | tupone | but It will take time. I will do it to learn too .. |
| 17:24.06 | JeffM | if it's going to be a pull request from your branch, just do what you need to do, and if it's not acceptable people can comment on the PR |
| 17:25.22 | tupone | I don't know alternative to that library, maybe someone else does :) |
| 17:25.39 | JeffM | then they will tell you in the comments of the PR :) |
| 17:27.09 | JeffM | how are you going to convert all the tank drawing into vbos? it's all triangle fans and strips now |
| 17:27.30 | JeffM | my plan was to export all the tank parts as obj files and then read them as data |
| 17:27.43 | JeffM | that way they could be rendrerd by whatever code was best |
| 17:27.51 | tupone | If we could use only FAN or strip is better |
| 17:28.08 | tupone | without switching, maybe calling glDrawElements |
| 17:28.12 | JeffM | I'd like the models to be external and not hard coded |
| 17:28.22 | JeffM | so they can be edited |
| 17:28.56 | tupone | just load in the vbo. I will do a pull request for what I have done up to now. |
| 17:28.56 | JeffM | with the low polygon counts of the current tanks, I don't htink there is a big speed difference between fans/strips, or a mesh |
| 17:29.42 | tupone | What I say is that we could send only a command if is strip or if is fan, |
| 17:29.52 | JeffM | ahh ok |
| 17:30.27 | tupone | Less commands should be better (not always) |
| 17:30.59 | JeffM | there are currently 19 cxx files dedicated just to drawing tanks |
| 17:31.44 | JeffM | I'm also not sure if the current LOD has any benfit |
| 17:32.11 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hzyoirvhojqfzpnf) |
| 17:32.11 | BZnotify | [13bzflag] 15atupone opened pull request #148: Use of Vertex Buffer Objects instead of Client Arrays (062.4...06GL1.5) 02https://git.io/vhCKr |
| 17:32.11 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-hzyoirvhojqfzpnf) |
| 17:32.32 | JeffM | the difference between the high res and low res barrels is like 8 triangles. |
| 17:32.42 | tupone | ahh :) |
| 17:33.27 | JeffM | the high res tank has like 300 triangles |
| 17:33.42 | tupone | The speed of client array and vbo is mostly the same here. So no gain. But client array are going to be deprecated |
| 17:34.16 | JeffM | well only deprecated if the context is initalized in 3.0 mode |
| 17:34.33 | JeffM | sadly GL 1.x will be around for a long time thanks to CAD applications. |
| 17:39.01 | JeffM | how will that PR merge into master? |
| 17:39.26 | tupone | that merge with 2.4 :/ |
| 17:39.30 | JeffM | I know |
| 17:39.39 | tupone | you should rebase it |
| 17:39.39 | JeffM | hence, how will it merge into master ;) |
| 17:39.53 | JeffM | also why didn't you add the files to the vcxproj? |
| 17:40.10 | tupone | because I don't know what to add :( |
| 17:40.15 | JeffM | copy what is there |
| 17:40.29 | JeffM | I'm expected to put new files in the makefiles, and I guess what to add there ;) |
| 17:40.36 | JeffM | it's just a text file |
| 17:40.44 | tupone | also libGLEW |
| 17:41.04 | tupone | I can do a pull request for master too, later, if you want |
| 17:41.07 | JeffM | it would be nice if PRs said what platforms they did not update. |
| 17:41.18 | JeffM | I think any PR for 2.4 should also have a master PR now |
| 17:41.58 | JeffM | so you did not modify tank drawing or lists at all? |
| 18:01.14 | blast007 | JeffM: I don't think there are any 2.4 plugin beyond fastmap that used the HTTP plugin API |
| 18:01.29 | blast007 | so I'm fine with breaking any that did |
| 18:04.21 | JeffM | blast007: yeah I can't think of any ether |
| 18:04.28 | JeffM | and I pulled fastmap from master |
| 18:04.53 | JeffM | now I did have to stub the event, because removing the event would change all the following event IDs |
| 18:05.00 | JeffM | and THAT would break the world |
| 18:06.22 | JeffM | waits for someone to ask what "bz_eDEADEVENT_ONE_DO_NOT_USE" does |
| 18:07.34 | blast007 | "when players die, bz_eDEADEVENT_ONE_DO_NOT_USE doesn't trigger" |
| 18:10.57 | JeffM | it triggers when a cheater should die |
| 18:11.02 | JeffM | but we like cheaters so we don't use the event |
| 18:11.59 | JeffM | so what kind of system represents the "Low end" for 2.6? |
| 18:12.27 | JeffM | worse than an old I3 with a low profile radeon? |
| 18:13.13 | JeffM | I think every system I have has a real video card... |
| 18:13.25 | JeffM | ooo maybe her laptop doesn't |
| 18:23.18 | tupone | JeffM: not yet |
| 18:23.33 | tupone | only mesh/flag |
| 18:25.42 | JeffM | my plan is to move all the tank parts into a model object class, then write a function that renders them, that way as GL changes, that one function can just be changed to do whatever is needed. |
| 18:36.42 | blast007 | JeffM: I would imagine low-end would be what I have in my dev machine :) |
| 18:36.50 | JeffM | what is that? |
| 18:36.50 | blast007 | a third-gen i3 |
| 18:37.00 | JeffM | with onboard GPU? |
| 18:37.01 | blast007 | (using the onboard GPU) |
| 18:37.45 | blast007 | I have no objection to targeting OpenGL 3.2 |
| 19:12.15 | *** join/#bzflag nitroxis (n@nxs.re) |
| 19:16.14 | *** join/#bzflag gartral (~gartral@162.243.117.98) |
| 20:03.08 | *** join/#bzflag Juesto (~AndC@190.194.204.95) |
| 20:03.08 | *** join/#bzflag Juesto (~AndC@unaffiliated/juest) |
| 20:24.15 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-euadgxgzcotvapkf) |
| 20:24.15 | BZnotify | [13bzflag] 15JeffM2501 pushed 1 new commit to 06master: 02https://git.io/vhCd5 |
| 20:24.15 | BZnotify | 13bzflag/06master 14b4dc787 15Jeffery Myers: add obj loading and rendering. |
| 20:24.15 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-euadgxgzcotvapkf) |
| 20:47.22 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 20:47.22 | *** mode/#bzflag [+v spldart] by ChanServ |
| 20:53.56 | JeffM | so what is most desirable for tank customization, letting people pick turrets, bodies, treads, or letting people just pick between different complete tanks? |
| 20:54.45 | JeffM | and of course a single item of "bling" that gets stuck on somewhere. |
| 21:13.34 | Juesto | Everything together |
| 21:14.15 | Juesto | i suggest making bodies that have the same size as the default tank |
| 21:14.47 | Juesto | so, absolutely cosmetic |
| 21:15.15 | Juesto | so there's no collision between tanks right? can that be enabled by chance? |
| 21:15.39 | JeffM | yeah it has to be the same size, that was never a question |
| 21:15.45 | Juesto | okay |
| 21:15.49 | JeffM | and no, there is no collisions |
| 21:16.07 | Juesto | only with world and bullets apparently |
| 21:16.07 | JeffM | and no, the lag issues in bzflag woudl make that horrible |
| 21:16.14 | Juesto | oh :/ |
| 21:16.24 | JeffM | yes, each client does it's own collision tests |
| 21:16.34 | Juesto | kinda bad imo |
| 21:16.40 | JeffM | a client only tests it's own tank against the world and shots that hit it |
| 21:16.50 | JeffM | way more than "kinda" |
| 21:16.53 | JeffM | it's horrible |
| 21:16.56 | JeffM | LAN game ;) |
| 21:17.04 | Juesto | fine, everything is horrible |
| 21:17.06 | JeffM | I was not joking when I said that |
| 21:17.14 | Juesto | optimize it for internet first of all |
| 21:17.20 | JeffM | the server doesn't even know where shots are |
| 21:17.25 | Juesto | that should be the top priority |
| 21:17.38 | Juesto | worse than gta online |
| 21:17.41 | JeffM | it's more than just optimization, it's redoing the entire simulation system |
| 21:17.52 | JeffM | and it will change how gameplay feels |
| 21:18.03 | JeffM | that's why nobody is jumping up to do it. |
| 21:18.05 | Juesto | then go ahead, yes i understand it might need a rewrite |
| 21:18.08 | Juesto | oh... |
| 21:18.28 | Juesto | how close can be the rewrite match the old sim? |
| 21:18.49 | JeffM | it has to send input to the server |
| 21:18.54 | JeffM | its' fundamentally different |
| 21:20.57 | JeffM | it can be done, it's just a very sizeable project |
| 21:31.54 | *** join/#bzflag nitroxis (n@nxs.re) |
| 22:06.34 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-iniwvxzzkajbklvx) |
| 22:06.34 | BZnotify | [13bzflag] 15JeffM2501 pushed 1 new commit to 06master: 02https://git.io/vhWeM |
| 22:06.34 | BZnotify | 13bzflag/06master 149fa0daf 15Jeffery Myers: give OSDir a method to iterator subdirs not just subfiles.... |
| 22:06.34 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-iniwvxzzkajbklvx) |
| 22:29.12 | JeffM | does this look like a reasonable directory layout for models? |
| 22:29.13 | JeffM | https://usercontent.irccloud-cdn.com/file/W958vzEq/image.png |
| 22:29.41 | JeffM | there is a parts folder, it has a dir for each part type, barrel, turret, body, treads, and bling |
| 22:30.08 | JeffM | each parts has a set of numbered sub dirs for the different part types, and a text file with optional human readable names |
| 22:30.24 | JeffM | then each part dir has up to 3 LOD mehses |
| 22:30.37 | JeffM | if there is only one mesh, all LODs will use the same mesh |
| 22:37.06 | JeffM | the parts will map to these sections of the tank https://usercontent.irccloud-cdn.com/file/0hhYeNaB/image.png |
| 22:37.25 | JeffM | some parts, like the treads are made of several sub objects, covers, treads, wheels etc, so they all explode nicely. |
| 22:39.16 | JeffM | and each blink will most likely have additontal data for attatchment point onto the body |
| 22:46.07 | JeffM | bling not blink |
| 22:53.56 | JeffM | I can think of 5 tread styles just off the top of my head https://usercontent.irccloud-cdn.com/file/h22B3XVa/image.png |
| 23:08.07 | Juesto | :p |
| 23:08.40 | Juesto | JeffM: don't the tanks have wheels in between on the default one? |
| 23:08.54 | JeffM | yeah, I didn't draw the innter bits and parts |
| 23:08.59 | JeffM | it's an overview |
| 23:09.12 | JeffM | the threads would have spinny whieels inside |
| 23:09.12 | Juesto | threadless could be a choice |
| 23:09.33 | JeffM | so the tank just slides around using the power of prayer? |
| 23:09.49 | Juesto | both actually no threads but uncovered and fully covered |
| 23:10.08 | Juesto | uh i thought no gameplay changes with those extras? |
| 23:10.29 | JeffM | the current "no animated treads", is simply a holdover from the old model |
| 23:10.33 | Juesto | if we're going to change gameplay then let's rewrite simulation |
| 23:10.39 | JeffM | the old model is intended to have treads, |
| 23:10.47 | JeffM | no, all tanks will drive the same as they do now |
| 23:10.52 | JeffM | what made you think it would? |
| 23:11.21 | blast007 | rewriting simulation is outside the scope of 2.6 |
| 23:11.26 | JeffM | very much so |
| 23:11.31 | Juesto | "tank just slides around using the power of the player" |
| 23:11.33 | JeffM | this is all just visual |
| 23:11.38 | JeffM | prayer :) |
| 23:11.43 | Juesto | Lol |
| 23:11.46 | JeffM | tanks with no trads slide :) |
| 23:11.51 | JeffM | how else would they move? |
| 23:11.58 | JeffM | they slide like tanks with trads |
| 23:12.07 | Juesto | oh right |
| 23:12.35 | JeffM | my plan is to get rid of the no-treads option, or only keep it as a low poly mode that doesn't do tank customization |
| 23:12.38 | blast007 | at most, we're just going to implement enough of the client tank logic on the server so that server-side players can move around, shoot, explode, grab flags, etc |
| 23:12.40 | JeffM | maybe if quality is low |
| 23:12.46 | Juesto | how about something unrealistic like changing the direction of the threads |
| 23:13.02 | JeffM | blast007: it can do movement now, it has enough stuffs |
| 23:13.13 | JeffM | Juesto: what do you mean? |
| 23:13.19 | Juesto | so, gameplay is going to be server controlled which in turn it's more secure? |
| 23:13.27 | JeffM | no |
| 23:13.28 | blast007 | Juesto: not in 2.6 |
| 23:13.41 | JeffM | that is hard |
| 23:13.51 | blast007 | that's a large enough task that it should be the primary focus of a major release |
| 23:13.58 | Juesto | JeffM: like, one of the multiple treads going in reverse and the others forward, etc |
| 23:14.11 | JeffM | no, all on one side go the same way |
| 23:14.17 | Juesto | so, if we ever reach 3.0 blast007 ? |
| 23:14.18 | JeffM | it's the same UV logic that's now |
| 23:14.27 | JeffM | BZFlag 3.0, it sucks less now. |
| 23:14.34 | Juesto | Xd |
| 23:14.35 | blast007 | we likely won't ever have a 3.0 because we already had a 2.99.x |
| 23:14.44 | Juesto | And? |
| 23:14.44 | JeffM | bzflag X |
| 23:14.49 | Juesto | Wtf |
| 23:14.59 | JeffM | BZFlag 3GS |
| 23:15.00 | blast007 | there was already a fork called BZFlag X :) |
| 23:15.12 | JeffM | BZFlag Low Siera |
| 23:15.13 | Juesto | gotta check the roadmap, is that still valid currently? |
| 23:15.21 | JeffM | oh no, 2.99 is dead |
| 23:15.28 | JeffM | and super busted |
| 23:15.37 | Juesto | BZFlag <insert codename here> |
| 23:15.42 | blast007 | Juesto: the 2.6 roadmap got scaled back a bit from what was on the wiki, if that's what you're talking about |
| 23:15.45 | Juesto | No more versioning numbers! |
| 23:15.46 | JeffM | it went too far, it tried to touch the sun and got burned. |
| 23:15.51 | blast007 | we won't have full-on dialog system for 2.6 |
| 23:16.18 | Juesto | blast007: yes, if the wiki is still accurate about the current plans |
| 23:16.18 | JeffM | blast007: does that folder structure seem reasonable? |
| 23:16.25 | JeffM | do you want tank parts in 2.6? |
| 23:17.03 | Juesto | so a part of 2.6 roadmap is pushed back? |
| 23:17.18 | blast007 | Juesto: that was mostly a proposal |
| 23:17.24 | Juesto | hm |
| 23:18.26 | Juesto | replace/reboot 2.99.x |
| 23:18.34 | JeffM | it's not a good design |
| 23:19.01 | JeffM | it has good ideas, but it's implementation is all over the place |
| 23:19.02 | Juesto | wiki is outdated, last is 2.4.10 it seems |
| 23:19.14 | JeffM | the wiki's are going away |
| 23:19.18 | Juesto | again, rewrite 2.99.x, scrap it |
| 23:19.24 | Juesto | how's that |
| 23:19.33 | Juesto | and what's coming in place? github wiki? |
| 23:19.40 | JeffM | Juesto: so you are saying, make 2.6 then... that's what is happening. |
| 23:19.51 | JeffM | the wiki's are mostly not needed |
| 23:19.52 | Juesto | uh i mean later |
| 23:20.04 | blast007 | JeffM: would there be a base tank model? |
| 23:20.07 | JeffM | issues design are github (brought to you by microsoft). |
| 23:20.07 | Juesto | when we get to 2.8 what's going to happen |
| 23:20.23 | JeffM | blast007: I'd ship with a set of standard parts. |
| 23:20.24 | Juesto | afterwards i mean |
| 23:20.27 | blast007 | I could see, for instance, having a top level tank model that you pick, and then for that model there would be various customiziations |
| 23:20.42 | JeffM | the default would be all the standard parts |
| 23:20.47 | JeffM | and you change out parts from that |
| 23:20.57 | JeffM | so yeah, it'll effectivly work like that |
| 23:21.24 | JeffM | part ID 0 is basicly what is drawn now |
| 23:21.37 | blast007 | I guess given that it's fully cosmetic, all of them would have the important parts in the same place, so you'd not have to worry as much about stuff not fitting |
| 23:21.39 | JeffM | and that's the default |
| 23:21.53 | JeffM | yeah, everhthning has to be in roughly the same place |
| 23:22.00 | blast007 | so yeah, I'm fine that |
| 23:22.18 | JeffM | and the idea isn't for user added models at this time |
| 23:22.28 | JeffM | just multiple models shipped with the game |
| 23:22.29 | blast007 | k, that was my next question :) |
| 23:22.44 | JeffM | once you have asset management, it can of course be extended. |
| 23:22.47 | blast007 | that'll be DLC later |
| 23:22.50 | JeffM | yeah |
| 23:22.51 | blast007 | ;) |
| 23:22.52 | Juesto | lol |
| 23:23.26 | JeffM | but I am making it flexable, just to make maintanance easier, want to add a new part, you drop in a folder and it picks it all up |
| 23:23.40 | blast007 | works for me |
| 23:23.40 | JeffM | and it always falls back to partID 0 |
| 23:24.04 | JeffM | so if you decide to add parts to 2.6.2, players wilth 2.6.0 will see people with the default parts. |
| 23:25.09 | JeffM | the only new part in the part enum will be eBling |
| 23:25.24 | JeffM | all the other stuff is existing parts that are just drawn using hardcoded logic |
| 23:25.29 | JeffM | now it'll just load the meshes from a file |
| 23:25.52 | JeffM | the actual tank drawing code is not changing much, just the stuff that builds up the parts lists |
| 23:26.17 | JeffM | there is still the same number of parts, just in some cases they may be empty |
| 23:26.52 | JeffM | a tread partID with no covers will have an empty list for the left and right covers. |
| 23:27.05 | JeffM | I'm assuming there is no desire to make asymmetrical tanks? |
| 23:27.15 | JeffM | wheels on the left, treads on the right? |
| 23:29.17 | JeffM | and no spider tanks |
| 23:37.21 | blast007 | no, keep the same tread style on both sides |
