Print

Liero v1.0 – 100lt
IP: 91.156.42.210
Game Mode: Death Match
Lives: 5
Max Kills: 20
Version: OpenLieroX 0.58 rc3

Players:

Cruel v0.96 – 50lt
IP: 69.255.183.244
Game Mode: Death Match
Lives: 5
Max Kills: 0
Version: OpenLieroX 0.58 rc3

Players:
iRod(0 lives, 0 kills)
[CPU]I'm Not A Human(5 lives, 0 kills)
[CPU]I'm Not A Human(5 lives, 0 kills)

Liero v1.0 – 100lt
IP: 37.205.11.54
Game Mode: Death Match
Lives: 7
Max Kills: 15
Version: OpenLieroX 0.58 rc3

Players:

[pelya]

I know Python firmly (learned it in like 2 weeks when came to current job, that's easy if you know any other programming language).

And our ded script is anything but "even more simple" because we're using some nice things like exec(string) in usercommands, function pointers in ranking, and totally crazy IO stuff in io module.
Though rough places are with comments inside the code (sometimes).

It should be easy by adding more user commands, or more presets, by simple copypasting.
I was thinking of implementing some more advanced gamemodes with ded server scripts, like Assault from UT, because it will be map and mod-specific and will do lot of stuff unsuitable for putting into core engines. If you're up to something, ask us, and we'll add some advanced possibilities to ded script, such as killing a worm or specifying where worm or bonus should respawn, or controlling score table.

[Gaston]

But anyway, Python is not very hard and the way we coded the ded script is even more simple because none of us (afaik) doesn't really know Python.

Like Pelya said, while most of it is understandable, there are quite a few lines that are fairly advanced.

Pelya: Why would you apply functions like that to the python scripts as opposed to the C(++?) code? Are they more effective?, or is it because they're more intuitive? I take it that it isn't because most users will mess with the scripts

[albert]

I am not exactly sure what code snippets you are refering to. Can you give some examples?

And anyway, even when not understanding every single line in every possible detail, I think it's still not really a problem to add/change things in these scripts.

Or who of you got what problems exactly when trying to do that? Where did you got stuck when trying to mess around with the scripts?

[pelya]

I was talking about writing an advanced game setting, dependent on specific map/mod, like - spawn blue team on the map here, red team on the map there, and tell one team capture some bonus, and another to prevent it etc, where all the map and all coordinates are predefind in the script.
We wont' include any predefined values into C++ (like, play Hide and Seek only on those 3 maps from the list), this should be done in Python script because it's (somewhat) user-editable, whereas yon can't edit .EXE to add your pro leet gamemode.

Well, then it sohuld be made available for non-dedicated server too.

[albert]

Yea but that aren't really the current issues of the ded script.

More important for example are such things that it automatically starts the game (it does not do that for some reasons in some cases), that map rotation works ok, voting system needs improvements, people should be able to vote for skip map, perhaps ded script should also be more intelligent in choosing the next map, for example not too big map if there are only less people, and so on. Also voting for CTF, H&S, TDM or whatever. Or just whatever you think is more important for a good dedicated server.

All that should be possible with just the basics.

[Gaston]

I am not exactly sure what code snippets you are refering to. Can you give some examples?

Apparantly, I was mistaken with what I said. The variable and string manipulation is fairly easy to understand in itself.

but when I glimpsed through the script, an awfull lot of importing and use of different functions isn't commented properly in the scripts. Also, quite a bit of the structure is weird. Why are variables defined as global all the time? Wouldn't it be easier to just use the return statement?

From the scripts I looked through, although, it's possible to read the code line by line, but the general structure is pretty hard to understand. I don't mean any offence to Pelya (the scripts seems to have gone through quite a bit of trying and failing, and are probably pretty solid), but to someone not already familiair with the scripts, it's pretty hard to understand the general purpose and structure, much because the commenting and structure seems to be, well, sporadic... :\

But yeah, I was wrong when I said some of the code was too advanced to understand, as I've made programs that seems to be not much below the level of the scripts. But I need to get a clearer picture of how they actually work overall, to be able to go through the scripts, and bugtest them and possibly add features.

[albert]

Don't hesitate too much with critism, the scripts are indeed not that clear.

The main intention while writing this was also to keep it simple for the writer, not really for the reader.

Also, about the variables: There is a bit the problem that some variables are defined by the script (mostly by the config script, which is in cfg/dedicated_config.py or something like that), some are hardcoded and some are read by the ingame variables of OLX. Well, this can be improved a lot, but cannot be avoided completly because the dedicated scripts of course give some further functionality over OLX, so they also need some further configurations.

The very rough structure is:

- There is the config part (I think always imported as cfg), from the file cfg/dedicated_config.py.
- There is the io part, which is an easy wrapper to do the actual stuff in OLX, or request some information from OLX. I think this code is also not really hard to understand but you even don't need to understand all that to do most things.
- Then there is the handler part. This is the main part of interest for you because it does all/most of the logic. It is indeed a bit chaotic in here.
- There is the initial starter script, the file dedicated_control. This is the script which is started by OLX. You don't really have to touch that, it basically just calls the handler stuff.


Btw., if you have an idea of a better structure, just make a suggestion.

[Gaston]

I got a few ideas yes. But it would be easier for me to just make the scripts from the bottom up to get a good structure on it. But for me to do that, I would need some documentation on what I can retrieve from OLX, and where from, as well as how I need to format the output file(s), and then I could just use the scripts already made, as a rough guideline from there. Do we have any documentation of the things I need?

[albert]

See here for further information about how to write an own dedicated script:
http://www.openlierox.net/wiki/index.php/Dedicated_script

[Gaston]

OK, so if I get this straight, whenever I print something in the command box with the python script, it will automatically be written to stdin, and OLX will read the file continiously to check for valid commands?

[albert]

when you do a print, it writes that to stdout but you wont see that because olx reads it

[Gaston]

ok, thanks. I think I got everything I need to know to try writing scripts in python.

[albert]

Btw., I created an entry in our wiki about it (mostly just copied my last post):

http://www.openlierox.net/wiki/index.php/Dedicated_script

Extend it yourself or ask here if anything is unclear.

[pelya]

Forgot to tell: all current user commands should work now, also !start and !stop usercommands added, do "git pull" plz.

[Gaston]

One thing. Python (like all other programs) handles the "\t" within the programming structure in a not so good way (annotation errors come flying the moment I edit the code using spaces, so it would be cool if when you guys modified the scripts, that you made them more universally editable (\t is interpreted differently in many programs and editors), by either fixing your programming editor, or by using a small little script to fix it. Here's one I just wrote up to fix that problem that should do the trick:

Code: [Select]

from string import *
import os

def tabremover(string):
    newstring = []
    string = split(string , " ")
    for i in string:
        i = replace(i , "\t" , " " * 4)
        newstring.append(i)
    newstring = join(newstring , " ")
    return newstring

def main():
    filename = "dedicated_control_functions.py"
    temp_name = filename[:-3] + "_temp.py"
    in_file = open(filename , "r")
    temp_file = open(temp_name, "w")
    for line in in_file:
        new_line = tabremover(line)
        temp_file.write(new_line)
    in_file.close()
    temp_file.close()
    temp_file = open(temp_name , "r")
    out_file = open(filename , "w")
    for line in temp_file:
        out_file.write(line)
    temp_file.close()
    out_file.close()
    os.remove(temp_name)
main()
just change the filename, and repeat for all files (or do it all in one loop with a list of filenames...)

[albert]

Please, no spaces. Tabs is the universal standard and we just use it everywhere (or at least try to). Also there aren't any problems if everything is tabs. Normally even not when mixed, I wonder about why it makes trouble for you.

But anyway, if you found any place where we mistakenly have used spaces, please just fix that to tabs.

Edit: I wonder also why you prefer spaces. Is there any reason? Tabs give you much more possibilities. I.e. some of us prefer the indentation size of 8 chars, some of 4 chars, some of 3 chars or whatever - and everybody can just use what he prefers.

Edit2: Many editors also have functions for autoindentication in case you have messed something up.

[Gaston]

Please, no spaces. Tabs is the universal standard and we just use it everywhere (or at least try to). Also there aren't any problems if everything is tabs. Normally even not when mixed, I wonder about why it makes trouble for you.

But anyway, if you found any place where we mistakenly have used spaces, please just fix that to tabs.

Edit: I wonder also why you prefer spaces. Is there any reason? Tabs give you much more possibilities. I.e. some of us prefer the indentation size of 8 chars, some of 4 chars, some of 3 chars or whatever - and everybody can just use what he prefers.

Edit2: Many editors also have functions for autoindentication in case you have messed something up.

alright, I'll just convert my spacing to tabs, when I share my scripts.

the indentation is easy to fix, using simple scripts (like the one above), and spaces are sooooo much more flexible when editing scripts. Especially in python where indentation is key to everything. It makes it much more practical to keep the code readable when splitting a line that is technically one line into several lines. unicode tabs are easier to set to personal preference, but spaces are much more flexible in editing, and are easy to fix to personal preference.

And, I'm pretty sure that in Python, spaces (as well as 79 chars max per line) are the standard. There's a reason Idle autmatically use spaces when you edit a script there.

Also, there's this: http://www.python.org/dev/peps/pep-0008/

EDIT: Oh, and while I haven't programmed for too long, I'm not completely lost, if I mess up the code, I'll manage to fix it

[albert]

Most editors I know use tabs by default. And also most C++ code or other code I have seen in the wild prefer tabs over spaces. I hate it when I open some source and the editor have used 8 spaces instead of a tab; or sometimes also 2 spaces, I have also seen 3 spaces and 5 spaces. All different from what I prefer: 4 spaces.

I actually don't even know what the other devs prefer. It never has mattered because we uses tabs in the whole OLX code for indentation.

I didn't know that the Python project officially recommends spaces. And I also don't really agree with that recommendation (mostly for the reasons given above). Up to know, we really didn't had any problems using tabs and I also don't see any case where it could lead to problems (unless somebody mixes them in a wrong way with spaces somewhere). On the other side, I really see my given reasons as a huge advantage.

Also, you have the same flexibility with tabs. You probably mean such case ('S' = space, 'T' = tab):

Code: [Select]

def foo():
SSSSa = [
SSSSSSSSS1,
SSSSSSSSS2,
SSSSSSSSS3
SSSSSSSSS]

The way I would to do that normally:

Code: [Select]

def foo():
Ta = [
TT1,
TT2,
TT3
TT]

But you even can get the same flexibility, by doing this:

Code: [Select]

def foo():
Ta = [
TSSSSS1,
TSSSSS2,
TSSSSS3
TSSSSS]

In fact, I know some editors which does exactly that automatically.

Well but anyway, I think all this is a bit off-topic and not really that important here.

How is your progress with the ded script? Got something working? I hope my explanations how you communicate with OLX were mostly clear.

Btw., some further notes on the ded script system which might be interesting for you:

In the past, our ded scripts looked very ugly/complicated because we wanted to have some handler in the background which does something after a while. We did that by another Python thread and a lot of hacks here and there to make it more or less working (and it was all the time buggy).

We solved that in a way that it should never be needed to have a background thread in your script. Your script, after it has done something, should send "nextsignal\n" and wait just for the next signal - doing nothing else. So, to get the same functionallity, we introduced a timer. You will get a default timer signal each second. I.e. that means that OLX wakes up the ded script every second. You can just ignore these signals and just wait for the next "backtolobby" or whatever - or you can do actually some further checks, perhaps you have internal timeouts in your script for something or so.

I also thought of giving some more possibilities here: For example create own timers with different time values, or just countdown-timers which will send a signal after time X, also start/stop timers, and such stuff. But that was not added yet as there was no urgent need for it.

Also, you may need some further signals about some stuff. If so, just say that, it's not really a problem to add a signal for something. The current workaround would be to just check it somehow manually after each timer signal. You can get a lot of information via all the functions. If you miss some functionality, also just say that.

[Gaston]

About the flexibility: The flexibility you get in your TSSS example, could be fatal, since it ends up mixing tabs and spaces. You'll have to stick to one, or it'll just mess everything up in the end.

About the scripts: I have tried some stuff out, but one thing that really bugs me, is the usage of threading when getting signals from stdin. Mostly because I'm not comfortable with the functionality of threading. Are you using threading because it's memory effecient compared to using for example a continious while loop reading stdin?

I ask this, because I want to build my own script from the bottom up, reading from stdin and printing commands, which would include the functionality the ones that have been written already do. Other than that, the code is pretty understandable, but adding stuff to it, will just make it more messy.

EDIT:

I was thinking of a structure (details hidden) with a top-down and object oriented appraoch:

Code: [Select]

from olx_ioscript import std_indetify

def main():

    #Boolean to check if while loop should be quit
    olx_error = False
    olx_quit = False
    while not olx_quit:
        line = stdinread()

        #std_identify is a class
        line_check = std_identify(line)
        olx_quit = line_check.QuitCheck()
        olx_error = line_check.ErrorCheck()
        if olx_error:
            raise line_check.TypeError()
        if not olx_quit:
            if line_check != "":
                print line_check
main()

[albert]

OT: About the space/tab mixing: The spaces are not used for identation there, only for the adjustment of getting some parameters or whatever to the right pos. The tabs are always used for identation. Some editors make it automatically like this and it is also consequent. Whereby I anyway prefer the other way with tabs I described.

Anyway: Not sure what you mean with the usage of threading. Probably was I explained in my last post was unclear. We explicitly did a lot that threading in your script should not be needed at all.

Or why do you think you must use threads? Or why do you want to use threads?

Btw., I would not make the reading from stdin seperated (in your case in the beginning of the loop) from the writing to stdout (at the end of your loop). They always should be together. You write some command to stdout and you should wait for all return values (":retval...\n") and the command completion (".\n"). And then you can continue.

See my sample code here, esp at SendCommand:
http://www.openlierox.net/wiki/index.php/Dedicated_script

With that sample functions, your main loop could look like:

Code: [Select]

while True:
    # do stuff
    # ...
    # wait for next signal:
    signal = SendCommand("nextsignal")
    # handle signal somehow ...

Btw., perhaps that was unclear: You only get the next signal when you call "nextsignal". In other case, when you just read from stdin without having send a specific command, you wont get anything. And when having send another command, you would get the return only to that command, not any signals. That is why you always must explicitly call "nextsignal" when you want to idle.

Edit: To adopt your sample code a bit to the usage of SendCommand: You probably meant this:

Code: [Select]

from olx_ioscript import std_indetify

def main():

    #Boolean to check if while loop should be quit
    olx_error = False
    olx_quit = False
    while not olx_quit:
        ret = SendCommand("nextsignal")

        # std_identify is a class
        # ret is a list of values
        line_check = std_identify(ret)
        olx_quit = line_check.QuitCheck()
        olx_error = line_check.ErrorCheck()
        if olx_error:
            raise line_check.TypeError()
        if not olx_quit:
            # check line_check
            # do other stuff
main()
Edit2: It may be handy to print out some debug messages for yourself. You cannot use print for that case of course because those prints wont go to the screen/console but to OLX and OLX tries to read them as commands.

But there is a special OLX command where you can print a message. For example, you can use:

Code: [Select]

SendCommand("msg my debug msg, ret was %s" % repr(ret) )
This will print out something like:

my debug msg, ret was ['backtolobby']