Let's discuss code and structure

[Mousikos]

It has been said that there is not enough interest from the community for new devs. I would like to contribute code. Here's why I haven't been able to yet.

What should I do? Let's take a look at the todo list.
https://github.com/assaultcube/AC/blob/m...E_TODO.txt

- monsters & jumppads
- hide monsters until triggered?
- trigger when monsters die?

There are monsters in AC?

recent stuff:
- try and debug depth read? GL_DEPTH_SCALE/GL_DEPTH_BIAS
- detect if sw driver? glXIsDirect(dpy, ctx) (can't get context from SDL) / glGetString(GL_VENDOR/RENDERER) (many HW drivers use mesa as base)
- make server port configurable?
- not reproducable: When you pop out of edit mode where a bridge is right under a ceiling you get stuck.

Let's say I'm new and I hop in and I want to look at stuff. What file? Why is something not reproducable on here?

Well, okay. I might as well go check out the rest of the code. Let's see if there's something I can work on.

Generally speaking, a program has a main.cpp (which we do!) and it is the file without a header file. Generally speaking, everything else should have a header file.

Do I need to look up function declarations so that I know how to use a function I need? Cool, let me go look at the header file so I don't have to scroll through definitions. Why is this object oriented? I don't care HOW you do something. If you CAN do something I need to do, I'm going to use EXISTING code. If you want to improve that function, cool. The handle is the same. That is to say, if I was using one prototype (?) before, I expect to be able to use it later (ie. void function(type var, typ2 var2) should not change).

Next, file name and function names should be descriptive. If it is not entirely obvious what something does, there should be comments. So let's say I decide to help out with some sound issue. How would I approach it? I would go to sound.h and check out what's there. I would look at things that sound like it would help. Then I would go search for the definitions in sound.cpp. But let's take a look a sound.cpp (I can paste the ENTIRETY of it here. If that doesn't scream "THERE's A PROBLEM WITH YOUR STRUCTURE", I don't know what does):

https://github.com/assaultcube/AC/blob/m.../sound.cpp

Maybe that was just a bad example. Fuck it. I'm going to check out main.cpp. Let's see how it starts what the important files are.... But wait, it only has #include "cube.h". at the top: https://github.com/assaultcube/AC/blob/m...c/main.cpp

Fine, let's dig through cube.h and figure out what's going on. It looks like the graveyard for "hm where should i put this? I have no idea. Let's put it in cube.h!" stuff...

https://github.com/assaultcube/AC/blob/m...src/cube.h

So how do you figure out where to start? Documentation? Comments? No go.

Why does AC not have any new devs? Because the only people who know what's going on are the people that already work on it.

So I propose a new structure. Let's call it a to-do list.

1. Comment all of the header files and cpp files giving a short description of what each file is supposed to accomplish
   
2. Create a diagram of dependencies
   
3. Figure out what really needs to be included by what file
   
4. Refactor
   

Yeah. That's what I propose. AC 1.3, AC 2 can be put on hold. Let's work on improving the code base and THEN adding features.

---

https://medium.com/on-coding/why-your-co...057c115a2b

[Felix-The-Ghost]

The TODO list and a lot of the code is from the original Cube engine.
I do agree new code should be held to higher standards though, simple documentation on the respective author's part would help newcomers.

[PhaNtom]

Firstly, Mousikos, this is perfect. Devs, please consider this.

In line with your proposal, this would also be a perfect time to introduce Unit Testing. This will greatly aid in the finding and prevention of bugs. If a refactor were to take place, this would be the smartest time to implement it.

Also, if a refactor takes place, it would be the perfect time to update the docs, many entries of which don't have any details...

[Robtics]

interest from the community for new devs

theres definately interest .. but who of the active community is actually an experienced enough coder who could not only contribute something, but also achieve progress on his "own" ?

To be atleast a little on-topic: your proposal sounds like a huge step forward but also very time consuming.

the only people who know what's going on are the people that already work on it

So, is it realistic?

[Nightmare]

About time we get jump pads on douze.

[Marti]

- gibs for health?
I found this on the todo list, i thought AC wanted to be sortof realistic?

OT: Is the base code for AC and Sauer the same?

[grenadier]

Yeah. That's what I propose. AC 1.3, AC 2 can be put on hold. Let's work on improving the code base and THEN adding features.

Sorry, but that would mean, there won't be anymore any new feature or bugfixes, because "code should always be in a constant state of refactoring for the purpose of improvement". ;)

From my point of view that is fictional problem, I'm weak programmer, and I could understand many parts of code, and send bug fixes and small new features. So what problem would have interested skilled programmer?
Such "refactoring" would be time consuming, boring, little useful (edit: and can cause appearance of new errors) - who would do it? At the cost of bug fixes, new features?

[...], it would be the perfect time to update the docs, many entries of which don't have any details...

Could somebody help in it?

[SKB]

Looks like some form of mentorship needs to happen. Those who want to work on AC should at least idle on #assaultcube.

[Ronald_Reagan]

Ok, feel free. Git has a handy fork feature, in which you can fork it, start on refactoring, and others can help. Once the process is done you can submit a pull request. If it is well done, we will merge it.

Its no secret that AC code is completely wack. If you need help navigating, feel free to go on IRC and ask us whats holding you up.

[Mousikos]

First off, I'd like to thank stef for deleting unused project files.

removed CUBE_TODO.txt …

Has been outdated for nine years and is apparently a huge distraction for
wannabe new coders.

latest commit be8d2f0923
stef ac-stef authored 5 hours ago

Now, to address grenadier:

That's not entirely true. One really big bout of refactoring, and then setting down code quality guidelines would do it. If the code doesn't meet the guidelines, it should not be merged into the main code.

Okay. You're a weak programmer, you can understand many parts of the code cool. Just because you can doesn't mean other people can. It's easier for a skilled programmer (not saying I'm skilled either) to read code that is actually written by skilled programmers. It's harder for skilled programmers (who are used to quality code) to flip through the code base. It's also not just about understanding bits of code.

Also, sure it's boring but it's important. You think it's not useful. But honestly, it's really, really useful. Furthermore, if this project has already reached "I do what I want to do" and not "I do what's good for the project", then it's already dead.

[Felix-The-Ghost]

wannabe new coders.

Shots fired.

[Alien]

The old code written by many coders is bitch, i know that pain, but remember, dont touch it if it works.
During testing pls write the steps to some textfile and publish them here, thanks.