CarlZalph

  • Content Count

    2065
  • Joined

  • Last visited

Community Reputation

4912 Excellent

About CarlZalph

  • Rank
    Mastermind
...

Badges

Recent Profile Visitors

15714 profile views
  1. It's missing the handling of return parameters. I wrote a thing a little bit back showing the boilerplate for function hooking here:
  2. Looks like Webber got swoll and didn't skip any leg or head-leg day, and took to personal grooming practices. In reality, the last I heard was that Toni and some of the core artists are working on other projects and not DST so the differing styles will be more pronounced.
  3. https://steamcommunity.com/sharedfiles/filedetails/?id=764204839 Please don't be afraid to custom tailor the game to your desires with mods.
  4. The player's builder component's onBuild function passes the builder and product where you can then record it on the product prefab. From there the product should have it save the builder's userid field in the OnSave function, and load it back in the OnLoad function.
  5. I liked the carrat racing minigame thing, it didn't feel like a skinner box but rather more of a who-can-dink-the-others-over-while-still-winning-yourself thing. Though the track setup was tedious. Did you find it enjoyable?
  6. In addition it also serves as dependencies so things can load in the proper order for like post inits and such, you can also see a lot in the forest prefab since it spawns off a lot of different prefabs for worldgen. Prefab = Class( function(self, name, fn, assets, deps, force_path_search) return Prefab(name, fn, customassets, worldprefabs)
  7. One item in a long winded path, had to traverse back.
  8. I believe the most constricting thing Klei has at the moment is time. The tradeoff of allocating hours worked towards new content, bugfixes, skins, etc versus adding in some more art for skins. Me too.
  9. It's been a while but I believe the builder_tag/owner_tag parts for recipes control the character-specific craft tabs.
  10. Quote

    Servers: 7141
      Group Only         : 53 (0.742193)
      Mods               : 5175 (72.468842)
        Players          : 4568 (65.331808)
      No Mods            : 1966 (27.531158)
        Players          : 2424 (34.668192)
      PvP                : 163 (2.282593)
      Passworded         : 3545 (49.642907)
      Dedicated          : 5965 (83.531718)
      Client Hosted      : 3916 (54.838258)
    Players: 6992
      In Lobby: 261 (3.732838)
      Vanilla: 6080 (86.956522)
        {wendy}: 1072 (17.631579)
        {wathgrithr}: 714 (11.743421)
        {wilson}: 683 (11.233553)
        {woodie}: 451 (7.417763)
        {wx78}: 409 (6.726974)
        {wolfgang}: 384 (6.315789)
        {webber}: 344 (5.657895)
        {walter}: 291 (4.786184)
        {winona}: 288 (4.736842)
        {wickerbottom}: 269 (4.424342)
        {willow}: 248 (4.078947)
        {waxwell}: 224 (3.684211)
        {wortox}: 203 (3.338816)
        {wormwood}: 180 (2.960526)
        {warly}: 141 (2.319079)
        {wurt}: 125 (2.055921)
        {wes}: 54 (0.888158)
      Modded: 648 (9.267735)

    Snapshot.

    1. minespatch

      minespatch

      That's a lot of players.

    2. Slagger

      Slagger

      Lol there is not much wortox on servers as I excepted

  11. If you're able to track them as they're important to each other, then it would be more efficient to do so. The post I put there is what most games do when having an underlying grid to work from to speed up radius-based checks and I assume is what Klei's doing for theirs when you use TheSim:FindEntities. (If they're not, well rip that optimization pass.)
  12. The game already runs on tiles, so it'd come to a shock to me if there isn't any partitioning up of the lookups by having each tile itself know what entities are on it for example. Assuming memory isn't too much of an issue for the redundancy for faster lookups, then doing it like this would see a huge increase if the number of entities to check increased. The dark blue tiles wouldn't need to be checked, the green tiles would, and the light green are the permitted entities. For example, let's say that the world is a typical 450x450 and that there is exactly 1 entity per tile. Thus there are 202500 entities in this world. Using the infographic as a basis, it would reduce the checks from 202500 to 24 (number of green tiles), and could create an array of 43 (blue + green) maximum entities and 19 (blue) minimum entities. Even in this trivial case it should be apparent at how much more efficient it would be to spatialize up the world. The granularity of the spatialization (the region size for each square) would have an ideal size based on probability distributions. You can see this by looking to the extremes: With a region the exact same size as the map you gain no benefits as the entire map is one region and thus all entities are checked. With a region size extremely small you now have a lot more zones to iterate over creating "artificial" entities to look at instead (imagine 202500 zones to look over being equal to 202500 entities). Some point in between the extremes would trade off memory use for performance at an acceptable ratio, and I would assume that it's the same size as the turf tiles the game uses by default.
  13. Quick aside, you might also see some skins with some random arbitrary letter or number appended to it, too. That's to resolve a hash collision with the string hashing function. You can find its definition here: