Recent Posts

Pages: 1 ... 8 9 [10]
91
Computers & Programming General / Eric Lippert - Vexing Exceptions
« Last post by Hooman on October 11, 2018, 01:22:43 AM »
This had an interesting little summary of types of exceptions:
Eric Lippert - Vexing Exceptions

The types were:
  • fatal
  • boneheaded
  • vexing
  • exogenous

Basically, don't catch fatal exceptions (disk failure, access violation), there is nothing you can really do anyway. Don't catch boneheaded exceptions (array index out of bounds), as they reveal a bug in your code, and so you should fix the bug, rather than try to catch and silence the exception. You're forced to catch vexing exceptions (Int32.Parse()), though these are really a misuse of exceptions and give them a bad name. Finally, do catch and deal with exogenous exceptions (file not found, permission denied), which seem to be at the heart of what checked exceptions are about.
92
Hooman,

What are you thinking for workflow when creating a new scenario? Would someone fork the blank template, then rename it? I've never tried this in GitHub, although I know you can rename repos...

Adding the APIs as a submodule to the scenario would typically place it in a subdirectory. So the repo would look like:

ScenarioRepo
 - APIS directory (submodule)
 - Scenario files

This seems fine to me.

Leeor, yes I think have CI setup would be a good idea. I haven't researched using Appveyor to build multiple projects  yet, so not sure of the feasibility.

-Brett
93
Outpost 2 Update / Re: LevelTemplate - WithComments?
« Last post by Vagabond on October 10, 2018, 05:26:20 PM »
For the sake of maintainability, I would be happy if we dropped to 1 template. Doesn't really matter if it is commented to me or not. Although I wouldn't want to get crazy with a full tutorial in the comments. Better to review a completed scenario or read on the wiki or sirbomber's tutorials for the details.

I would also be okay removing the hooville template. I wonder how many people review it / find it helpful?

All of my scenarios use HFL. What do you think about adding a reference to HFL from the template library? You could make a simple multiplayer scenario without it. I think if you want to do anything more complex then you are going to want the added functionality it provides. For me it would cut down on some boilerplate reference code. Also understand if it is better to keep it simple.

-Brett
94
Outpost 2 Update / Re: LevelTemplate - WithComments?
« Last post by leeor_net on October 10, 2018, 05:12:05 PM »
Personally I would leave in comments that explain required parameters and leave the rest for tutorials/documentation either on our Wiki or through GitHub's wiki features.
95
Technically speaking most of these widescreen monitors can be turned to make them taller than they are wide. And to play devil's advocate, with window snapping a wide screen monitor makes more sense if you have a single monitor layout -- e.g., you can have two narrow windows side by side if you're doing comparison (e.g., code diff, etc.).
96
Outpost 2 Programming & Development / Re: visual Studio 2017
« Last post by Hooman on October 10, 2018, 02:27:13 AM »
Heh, I like the idea of mixing spiders with stickyfoam. In hindsight, that should have been more obvious, though I'd never thought of it before.
97
Ahh yes, the practical problems that crop up when people actually try to use stuff. :P

This is good though, I'm glad people are working on this problem.

I would propose keeping the levels separate from the API projects. I would not be terribly opposed to combining the API projects into a single repo:

Repo1:
  API/
    Outpost2DLL
    Outpost2App
    OP2Helper
    HFL
    HFL-IUnit
Repo2:
  LevelTemplate
Repo3:
  Hooville
...

Each level could go in its own repository, each one referencing the API repository as a submodule.

I think it's reasonable to have the API projects kept in sync with each other. I don't think it's so reasonable to try and keep all possible levels, released or unreleased, in sync with API changes. I think that's an area we need a version boundary.
98
Outpost 2 Update / LevelTemplate - WithComments?
« Last post by Hooman on October 10, 2018, 12:58:23 AM »
Do we need both a blank level template project, and one with comments? Perhaps we can or should remove one.

I liked having a blank template that wasn't littered with comments that I didn't need. Though perhaps levels based on a blank template would then be less useful for other people to learn from or adapt.

For people who hate excessive comments, it's not so hard to just delete comments after forking.

We could perhaps have the commented and non-commented versions as separate branches in the same repository. I'm not a fan of this solution though, as when you fork, you'd fork both branches, and I wouldn't want to encourage having extra stray branches around, which will inevitably become stale.

We could expand on the comments to make it more of a tutorial, though perhaps that's best as a separate tutorial level project.

