300 API calls per minute -> https://www.tumblr.com/docs/en/api/v2#rate-limits

This is not required any longer.

Hi! I am successfully able to submit text posts or photo posts independently into tumblr via the legacy endpoints in the tumblr.js libbrary. The issue is that I would like to submit a mixed text/photo img post. The images are computer generated, so I insert them as a data64 string.

Here are the things that I have tried: 1.I have tried to use the generic createPost method and supply the "text" parameters as well as the image parameters. The only thing posted is the text.

2. I have attempted to createPost, then I call editPost using the id_string in the successful initial post. In the editPost, I submit the image parameters (which do seem to work in the createPhotoPost call). The edit post returns successfully with the original id_string, but I do not see an image posted.

I am sure this is something dumb I am doing. Additionally, in playing with the api I don't see how one would build a thread. Is that the "chat" message? If so, how does one go about responding to it? In analyzing the message flow of the web site I see the following sent by the browser to tumblr: {"post_id":"643848899420930048","reply_text":"Blah blah bla....","reblog_key":"Tk00VfYk","tumblelog":"commodityvol"} I cannot see an analogue in the api. Again, probably my ignorance here.

Thank you.

Bumps jackson.version from 2.10.1 to 2.12.1. Updates jackson-core from 2.10.1 to 2.12.1 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/FasterXML/jackson-core/commit/67a29707d4a41cbc52c25f1886eaf1da863f9c40"><code>67a2970</code></a> [maven-release-plugin] prepare release jackson-core-2.12.1</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/2649dd44d64d39fb70bd45b1965c5832a3fc76bf"><code>2649dd4</code></a> Prepare for 2.12.1 release</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/1e30c8c3122458660d7260099de0b04fbc88bc55"><code>1e30c8c</code></a> ...</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/aa54f0a1b25b84fbdc50af69e71fdd40fcb65be1"><code>aa54f0a</code></a> javadocs, javadocs</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/e5cbda207aa2b9e69da0f63bb79df5d9d072872b"><code>e5cbda2</code></a> More javadocing</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/8dadf29d5b587a4f70eb0fa964a50a854a16327c"><code>8dadf29</code></a> Minor refactoring... and more javadoc stuff</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/2493625b18d2e99f1747808c8e4d3d69e2629406"><code>2493625</code></a> Yet more javadoc'ing</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/00a8c72eb4b56cfcfe1ea815cfcdcfbcc97b183e"><code>00a8c72</code></a> more javadoc stuff</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/a40a7f7b80207f0c5c3c3802aca30d8ba66a4190"><code>a40a7f7</code></a> yet more javadoc fixes</li> <li><a href="https://github.com/FasterXML/jackson-core/commit/01d1e8877a2cb90f8b88ed952420bce808d0bd5a"><code>01d1e88</code></a> More javadoc work</li> <li>Additional commits viewable in <a href="https://github.com/FasterXML/jackson-core/compare/jackson-core-2.10.1...jackson-core-2.12.1">compare view</a></li> </ul> </details> <br />

Updates jackson-annotations from 2.10.1 to 2.12.1 <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li> </ul> </details> <br />

Updates jackson-databind from 2.10.1 to 2.12.1 <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Giving up.

As a warning rightly indicated, the ! operator was only being applied to the lefthand side of this comparison, meaning that this early return would only be evaluated if the value in the change dictionary was nil (which, according to the docs, should be never).

The intention was that we would return early if this is not a KeyValueChange event, which would make NSKeyValueChangeOldKey nil. This fixes the logic and removes the warning.

I took the liberty to modernize the codebase a bit and bump the minimum deployment version to 7. It should still be iOS 6 compatible but I didn’t have means to test it. The commit history sums up what I did. If this fits your roadmap for TMCache, please feel free to merge.

Deprecated by https://github.com/CitrineInformatics/lolo/pull/232

Is there any chance that the tumblr team is migrating to something more up to date, like https://www.npmjs.com/package/node-fetch?

The name of the region matches the database backup fine. It's just, we parse turf names for displaying when you F7 on yourself in a particular way. We don't just pass the region name along when you F7, but instead we take the context name (seperate from the region name) and massage it to look good. That's fine for Popustop regions, but not for Street/Homes.

This is still active and has not been diagnosed to my knowledge.

Note: Even if we change the names, they won't get changed on the server until the next database reset.

The name of the region is the name of the region. What were the original names? Is the help text the same as it was then? It should match what it was in 1986. If it does, this issue will be marked as "As Designed", if there is a mispatch, we should fix the region names to match their 1986 text.

I would like to propose we create a tool that allows you to create NeoHabitat regions with ease.

Originally, regions were created using FRED, an interactive region editor that allowed you to piece together a region onscreen, output it into Griddle format and then feed into the database.

In NeoHabitat, we converted Griddle regions by hand to JSON or used Steve’s Regionator tool to convert Riddle files to JSON (the bulk of the regions were in Riddle format thankfully).

Personally, I have created new regions simply using Notepad++ but it's not as efficient as it could be.

How do we simplify/speed up region creation without recreating something like the Fred tool? (essentially an offline version of Habitat on the C64 that utilized Fastlink).

I propose we create a tool that has the JSON schema for a region and its objects stored that allows you to add/remove an object, provide the necessary values and let you save this as a valid region JSON file.

For example, you could load up this tool and it would have the basic region skeleton that features the following:

[ { "ref": "context- ", "capacity": 64, "type": "context", "name": "", "mods": [ { "town_dir": "", "neighbors": [ "", "", "", "" ], "orientation": 0, "nitty_bits": 3, "port_dir": "", "type": "Region" } ] } ]

This skeleton may or may not be viewable, perhaps you could toggle it on and off to see the eventual JSON output at the same time.

You’d be able to click on “Add Object” and select an object from the Class List. This would then populate the JSON with a new object appropriate for that Class, with the relevant class-specific variables included. It’d then have some sort of screen featuring a list of those class-specific variables and allow you to fill those in, with the tool populating those automatically.

In an ideal world it would have a list of max/appropriate values built in to prevent you from entering incorrect values (or adding too many objects).

It’d also be good to have some default values for certain objects with common values to be automatically populated (such as the Sky object having x:0, y:0 and style: 4 pretty much exclusively in most regions).

It’s possible that this could be used as a future skeleton for a potential graphical region editor should someone choose to take up that mantle, but it sounds like a lot more work.

This would allow for faster region iteration on the fly (perhaps you could even have the ability to save a region template, so you could have a template for a region that has the default ground/sky/street to allow you to iterate on).

It would also save a bit of time when manually converting regions that were saved in the contentsVector format into JSON.

A mockup of what such a tool could look like (please excuse the terrible design, it's purely to show functionality)

This issue can be closed.

F7 on your avatar formats the output wrong for the turf if your turf is a street/home.

As you can see in this screenshot, it says:

"You live at OutamyWy 529 #interior."

It would look much better as:

"You live at 529 Outtamy Wy."

F7 inside the street/home turf itself displays the regions name which is formatted as "number street name" or "529 Outtamy Wy".

Would there be a way to add in a case where if the turf context of the avatar doesn't say Popustop, to just use the home regions name instead of the context file name?

This bug is still active. @ssalevan is this something that'd be fixed with the new bridge?