New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unified naming convention for lump names & LumpClass members #73
Comments
Common naming conventions should also mean branch_script methods will be more universal & reusable |
The wiki page also lays out a style guide for lump class members |
Making sure each LumpClass extends the LumpClass it builds on is probably a good idea Might need to look at the arguments for simplifying LumpClass definitions in #74 too # borderline illegible
class LumpClass(parent.LumpClass):
"""Extremely hard to parse; comparing as_cpp would be much easier"""
origin: vector.vec3 # position of this LumpClass
_format = _format.replace("h", "i").replace("H", "I")
_format = "3f" + _format
__slots__.insert(0, "origin")
_arrays.update({"origin": [*"xyz"]})
_classes.update({"origin": vector.vec3}) This is pretty core to why we need to unify in the first place, keeping member names consistent
If going for 2, we will have to do 3 anyway to figure out what the tool needs to do, and find edge cases void readEntities(char *src, std::vector *dest) {
while (src) { // until end of raw lump bytes
dest.push(parseEntity()); // "{\n\"key\" \"value\"\n}" -> std::vector
}
} Tbh, I think going for 1 would be a great bonus, but 3 is going to have to happen TL;DR, Inheritance is a useful tool, but it has to be used correctly. |
Unification is more of a Quality of Life thing anyway, it makes using Going forward, build documentation around Copy the lump changes & relationship docs from each branch script! # in developer.branch
__parent__: str = "developer.parent_branch" # module.__branch__ + module.__name__ (at bsp_tool.branches level)
# __changes__: Dict[str, Dict[str, str] | Set[str]]
__changes__ = {"renamed": {"FROM": "TO"}, "new": {"NEW_LUMP"}, "deprecated": {"OLD_LUMP"}}
__relations__: Dict[str, Set[str]] = {"LUMP_NAME": {"INDEXED_LUMP"}}
# TODO: function to generate nice looking ascii relationship diagrams for each branch_script
# -- or a mermaid script to generate an ERD svg diagram
# TODO: generate from / extend with LumpClass member names & annotation comments (e.g. Face.plane -> Plane) 0.5.0 idea
bsp.LUMP[i].other_lump.another_lump.data This would probably require some
bsp.get("model[0].meshes[0].material_sort.texture_data.name")
# behind the scenes:
model = bsp.MODELS[0]
meshes = bsp.MESHES[model.first_mesh:model.first_mesh + model.num_meshes]
material_sort = bsp.MATERIAL_SORT[meshes[0].material_sort]
texture_data = bsp.TEXTURE_DATA[material_sort.texture_data]
return bsp.TEXTURE_DATA_STRING_DATA[texture_data.name] Actually, if we use a different naming convention, we have another option:
bsp.model[0].meshes[0].material_sort.texture_data.name # do the same as get method above This approach should probably wrap a
|
VIS How do they work? |
Like this?: A stencil buffer & winding tests could be used to draw visible spaces closest first by using depth & occlusion tests on portals before rendering the contents of each leaf |
Just noticed Tbh there might be a better way of doing BasicLumpClasses, as they have become exclusively integer types SpecialLumpClasses are a mix of singular & plural (makes sense, some are lists, others are a single & complex object) |
Trying to apply this principle to Though this does mean we can't use the |
Might be worth refactoring Should also help with catching extraneous related files (see #104), as we can't use Being able to grab a |
We should move branch methods from |
How should branch splits be named?
I wish devs would just used lump versions |
TODO: |
ce8b18d brings |
This will involve some light refactoring
A bunch of lump names differ across different branch scripts
Many of these lumps share functionality, and even structs in some cases
Unifying these different lumps to singular names with clearly conveyed use & context would really help documentation
This could also hugely help research & tracing the iteration of various small engine concept (e.g.
.bsp
geometry rendering)I've already started doing a little of this and am already seeing some
Quake 3 -> MoH:AA -> CoD -> Titanfall
connectionsRefer to the new "Etymology" page on the wiki for more info on the rationale behind this
TL;DR: make more code the same so we write less code and don't get confused as frequently
The text was updated successfully, but these errors were encountered: