◢███◤      ◢██◤                            ◢██◤                            
     ◢██◤       ◢██◤                            ◢██◤                             
    ◢██◤       ◢██◤                            ◢██◤                              
   ◢██◤       ◢██◤                            ◢██◤                               
  ◢██◤       ◢██◤                            ◢██◤                                
◢███◤       ◢██◤                            ◢██◤                          ◥██◣   
◥███       ◢█████◣    ◢████████◤ ◢███████◤ ◢██◤ ◢██◤                 ◢██◤   ██◣  
 ███      ◢███████◣        ◢██◤ ◢██◤ ◢██◤ ◢███████◤                 ◢██◤    ███  
 ███     ◢██◤  ◢██◤ ◢████████◤ ◢██◤      ◢█████◣                   ◢██◤     ███  
 ███    ◢██◤  ◢██◤ ◢██◤  ███◤ ◢██◤ ◢██◤ ◢██◤◥███◣                 ◢██◤      ███  
 ◥██   ◢██◤  ◢██◤ ◢████████◤ ◢███████◤ ◢██◤  ◥███◣               ◢██◤       ███◣ 
  ◥██◣                                                          ◢██◤       ◢███◤ 
                                 ◢███◤ ◢███◤ ◢██◤  ◢██◤ ◢█████████◤       ◢██◤   
                                ◢█████████◤ ◢██◤  ◢██◤ ◢██◤  ████◤       ◢██◤    
                               ◢██◤◢█◤◢██◤ ◢██◤  ◢██◤ ◢██◤   ███◤       ◢██◤     
                              ◢██◤   ◢██◤ ◢████████◤ ◢█████████◤       ◢██◤      
                             ◢██◤   ◢██◤ ◢████████◤ ◢█████████◤      ◢███◤       

0001
[REQUEST] A HCF (Halt and Catch Fire) instruction to be used in scripts
qg5fsq
I am writing to request then addition of an instruction (Such as #HCF) that can be called in a scriptor order to stop the execution of the main script. For example, imagine I were running bladewolf.notes (NOTE: THIS IS A NULLSEC SCRIPT!) and wished to have an underlying script #s.bladewolf.user_check. If I were running the script, it would run as normal, else the underlying script would terminate the outer script. Would it be possible to implement a feature such as this? -Jamie Ridding (Student, South Staffordshire College) (bladewolf and diag in-game) (Zuris#4495 on Discord)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wouldn't this cause an issue with scripts running themselves?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I've considered this, and I've got a plan to improve overall stability as well as provide this functionality to players.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
With an error, the wrapping script can catch and ignore the error. The idea here is that you could make a script that basically asserts that certain things are true -- for example, that dtr.man is still fullsec -- and people can include it in their script. If the assert fails, it hard-kills the entire execution to prevent anything bad from happening. That can be simulated by returning boolean and then all callers have to check true/false, and even then a caller might itself be wrapped.  Basically, it's a way to do a runtime assertion without caring how you were called. As noted, we already can by just going to while(true) ;, but that is quite rough on the server
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does returning an error value from the underlying script not work for this purpose? Being able to nest complete execution termination in any script (understanding that this can be quite malicious) will take some time to balance out properly.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Seconded. One of the alternatives that's being discussed is a hot busy-loop until the process is killed by timeout, so having a clean, low-resource way to HCF would be useful.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This would still be a good idea (but also this post is 99.9% to see wtf happens with ordering, sorry)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -