• Announcements

    • JoeW

      [UPDATED] Physical Megapack Disc Issues   04/16/2018

      We are now ready to accept claims for PS4 Megapack replacements.  Once again, our deepest appologies for this entire situation. We understand that your purchase of the Megapack was a show of support by our fans, many of which already owned the game. Please know that we have done our best to push as hard as we can for a quick and fair resolution to this issue. This has taken WAY too long to be resolved but we have done everything in our power to make sure our fans get what they purchased.   We are going to use the voucher codes we have been using to provide the digital version to claim the physical replacement discs. For North America, we are handling these requests directly through our own store with help from our friends at IndieBox. Claims will be handled at no cost to you. For claims outside of North America, 505 will be taking your information and processing your claims.  Those who purchased the Megapack after 4/26/2018 should have been given a voucher at the time of purchase on your receipt.  Those who purchased before 4/26/2018 or did not get a code otherwise can contact us for a voucher code that will entitle them to the digital megapack and can be used to claim the physical replacement discs. We have been handing those out for a while now, but if you are in this category and have not requested a code, you can do so here: http://support.kleientertainment.com/customer/en/portal/articles/2935839-physical-mega-pack-disc-support-information Once you have a voucher code:
      For purchasers in Europe (SIEE). To make a claim you will need to make file a claim through 505 here: https://docs.google.com/forms/d/e/1FAIpQLSckru65CWkXH5RZ_3j2f5_h1djNiAyrl8R0PCvdKPmGwItyvA/viewform For purchasers in North America (SIEA). To make a claim you will use our support site and use the voucher code to claim a replacement here: http://support.kleientertainment.com/customer/portal/articles/2952265-ps4-faulty-disc-claim If you have any questions or concerns, please let us know here on this thread or contact us at livesupport@kleientertainment.com Thank you.   

Some1

  • Content count

    215
  • Joined

  • Last visited

Community Reputation

26 Excellent

1 Follower

About Some1

  • Rank
    Member

Badges

Don't Starve Together
  • Contributor
Oxygen Not Included
  • Alpha Contributor

Recent Profile Visitors

3,051 profile views
  1. TheSim:QueryServer memory abuse

    Please, just take a quick peek on this.
  2. Currently I'm working on utility mod, which will upload all changes in strings to our translation server. Of course, I use built in TheSim:QueryServer function. Recently I noticed, that it uses enormous amount of memory to send data, if this data is larger than 20-30kb. For instance, to send up 70kb data dump it requires more than 2gb of memory (and a lot of cpu aswell)! Go, check it yourself! P.S. b.t.w. can you reveal all TheSim:QueryServer parameters meaning? Is it TheSim:QueryServer(string domain, function callback, string method, integer timeout) ? Is it possible to modify this function, so that it would be capable to process user-given http request header fields? Currently I'm unable to provide normal cookie-based login, cause this function doesn't allow me to get/set cookies, as well it doesn't allow me to change content-type field, which could be crucial in particular conditions. The way I see this improvement is to add an optional table-parameter, that would override existing and add new header fields to request: TheSim:QueryServer(domain, callbackFn, "POST", {["Cookie"] = "....", ["Content-Type"] = "application/x-www-form-urlencoded"}) and callbackFn should have fourth table parameter, filled with responce header fields: function callbackFn(data, status, resultCode, headers) print(headers.Cookie) end What do you think?
  3. There is a minor problem with dumtable function, if you use it to show tables with mixed type of keys. Let's say, we have the following table: tbl = {a = 1, {} , ""} --a table with one string key named "a" and two number keys 1 and 2 dumptable contains table.sort function, which can't sort tables with mixed type of the keys, so the game would throw us an "attempt to compare string with number" error. To avoid this you should add custom comparator, which would make the job, s.a.: ... --part of dumptable local table_keys = {} for k,v in pairs(obj) do if type(k) == "table" then table.insert(table_keys, k) else table.insert(keys, k) end end local function compareMixed(a, b) if type(a)~=type(b) then --convert both to strings first, then compare return tostring(a)<tostring(b) else return a<b --this should stay to maintain normal order for numbers (55 is greater than 8, while "55" is less than "8") end end --and only after that... table.sort(keys, compareMixed) --using comparator ...
  4. I'm pretty sure this is not what is meant to be:) INVALIDNEWHOST_TITLE = "Creating your first world?", INVALIDNEWHOST_BODY = "We recommend trying the game alone in a private world while you learn the ropes and get the hang of not starving. But it's totally up to you!", You also already have this (which seems to be correct): NEWHOST_TITLE = "Creating your first world?", NEWHOST_DESC = { ALONE = "Play alone in a private world where you can collect your bearings and get the hang of not starving. This is recommended for your first time playing.", TOGETHER = "Start an online server where other players can join in your adventures. It's up to you whether it open to everyone, or just your friends.", },
  5. Take a look the following example: function FrontEnd:OnMouseMove(x,y) if global_error_widget ~= nil or self:GetFadeLevel() > 0 then return false end if self.lastx and self.lasty and self.lastx ~= x and self.lasty ~= y then self.tracking_mouse = true end self.lastx = x self.lasty = y end Don't you think, there should be "and (self.lastx ~= x or self.lasty ~= y)"? It looks, like current implementation ignores straight mouse moves (i.e. when lastx is not equal to x AND y stays the same, or vice versa).
  6. Russian Language Pack

    Эта проблема решена в последних версиях русификатора (начиная с 4.2b и выше). К сожалению парень, который занимается выкладыванием версий, до сих пор не обновил файлы. Простите за задержку. Скачать последнюю версию можно здесь. Простите за неудобства.
  7. Russian Language Pack

    В DST иероглифы вместо текста означают то, что у вас старая версия игры. В игре последних версий (159550 и выше) изменена кодировка, соответственно она изменена и в русификаторе версии 4.0 и выше.
  8. @Granis, you can easily check it by looking any fnt contents.
  9. Russian Language Pack

    Кнопки уже давно есть. Версия для Тугезер тоже. Начиная с версии 3.8 появилась возможность вводить русские буквы на Mac OS и Linux.
  10. Yes, you have to do it manually, however I may help you with your problem:)
  11. This sounds frightening in the view of those guys, who work on translation of game content to other languages:)
  12. I always think ahead So in that case I just think to myself, why don't add all those glyph, it could save a lot of time for ohters.
  13. Hey, @AzureBalmung, why don't you just use my versions of those? They seem to have all glyph you need:
  14. @rooks, I think it would be nice, if you provide people with bmfont presets, as Brook did for me. Though developing of those presets without assistance could turn to true headache, you know... Yeah, and even some extra-fonts, which were deleted during past steps of developement
  15. @CharlesB, PeterA have told me, that he's going to convey my request to you (He said Charles, so that's why I'm addressing to you ). I'm still curious, if you've had a chance to investigate this, and I want to know, if it possible to fix this or not. I assume, that the problem is much more complex, than it looks at first sight, because windows uses 8-bit implementation of input and 8-bit codepages, which are language-specific. At the same time linux may (just guessing) use full unicode implementation of text I/O, which yields a constant headache to you and other DS dev's, because of that our lua is totally 8-bit. The easiest thing to do here is just to provide pure unicode input flow, however in that case people will see double and triple byte sequences instead of desired symbols. The second thing you can do is to use standard lookup tables in accordance to windows ansi codepages, which basically are national unicode symbols, perfectly mapped to 8-bit range. Of course this will mean that you should built in those codepages into the game core. But I might be totally wrong, so you're free to laugh on my fancy thoughts Anyway, to put it briefly, I'll be happy, if you answer me, how do matters stand with this stuff