
























3

good morning btw



































(edited)
















GetServerInfo function once, as it should not change within a call of the CGameClient::OnNewSnapshot function.








(edited)















):
1. rm -Force build
2. mkdir build
3. cd build
4. cmake ..
5. cmake --build . -j
6. cd debug
7. mv .\steam_api.dll .\DDNet.exe ..
I think there is a lot of "unnecessary" stuff happening. someone told me a better way to build, although I forgot. Can someone maybe point out a better way to build? (edited)/build ?
1


):
1. rm -Force build
2. mkdir build
3. cd build
4. cmake ..
5. cmake --build . -j
6. cd debug
7. mv .\steam_api.dll .\DDNet.exe ..
I think there is a lot of "unnecessary" stuff happening. someone told me a better way to build, although I forgot. Can someone maybe point out a better way to build? (edited)
cmake --build . -j works exactly. Does it overwrite changes making the rm unnecessary?

cmake --build . -j works exactly. Does it overwrite changes making the rm unnecessary? cmake --build should only recompile necessary changes. rm shouldn't be necessary
--clean-first if you want a.. well.. clean rebuild


cmake --clean-first --build . -j
or
cmake --clean-first, cmake --build . -j (edited)
1

cmake .. and cmake --build . -j
-j shouldn't be necessary either btw

ninja for building?

ninja does the correct thingmake: switch to ninja. it's faster)

cmake .. -GNinja)
-j. maybe it's necessary there




















spectate_free_view and spectate_recent to the Spectate-Mode
spectate_free_view: changes to Free View
spectate_recent: Spectates the most recently spectated player (edited)

spectate_free_view and spectate_recent to the Spectate-Mode
spectate_free_view: changes to Free View
spectate_recent: Spectates the most recently spectated player (edited)spectate -1 for Free View
I didnt know until i looked in the code tho. maybe adding it to the command description would help some (edited)

spectate_recent. When I spectate someone else, I often want to check out parts of the map in free view, then switch back to spectating that particular player
















#[derive(Debug, Clone, PartialEq)]
pub struct ExprStruct {
name: String,
fields: BTreeMap<String, Expr>,
}
impl IntoIterator for ExprStruct {
type Item = (String, Expr);
type IntoIter = <BTreeMap<String, Expr> as IntoIterator>::IntoIter;
fn into_iter(self) -> Self::IntoIter {
self.fields.into_iter()
}
}
is this a cursed way to implement .into_iter() or is it ok?





as all things should be









#[derive(Debug, Clone, PartialEq)]
pub struct ExprStruct {
name: String,
fields: BTreeMap<String, Expr>,
}
impl IntoIterator for ExprStruct {
type Item = (String, Expr);
type IntoIter = <BTreeMap<String, Expr> as IntoIterator>::IntoIter;
fn into_iter(self) -> Self::IntoIter {
self.fields.into_iter()
}
}
is this a cursed way to implement .into_iter() or is it ok? 

<BTreeMap<String, Expr> as IntoIterator>::IntoIter part, maybe it's bad ¯\_(ツ)_/¯




<BTreeMap<String, Expr> as IntoIterator>::IntoIter part, maybe it's bad ¯\_(ツ)_/¯ btree_map::IntoIter<String, Expr>






btree_map::IntoIter<String, Expr> 

#[derive(Debug, Clone, PartialEq)]
pub struct ExprStruct {
name: String,
fields: BTreeMap<String, Expr>,
}
impl IntoIterator for ExprStruct {
type Item = (String, Expr);
type IntoIter = <BTreeMap<String, Expr> as IntoIterator>::IntoIter;
fn into_iter(self) -> Self::IntoIter {
self.fields.into_iter()
}
}
is this a cursed way to implement .into_iter() or is it ok? 

















#access for vec, i need a very special case... access by index is ofc almost instant


