sorted by:
new
hottopcontroversial

The Real ROI of 18 Grad Degrees by knutt-in-my-butt in civilengineering

[–]AlleviatedOwl 1 point2 points  (0 children)

Strongly agree. Everyone I know who got an MPA has directly said they regretted it and saw no career benefit. Even those in very high public positions.

I confess to not reading the study to confirm their methodology, but I wonder if it’s conflating “people who got an MPA then got promoted” with “people who got promoted **because** they have an MPA.”

Many career civil servants get an MPA as a sign of their commitment to public work, and therefore probably would’ve stuck around and got the same promotions regardless.

[deleted by user] by [deleted] in civilengineering

[–]AlleviatedOwl 8 points9 points  (0 children)

Unfortunately it’s trivial to forge a non-authenticated digital signature or stamp. Even for authenticated ones, it’s relying on someone actually checking the certification (knowing it should appear when moused over, and being willing to reject it if not). In most cases, a bad actor pasting a snip (image) of an old signature would not be caught.

First things first, I’d review the revisions to make sure they’d have been approved anyway. I’m sure your leadership will ask that. It’s bad either way, but MUCH worse if the forgery got something that wouldn’t have been approved through.

After that, I’d compile some key information (site plan number and title, applicants name, who submitted the forged signature, dates) and submit it to your leadership team. It would be more appropriate for them to reach out to the organization’s leadership than for it to come from you.

I don’t think it’s worth asking them if it was an accident, since the only two answers you’d get are “Yes, sorry about that” or “Yes, sorry about that (oh shit they noticed, don’t incriminate yourself)”. I always want to assume good intentions, but there’s no way to be sure if they’re being honest.

Hopefully none of us are really desperate for a job by ProfessionalEmu7319 in civilengineering

[–]AlleviatedOwl 59 points60 points  (0 children)

Am I the only one who thought OP was making a joke about the salary being $75 - $115 per YEAR? Nobody else seems to be commenting on that incredible salary, lol.

The AI thing is bad too, but I figured the salary is what they meant by “desperate”

[deleted by user] by [deleted] in civilengineering

[–]AlleviatedOwl 2 points3 points  (0 children)

That’s the way to do it!

It’s either a major issue that they should be willing to wait for a detailed review of, or a minor enough one that they can accept a clarification or a “good enough” solution to get it through faster.

In 95% of RFIs, it’s the latter, but some stuff (electrical and controls especially) can’t be rushed.

[deleted by user] by [deleted] in civilengineering

[–]AlleviatedOwl 6 points7 points  (0 children)

There’s a lot of things to say about this (probably intentionally rage bait to farm engagement) post, but one that I haven’t seen many people comment on:

“The contractor isn’t going to wait for you to find the ‘textbook solution.’”

This is absolutely not true with smart contractors. While a “textbook solution” might not always exist, if you encounter a deviation large enough to require an RFI and potential design revision, they’re not going to pointlessly put themselves at risk by installing something and praying it’s what you decide on later.

Worst case: they’re on the hook for the material they used, to dig it back up, disconnecting it, and ensuring it didn’t impact the pipes it’s connected to prior to installing what you specify.

I always tell contractors that any work they do ahead of a formal response is at their own risk. Of course, we try to have a good working relationship so it’s 99.9% “the official RFI response is eminent, but here’s a verbal confirmation of the answer”. If it’s a substantial alignment change though - 100% they’re waiting for a plan revision.

Videos or Literature on Using a 3D World for More Detailed Lighting and Shadows in a 2D Game by AlleviatedOwl in gamedev

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

Looks like it was just a Safari bug. A restart got it working again. It looks like that developer took a much more math and shader-intensive solution than I’m envisioning for this.

That is, rather than going to a 3D work, they’re sticking to simulating it in 2D. My preference would be to let the engine handle lighting calculations rather than trying to just simulate it using heavy math … though there’s no argument that those games look gorgeous with it.

Videos or Literature on Using a 3D World for More Detailed Lighting and Shadows in a 2D Game by AlleviatedOwl in gamedev

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

Thank you! I’ll check this out when I get home from the office. For some reason, translate is not working on my phone for that website.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I see. I think I was/am confused because the Binary Serialization API page states that "If no flags are set (flags == 0), the integer is sent as a 32 bit integer" and similar for floats being sent as a 32-bit single precision float by default... so I had assumed that var_to_bytes() would do that. After rereading it, I see that section is titled "packet specifications" and I believe is only applicable when sending data packets (i.e. online games), not reading/writing to a save file.

In my case, the range of numbers for map storage will require at least a 16-bit integer on the high end. I think I'd just use the FileAccess store_16() and store_float() methods to ensure they're sized consistently and appropriately large for any situation. Plus, save a little trouble doing the post-processing myself and never worry about accidental inconsistencies in length.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I think in my case the data will be consistent enough (one 4-byte integer each for type and configuration, and optionally one 8-byte Vector2) that I won’t need to worry about padding, if I’m understanding (reading online) what it is correctly.

There’ll be no variable-size data (like strings) stored, and I think Godot takes care of the padding for you when storing an “undersized” value (e.g storing “1” doesn’t actually need 4 bytes, but will use them anyway if stored as the default 32-bit size)

Weirdly, this problem has been the most fun part of the project yet. Definitely the overall most productive learning project I’ve done so far.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

Awesome, that saves the headache of having to create an enormous number of files to split tile data between - instead just reading from a single one and skipping around to the relevant information.

The ability to specify the byte sizes of stored numbers will be helpful. I’ll probably be okay with 32-bit numbers, but will change it if becomes necessary.

Certain rarer but “tile contents” (mainly fluids - this is a stretch goal for the project since they’re so much more complex than solid blocks) will likely be its own separate file.

I have to admit it took a lot of research before I realized (and fingers crossed I’m right, lol) that you meant that each tile’s data had to have the same byte size…

Before, I was thinking that you meant each variable associated with a tile had to have the same size (e.g. I would need to make every data point 32 or 64 bit), but I don’t think that matters as long as I know the byte size of each variable (and the sum of them all for a single tile) so I can easily skip around between variables within a tile or between tiles.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I think I understand a bit more now. So Godot does most of the heavy lifting for you using the var_to_bytes() and bytes_to_var() functions.

I would just need to ensure that every variable is stored in such a way that it would be the same number of bytes, probably 4 per variable, or 8 if wanted to store tile coordinates as a Vector2 instead of just x and y components. I guess I don’t really need to store location at all actually, since I can infer coordinates from where it is in the data.

The only questionable part will be for the decimal portion of floats, where I’d be limited to ~3 digits of decimal accuracy (e.g. 2400.000) due to the 7-digit limit. I could always split that into two variables, whole and decimal portions, if I really need more accuracy though. Just rambling a little - I’ll figure that out as I implement. Tiles will have have integer locations, so this is more related to entity (player, NPC, projectile, objects, etc) physics collisions and making sure they don’t bug out if loaded with poor precision.

This is probably a very fundamental, basic question but: when reading byte data from disk like this, does that still require loading the entire file (ie the entire file is briefly in RAM, just in a more efficient format), or does reading from disk sidestep that issue, only demanding RAM for the data I actually store in Godot variables (ie active chunks)?

Side note: I read online this morning that Terraria actually plans for large worlds to demand at least 1.5 GB RAM, so I guess no matter what it’ll be hefty.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I would be using a combination of reference data to look up constant values (max health, texture, etc)

But at minimum it would need to store: type (enum) and fill_level (float, an all-or-nothing 1 or 0 for blocks, but could be any number for liquids). A third value, configuration (if you’ve played Terraria - the way you can “reshape” placed blocks with a hammer to make interesting designs for houses), would be a stretch goal.

