Can UPBGE show stuff pulled off a server?

I posted this question elsewhere - Can it show stuff pulled off of a server? Suppose I have a cube, and when it’s clicked, I want some text to be displayed, which will be pulled off a server - eg. onclick, run , if that script returns “HELLO”, then display “HELLO” in 3D text (or maybe 2D, ie. with zero extrusion or something, as a texture map). Is this possible? How do I do this?

Thanks for all your help.

you need configParser for it, you can post and get stuff from a webpage.
i got a pinball machine in my resources, you can open that file and look how i have done it there.

1 Like

Ah OK, I’m new to UPBGE, I have no idea what “configParser” is, but I’ll check it out. Thanks! :slight_smile: (where can I get documentation on it??)

Thats easy to do. Python 3 comes with the requests library which can be used to GET, POST, etc other functions for website stuff. If you write a php script that you put onto your server, you can call that script and code it to output a certain response to you.


Oops sorry i was wrong with my answer, configParser is very usefull to read/write data to/from .ini files

@Nicholas_A is right

import requests

is the module you need, if you download my files then you find it near the bottom of

def send_data_to_website(cont): #send
def monitor(cont): #read
1 Like

Be aware that tcp has significant latency. I believe there is a tutorial regarding asyncio on the official UpBge wiki. I would also like to mention that LibLoad can take binary data instead of a path. I haven’t actually tried this, but it should be possible to download a .blend file over the Internet and directly LibLoad it.

No, it really doesn’t.

Seconded; his solution sounds ideal for the OP’s situation.


Not all of us have good internet connections you know . . . :wink:

Requests will block game logic for about 30-600 ms. This will create a noticeable stutter. It is not necessarily a problem. I thought I would mention that people have been trying to address the issue, just in case any readers ended up suffering from it. If you are using requests and your game is briefly unresponsive every time a packet is sent, check the official wiki for information about asyncio.

To add another topic of discussion to the chat: using a UDP socket to transfer data is practically instant and the performance drop is negligible. Also threading can be used with anything to separate processes from the BGE loop

1 Like

Well, crap. And here I was appending callables to scene pre_draw.
Time to raid the standard library for answers!


threading is one of the my favorite libraries. The one drawback is that it can’t return data back to the main thread when its done without stopping the main thread to wait for a response. But it’s really useful in BGE to speed things up. Just be careful that processes happening on shared objects can still slow down the main thread since the object is being shared by both threads.

Singling out TCP implied to me it was a criticism of TCP, rather than the Internet connection. You’re right; a slow Internet connection will make it slow to load, for everything.

Using sendAll() will block the thread until it’s finished sending everything. Then, receive() will also block until the data comes in. That’s likely to be what’s causing your stutter, since your game logic uses the same thread. There are two ways around that:

  1. Use a different thread for your network traffic.
  2. Or, turn off blocking. You’ll interact with it a lot more like UDP, but still with the reliability.

The actual “speed” of UDP is basically the same as TCP, unless there is significant packet loss. UDP is great for things like position updates, where you simply want the latest information and don’t care if some of the packets get lost on the way. TCP is great for data that needs to get there, such as updates to kill counts or item changes, but accept that sometimes the data might take a bit longer if the packets are dropping.

Sure it can. Write a class that manages your network traffic and has a thread. That thread saves completed messages in a dictionary or list or something… then, in BGE, poll your class occasionally to see if it’s got any new messages, and act on it.

It shouldn’t… that suggests to me that you’re not using a different thread for your network IO. If your computation is CPU-heavy then no amount of threads will make that quicker (read up on the Global Interpreter Lock to understand why). But with disk or network input/output, threading will give you huge performance increases since you don’t have to wait for the input or output to finish.

I’ll try to dedicate some time this weekend to either uploading my partially complete TCP game, or a minimal example of how to do TCP network stuff with threading.

Well polling the class isnt exactly the same as a return statement

And im not talking about network stuff in the second part. Like if a game object is being modeified by the thread or direct changes are made to the game in a thread, it still slows down the game

What do you mean? A class doesn’t return; a function on it does.

Fair enough, I have never tried changing anything in the game engine from a thread. I think I heard somewhere that it breaks things.

You can thread a regular function like you do a class. If that function being threaded has a return statements data being returned from it just disappears because the main thread has moved on from there.

Edit: I did some further prototyping that suggests this wont work with requests, but I do not really know. Be careful about prototyping! No matter how much you test, it still might not work in an actual game. Sorry. :grimacing:

Tcp requires a round trip for acknowledgments so it can be considerably slower relatively. I did not mean to be comparing tcp and udp tho. I was referring to some thing that is very particularly and possibly exclusively a Bge issue. If you run two scrips in the same tic, then the second script will not run until the first script closes. When a python module is told to not block, it will allow the script to continue, but will not allow the script to close. This means that even tho the script is not blocked, game logic will still be blocked.

This is the closest thing I have been able to find that seems to work. Its based on this tutorial. Notice the last line event_loop.run_until_complete(sleep(0)) is different then in the tutorial. I have not yet tried it in an actual game.

import bge

if 'frameTime' in bge.logic.globalDict:
    bge.logic.globalDict['frameTime'] += 1
    bge.logic.globalDict['frameTime'] = 0
print('\n-'+str(bge.logic.globalDict['frameTime'])+': tick-')

from asyncio import get_event_loop, sleep
from random import randint

event_loop = get_event_loop()

async def longTask(taskId, secs):
    print(str(taskId)+': sleep for '+str(secs)+' secondes.')
    message = await sleep(secs)
    print(str(taskId)+': slept for '+str(secs)+' secondes.')

event_loop.create_task( longTask(bge.logic.globalDict['frameTime'], randint(1,10)) )


Networking in the Bge has been a continuing problem. I would likely read your code even if it is incomplete or dose not work. Consider making a page for it on the Comunity Wiki. That way it wont get buried under other posts.

Just finished creating the thread:

The game is being made in BGE, so I don’t think it would be appropriate for me to make a WIKI page about it.

I tried asyncio too, but ran into the same problems that you’re experiencing now. I gave up and ended up sticking with older ways to do threading.