I'm thinking we should get rid of the template without comments, and rename the other to simply LevelTemplate. Would love to see people's comments on the matter ;)
99
Thank you Brett for the code examples!  :)

(I think that was the transcript that Leeor required. ;) )

I suppose we should add an example of one of the better ways to write and justify parameter lists:
Code: cpp [Select]

void SomeRatherLongOverlyVerboseFunctionName(
    int param1,
    int param2
) {
  // ...
}

The parameter list is then kept together as one unit, with consistent indentation that depends only on structure, and not on name lengths. In particular, if someone renames the function to have a different name length, you don't have to re-justify the parameters to maintain a consistent indentation, and the parameter list is not split across both sides of the screen.



Leeor, that's a good point about passing a struct reference, rather than a bunch of individual parameters. There are many cases where that's the best way to do it. I suppose it depends on context though. If the parameters would be naturally bundled together, it makes sense to exploit that. If they are not naturally bundled together, or would need to be bundled together just for this one function call, then maybe not. I'd probably prefer a long parameter list than bundling together parameters in a forced artificial way. Though certainly long parameter lists can be a sign that something about the design is not so great.

As an example, here's a method with different levels of parameter bundling:
Code: [Select]
void DrawRect(int x1, int y1, int x2, int y2, unsigned char red, unsigned char green, unsigned char blue);
void DrawRect(Point p1, Point p2, Color color);
void DrawRect(Rect rect, Color color);

void SomeMethod() {
  /* Parameter meaning is not so clear at point of call */
  DrawRect(5, 10, 10, 20, 30, 50, 10);
  /* These two are more self documenting, without needing comments */
  DrawRect(Point(5, 10), Point(10, 20), Color(30, 50, 10));
  DrawRect(Rect(Point(5, 10), Point(10, 20)), Color(30, 50, 10));
}

On a related matter, when constructing a Rect, there is a choice of parameters, which might not be immediately clear:
Code: cpp [Select]

/* Parameter list types are identical, so you can't have both overloads. Choose only one. */
Rect::Rect(int x1, int y1, int x2, int y2);
Rect::Rect(int x1, int y1, int width, int height);

/* These options are more clear, and can both be available at the same time */
Rect::Rect(Point p1, Point p2);
Rect::Rect(Point p1, Vector size);




The 80 character limit does seem a bit archaic. Even if you're using a terminal, modern systems still allow terminals of varying sizes. Granted, I default mine to 80 characters wide, so there's that. At any rate, I don't particularly mind a limit of 120 characters, or pushing past the margin just a little, but by and large, I prefer code to be largely left justified.

His comment about how people read was noteworthy. We read in columns, like newspaper articles. I've heard elsewhere, that's much easier on the eye, and takes less effort to move the eye from one line to the next without losing which line you're on. Though I suspect that's less of a problem with code, since the greatly varying lengths of most code lines already creates a visual indicator that can help your eyes track which line is which.

At any rate, I've long found these widescreen computer monitors a bit silly. I spent most of my time on the computer reading, and yeah, I prefer to read in a column, than going all the way across a wide screen monitor. I've long felt computer monitors were being expanded in the wrong direction. I'm sure widescreen is just fine for movies, but it's not what I want for reading. Curiously, I once got a monitor at work that could be swivelled 90 degrees, so it was tall rather than wide. One of the selling features was being able to see more lines of code at one time. The only problem though, was the monitor's viewing angle was not the same between top-bottom and left-right. In normal widescreen mode, it seemed fine, with a decent viewing angle to the sides, but when you rotated in 90 degrees, it had a rather narrow viewing angle to the sides, which affected color display. In the end, the lackluster viewing angle meant I never bothered to use it in tall mode. Would have been nice though.
100
What about setting up a CI solution that checks all of that whenever you make a change?

I support any solution that automates things.

I personally like them being separate repos. If we have multiple repos that need checked out, I would rather us automate the process then combining the repos back into a monolithic one. I can throw together a simple shell script you can run inside of Git Bash (on Windows, or just a Terminal/console on everything else) that automates the process.

EDIT: I just threw this together really quickly: https://github.com/OutpostUniverse/OP2-Workspace

I threw in the workspace file I had for VS Code, but we could add a Visual Studio solution file as well to auto open all of the projects as well.

EDITEDIT: So I might have just went and fully automated the whole set up. The install script from above can fully install Visual Studio 2017 Community Edition or Build Tools for Visual Studio for you on Windows. I have the non-Windows (Linux/Mac?) about half way done. I just have to configure the env vars and put them in your ~/.bash_profile.
Pages: 1 ... 8 9 [10]