Maps [for the lack of a better word]

[philippeqc]

philippeqc: I didn't get your idea of differencing arena:// and http://. What are you thinking when you say arena://??

I thought something like

arena://shape<(x1,y1),(x2,y2),(x3,y3)>spawn<(x4,y4),(x5,y5)>

You mentionned to just pass the description inside that string element. So I though, you only need to add a prefix to say its an arena, not a url.

Nota: Adapt with your own map format. I made one up on the fly.

Now I've done HTTP Fetcher work without installing any libraries. We could use it inside AA without installing any 3rd party library. I've tried in AA and it downloads an http file inside AA .

I bow in front of you, master coder!

Now some more doubts:

When you enter a server it will connect to a http url to download the arena. Do u think we should save that file to any directory? That way the next time you connect to the server it will look in a local directory for the arena file. That way the next time you connect to the server it will look in a local directory for the arena file.

yes, allow for local caching based on the file name. If its not there, fetch from the Interweb. Be it on the game server or some other machine.

But this way we'll have this problem: if the admin of the server updates the file and don't change the name, how will we detect if the file is new?

btw: the download of arena files will be semitransparent because of the few kbytes to download

Humm, I dissagree on that. It will be if your on a fat broadband and the server hosting the file is not under load. But imagine 16 player trying to get the same new map? Or our poor friends behind dial-up. You need a synchronization system where all the clients report when they are done loading the map so the server can proceed.

k: Can you test if this minitest works in windows? You'll have to use the command line compiler of Visual C

Here is what I did to make it work the testfetch in linux:

Code: Select all

gcc -o testfetch testfetch.c http_error_codes.c http_fetcher.c

./testfetch
Page successfully downloaded. (www.google.com)

Sorry, I'm not at home. I'm sure someone else will be able to lend a hand.

Very nice progress klax! I will probably not be able to do a thing before the weekend.

-ph

[k]

I thought something like

arena://shape<(x1,y1),(x2,y2),(x3,y3)>spawn<(x4,y4),(x5,y5)>

You mentionned to just pass the description inside that string element. So I though, you only need to add a prefix to say its an arena, not a url.

But this way we'll have this problem: if the admin of the server updates the file and don't change the name, how will we detect if the file is new?

Could you tack on a version parameter to the url or arena description then compare what the server sent with what was saved on disk the last time?

[klax]

More progress:

I'm doing a miniapp (without any 3rd party lib, I'm getting the pieces we need from http fetcher and from one tutorial) that do a http retrieval. Also I can get the date of the file modified (it's retrieved on the http header, I'll need to look at dates functions to do compares). This miniapp will also work in windows without problems (I hope). When I'll finish it I'll post it here to test it with VC6 (it works well with mingw using windows sockets library).

This way we can have our minicode to get an http retrieval without depending any 3rd party library and without code bloating ;P

Here is my plan:

You select a server and press intro.
Before connecting, if there is an ARENA field (now I'm working with URL field) it will connect to the http url and it will retrieve the HTTP Header.

If the file does not exist --> retrieve the file from http
If the file exist --> compare the dates of the local file and the date got from http header.
If the http file in ARENA field is newer --> download it
If they have the same dates --> do not download it and use the local file (this case we will only download the http header and not the content of the file)

If there is not ARENA field or if ARENA field is 'basic.aar' and not an url (default square) --> load the local file giving the same arena and spawnpoints as previous versions

If ARENA field is another predefined one and not an url (we could use some predefined ones having them in local) -> load the local arena file

[philippeqc]

I thought something like

arena://shape<(x1,y1),(x2,y2),(x3,y3)>spawn<(x4,y4),(x5,y5)>

You mentionned to just pass the description inside that string element. So I though, you only need to add a prefix to say its an arena, not a url.

But this way we'll have this problem: if the admin of the server updates the file and don't change the name, how will we detect if the file is new?

Could you tack on a version parameter to the url or arena description then compare what the server sent with what was saved on disk the last time?

Yes, true. That would be required. But I was mostly suggesting that it would also be possible to just send the whole arena between every match with simple arenas. So no need for version on this.

-ph

[klax]

Tank/Someone: can u try to compile this test minicode with VC6? Uff, it's harder than I thought...
Thanks in advance

It compiles succesfully in mingw. I do this:
gcc -o httpget.exe httpget.c -lwsock32

Don't know the command line in VC6

To get it working:
httpget http://www.gnu.org/licenses/gpl.txt

It will have to display the http header and the text file.

[subby]

I also thought about doing some new shaped arenas (triangle, hexagon, ...).
I was thinking about doing general regular polygon shaped arenas, and only indicating the number of sides describing an arena.

But I think these arenas shapes require quite a lot of new code (detecting when you are outside the new arena and new render code to draw to new arenas (doing 3 walls, 6 walls, etc..)).

Another idea it came to my mind was seeing how the new deathzones work. We could make it new square permanent deathzones that are rendered just above the grid (in contact with the grid and rendered transparent). Like a transparent miniwall. We could make it just show one newdeathzone or a lot in the same arena doing some new funny arenas like these done with paint LOL. I think the work of doing this kind of arenas will be a lot easier than doing regular polygon arenas:

Hi there, The simplest way to change arena shape with walls in diffrent areas as far as i can see is to have a big arena and within that you add light cycle walls that are permanent.

The added benifit is that you could have the walls explode (when hit) enabling more space to play... more stradegy. You could also have walls slowly pop up as the game went along. This would also make the game still backward compatible as it would only be server side code.

[klax]

subby: Nice to see you around here

Yep, this idea also came to me from Emuman while playing one day. You start in the arena with some walls upped (making shapes in the outside, inside, mazes, ...)

As you say maybe it is simple to code and it will be compatible with all versions.

[subby]

subby: Nice to see you around here

ty

As you say maybe it is simple to code and it will be compatible with all version.

THats why i think its very worthwile considering as the last thing we want is a split b/w what ppl want and what we can give them. That is we want a system where the server admin can employ a maze (diff arena) w/o special upgrades - Allowing server admins to keep classic arenas as well.

[philippeqc]

Subby, I beleive you must have missed the part in the description where it is mentionned that the current gameplay would still be available under the proposed model.

What I want to do is explore another game play. And allow for new possibities.

GLTron seem to already have regular polygon shape arenas (I've seen picture of it on its web site, but havent tried the game recently). It is not my opinion that this change will divide gltron's user base.

I know we dont have the power of Manuel to just say "hey everybody, I've upgraded my game seriously, so get the new version."

You mention the offer and wants. I dissagree with you a bit. In your scenario, only the server would need to be changed, offering some new capacities without client modifications. But that is true only of the wants for the group of ppl that refuse any update not from Z-man. What about the group that dont mind change?

I have a lot of respect for Manuel. He has done what I could never have. But he isnt there, and there is no signs that he might come back. I dont feel we should contend ourself with standing in the shadow of an absente.

I respect a lot your opinion, because you bring me down a bit, forcing me to consider that a transition is needed. But at the same time, I dont want to limit myself to the ethernal backward compatibility.

-ph

[subby]

I respect your opinion. I wasn't even thinking about Manual. What you propose, I believe is a major rewrite? And as such would be in a longer cycle of release?

All I wanted to do is propose an possible solution that may or may not be easier (and quicker to code) to increase the game play. I'm a very impatient man that wants everything 2 weeks ago

But thats not up to me to decide (I resigned from the developers a group a while back now) but the person coding. And if it's you , you can do what ever you want