| 00:41.39 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 01:19.20 | *** join/#bzflag infobot (ibot@rikers.org) |
| 01:19.20 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 01:19.20 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:49.48 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-vbqehjmxadgjqwyc) |
| 02:49.45 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-wrhzqtkzgtoilsst) |
| 02:49.45 | BZnotify | [13bzflag] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vA8HP |
| 02:49.45 | BZnotify | 13bzflag/06master 14ab67f4d 15Scott Wichser: Removed unused function. |
| 02:49.45 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-wrhzqtkzgtoilsst) |
| 04:16.19 | allejo | in bzfs, what classifies a shot being "ended" with regards to the bz_eShotEndedEvent |
| 04:24.04 | JeffM | When it does not kill |
| 04:26.18 | allejo | so that'd include when a shot hits an object in a world with no rico? |
| 04:41.53 | JeffM | Yeah |
| 04:45.03 | allejo | neat. i've got something to hunt down now as to why this is not working |
| 04:47.14 | allejo | also, since you're around jeffm. any idea why did it per player here instead of using the internal world shot counter? https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/bzfs/bzfsAPI.cxx#L1765 |
| 04:47.30 | allejo | I found this commit, https://github.com/BZFlag-Dev/bzflag/commit/d0ee6c80d23e45d1d7c7549c679f70358fc23feb |
| 04:48.11 | allejo | and by the world shot counter I mean on line 1743 |
| 04:48.17 | JeffM | The client sends them too |
| 04:48.24 | JeffM | Iâm not on a computer |
| 04:50.01 | allejo | ah no worries then, i'll do some more digging. i keep getting 0 for all the world weapon shots and they keep taking priority over still existing shots |
| 04:51.38 | JeffM | The id handling of world weapons is kinda BS |
| 04:52.30 | allejo | "kinda" is putting it lightly :p |
| 04:53.01 | JeffM | Yeah, id manage them yourself |
| 04:53.19 | JeffM | I think you have 200 ids to play with |
| 04:53.42 | allejo | was just trying to avoid that to avoid possible conflicts with multiple plugins |
| 04:54.03 | JeffM | Best to |
| 04:54.18 | JeffM | Fix the server to handle them right |
| 04:57.49 | allejo | got any ideas on how to best handle them? my first thought is a map of shotID => ownerID and just add/remove as shots end |
| 04:59.12 | allejo | also, any idea if you know if weapon IDs are mixed in with regular shot IDs |
| 04:59.43 | JeffM | Shot ids are per player |
| 04:59.51 | JeffM | The server is a special player |
| 05:00.24 | JeffM | Everyone has a shot 1, 2, 3 etc... |
| 05:01.24 | JeffM | Have the server track the life time of world shots and look for death messages and end shots from players. |
| 05:03.41 | JeffM | A unique shot is ownerID and a shotID |
| 05:03.57 | allejo | noted |
| 05:04.32 | JeffM | So your map is only for shots from the server player id |
| 05:04.51 | JeffM | But you need to mange the life times too |
| 05:05.07 | JeffM | Thatâll pull some code from the client into the server |
| 05:05.56 | allejo | are lifetimes currently handled server side, client side or both? |
| 05:06.18 | JeffM | Just client |
| 05:06.23 | allejo | pfft |
| 05:06.27 | JeffM | A client is responsible for its own shots |
| 05:07.19 | JeffM | The client may think itâs responsible for server shots too |
| 05:07.42 | allejo | how are world weapons handled right now? |
| 05:07.55 | JeffM | Iâd have to look |
| 05:08.33 | JeffM | Check the server to see if it sends our its own end shots |
| 05:09.53 | allejo | so i can understand how shots are handled. the server relies on clients to tell it when shots have ended, right? i'm assuming deaths send that info. but how do shots ending without hitting something or hitting a non-rico object work? |
| 05:10.50 | JeffM | Thatâs what the end shot message is for |
| 05:11.03 | JeffM | A shot is ended by death or endshot |
| 05:12.13 | JeffM | The server also generally does t care about shots |
| 05:12.22 | JeffM | It doesnât track them |
| 05:12.50 | JeffM | The only one that needs to know a shit ended is all the clients |
| 05:13.39 | JeffM | Shot ended |
| 05:14.34 | allejo | right. so do clients only keep track of their own shots? e.g. "i shot this shot. it has 2 seconds to live. ... ok it's done. everyone remove that shot" |
| 05:16.48 | JeffM | Yeah |
| 05:18.15 | JeffM | Itâs all very client centric |
| 05:19.37 | allejo | mkay, now I gotta figure out where current world weapon shots are being tracked. clients too? |
| 05:20.24 | JeffM | Yeah |
| 05:20.43 | JeffM | They are kind of a hack, and I donât remember how they were implemented |
| 05:20.59 | JeffM | The server does not do full shot tracking |
| 05:24.48 | allejo | this has been really insightful, makes me dislike things now... but at least i have a general idea of what I should be looking for |
| 05:24.52 | allejo | thanks jeff :D |
| 05:30.36 | JeffM | Sure |
| 05:31.39 | JeffM | The non rico case is the hard one for the server to track, it doesnât do shot paths |
| 05:32.50 | allejo | yea |
| 05:33.27 | allejo | my original thought for using the shot end event was in combination for world weapons, but if those are improved that'd remove my need for watching shots ending |
| 06:01.32 | JeffM | Really the shot logic from the client should be added to the server too |
| 12:09.25 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-saginatalmttjllm) |
| 17:03.44 | JeffM | allejo: there is some weaksauce shot ID management for world weapons built into the server, with getNewWorldShotID |
| 17:04.01 | JeffM | and shotUsedInList |
| 17:05.31 | JeffM | if you call bz_fireWorldWep with a shot ID of 0, it should try and find one that has a high likelyhood of being unused |
| 17:07.06 | JeffM | you've also got shot manager. |
| 17:07.07 | JeffM | https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/bzfs/ShotManager.h |
| 17:07.11 | JeffM | totaly forgot I wrote that |
| 17:40.55 | allejo | yea, but when getNewWorldShotID(void) is called, that API fxn doesn't return the shot ID. the new API fxn allows a pointer, but that uses an overloaded getNewWorldShotID() which returns an entirely different shot ID, from my testing. only 0 |
| 18:06.00 | JeffM | yeah, you'd have to call the one that takes a player and send in BZ_SERVER to get the actual shot ID out. |
| 18:08.00 | JeffM | bz_fireWorldWep("SB", 10, BZ_SERVER, _pos, 0, 0, 10, &myShotID, 0, eRogueTeam); |
| 18:08.57 | JeffM | so the one that takes an int* is really the only useful one. |
| 18:10.44 | JeffM | are you trying to hang extra data off the shot? |
| 18:20.29 | allejo | nope, just trying to get the shotID from the int* one |
| 18:20.58 | allejo | so I could keep it in the plugin's memory |
| 18:22.09 | allejo | but the overloaded getNewWorldShotID(player) version always returns 0 for me, from what I was testing it last night. but didn't dig too far into it |
| 18:25.57 | blast007 | I'm adding the player's locale to the MsgEnter. Do we want to keep around the redneck and klingon locales? |
| 18:27.43 | blast007 | I should probably replaced the fixed-sized strings of MsgEnter with std::strings, too... then it'd be less of an issue having to pad the locale length to account for "en-US-redneck". :P |
| 18:36.39 | BulletCatcher | We shouldn't assume that std::string objects are binary-compatible between clients and servers. |
| 18:38.23 | blast007 | I'm not adding a new method of sending std::strings across the network. It'd use the one we already have. |
| 18:38.31 | BulletCatcher | k |
| 18:39.14 | blast007 | https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/net/Pack.cxx#L136 |
| 18:42.27 | blast007 | <+JeffM> blast007: did you know there are 6 different ways that strings are packed in BZFLag? |
| 18:42.37 | blast007 | https://docs.google.com/document/d/151M1NGDo6ubqr6WY6Vo_vARAS7bopSCWb_TOAoK9hLw/edit#heading=h.j5trnqspg36s |
| 18:43.54 | JeffM | yeah, there are a lot of them :) |
| 18:45.07 | JeffM | allejo: you should be calling the getNewWorldShotID that takes a player |
| 18:45.15 | BulletCatcher | Klingon is kg as French is fr so no extra effort is needed there, but en_US_l33t and en_US_redneck would indeed need extra space. |
| 18:45.16 | BulletCatcher | To miminize padding in fixed-length messages we could either drop l33t and redneck entirely, or support them in the client but not the server. |
| 18:45.48 | JeffM | it should only return 0 if the shot list was empty |
| 18:46.10 | blast007 | "or support them in the client but not the server" how? |
| 18:47.55 | JeffM | allejo: debug into shot manager, and make sure that LiveShots is gettgin an entry for the server player. |
| 18:47.58 | blast007 | for now I'm padding it to 16 characters (or 15 plus a NUL), but after it works I'll switch the packet to use nboPackStdString |
| 18:48.16 | JeffM | that may be why it's alwasy reutrning 0, it may not be keeping the shot list around when it should. |
| 18:49.43 | JeffM | or just add this to the start of the function https://usercontent.irccloud-cdn.com/file/sigA51Cl/image.png |
| 18:50.28 | JeffM | but my guess is ShotManager.LiveShotsForPlayer(player); is alaways returnign an empty list for server player. |
| 19:04.18 | allejo | neat, will try that out when I get a chance :D |
| 20:10.41 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-qfteukwubkikmkix) |
| 20:57.55 | JeffM | allejo: I was slightly wrong about shot manager, it doesn't keep shot lists per player, there is one global shot list, it assigns a global ID to every shot. |
| 20:59.14 | blast007 | the other fun thing is that shot messages (both starting and ending) are UDP, which mostly matters for GM, since clients kill off other shots based on their lifetime |
| 20:59.20 | allejo | so there's no mapping as to who owns the shot, it's always the "server"? |
| 20:59.35 | JeffM | no no, the global shot list keeps the owners too |
| 20:59.59 | blast007 | for GM, the end shot message to end the shot (if it doesn't hit anyone or anything) is sent by the shooter |
| 20:59.59 | JeffM | it's a list of shot objects |
| 21:00.11 | JeffM | has the owner ID, the local ShotID and the global shot ID |
| 21:00.30 | JeffM | and a flight logic pointer |
| 21:00.51 | JeffM | shot manager keeps 2 lists |
| 21:00.56 | JeffM | ShotListLiveShots; |
| 21:00.56 | JeffM | ShotListRecentlyDeadShots; |
| 21:01.13 | JeffM | blast007: yeah owners end there own shots |
| 21:01.24 | JeffM | I was trying to see if I could move that server side in my server |
| 21:01.28 | JeffM | and ignore client endshots |
| 21:01.38 | JeffM | and not break proto |
| 21:01.45 | blast007 | :) |
| 21:01.51 | JeffM | I think it can be done |
| 21:02.08 | blast007 | I'm fine with breaking proto if it makes it easier |
| 21:02.20 | JeffM | the proto isn't the hard part |
| 21:02.49 | JeffM | the proto break would just be to save bandwith |
| 21:02.57 | blast007 | k |
| 21:03.05 | JeffM | the server HAS all the info it needs. |
| 21:04.23 | blast007 | is dealing with latency part of the difficulty with some of these kind of changes? |
| 21:04.48 | JeffM | no, getting the server to have the collision logic |
| 21:05.07 | JeffM | it's actualy better to handle some of it on the server, because the latency can be lower |
| 21:05.24 | JeffM | only have to get to the server, not get to the other clients too and then maybe back. |
| 21:05.31 | allejo | for the shot manager, the globa; shot ID is a unique ID across all shots on the server (dead or alive), I'm assuming, right? what's the local shot ID? |
| 21:05.44 | JeffM | allejo: all shots for all players |
| 21:05.51 | blast007 | just as long as we're not repeating the 2.99.x lag comp situation that gave high lag an advantage :) |
| 21:05.54 | JeffM | every shot gets a unique unsigned long |
| 21:06.10 | JeffM | blast007: no, worst case is it's the same as current code. |
| 21:06.21 | JeffM | allejo: the local shot ID is what the client knows the shot as. |
| 21:06.39 | JeffM | the client keeps an array for every player |
| 21:06.49 | JeffM | with local shot IDs of 0 to max shots |
| 21:07.25 | JeffM | so on the client, if you have MS = 2, you can't shoot a shot untill one expiores |
| 21:07.35 | JeffM | there is no place to store a third shot |
| 21:07.58 | JeffM | the server is trying to let shots exist outside that limit |
| 21:08.10 | JeffM | it's the first part of the shot rewrite. |
| 21:08.58 | allejo | so local shot ID would be 0 or 1? whereas the global shot id could be some really obscure number? |
| 21:10.52 | JeffM | 0 to whatever -ms Is set to |
| 21:10.57 | JeffM | but yeah |
| 21:11.04 | JeffM | the global IDs keep going untill they wrap around. |
| 21:11.23 | JeffM | the idea was to make it simpler for plugins to track shots by giving them a single unique number. |
| 21:11.33 | JeffM | instead of a pair that gets reused. |
| 21:12.05 | allejo | right. that single unique number would ideal to use, if only I had access to it :p |
| 21:12.14 | JeffM | I think you do |
| 21:12.41 | JeffM | uint32_t bz_getShotGUID (int fromPlayer, int shotID); |
| 21:12.54 | JeffM | once you get the server shots to give back valid local IDs |
| 21:13.26 | JeffM | you can also hang values off of shots, BZF_API uint32_t bz_getShotMetaData (int fromPlayer, int shotID, const char* name); |
| 21:13.26 | JeffM | BZF_API void bz_setShotMetaData (int fromPlayer, int shotID, const char* name, uint32_t value); |
| 21:13.26 | JeffM | BZF_API bool bz_shotHasMetaData (int fromPlayer, int shotID, const char* name); |
| 21:13.46 | allejo | right, just need to make sure the server gives back that unique number (which currently returns 0, issue discussed earlier) |
| 21:13.57 | JeffM | yeah, |
| 21:14.08 | JeffM | but looking into the code, it should be working |
| 21:14.21 | JeffM | how far appart are you calling your world weapon shots? |
| 21:14.31 | JeffM | is it possible there is only one alive at a time? |
| 21:14.39 | allejo | a few seconds apart |
| 21:14.49 | JeffM | what is the life time of each shot? |
| 21:14.57 | JeffM | less then the delay between shots? |
| 21:15.10 | allejo | the shots hadn't ended yet. basically as soon as i added another shot, the previous one was removed |
| 21:15.21 | JeffM | ok |
| 21:15.27 | allejo | disregarding the lifetime or collisions |
| 21:15.55 | JeffM | the fire command does add the shot to shot manager, so it should be in the list |
| 21:16.07 | JeffM | something may be removing it early for some reason. |
| 21:16.33 | allejo | the fire command where the server picks an ID works just fine. the fire command with the int* point is the one that removes shots early |
| 21:16.53 | allejo | but the former doesn't give access to that shot ID, hence the reason the int* was added |
| 21:17.12 | JeffM | I mean the CORE fire command, not in the API |
| 21:17.13 | JeffM | fireWorldWepReal |
| 21:17.22 | allejo | ohhh |
| 21:17.32 | JeffM | everybody goes into that |
| 21:17.36 | JeffM | this isn't a GM right? |
| 21:18.02 | allejo | nope, not GM |
| 21:18.20 | JeffM | fireWorldWepReal calls ShotManager.AddShot(firingInfo,player); |
| 21:18.26 | JeffM | that adds the shot to the live shots |
| 21:18.38 | JeffM | what are you passing in for a lifetime? |
| 21:19.57 | allejo | iirc, _reloadTime |
| 21:20.06 | JeffM | ok, so not 0 |
| 21:20.13 | allejo | correct |
| 21:20.58 | JeffM | yeah they should stay in live shots till ended. |
| 21:21.40 | JeffM | so I'd debug it and see what the conents of LiveShots is on the second call to fire. |
| 21:23.45 | JeffM | give me your call to the API fire and I can see if I can replicate it |
| 21:25.57 | JeffM | wow, is USE_TR1 even needed? |
| 21:27.46 | allejo | my current call is using the API fxn without the int*. I don't have my attempt to use int* on my atm |
| 21:27.55 | JeffM | ahh ok |
| 21:28.44 | JeffM | the one with out the int will hide the actual shot ID. |
| 21:29.37 | allejo | yup |
| 21:29.43 | JeffM | what the FUDGE, did I try to do events in C++? |
| 21:30.05 | JeffM | probalby should add an API callback for world weapon fires too |
| 21:30.10 | JeffM | so that there can be notifications. |
| 21:30.20 | allejo | bz_eWorldWeaponFired event? |
| 21:30.38 | allejo | i.e. create one |
| 21:30.45 | JeffM | checks to see when that is actualy called |
| 21:31.15 | JeffM | or does that not exist yet? |
| 21:31.21 | allejo | does not exist atm |
| 21:31.27 | JeffM | ahh yeah, make that :) |
| 21:31.30 | allejo | but should be trivial to add |
| 21:31.39 | JeffM | then have it give the local and global shot iDs |
| 21:31.48 | JeffM | then who cares what shot funciton is called. |
| 21:32.05 | BulletCatcher | TR1 support was added in 2013 for the Apple LLVM command-line compiler. It should be safe to remove it now. |
| 21:32.14 | allejo | adds it to his to-do list |
| 21:34.15 | JeffM | bool bz_fireWorldWep ( const char* flagType, float lifetime, int fromPlayer, float *pos, float tilt, float direction, int shotID, float dt, bz_eTeamType shotTeam ) |
| 21:34.15 | JeffM | <PROTECTED> |
| 21:34.56 | JeffM | I'm also not so sure about making the caller specify lifetime and speed and stuff |
| 21:35.16 | allejo | yea, bzfs should handle shot IDs. that'd avoid this whole problem we're currently having :p |
| 21:35.18 | JeffM | the server should be able to get all that from bzdb so that the shots are consistent with player shots. |
| 21:36.46 | allejo | I wonder, is there a way in BZ to send a deprecation notice at compile time? |
| 21:37.22 | JeffM | sure |
| 21:37.26 | JeffM | #defs |
| 21:38.45 | JeffM | #define bz_fireWorldWep #error bz_fireWorldWep is deprecated, use bz_fireServerShot instead |
| 21:39.34 | JeffM | then add these 2 functions |
| 21:39.37 | JeffM | BZF_API bool bz_GetLookAtVector(float origin[3], float vector[3]); |
| 21:39.37 | JeffM | BZF_API int bz_fireServerShot(int targetPlayerID, float origin[3], float vector[3], float dt, bz_eTeamType color = eRogueTeam); |
| 21:40.41 | JeffM | actualy, BZF_API int bz_fireServerShot(const char* shotType, float origin[3], float vector[3], bz_eTeamType color = eRogueTeam, int target = -1); |
| 21:40.54 | JeffM | and make it check for GM internaly |
| 21:41.31 | JeffM | and make it return the uint32_t ID |
| 21:42.25 | allejo | so instead of the int return time, it'd be uint32_t, which then would allow plugins to assign a "proxy" owner of the shot if desired |
| 21:42.31 | allejo | s/time/type/ |
| 21:42.53 | allejo | or whatever information wants to be tied to that shot |
| 21:43.11 | JeffM | I'd have this be the API for server shots. |
| 21:43.13 | JeffM | https://usercontent.irccloud-cdn.com/file/A2jKe2w3/image.png |
| 21:43.38 | JeffM | the game screws up if you try to add shots for players, IRC so don't even let them set the player. |
| 21:43.48 | allejo | what would getLookAtVector() do? |
| 21:44.05 | JeffM | oh crap that's missing an arg :) |
| 21:44.11 | allejo | yea the game does screw up when you set it for players. something I was planning on changing so it'd always do server as the owner |
| 21:44.36 | JeffM | BZF_API bool bz_GetLookAtVector(const float origin[3], const float target[3], float vector[3]); |
| 21:44.53 | JeffM | it takes an origin, and a target point and computes the vector for the shot to get there. |
| 21:45.06 | JeffM | use that instead of tilt and direction. |
| 21:45.19 | allejo | I wasamy thinking was allow the API call to set a "proxy owner" but always send it as the server. on death events, assign the owner of the shot to the "proxy owner" |
| 21:45.23 | JeffM | SSPs will need it :) |
| 21:45.43 | JeffM | the shot meta data is for that |
| 21:46.02 | allejo | so make plugins store that info instead of the server? |
| 21:47.29 | allejo | when would bz_getLookAtVector() be used? and what's the use of the bool? |
| 21:47.40 | JeffM | https://usercontent.irccloud-cdn.com/file/rieDBqEp/image.png |
| 21:47.55 | JeffM | the bool returns true if the vector computed was valid |
| 21:48.10 | JeffM | if the target point is the same as the origin, no vector can be computed ;) |
| 21:48.27 | JeffM | and you'd use it when you wanted to aim at something :) |
| 21:48.54 | allejo | would vector need to be a pointer? or is that something you have to calculate? |
| 21:49.06 | JeffM | and no, the server would store that info as part of the arbitary data stored with any shot |
| 21:49.30 | JeffM | the vector is a pointer to where the funciton puts what it' computes. |
| 21:49.33 | allejo | well yea, the server is the authoritative source but it'd be on the plugin to set that data, right? |
| 21:49.36 | JeffM | arrays are pointers. |
| 21:49.43 | JeffM | yes, plugin sets the data |
| 21:49.58 | JeffM | because the server deosn't know it's a player shot, because it's a server shot |
| 21:50.10 | JeffM | it's up to you to do what you want with it |
| 21:50.15 | allejo | makes sense |
| 21:50.28 | JeffM | if you want to make the server keep the player with the shot, then fix the game to just allow arbitary player shots |
| 21:50.38 | JeffM | that was the goal of the shot list and GUId |
| 21:50.47 | JeffM | but that needs a proto break |
| 21:51.09 | allejo | one small fix at a time! |
| 21:51.15 | JeffM | yeah |
| 21:51.47 | allejo | so what would be getLookAtVector()'s body? the client's calculation code for shot paths? |
| 21:51.48 | JeffM | the idea was to have the client allocate a temporary shot ID for all local shots, send them to the server, server allocates a global shot ID, and then sends it back |
| 21:52.05 | JeffM | client also gets the temp shotID, so it replaces the temp ID with the global ID and then it's all good. |
| 21:52.24 | JeffM | it would be fine getting shots with GIDs for itself and no local ID. |
| 21:52.50 | JeffM | <PROTECTED> |
| 21:53.22 | JeffM | http://www.euclideanspace.com/maths/algebra/vectors/lookat/index.htm |
| 21:53.28 | JeffM | it involves maths |
| 21:53.44 | JeffM | it's easiest when you have quaternions. |
| 21:55.53 | JeffM | libBZFlag has a matrix version in BZFlag.LinearMath.Matrix4F |
| 21:56.32 | JeffM | https://www.irccloud.com/pastebin/v9p2yUla/ |
| 21:58.09 | JeffM | you could also make a utility funciton that took 2 angles and computes a vector |
| 21:58.18 | JeffM | for legacy compatibility |
| 22:01.46 | allejo | hmm I'd have to take a look at the GM logic to see if I can get a better idea of its purpose |
| 22:02.03 | allejo | kind of hard to imagine atm |
| 22:09.31 | JeffM | do you know what a vector is? |
| 22:09.34 | JeffM | a unit vector I mean |
| 22:10.18 | JeffM | oh wait, I'm overthinking it, it doesn't even need the rotation part |
| 22:10.22 | JeffM | it's way simpler :) |
| 22:10.44 | JeffM | Normalize((target - origin) |
| 22:36.11 | allejo | can't say I'm familiar with it |
| 22:41.40 | JeffM | you didn't have to take linear algebra? |
| 22:41.57 | JeffM | well a vector is a thing that points in a direction |
| 22:42.05 | JeffM | it's made of 3 floats |
| 22:48.33 | allejo | a long time ago and not enough practice to recall :( |
| 22:49.05 | JeffM | so it's a way to basicly point in 3d space |
| 22:49.11 | JeffM | it's what all the shots need |
| 22:49.23 | JeffM | "when I move, what direciton do I move in". |
| 22:50.10 | JeffM | a vector of 1,0,0 means that it's moving in the X+ direction |
| 22:50.33 | JeffM | 0,0,-1 means down in Z- |
| 22:59.05 | JeffM | so if you want a shot to go from point A to point B, you need to aim it along some vector |
| 23:07.48 | allejo | ohhh that sounds so handy |
| 23:08.09 | JeffM | yeah, the functions right now only take 2 angles. |
| 23:08.20 | JeffM | but internaly those angles get turned into a directon vector |
| 23:08.36 | JeffM | may as well make the shoot function take the vector, then you can do a lot more |
| 23:09.35 | allejo | ah, so instead of having things being separate arguments like tilt, direction, etc. it'd just be in one of these vectors? |
| 23:16.20 | JeffM | yeah |
| 23:16.42 | JeffM | it's easy to turn 2 angles into a vector, it's not very eash to find out the 2 angles to aim at a point :) |
| 23:20.07 | allejo | so bz_getLookAtVector() would calculate that vector and stuff it into 'vector'? |
| 23:26.32 | JeffM | yeah |
| 23:28.34 | allejo | the core fire weapon takes all that info as separate arguments, so would that be changed or would the API functions convert that? |
| 23:30.27 | JeffM | I'd simplify it as much as possible |
| 23:30.47 | JeffM | it's also called by the map based world weapons, so you may need to keep some args there, or change the code that calls it |
| 23:31.15 | JeffM | in my server I was going to make the map world weapons call the normal API using a module |
| 23:31.19 | JeffM | so the "core" was just the api |
| 23:35.14 | allejo | what do you mean "simplify it as much as possible?" |
| 23:35.28 | JeffM | take out lifetime and stuff |
| 23:35.38 | JeffM | how much of that is exposed to the map? |
| 23:36.02 | allejo | i'd have to check |
| 23:38.33 | allejo | judging by the wiki for the weapon object, seems like only tilt (and rotation which would likely be direction) |
| 23:38.54 | allejo | i'd look into it further when the changes are actually made |
| 23:44.55 | JeffM | then yeah, I'd make the core function figure out the lifetime and stuff |
| 23:48.44 | *** join/#bzflag eeinsteein (uid282735@gateway/web/irccloud.com/x-kfldpwkdqsigzxjg) |
