Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

56 Excellent

About g4borg

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  • Interests
    Development, Computer Science, Games

Recent Profile Visitors

1409 profile views
  1. g4borg

    Stable Update 1.03.151658

    DDR3 based systems have slower RAM, that is often not taken into account, causing micro lags in many contemporary games, I also had a 3rd gen i5 cpu until recently and suffered microstutters in many titles, even if same games worked perfectly years ago. Sometimes these changes occur so slowly, but models get swapped for more polygons, etc. the cpu itself may even have enough raw power to handle all fine. Old HDDs, not enough RAM, etc. culminates as well. if you drive, you will a) do physics calculations and simulate your car, b) load map/assets into RAM, c) eventually load textures / models into GPU, the faster you drive the more throughput, the more vulnerable the whole simulation gets. you only need to enter a small cycle of lags, and this could be even from a few stray network packets, and if multiple parts struggle, you will end up with really heavy hits on performance, since in a simulation, you have to "keep up or sync", causing even more stress on an already bottlenecked system. in worst case, this leads to a simulation "explosion", where syncs and trying to catch up lost frames cause troubles, especially if e.g. the car is slightly sticking in the ground, causing the known death trap. Try lowering settings, swap in an SSD, make sure you have plenty of RAM. (E.g. do not underestimate, that windows 10 will use your swap for the gpu as well, so make sure you have enough swap / free space)
  2. g4borg

    Stable Update 1.03

    you can easily adjust that in the mission file in types.xml, by setting the values to "0" where you do not want them to be counted in the totals. i have removed that on my server a long time ago, i am sure others have aswell, as it kinda does not work well in a single server economy. because turning it up will only result in people hoarding more of them, and them disappearing again to be honest i am myself very skeptical about that feature.
  3. Really nice. Especially the docs. Happy about them documentation. So there is no try/catch for exceptions? And, maybe, just maybe, could we get a config setting to - define how many files can be in a directory (max of 500 is bad) - define a separate path for missions folder (so we can have it on a RAMDISK, but not the game) Well, maybe time to create some tickets for these...
  4. g4borg

    Quick test on 1.02

    I tend to agree, that server hopping is a subpar solution. initially i thought they wanted to make a server-independent system, where you switch server instances with your network bubble. kinda like “Star Citizen” or “Dual Universe” aim to implement it (which however is questionable if they even succeed at this, as this has never been done yet successfully - but it kinda begs the question, if it is not the age of cloud computing, where such a solution would begin a new era of online gaming, but i digress) however, I do find, the server hopping could be solved really better by “extracting” and “landing” on the island in some way. If you really want to go from one server to another, this being possible is not bad, but it does not need to be as it is now. Since as it is now, you can simply walk into other players' bases, and other ghosting tactics. To be honest, this was a personal project of mine, by looking at what I saw from Escape from Tarkov, or remembering the good old Ultima Online times where you had a magic bank account, you could access in each town: simply have a player storage, you can return to, equip items, and start into the game, and have a specific extraction goal (reaching a bunker, flaring for a chopper, driving out with a boat, etc.) to return to that magic place. From there you could either be smuggled back to one of the insertion points, or jump in via plane, or come by boat. This is what I would have modded my server to play like to. Atm. this is on hold, as without mod-loading, proper DB access, or interprocess communication, I struggle to do it. I am pretty sure, DayZ needs such a spin, to evolve (not just watering it down with trader cities or ten thousand different items) To the technical solution of Duping, I got also my two cents given the current solution, and it's downsides, which IMHO is mainly a problem of communication between the central player database and the instanced server (less an issue of the actual economy system), I find it a bit of overkill, to mark every item generated on the server with a serial number. However, items which players do bring into the game, and items which they take out of the game, could be added with a serial number. However the main issue seems to be communication with the player database and servers. I had this happening already by accident, as I died to a Zombie, logged off, relogged, and spawned just where I was before I died, and ran from a player shooting at me. In this case I was happy about Groundhog day, as I could escape my death the second time, even if the stakes were higher. I understand that fixing this issue, of proper communication between servers and player db, has it's caveats. Locking the player character from relogging, until the old server reports what happened to it in the instance, would be the best solution. However of course, what if the server goes down - crash or restart? The solution seems actually to tackle it at its source, with some proper protocol of how server instances get player characters, like in some financial transmission or object database: A server can lease a player. A leased player is completely managed by the server database. The Server can update the lease, by sending a current status of the player occasionally. Each time a player logs in the server asks if his lease is valid, and proceeds to load the local cache copy of the player if yes, or retrieve the current player from the central database, if not. If the player wants to play on another server, the leased server has to have transmitted its current data, and returned the lease. This is the tricky part. Now there are two ways to accomplish this server2server: one is to have the servers listen to active push notifications from the player db, which asks them to submit the latest version of their leased player. This might be extra work, but it might be worth it. The other is to rely on periodic lease updates, and give a grace timer until the next update window. This of course increases the server traffic needlessly, better is the server polls the central db for current tasks, and in such gets informed to inform about the current player state of one if its leases. If the server fails to respond, and only then, in the grace time period, the player gets reset to the last centrally saved state / character. This might still allow duping by abusing server restarts, but only between two servers, and only once in a while. It certainly does not allow to dupe on the same server. Together with the solution, to tag serial numbers to items players have brought into the world, and maybe even revamping the whole system you travel between servers, this could make duping really hard. Of course this assumes, duping is mainly done with the central player database being abused. But everything else is a major flaw in your object instancing and server authority model.
  5. I just whish they would improve the core. Better modability, mod loading on server join, database bindings or at least socket communication so we can do it on our own, some documentation... Why build a new scripting engine and have very limited exposure of tunable functionality like weather or item scripts. Why not focus on this engine with arma 4 in mind and use the opportunity. Dayz itself was a result of modability. That value should be core.
  6. g4borg

    Some great reading to pass the time.

    Sorry to say but no. The correct critique would be that they should have used a new engine from the start. And they should have developed it to be used for a future engine used in more titles. The engine they used, arma2 / choppers, is very amateur compared to even a five minute unity project, or modding unreal a bit. Which got proven by pubg using standard assets and minimal coding in unreal. So that choice was just late. Also it is not a few hackers. It is a lot of them. Even more than you assume, as many only use hacks moderately. Not everyone staples all cars on the server. FPS. Something that clearly improved. Physics. Network code. Fluidity of animation. No clipping through walls. Not saying I am happy about the current state especially about how overengineered cr4p the scripts are, I am absolutely not happy at all. But the old engine was a wrong choice from the start.
  7. g4borg

    Unpopular Opinion

    sorry, but making money should be the companies priority, not the consumers. this defensive attitude is by no means "unpopular", and many shady game developers actually profit highly from the advocates, even pushing their own "victim" standpoint, while most of the money is disappearing in completely unrelated "sinks". I know you mean it well, but unfortunately, money isn't everything. Game development is one of the hardest jobs in programming, it is taxing intellectually, operationally, emotionally. Sometimes money cannot solve these issues.
  8. I know this is sort of a rant, but I have to kind of document it somewhere, because atm. DayZ Scripting made me encounter a really frustrating situation. How it started: It seems that files have maximum sizes, that means, simply serializing e.g. player based data into a json file is impossible. I have to start using multiple files. Weird, but fine. I implemented my systems with steam ID as filename in a custom directory in $profiles. It also seems, maximum amount of files in a directory, for whatever reason, is set to 500 in scripts. Saving a file will raise an exception. Nice to realize this by accident. Now since there is a MakeDirectory function in System, one would think: okay, let's use sub-directories with hashed directory names. At this point I just whish, the dumb 500 would be at least 1000, so I can properly hash a SteamID. But no. And MakeDirectory does not work, it simply returns 0, and does not create a directory in $profile. I have no idea how to use $saves on a server, but it does not matter, as it also returns 0 there. I cannot of course read inside a script, how many files there are in a directory, but maybe I have overlooked a function in EnSystem.c I could also of course pre-create a trillion directories so i do not need to create them. naaah... c mon. I have no idea how to create exception handling in this script language, as the documentation is non-existant. But of course if I had that, I could at least try to catch the maximum files error and simply hardcore some directory rotation and predefine maybe 100 directories i jump through until i can save; Of course I would feel dirty at that point, having to fall back to programming techniques like this. (If anyone has an idea how to do that, pls tell me; I mean exception catching, not feeling dirty) There is no socket support whatsoever. By now, But Clipboard copy / paste. Maybe I should implement communication with the outside world over that? Holy crap, do I just really thought about using the clipboard for application communication? No DB Support exposed. I mean, after the problems Arma2-DayZ Servers had, because you could not use .so files like .dll files to write a db plugin, while most servers ran actually on linux, you would expect them to at least have that on windows. But no DayZ Standalone is even worse in this regard. I know there is database stuff used internally, as the player database is a sqlite db file. So maybe it is still under development. Please tell me it is under development. Because SQLite is not really something you would use in production. It is usually used as placeholder for a more dedicated db system, because it is really not performant, like at all; which probably also lead you to use file dumps for the saves. I am deeply disappointed at this point, how the technical stuff is handled. No mod loading on join, no linux servers, no database or at least socket communication, no documentation, and then silly restrictions on stuff like files in directory. Who decides to set a 500 file restriction in a game scripting api? What is that even for? Why? The Operation System itself will handle that! Or wait, was it just because you did not implement exception handling from the operation system side?
  9. g4borg

    Just another weather question

    I usually try to avoid 0.0 tbh with the weather script. but yes, in theory that would mean it, albeit, Set actually is supposed to set the current rain, and it very much depends whether the weather system itself reacts or not. maybe better to ask in that reddit post however.
  10. g4borg

    Stable Update 1.02

    I like the changes, and congratulate on a lot of fixes, and the introduction of the new car. I am a bit confused which xml has which line endings, and a bit displeased about stuff like 500 files per directory limits, or file size limits, while at the same time no proper database connection implemented yet. I really whish we could put that in postgres Also, I am still missing one decisive feature for my personal taste: to define a separate drive/folder for the mission folder; so we can have it on a different drive. I feel like you devs really need to catch up in development practices. Which is why I hope you actually have a good big sale to give you some breathing room Finally, I'd whish we could put the dayz scripts unpacked into a repository like git (I try that at home, to follow your changes in the commits), so we can easily read changes there, as sometimes it impacts the custom scripts. I would have opened mine read only, but I am unsure whether that's allowed. I know I see it from a technical perspective, but ultimately, it's for the greater good (tm).
  11. i don't follow your argument. you complain about it making lights obsolete, about super brightness, and so on, and think toning it down would not help make it better. okay... i understand, you want to know if you are visible or not, but truth be told, you would not be able to tell, because it depends on the others monitor, resolution, gamma, and how your movement affects you due to the background. so if i read you right, you actually bring up the argument, it could not be toned down, because you lose a personal advantage of telling how well you hide.which is fine, it's a valid argument. but i understand, why you therefore do not feel it can be toned. it's almost if you have two separate issues with the feature. on the flipside, dark vision is a real ability of humans. if you turn lights off, your eyes will slowly turn off the color vision, and ramp up your black-and-white vision, which is highly movement sensitive, and very sensitive to light, so you will start to see even in star-light. you probably know, if you ever spent time outside of the light smog of modern civilization. which is how i built my argument. it should be greyscale, mainly outside, need time for adjustment, etc. light sources will be rendered obsolete anyway as soon as there are NVGs, except the NVGs also shimmer green; with the current gameplay, nights are usually ignored, servers empty, and a light source is such a high risk, it is obsolete in any way. Let me expand my initial proposal then: The feature should be toned down, greyscale, adapt slowly, and be more prominent outside than in a building, also for reasons of balance. You should be able to disable the feature personally in the options if you so whish. Might even be a server side flag option for the hardcore. It might be even fair to only have this feature from first-person perspective. I also like the proposals about real moonlight, and maybe the ability to restore streetlights, albeit i would love that feature to be configurable. The original plan was to allow players to hook up a generator to restore lights in a particular town, I whish that back on the roadmap.
  12. they should just tone it further, so it becomes similar to natural human dark vision. it should be darker or even off in buildings. it should be greyscale. it should need a while to activate and be reset when you encounter a bright light and of course it should not illuminate things completely. perfectly fine however if they have a system like this.
  13. g4borg

    Stable Update 1.0150627

    if they go the DLC route, they can just as well stop working on the game right now, because that is not gonna fly with anybody, and it will literally kill their game. if anyone has plans like this, he or she is absolutely not suited for marketing and they should fire him or her, as that is the only extra revenue they can actually look forward to. the only thing i can imagine the majority of players would accept as DLC are new maps. there it actually would seem like a good idea.
  14. g4borg

    Player Stats Tracking

    i only saw playtime being updated for now you can read that from PlayerBase: float playtime = player.StatGet("playtime"); it's a float in seconds (so 900.0 is ~15 mins). i saw other stats, but they do not get updated as you say, and it is probably not worth it implementing this yourself. i use this variable to determine respawn loot on my server.
  15. I think it would be benefitial to decouple this in a separate CLI tool, instead of binding it into a fiddly-to-setup-editor Especially since the language is sparsely documented; I think it would also improve the quality and maturity of the development tools, if the editor is handled separately to the compiler, even if using the same core functionality. It should of course not end up in parallel development, like the worktools, where the GUI Version uses a different config file (and e.g. the CLI Tool, which is used to deflate the game files, does not really adhere to using the Workdrive configuration, and seems to use P:\ at all times, while the GUI Version has other functions missing, but theoretically allows you to set another drive letter)