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.

01.123 Patch Programming Changes?

Discussion in 'Programming (In-game)' started by Bullet_Force, Feb 25, 2016.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Malware Master Engineer

    Messages:
    9,625
    @thepackett The ingame scripts are injected into a class wrapper:

    Code:
    // a bunch of predefined usings
     
    public class Program: MyGridProgrram
    {
    // your script goes here
    }
    
    "using" is not allowed inside class declarations.
     
    • Informative Informative x 2
  2. Malware Master Engineer

    Messages:
    9,625
    @craigp I understand your frustration, obviously. However: It will break again, you should expect it to. To paraphrase you: do you have any idea how much work it would be to try to maintain an unchanging scripting API while the game changes around it? ;)

    I am actually lobbying for a change which will break every single script currently out there, but will finally make the programmable block perfectly sandboxed, allowing for more advanced features without exposing exploits, and lower the workload for Keen when adding new blocks.
     
    Last edited: Feb 27, 2016
    • Like Like x 4
    • Agree Agree x 2
  3. Loues S. Cat Apprentice Engineer

    Messages:
    143
    If would be nice if we could do something like, catch errors and exceptions and do something with them, so when a script fails due to an unmentioned change somewhere the resulting error can actually be announced in a way we dictate rather than only being indicated on the programmable blocks individually effected >.>
    Heck, setting the block to show on hud, or having some kind of in-world visible indicator on the programmable block saying, 'Hey! something went wrong >here<'
     
  4. Malware Master Engineer

    Messages:
    9,625
    Problem is though, most of the unmentioned changes cause compilation errors, not runtime errors.

    But some kind of visual cue would indeed be helpful.

    By the way, the reason try/catch doesn't work is once more due to the IL injection. Pretty much any and all deviation from standard C# behavior can be chalked up to the IL injection system. It is incredibly difficult to get right.
     
    Last edited: Feb 27, 2016
    • Informative Informative x 1
  5. craigp Trainee Engineer

    Messages:
    47
    If they could keep it to once a week, I'd be grateful. Twice in 20 hours is just miserable.

    Alternately, everyone should stop playing on Thursdays, so modders can wait until the hotfix to actually do any patching work.
     
  6. Malware Master Engineer

    Messages:
    9,625
    You already know they release a patch on Friday though. They always do. I.e. it's better to try stuff out on thursday, report what goes wrong, especially if it's whitelisting or namespacing issues, and then wait to see if the friday patch fixes the problem. Because that's what the friday patch is for :)

    People can live without playing for a day or two. If not - they really shouldn't be playing an early access game in the first place - especially not one that's still in its alpha phase.
     
  7. craigp Trainee Engineer

    Messages:
    47
    Well, I get complaints within an hour of the patch. Even though I say "let's wait until the hotpatch" every time, I never do.

    In regards to "alpha" or "early access", those words have no meaning. It's a program with a hundred thousand users.
     
  8. Malware Master Engineer

    Messages:
    9,625
    I'm sorry to disappoint you, but facts are facts, no opinion can change what is. The number of users are irrelevant. Things are what they are, Keen aren't magicians, they can do only what they can do. Doesn't matter how you feel about it. I'm sorry, like I said I sympathize, but this is simply something you have to accept because it won't - can't - change. It has nothing to do with Keen, it's simply the nature of software development at these stages.

    All they can do is try to avoid changes. During a refactoring phase which they have stated they're going through right now, it simply cannot be avoided. Can they get better? Probably. Everybody can. But things will slip through.
     
  9. craigp Trainee Engineer

    Messages:
    47
    Well, I don't want it to devolve into an argument, but as someone who develops networked devices for a living, I strongly disagree.

    That said, there's still more plusses than minuses. The game is pretty fun.
     
  10. Malware Master Engineer

    Messages:
    9,625
    As someone working as a professional software developer for many years, I disagree with your disagreement :p There are huge differences between project complexities.

    [Edit] but yes, I see your point, there's no use arguing. For one, none of us is going to change the mind of the other, secondly, like I said, it's not going to change no matter what the base reason is. So yes, let's just agree to disagree and stop here.
     
    Last edited: Feb 27, 2016
    • Friendly Friendly x 2
    • Like Like x 1
  11. 3vil_Luigi Apprentice Engineer

    Messages:
    191
    Is this still the internet? People here can actually argue in a civilized way and then agree to disagree? My faith in humanity just got restored, thank you guys
     
    • Funny Funny x 2
  12. Tylus Apprentice Engineer

    Messages:
    427
    I am sure this is just a temporary error in the matrix and gets corrected soon.

    But yeah. People especially here tent do discuss with very good manners instead of just hating/trolling and blaming each other... In my opinion it has something to do with two people who actually know their stuff instead of people who just pretend they know stuff to sound interesting to everyone else (Which seems to be the average person who uses the internet :)).

    To throw my hat in the ring... I can understand both sites, but I agree more with @LordDevious opinion. As long as the game is not final, I expect the API to change with every update. On one hand it will lead to more work for me to fix it, but on the other head it prevents me from getting bored and offers new ways for optimization :).

    Also I like two updates per week. The game is in early access and all people who bought the game know that. (Steam has a really really really huge information on top of the shop). Early access means it is of course not finished, everything can still be changed and of course bugs may happen. Additionally it means we, the community who already bought the game can ask for specific features to be added and of course test the game. So the biggest issues that come up on thrusday have a chance to be fixed on friday. That doesnt mean the devs are fixing every issue occuring, since not everything can be fixed within one day. Also it doesnt mean there cannot occur new bugs.

    To find all and every bug in the game, it requires a company to hire a whole lot of people to find them. This may be quite expensive, so its always a good idea to let the community help with testing. I would like to have an issue tracking software like jira for bug reports instead of a forum, since its more organized and can be managed better, but still as long as there is any way to report bugs it will be bettern then nothing.


    The game being in alpha state also means that at the moment the focus is on new features. Its not wise to optimize the game in the best way possible since the beginning of development. It would cause a huge overhead if you need to rip parts of the optimized code apart to add a new feature and optimize it again. Of course that doesnt mean to implement a whole bunch of trash and polish it later. The use of designpatterns and refacturing the code is still necessary, but stabilize the whole code is something which should be done in beta state, where normally less new features are introduced but many more performance optimizations and bugfixes happen.

    According to the roadmap posted a few weeks ago, the game should complete the feature set and enter beta this year. I am looking forward to it.
     
    • Agree Agree x 1
  13. mexmer Senior Engineer

    Messages:
    1,977
    using keyword is not allowed, you need to use class/interface name including it's name instead.
     
  14. Phoera Senior Engineer

    Messages:
    1,713
    yeah, that pain in ass, i looked once into this...don't wanna do it again ><.
    also don't forget that IlCounter also throws exception.

    also, because of try/catch/finally also foreach not works sometimes, as sometimes it generate code with finally.
     
  15. Malware Master Engineer

    Messages:
    9,625
    Yes, the ILCounter throws an exception but that's not affected by the problem. Only the code in the script is affected by that. Any other exception works as expected.
     
  16. Cuber Apprentice Engineer

    Messages:
    262
    Doesn't this work anymore?

    Code:
    void Main()
    {
    	Toaster.ActualProgram.Start();
    }
    }
     
    namespace Toaster
    {
    	using System.Linq;
    	
    	public static class ActualProgram
    	{
    		public static void Start()
    		{
    			
    		}
    	}
     
  17. Malware Master Engineer

    Messages:
    9,625
    @Cuber That should work, because it's not within a class. Haven't tried though. In theory you shouldn't need the namespace either...

    Darn it. Now I have to try it :p
     
  18. Cuber Apprentice Engineer

    Messages:
    262
    `using` statements have to be at the top, so it won't work without the namespace :0)
     
  19. Malware Master Engineer

    Messages:
    9,625
    You're right. It hasn't stopped working though.

    Well, it doesn't have to be at the top, just before any non-namespace declarations.
     
  20. mexmer Senior Engineer

    Messages:
    1,977
    wait, since when was using allowed in pb scripts?
    when i started with PB it was not allowed, so i didn't bother to try it later tbh.
     
  21. Malware Master Engineer

    Messages:
    9,625
    This technique has been possible for as long as the extension classes has been possible. There was never any restriction on it other than the restrictions of C# itself. You obviously can't use it in a traditional script, you need to what @Cuber did - which limits its usefulness.
     
  22. StuffYouFear Apprentice Engineer

    Messages:
    416
    LordDevious, has anyone ever thanked you for everything you've done to help us?
    Just wanted to say thanks. I dont talk much in this section but I do read it quite alot as I stumble though the code, and your efforts are not unnoticed.
     
    • Agree Agree x 4
  23. Malware Master Engineer

    Messages:
    9,625
    It's my pleasure to help if I can, but it's nice it's appreciated :)
     
  24. gothosan Junior Engineer

    Messages:
    723
    isnt it simply possible to use a pb to turn a light block on and off so it could give an indication to if the script actually is running?
    I know lights have the blink offset but if you use the on off method should the script crash the light will not blink.
     
    • Agree Agree x 1
  25. noxLP Junior Engineer

    Messages:
    729
    It's perfectly possible, along with using LCDs to write "debugging messages", but it's a HUGE pain in the ass to debug a script that way, at least for me. Simply you can not see what's happening with the blocks AND with the script, the only thing you can do is to place LCDs (and control panels combined with menu transparency thanks to LordDevious's Echo method, which was a huge help) all around so you can view all LCDs and blocks, to have something like a global perspective, which add one more new thing to do besides building and scripting: prepare a set of LCDs and control panels all around the site for debugging.
    Is that or losing a lot of time running from blocks to PB and viceversa, trying to adequate your angle so you can see the blocks while in the menu with total transparency, and so on.

    Honestly, a simple "SendChatMessageToPlayer" method will be just glorious. I hate to debug scripts in this game.
     
  26. Malware Master Engineer

    Messages:
    9,625
    I doubt a SendChatMessageToPlayer will be accepted, because the PB is supposed to follow the rules of the game - i. e. it would need to check for the existence of an owned, powered antenna set to transmit.

    Well... we could do that, if we also restricted how many messaged can be queued up so it don't throttle the game...

    How about the script output being put into a separate scrollable window rather than the small detail area? This would allow for more echo output and lessen the echo's effect on online games, since the detailinfo wouldn't need to be synchronized so often. It would only be synchronized on demand.
     
  27. mexmer Senior Engineer

    Messages:
    1,977
    tbh. i use large LCD as debug info storage and to display it.
    hence, why my station has computer room, dedicated to testing scripts ;o)
     
  28. Malware Master Engineer

    Messages:
    9,625
    This is not always practical though.
     
  29. Malware Master Engineer

    Messages:
    9,625
  30. noxLP Junior Engineer

    Messages:
    729
Thread Status:
This last post in this thread was made more than 31 days old.