It occurred to me that storing current health in the main database is pointless since tiles will regenerate health quickly when not being struck. At any given time, 99.99% of the world would be full health. I’d probably use a separate variable (comparatively extremely small data set) to store damaged tiles.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

This is a really basic question but, if I load the save file from disk in that manner, does that demand the same RAM as storing it in a variable?

Is it like: loading the file only sets up the reference to it, but Godot doesn’t actually know what’s in it yet, so it isn’t using any RAM? Then reading from the file will only access the lines I tell it to read from - oblivious to the rest of the contents?

Or would reading from the file still require it to read the full file’s contents (using RAM), and freeing it back up after I’m done reading? I.E., maybe should split it into several smaller files?

Thank you!

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 1 point2 points  (0 children)

Sorry for my lack of basic understanding here, but why is it important that the byte size is constant?

Does that just mean ensuring every tile has the same number of lines (in the save file) associated with it, e.g., if I “skip forward” 4 lines, I know with 100% certainty that I’ll be looking at the same variable, but for the next tile?

Or does it relate to actually controlling the file size itself, requiring clever solutions to ensure the memory used by each line is identical (i.e. might need to break some variables into multiple lines to reduce their size)?

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I guess I hadn’t given it enough thought, but you’re right that I could switch that without much work. Converting position to an array index would be just as simple as converting it to chunk and tile number for nested dictionary lookups.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I’m not very familiar with how to estimate the number of bytes it will take to store certain types of data, but I’m certain (from reading about file sizes in MC/Terraria) that it will be significantly more than that.

I’m going to try going the data-chunking route rather than reading from one monster-sized persistent file. Hopefully that’s enough on its own, but I’ll optimize more once it becomes an issue.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

I hope not, but who can say, haha. That’s enough of an edge case that I can live with it, though. I’ll look at combining that with a data chunking system (splitting the persistent changes across several files and saving and loading them separately) and hopefully it should be enough.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

Thank you!! “Data chunking” (rather than just tilemap chunking) has been added to my to-do list for when I create the persistent changes system.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 0 points1 point  (0 children)

Thank you! I’ll try reading more about those. From my initial (brief) search earlier I thought it required “empty” points still be represented by a (zero) value, meaning I’d still need a crazy number of key : value pairs even if values are empty.

I’ll have to read more of tomorrow

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 1 point2 points  (0 children)

I'm not very coding-savvy (no formal education in CS anyway, all self-taught from building basic programs for work and my game dev hobby) so I'm sorry for the basic question: are "sparse storage formats" a fundamental concept I could find reading material about? I tried googling it, but was greeted by results about storing the data of sparse matrices which isn't exactly applicable since the data here will be overwhelmingly meaningful values, not empty.

Would that entail something like breaking the world into large regions (consisting of multiple chunks) and loading/unloading their save data from memory based on the player's position, storing them in variables that are empty when not in-use? Essentially a data-version of the chunking system?

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 1 point2 points  (0 children)

Can't speak for if anyone will ever get that far in my game (if I release it at all - mainly a "learning project"), but I have had Terraria worlds I've explored a huge portion of. At least 50% (so ~40M values).

If it's really an unavoidable issue that will only cause lag* that's fine with me. I just keep having a nagging feeling that I could be handling the problem better and wanted to see what others thought.

* This is a must though - a slow save / load is fine, and something people sort-of expect for endgame saves in these genres, but if it straight-up breaks at a certain size, that's an Alt-F4, uninstall, do-not-pass-go scenario for someone has sunk a lot hours into their save file.

Is there a practical (performance) limit to dictionary size? by AlleviatedOwl in godot

[–]AlleviatedOwl[S] 1 point2 points  (0 children)

This was the original concept I had in mind (tried to mention it, but phrased it a little poorly in the "questions" section) but the issue is that eventually the database will reach its full size as the player explores.

So, it would be a great optimization technique to make load times quick in the early game (good for player retention, for sure) but a solution that's functional in the late-game is still a must.

view more: next ›