Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Complaining about Update60

Discussion in 'Programming (In-game)' started by Lynnux, Nov 11, 2017.

Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.
  1. Lynnux Junior Engineer

    1, 6, 10, 60 and 100, please !;)
    • Like Like x 1
    • Funny Funny x 1
  2. Bleuhazenfurfle Apprentice Engineer

    I believe those intervals are hard-coded throughout the entire game, and presume they're just being picked up by the block if the appropriate interval is active. (Which is exactly what I was hoping they'd do ages ago… seemed silly it was right there, but not being used.)

    I'd much prefer 1, 8, 16, 64, and 256. I never learnt to count with my thumbs, you see … and whole seconds are so last millenia!

    • Funny Funny x 1
  3. rexxar Senior Engineer

    The system only supports 1/10/100
    • Agree Agree x 2
    • Like Like x 1
  4. Malware Master Engineer

    As rexxar says, this is tying into the general update system of the game engine itself, it's not specially made for the PB. Changing that just to give you the other options is... well, not a feasible option :p

    [edit: Damn this multiquote thing... Sorry for needless pings]
    • Agree Agree x 1
    • Funny Funny x 1
    • Informative Informative x 1
    • Friendly Friendly x 1
  5. Lynnux Junior Engineer

    Yes, and you can even run multiple PBs every tick and use that method to execute each PB at a different tick distributing CPU load, did you know ? :p
    6 and 60 would simply be practical. Obvious reason. ;)
  6. Malware Master Engineer

    Yes, the practicality is clear, but not worth potentially affecting the entire game ;)
  7. Lynnux Junior Engineer

    Yes, and you can even run multiple PBs every tick and use that method to execute each PB at a different tick distributing CPU load, did you know ? :p
    6 and 60 would simply be practical. Obvious reason. ;)[/QUOTE]
    Yes, the practicality is clear, but not worth potentially affecting the entire game ;)[/QUOTE]
    Yes, that's understood. I just wanted to get rid of some extra lines in the code, if possible ;)
  8. Pharap Apprentice Engineer

    I get that 60 is a common desired FPS (and what vsync often caps to), but I don't get why syncing a PB's updates to frame updates would be beneficial. Most modern game systems rely on delta timing and don't really care about the frame rate unless it's to do with something specific to rendering.
  9. Bleuhazenfurfle Apprentice Engineer

    My points were none the less quite serious; 1) that the choice of frequencies weren't arbitrary, they were in fact dastardly efficient. 2) that right after they add 6 and 60, someone will want 12, 120, 600, 1200, heck, lets just make it a slider. 3) choose the frequency that gives you the lowest acceptable resolution, and do the actual timing yourself (it's what the Timer block does, and what you'd be getting).

    I think you might be exaggerating a smidge there… they didn't mess up the entire game's timing when they added the Timer block, now, did they? That said, I have been somewhat curious for a while now, about the exact reasons for choosing 10 and 100… As far as arbitrary units go, choosing either powers of two (my favourite since, like, age 16), or a ratio to seconds (that 6 and 60 thing), both seem more practical — that said, there's the distribution of errors thing, less apparent interval collision thing perhaps, or is it just like an industry standards thing?

    Anyhow, the question is, leaving it to the scripters, or getting it done at the source? The lions share of that, however, probably isn't the potential gain of getting it added at the source over the bumblings of the scripters. That gain at it's best, most probably isn't worth the effort to actually do so — and if that does turn out to be a false assumption, then they can just add it in later. Plus, the people who'd be benefiting from it, are the same ones more than capable of just doing it themselves anyways. So personally, I'm more than delighted with the offering as it stands, and I'm quite happy to help slap around anyone who might lead Rexxar and co to feeling in the least part underappreciated… (Looking at you, Lynnux… :p )
  10. Malware Master Engineer

    May be, but all you need is a good IDE (like Visual Studio Community Edition which is free) and you'll see for yourself with intellisense, as "the new way" is simply proper interface properties rather than the horrible terminal properties.
    --- Automerge ---
    No, because the timer uses the very same update method (Update10 unless I misremember), and then does timing code in its own logic hit the correct spots. here's a reason there's extra overhead with using timers as opposed to this new method.

    Meaning, the timer didn't change this core system either.

    I'm not exaggerating at all. True, the risk is minimal, but there is a risk.
    • Agree Agree x 1
  11. Bleuhazenfurfle Apprentice Engineer

    …which was my point exactly. (Update10 has always been my guess.) Either way it's a long overdue feature, and good to finally see it implemented, and in a quite reasonable way, too.

    Going through a Timer block was way overhead — just as a simple guess; triggering the Timer block, doing it's internal timing logic, running the Actions list, each Action probably gets some measure of sanity checking, and whatever other invocation logic it involves, finally triggering the Programmable block, which does it's entry logic, runs the script, unwinds back to the Timer block, which continues with the Actions list, and then unwinds itself. Versus skipping the Timer block stuff entirely, and just doing the Programmable block part. Yeah, perhaps a little extra overhead there.

    btw, I'm not disagreeing with a single word you've said on the entire topic. That is, except for…


    if (! snazzy_divide6_setting || ++magic_div6_counter >= 6) {
    	magic_div6_counter = 0;
    Triggering code change done. (Well, perhaps some minor adjustments may be necessary…)

    No one would ever touch a keyboard, if they were worried about that level of risk. There's probably a bigger risk of one of the Keen developers spraining a finger, and the medical bill sending the whole company broke. That's still called an exaggeration in my book. :p
  12. Malware Master Engineer

    It's a weighing. The gain is not worth even this little risk, because any fault will affect the entire game. No, the risk itself isn't big, but any consequence of a failure will be huge since everything in the game uses this update component. So since it's nothing but a quality of life kind of deal, and it's so easy to work around yourself as a scripter, why take the risk at all?

    For all I know they will redo this weighing again and find it worth it. That's not the point. The point is this is perfectly prudent thinking. Call it exaggeration if you will. I have seen enough of the consequences of "Meh, I'll do just this little simple change", my own included, that I won't :)
    • Agree Agree x 1
    • Friendly Friendly x 1
  13. rexxar Senior Engineer

    Apart from the load balancer, the entire update system was implemented by me. I am not going to change it because it's too deep down in the system and would require changes to other game structures to support. The issue is vastly more complex than you realize.
    • Like Like x 1
  14. Bleuhazenfurfle Apprentice Engineer

    So you guys are seriously saying that the Space Engineers code is so fragile, that the entire game could be significantly broken by adding a divide-by-6 flag to the new mechanism in the Programmable block? Well, that explains a lot…

    btw Malware, that was a light-hearted friendly jab, and perhaps you guys were thinking I was saying the whole 1/10/100 thing should be changed to add 6 and 60, or something… I wasn't — I get why people reckon having multiples of a second by an option would be handy, but I'm sure anyone able to make use of the new functionality will be more than capable of doing it themselves within the script, anyhow.

    But now I'm kind of actually seriously worried about how much of a mess the SE code base must be, for my rather minor and not particularly serious enquiry to have generated such responses — not even my code is that fragile!
    Last edited: Nov 22, 2017
    • Disagree Disagree x 2
  15. Malware Master Engineer

    I am saying no such thing. I don't work for Keen. The state of SE's code base simply doesn't enter into it. I'm simply stating what is for me common sense as a programmer. If it wasn't so easy to deal with this on-demand in script I might have said differently.

    It's really simple. The risks in doing this change are small. But the gains of doing this change are deemed even smaller. So it won't get done.

    I am afraid I have a tendency to take certain things seriously, especially that which I care about. It's a character flaw. I know about it, but it's so fundamentally "me" that it's nothing I can do with it. I never realize until it's already done. My "status" if you will here in this community has also put me in a more-or-less permanent "teacher" mode, which sometimes make me come across as arrogant and/or patronizing, when all I really want is to pass on my experience.
    --- Automerge ---
    I'm also really starting to get annoyed by the fact that I can't edit my posts when I find blatant errors or poorly stated sentences...
    • Agree Agree x 1
  16. rexxar Senior Engineer

    That's not at all what I'm saying. I'm saying that as a rule, you do not touch systems at this low level without a damn good reason. Adding a 60 or 600 flag would be a minor change, and would probably not break anything, but the benefits to doing such a thing are not even worth considering.
  17. Pharap Apprentice Engineer

    That's not just space engineers code, that's true of all code.
    If you take a component as central to the system as that and suddenly change it the potential for breaking things is on the scale of how many things are depending on that code.

    Even with a 6/60 system it wouldn't be a proper second, there would be variances because the game updates don't take a constant time, each update varies in length. (The variance might be small, but even small errors can add up to noticable temporal drift.)
  18. Ronin1973 Master Engineer

    I think 1, 10, 100 is completely manageable. Our choices before were each tick or so via "trigger-now" loops or basic integers of time that match the clock on the wall; not the sim speed time relative to the game. (i.e. - at 0.5 sim speed, one second of game time goes by every two seconds of real-world time).

    I really like the idea of being able to vary the update speed without any complex management of external timer blocks. This will be helpful to keep scripts lean for grids that are just waiting for a stimulus to activate more complex behavior. You can have 20 drones hanging out waiting for a player conserving CPU power by only running checks every 100 ticks. It can approach the player at 10 ticks, and do things like compute a firing or intercept solution at 1 tick when in firing range.

    Throttling scripts means scripts that will play better. For us mere mortals it's not so huge. But for those who create some of the epic scripts in the workshop, this could be an absolute goldmine. I'm sure a lightbulb turned on in RDAV's head at this news. Managing a fleet of ships becomes less expensive as each ship can be throttled for the type of action it's performing. Example: moving to a new location might be every 10 or 100 ticks. Docking inside of a mothership might run at every tick.
    • Agree Agree x 3
  19. midspace Senior Engineer

    1, 10, 100 is a game mechanic. Lots of work to change. Which I would say, that will never happen.

    You want a trigger your code every 6th frame?
    Why don't you try the old fashioned way.
    Write a damn counter!
    Use the PB configured every 1 tick to increment.
    When it reaches six, reset the counter to zero and execute your logic.

    You don't like 6? Pick another number.
    • Late Late x 2
    • Agree Agree x 1
  20. Bleuhazenfurfle Apprentice Engineer

    Oh well. Close enough. Doesn't sound toooo much like you've been doing more beer drinking than actual programming, when you put it that way. :p It's all sweet, honest.

    And yes, a little distrust and prudence of implementing any changes is a good thing, but too much makes you less willing to belt it around with a hammer when it needs it — and SE most definitely still needs it, in my oppinion. And the way you guys were responding there, kinda sounded like you were falling to pieces at the thought of reserving another bit, and an extra line of code or three — and that would be the sign of a far more endemic problem. (Yes, I do know I'm probably under-exaggerating slightly, no need to correct me there — should be at least five lines with comments, or 15 in the Microsoft commenting style.) Besides, if you really mess it up, that's what version control is for. :D

    But nah, it's not a character flaw, at least, no more so than my allergy to people taking things, or themselves, all too seriously — especially that which I care about. But if you're going to go into teacher mode, just try not to go off half-cocked like midspace there, because you kind of end up looking more like you're just another parrot squawking out the company line, rather than someone with actual real experience to share. (Speaking of which, anyone who still thinks midspace's first line there has anything much to do with my last several posts — and I hope that doesn't include you two by now — needs to either go back and read them properly, or give up and move on to the next discussion.) And while it's awesome and reassuring to see the Keenian wage mages in here actually communicating with us, they don't really have the time to fully grok all the random chitterings of us forum monkeys, that's why we need the Malware's of the forum all the more, but, as I said to you a year or two back, we really need you — even more so because of your "status" — to try and do a little better in that regard; others (including the Keenians with their limited time) see your comments, use them to validate their own interpretations (or change/focus their uncertain interpretation — I've even caught myself almost falling into that trap once or twice), and it ends up being a bit of a sounding room with everyone patting each other on the back for being just as smart as you, and no one actually going back to check they're really on the right track, or even trying to move the track so they don't look like they're wrong in front of their peers — basically, good ol' mob mentality, and then once the mob has formed, anyone who does notice, doesn't want to be the first one to stand in its way. It's an easy thing to do, too, you skim a post, see keywords you recognise, respond like you've done so many times before, and move on without realising you've missed the point, and by the time you come back to it, there's several more voices validating your perspective, so you assume you must be right. I learnt all about this rather quickly about 20 years ago when I was running a social group of my own, and embarrassed myself once or twice by jumping on the wrong people, mostly because I didn't trust my instincts.

    And here, my instincts were saying you guys were reading more into what I was saying that you should have been, and compounding the issue with your talk of doom and gloom that would befall the game if you tried. There's another couple alternative rationalities that I get, too, but I gotta say the doom and gloom possibility, combined with SE really taking a very long time to get anywhere much at all, kind of felt like it might be the right interpretation for a bit there.

    I do think that's perhaps some of the confusion — with the specific change I was referring to, that would be a grand total of one thing depending on that code: the script in the Programmable block waiting to be triggered. To be clearererer, the bulk of the change I was talking about, would go inside the Update1/10/100 receiver of the Programmable block itself — the kind of change a modder would make in their own PB variant, nowhere else. Moving it further down might gain some further efficiency, and there are quite a number of blocks that would probably benefit from a far more flexible timing system (not to mention likely gaining higher accuracy at the same time), but that's something that comes if and when it appears important enough, and I'll be right with Malware, rexxar, and everyone else, saying that deep a change, would need to be very very necessary indeed.

    Well, yeah. rexxar (I think it was?) has already pointed out that Update10 can in reality be anything up to an Update19, and then there's been no clear explanation that I recall of how the time dilation affects this. If you want accuracy (or just the ability to chose which clock you're adhering to), you'll be going for Update1 and timing it yourself — the others are more for taking load off the game, spreading out of bulk activities, and the likes — but that comes at a cost to game performance, so you should take the 10/100 options if possible.

    Though I wouldn't expect there to be any temporal drift (can anyone confirm or deny that?) beyond what you'd expect from time dilation. Which brings up a point… Something that I don't recall seeing explained clearly, is whether that 60-ticks-per-second thing is locked to game-time, or wall-time. I'd assume it's game-time; I'd be inclined to think the 60 thing comes from monitor refresh sync — which is wall-time — and was then set free at some latter point, around about the introduction of time dilation. I've often wondered if that's not some of the confusion others have with regards to timing in the game, also.

    I quite agree. Not having a multiple of one second has potential benefits, too, like causing some jitter which could naturally spread things out a little — on the other hand, it also brings with it people who think they need more accurate timing than they do, turning it up a notch and counting back down again, often in the worst possible ways. It just caught my attention because I envision a whole lot of scripts starting off with a divide-by-6 — or worse, divide-by-60 — and struck me as something sufficiently common, especially among the wrong people, that perhaps it should have been tossed in to begin with. Not that I envision it to be that much of a big deal, either. But while we were on the topic anyway………

    Absolutely. As long as you don't get lazy and just register all three, ignoring the other two when they're not convenient — I'd suspect there's some small but non-zero cost to invoking the script, just to have it increment a counter and return again. And I view adding a divide-by-6 option as being similar to handing out bean-bag rounds to go with the gun, rather than the armour piercing bullets. Makes the nice bang you want, but won't hurt their feet quite so much. :p
  21. Pharap Apprentice Engineer

    As far as I can see the only benefit it would provide is shifting the maintenance/effort onto the Keen programmers instead of scripters. Frankly if something's going to go wrong I'd rather it were in the script than the programming block code since scripts are easier to fix - you can just edit them on the spot instead of waiting till thursday.

    I'm not a qualified scientist but programming experience has taught me that time is a pain in the ass.
    Not just wall time but also the accumulation of delta time - variable update lengths really mess with things and make accurate timing hard to do.

    (Recommended reading: falsehoods programmers believe about time and fix your timestep.)

    I'm assuming its game time and that game time has only a loose correlation to real-time - i.e. both flow forwards (but at different rates). Of course, time measured by a clock on a wall doesn't necessarily always go forwards, running programs at the crossover to/from daylight savings time is always a fun way to test just how crash-proof your code really is.

    (TL;DR: people should be asking for 'once per second' rather than 'every 60 ticks')

    60 is a probably a preferred number because of the monitor refresh rate thing, but modern monitors can have higher refresh rates than that, so despite popular opinion it would not necessarily be running once per second even if 60hz monitors actually refreshed exactly 60 times per second.
    On top of which, a programmable block update isn't necessarily in sync with frame updates. It's not unknown for games to run physics simulations more often than frame updates (e.g. 100 physics updates per second), and even then it's not going to have much impact on the appearance of the world.

    If people want accurate timing they should be asking for a 'once per second' option rather than worrying about frame updates or physics updates.

    Beyond attempting to make a clock I'm not really sure why people would need accurate timing anyway (except maybe for attempting to do physics calculation/integration, in which case they'd want to be matching game time and the way the game models physics rather than attempting real world physics).

    I admit though I don't know the ins and outs of how Space Engineers works in regards to timing.
    My comments here are about game design in general. For all I know Space Engineers could be running 60 physics updates per second and 60 frames per second and could be running all physics calculations completely accurately.
  22. Bleuhazenfurfle Apprentice Engineer

    …and yeah, Malware, talking about teacher mode. Told you I don't consider it a character flaw. There's a reason I like you. lol

    Yeah. The stupid part, is that 80% of that discussion was actually over Malware saying the game would fall down if they added the feature, not arguing that the feature was actually worth implementing. And it kind of went downhill from there. Aren't forums fun…?!?

    heh I love that first one. Bookmarked. I'm not particularly surprised by that list, as someone who does an uncomfortable amount of bit-banging custom or glitchily implemented wire protocols. But it's funny to read, none the less.

    And the other one seems pretty straight forward. Would have appreciated it 25 years ago when I was messing with 3D graphics and physics simulations, kinda old hat now. And while it explains why, it doesn't actually answer the question. I rather specifically included the words (which you omitted from the quote), "beyond what you'd expect from time dilation". I was rather hoping someone who actually knows, would chime in with any components known to not be accounted for.

    (I actually did read it, but didn't want to quote it.)

    Yeah… The mechanics I'm well aware of, the reason I keep saying I'm not a programmer, isn't because I can't program, but because I'm more of the proverbial jack of all trades, with my focus being on small-scale ųC's, where quite often every byte and even every clock tick is precious, and my education covering everything from the basics of how transistors work on silicon, right through to writing an RTOS (where timing is often one of the most important considerations). Along the way I think I've done a bit of just about everything. lol But anyhow…

    You and me both, there. But, people want what they think they want, and giving them a timing interval with what looks like 1 second resolution, without introducing an entirely new interface in the process, and practically for free to boot (well, I suppose, except for the play testing), seemed like a win-win to me. *shrugs*
  23. midspace Senior Engineer

    After reading the first few complaints and then seeing walls-of-text about changing the game, it tends to make my eyes glaze over at that point and I tend to give up reading the rest of the thread.
    No, I still didn't read the rest, since it's further digressed further from the subject.

    I don't have an answer why KeenSWH use 1,10 and 100 frame counts. All I know is, they have optimised the game around those update frequencies.
    Putting something into the ProgrammableBlock specifically to allow arbitrary frame execution may be possible ( I glanced at the code). Even though I'm a programmer, I'm not a game architect, or an expert on Space Engineers innards. Malware is way more knowledgeable in this area than I and would have a better idea.
    It may be possible. If no one has come back and said it can't be done, then at least take that as a possibility of it been looked into, and not outright disregarded... yet.
    But it's not all about if it can be done. A lot of the time, it simply comes down to time.
    The team that works on Space Engineers is small, and there are lots of features and bugs in development. Putting time into further changing how this works will take time out of other features that have been put on the back burner (Rexxar himself had a couple of things he was working on for instance that I know have been delayed, and then there are those teased about features like wheels/tracks, windmills). And having Keen staff spending time reading through dozens of offtopic conversations or thought bubbles is something I've heard countless times that they don't like to do.
    You might call it the "company line", but guess what. It's their game.
  24. Bleuhazenfurfle Apprentice Engineer

    No one forced you to join in, either — I generally won't join a conversation I'm not willing to read, for just that reason.

    And yeah, I'm pretty sure the subject has been discussed to death by now, or rather, something just a little off to the left of it has been. But it's all good. And though the topic has veered a little, I think it's still more on-topic than me teaching Malware better teaching techniques. As one of my teachers used to say: Those who can; do. Those who can't; teach. And those who can't teach; teach the teachers. Well I can but I don't want to, and I can't teach either, so… :p

    That much was plain from about 10 minutes looking at the MOD API, and I've done similar myself in programs… But I've seen 1/10/100 used elsewhere, and I'm mostly curious whether it's a practical, accidental, or historic choice.

    …though I'm still not sure he wasn't a little confused about where I was asking the change to be made, with all that carry on about low level changes breaking the game. But, meh, maybe there's something really weird in there they keep dancing around mentioning, that makes it more complicated than it should be. *shrugs*

    Oh, I agree totally — I read the news posts also — have not said otherwise, and the Keenian wage mages are more than welcome to their company line, I even understand a good many of the business and social reasons behind them — I've no gripe with them what so ever on this, only thanks for rexxar implementing what he did. My complaint, if there is one in here, is more-so when the company line comes from someone other than the company, and sounds more like a brush-off than an honest considered response — let alone when it's from someone whom I, too, have a great deal of respect for.
  25. Pharap Apprentice Engineer

    Depends on the forums.
    The Space Engineers forums often degrade into arguments and digressions unlike some of the other forums I visit.

    I think it's likely due to it being a gaming forum which by extension means a lot of people are overly passionate about their opinions and few have any idea about how the game works or the amount of work that goes on behind the scenes.

    (Not to mention a lot of people can't be bothered to file a bug report in the correct area and would rather camp the update thread to complain.)

    I wasn't sure what you meant by that.

    When it comes down to it, variable length updates are the crux of why it's difficult to have programmable blocks run at precise times. Having a programmable block run on every 'wall time' second doesn't do you much good if the physics system is running at 'game time' (which could be subject to very large levels of lag). And generally lost time can't be 'made up for' easily so the errors just accumulate.

    I have experience with both microcontrollers (Arduino and mbed stuff) and client-side software (games/UI stuff/command line stuff), and I'd say the two are very different beasts.

    For microcontrollers you're often more worried about making the most of what little RAM/Flash you have than whether your code is well designed, whereas for games and typical UI-based software you're more concerned about design, flexability, robustness and by extension the SOLID principles.

    No decision in software development is ever truly 'free'.
    It has to be put in a queue, scheduled, tested (not just play tested but also unit tested), documented, maintained etc.
    Especially in a company setting where developer time is precious.

    They've probably already got other things to be worrying about.
    (Besides which they have a proper platform for submitting suggestions so it's somewhat understandable that they wouldn't listen to random suggestions on a forum thread.)
  26. Bleuhazenfurfle Apprentice Engineer

    Wooot! We have our own thread now.

    heh Gamers do seem to be a remarkably passionate lot, don't they? Though I have to say, I really didn't see a whole lot of actual complaining; I think some people assume something like there's a list of when to trigger the script, with [1, 10, 100], and if you just add the 6, 60, 600, and whatever else into that list, it'll do those as well. The only ones who'd actually know that 1/10/100 is a game-wide thing, are the ones who've at least poked at the MOD API. So personally, I think I'm glad they're not all filing bug reports, because you know they'll each file their own, because the other 100 or so didn't quite emote it right, or something (as we already see over on the feedback side — they really need some mods to go through and merge/split the posts — I hit two suggestions just a couple apart asking for the same thing, at once point).

    Basically, I meant, without any regard what so ever to wall-time.

    Okay, so… From what I understand of rexxar's comments, the game tries to distribute an Update10's queue over a 10-tick block. If there's more than 10, it doubles up. More than 20, it tripples up. etc. If there's too many, there's simply not going to be enough time in the tick to run everything, and those ticks then overrun their allowed time.

    But here's the point; as I understand what was said, it will still complete all the tasks that are scheduled for a given tick — the result of having too many tasks in a tick, being time dilation. So, from your script perspective, so long as it's only reference frame is the game clock, it won't have noticed a thing, and it's next Update10 invocation will occur during the next 10-block just as it expects. It'll be totally oblivious to the fact that the Update10 is lagging behind wall-time, or those 10 ticks took longer than 1/6th of a wall-time second.

    So long as the game does everything that's expected to occur within a given game-time timeframe, before advancing the game-time counter past that point — which is what I expect, and the way I interpret those comments — then game-time wise there is no slippage, no overrun, and every tick takes a nice square integer unit of time. They haven't done anything weird that breaks that, have they?

    Okay, now 'dems fighting words!!! I don't think that has any impact on "well designed" what so ever. It's more, "differently designed" — the things you need to optimise for in your process, are different. Although, looking at the IoT devices proliferating the market these days, I think your view may not be uncommon. ;(

    I'd tend to put it the other way, designers of big computer software tend to be lazy, careless, and myoptic, requiring those SOLID principles and all the rest to stop them from ending up with nothing but a grotesque mess that never makes it off the ground, and then they sadly bring that same attitude with them into the ųC world. Admittedly, at least some of that is because the code base, and the team working on it, tends to be somewhat larger. But I do rather take offence at the suggestion ųC software by definition isn't well designed. That could be a matter of bias, though. heh

    And gawd how I wish Arduino was around 30-40 years ago… the fun I would have had as a kid with those kinds of toys at my disposal… Anyhow…

    Well, that's why I used the word "practically". :p

    Keeping in mind that this is adding a flag alongside one that's already there, not a whole new chunk of code with intricate deep changes, as seems was originally assumed. Even maintenance, the ever-present bugbear; I can't realistically imagine the maintenance cost of this change not being utterly dwarfed by the maintenance cost of the change it's being moulded into, so I don't personally consider it significant. But yes, there would be an additional cost, since the feature has already gone in, been tested, documented, and all the rest. Possibly an extra game sale or two? I know this, and would have much preferred to just discuss the pros and cons, without the immediate jump into woo-woo land that happened. In any case…

    I do kind of wonder, though, had we forum monkeys known what rexxar had planned, and been able to have this discussion then, before it was implemented, would it be in there now, or not?
  27. Pharap Apprentice Engineer

    There are many different types of gamer so it does vary, but in general yes.
    I think certainly the gamers who also do modding and scripting are a bit more patient and understanding.
    On the other end of the spectrum there are people who don't know how difficult programming can be who seem to think the developers are Matrix-style hackers who can wave a magic wand to make a new feature appear.

    Ironically the ones using the mod API are more likely to be able to make use of such a feature or even know if it's actually necessary.

    A little bit harsh, but somewhat true all the same.
    Bug report filing does require important skills like formality, discipline, politeness and the ability to know how to find a crash log and provide a decent explanation of what was going on when the crash happened.

    Yeah, I think that was used more than they were expecting so curation fell to the side.
    Also the fact things are marked as 'considered' but never 'rejected' means there's a lot of stuff floating around that looks like it could still get implemented when Keen have effectively said 'no'.

    That's roughly the idea that was in my head as well, though I had a bit extra in mind, like tracking how long scripts take in order to optimise queuing them (group long stuff with short stuff etc to try to balance it out and lessen the impact on the update rate - lots of slightly overrunning frames are considered better than lag spikes).

    Assuming they're counting how much game time has elapsed and are providing that to scripters rather than only providing wall clock time. Otherwise the scripter has no idea how much game time as elapsed.

    They might be, I don't know, I've never written any SE scripts/mods that are heavily time dependant.

    Remember "Hello Barbie"? That was a fun incident.
    It's not the only case of that either, there's lots of IoT stuff where the security has gone belly up.

    For design though, I'm mostly going by Arduino stuff.
    I've seen some quite well written libraries and then some libraries that were obviously written by a C person attempting to use C++ and in the process generating a horrible number of compiler warnings (the EEPROM library being infamous for that).

    mbed APIs tend to be better designed than that though.

    I half agree with that. It depends on how well someone understands the principles and design matters.
    Some people learn about SOLID and programming patterns and then preach them and throw them at everything without fully understanding what they're there for or what they're supposed to be solving.
    It's like giving someone a toolkit and they run off trying to hammer screws into a wall because they don't know what a screwdriver is for.

    On the other hand, when someone does understand design patterns and SOLID principles and knows how and when to use them they can create brilliant pieces of software.

    Of course software that's good from the front end isn't always good from the back-end, there's a lot of flailing ducks out there.

    I'm not saying it isn't well designed by definition, I'm saying that the lack of resources necessitates having to sometimes forgo clarity in favour of producing smaller/faster code. It also limits what techniques you can use, for example you have to be much more careful about using dynamic allocation and in some cases you might have to avoid things like virtual functions and exceptions.

    In some cases it's completely possible to have code for microcontrollers without having to forgo good design, but when resources start running out something has to give and often that's throwing out clarity in favour of code size/speed.

    Of course there's also the issue that the C++ idea of 'good design' is very different from the C idea of 'good design'. (Spoiler: I'm pro C++ and grumble intently at C.)

    I concur.
    (Although one or two decades would have been enough for me to catch it.)

    Probably not unless there was enough screaming for it, which seems unlikely since it seems to be mainly a small number of more casual/less well known scripters asking for it rather than the modding bigwigs. Demand dictates the benefit of supply after all.
    • Agree Agree x 1
  28. Lynnux Junior Engineer

    Heh ! My "request" was not to be taken seriously. Only if 6 and 60 could be added easily which I didn't knew at this moment and rexxar perfectly explained later that it isn't.
    So we can keep a few extra lines in the PB to achieve those timings, no big deal.

    Please calm down everyone, no need to fight about this.

    And this is not funny, too. Making it look like I've complained about something and created this thread, which I clearly didn't do ! Neither complaining, nor creating this thread. That was below the belt !
    Your post in the thread ModAPI and PB API changes Nov 2017 was moved to Complaining about Update60. Reason: offtopic discussion that took over the entire thread
    --- Automerge ---
    So please close this thread and delete it, thank you !
    • Agree Agree x 1
  29. Pharap Apprentice Engineer

    While I agree with this being split off into a separate thread I must admit the chosen name was a bit harsh.
    (No way of telling who moved it though since the icon is generic.)

    I think requesting a close requires using the report button.
Thread Status:
Not open for further replies.
This last post in this thread was made more than 31 days old.