Total servers: 6
Old community member outreach (LieroX2 General Discussion) by JasonB Today at 12:50:52 pm
Saturday Nights (Graveyard [RIP]) by MiLeC May 19, 2013, 01:10:07 am
Thread for anything (Chat/Spam topic) (The World Outside) by Sebbe May 18, 2013, 05:28:04 pm
Dedicated server questions (Support & discussion) by Kurko May 17, 2013, 12:11:22 pm
Straight - [Str8] ([Str8]) by b-cátt May 16, 2013, 12:18:34 am
89.72.209.176
Unknown
Unknown – 0lt
IP: 89.72.209.176
Game Mode:
Lives: 0
Max Kills: 0
Version: LieroX 0.56b
Players:
[ Fast mortars ]
Modern Warfare1.0 – 20lt
IP: 37.205.11.54
Game Mode: Death Match
Lives: 0
Max Kills: 15
Version: OpenLieroX 0.58 rc3
Players:
Cruel Mod by iRod
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(3 lives, 0 kills)
Kurko's testlab
Liero v1.0 – 100lt
IP: 91.156.42.210
Game Mode: Death Match
Lives: 5
Max Kills: 20
Version: OpenLieroX 0.58 rc3
Players:
5o4
Food Fight v0.6 – 100lt
IP: 96.226.120.99
Game Mode: Death Match
Lives: 0
Max Kills: 50
Version: OpenLieroX 0.58 rc3
Players:
Tale(0 lives, 2 kills)
WiLyAmN(0 lives, 0 kills)
Jetxfrost(0 lives, 0 kills)
WiteWind(0 lives, 2 kills)
TK(0 lives, 1 kills)
Gacu
Liero v1.0 – 100lt
IP: 89.72.209.176
Game Mode: Death Match
Lives: 0
Max Kills: 15
Version: OpenLieroX 0.58 rc3
Players:
Markozbi(0 lives, 3 kills)
Pages: 1 2 [All]   Go Down

Author Topic: morphes' suggestions  (Read 1818 times)

morphles

morphes' suggestions
« on: November 17, 2008, 07:34:24 pm »
I'll admit i didn't read full thread but thought this is the right place to suggest one thing.

This is related with higher resolution feature.
One day i was checking options.cfg and found this line "PostProcessor =", tried to look what might go after = but couldn't find.
The thins i expected to go here didn't work. So i suggest making them work, this would give higher resolution, and in a way cool vector graphics look. But it would take a large chunk of CPU power.
(But i guess it could be threaded, and people with older/waker machines would probably have problems with high resolution anyways, just a guess thou).
So what I'm talking about and failed to mention till now :) is filters/scalers/post processors like the ones used in emulators, zsnes, fceultra, mame and alike, scalers that go with names hq2x, hq3x, supersai and others. I thing the dev's and probably others should know what I'm talking about.  I think it would be really nice to look at on "beefier" machines.

P.S. if that PostProcessor does something i would be glad to know, maybe i just requested a feature that exists already. But as i said from my search it seems to do nothing or is just totally undocumented.

Edit: and since it's filter-like feature, and they should be already in some libs that could be used, i guess it shouldn't be very hard to implement (and i of course might be very off here: ).
« Last Edit: November 17, 2008, 08:39:29 pm by morphles »

SteelSide

morphes' suggestions
« Reply #1 on: November 17, 2008, 09:53:31 pm »
The postprocessor is functional, these values are accepted:
stretchhalf
scale2x

:) (pretty much undocumented, been in since like beta6 or 7)
Warning: My normal fps is around 200, if i remove the limit.
stretchhalf gives me 50 fps.
scale2x gives me 10 fps.

So unless you got a real secksy computer, don't expect much.
« Last Edit: November 17, 2008, 10:37:17 pm by SteelSide »
Get yourselves to IRC asap, I'm lonely. (And please change nick from OpenLieroXor)

morphles

morphes' suggestions
« Reply #2 on: November 21, 2008, 02:37:46 pm »
Problems with these PostProcessor's.
Well if i enable any oof two you mentioned the game doesnt start (beta8). If i start installed or from bin in dir where i compiled i get segfault. If i start with ./start.sh i get long error report about threads and loaded libraries, it also says send output to ... so i guess i should do that? :) But its weird that launching openlierox directly doesnt produce anything more that "Segmentation fault".
Also i noticed this line in console: "HINT: Unable to use hardware surfaces, falling back to software." and i can't figure why it is unable to use hardware... Any help? (Lots of opengl/SDL games seem to have hw acceleration pretty fine, and i cant run very graphically intense games)

DarkCharlie

morphes' suggestions
« Reply #3 on: November 21, 2008, 04:35:03 pm »
Problems with these PostProcessor's.
Well if i enable any oof two you mentioned the game doesnt start (beta8). If i start installed or from bin in dir where i compiled i get segfault. If i start with ./start.sh i get long error report about threads and loaded libraries, it also says send output to ... so i guess i should do that? :) But its weird that launching openlierox directly doesnt produce anything more that "Segmentation fault".
Also i noticed this line in console: "HINT: Unable to use hardware surfaces, falling back to software." and i can't figure why it is unable to use hardware... Any help? (Lots of opengl/SDL games seem to have hw acceleration pretty fine, and i cant run very graphically intense games)

PostProcessors are mainly meant for non-PC platforms where it is necessary to resize the screen to fit on display for example. From what you say I suppose you use Linux - postprocessors currenty don't work on Linux because of some synchronization problems that cause crashes.
On Linux you have to have special privileges to run a program with hardware acceleration - play with your account settings. Also you most probably will not get hardware acceleration when running the game in a window.

morphles

morphes' suggestions
« Reply #4 on: November 21, 2008, 04:43:44 pm »
Yes i use linux. That thing about hardware doesn't seem likely, as i said ai play hw accelerated games, with intense graphics also compiz works for me ant other opengl sdl stuff, so it shouldnt be relatd to any privileges. Also i run all games in windowed mode and it doesn't drop performance, for example "Nexuiz" is Very graphics intense and i can play it windowed with everything maxed out (well except maybe hdri). So i see no system related reason why it should not work here (i tried full screen it still says unable to use hardware).

So what about the idea i mentioned in earlier post implementing scalers as one of high res option? I beleve there are libs for them, shouldn't be very problematic (and they seem to work on linux, i.e. zsnes, mame). Also i guess as dual (and more) cores a getting popular if it would run in other thread it shouldn't cut too much in the fps.

SteelSide

morphes' suggestions
« Reply #5 on: November 21, 2008, 08:11:49 pm »
morphies; if you svn up it should be able to run.
There's some variable which determines if it should run post processor as multi or single thread, running it in single does not cause the crash - i changed that to single, see revision 2868 (or higher, as long as no one changes it back!)
Get yourselves to IRC asap, I'm lonely. (And please change nick from OpenLieroXor)

morphles

morphes' suggestions
« Reply #6 on: November 21, 2008, 08:55:47 pm »
Just checked svn and PostProcessor works. I get 20-25 fps on scale 2x and ~75 strechhalf :) could be better :)
Could max fps affect netplay in any way (just purely theoretical question, without any base, just came to mind :) )

And i still get hint that i use software surface.  And im pretty sure i should be able to get hw, maybe detection for some hardware/software is not entirely right? Or some compile options or something else? Or maybe that hint just shows up anyway?

DarkCharlie

morphes' suggestions
« Reply #7 on: November 22, 2008, 01:09:52 am »
Just checked svn and PostProcessor works. I get 20-25 fps on scale 2x and ~75 strechhalf :) could be better :)
Could not ;) I did my best to optimize the algos, but especially Scale2x is a slow algorithm that is designed to stretch 320x240 images to 640x480 images, not 640x480 to 1280x960.

Quote
Could max fps affect netplay in any way (just purely theoretical question, without any base, just came to mind :) )
Yes, if set to a very low value. OLX sends/reads packets every frame, which means the less FPS you get, the more time it takes to receive/send a packet. However, for normal ranges (> 40) it is irrelevant.

Quote
And i still get hint that i use software surface.  And im pretty sure i should be able to get hw, maybe detection for some hardware/software is not entirely right? Or some compile options or something else? Or maybe that hint just shows up anyway?
This is how hardware support basically works (SDL is the graphics library):
OLX: hey, SDL, I want a screen 640x480, 32bit colors, fullscreen and hardware accelerated
SDL: bad luck guys, you won't get hardware surfaces today, I can offer only software surfaces
OLX: well, better than nothing, let's move on

SDL internally asks the system for the settings and does all the stuff behind. I highly doubt there's a bug in SDL which means that your system won't give OLX the hardware support. This can be from various reasons:
1) Your GFX card doesn't support it (very very unlikely)
2) You don't run OLX in fullscreen
3) You have OpenGL on (I'm not sure how well hardware & OpenGL can be combined, I think OpenGL takes care about this itself)
4) You don't have enough privileges (unlikely, I suppose you've checked that)
5) The GFX card is in use by another program (for example Compiz comes to my mind)

By the way, even if you get the hardware support, don't expect any great FPS increase. FPS will be probably fixed at 60 because it is limited by the screen framerate. There might also be some flickering problems as hardware support is in experimental stage atm.

morphles

morphes' suggestions
« Reply #8 on: November 22, 2008, 08:40:40 am »
Ok so no scale2x for me then :)

And about hardware surface, somethings not right as i keep saying. I always play windowed, all games,  ant doesn't stop them from havin acceleration (but reasonable guess from fps), also i am able to run 2 (or more) opengls games and seem to get acceleration, i.e. saurbraten (200fps), and in the other windows just above this nexuiz (~150-300 fps) all games are practically maxed out. I also recal being able to do this while compiz was running (now i use dont use it). Also remember seeing youtube video which showed how to run ut2004 when compiz was running, (also windowed),  and it seems to have acceleration (or else i guess it would be unplayable) ditto for WoW.

I have nvidia gefoce 8800 gts, if that matters.

I'm trying to look at the source, Found that initialization is in AuxLib.cpp, maybe i'll come up with something.

I understand that having hw acceleration would not give me practically anything more, but that should be correct way how it should happen.

morphles

morphes' suggestions
« Reply #9 on: November 22, 2008, 10:07:57 am »
After doing some "investigation" :) i found some interesting things. If using opengl, and opengl get acceleration and other neat stuff you cant check for acceleration/hw surface using sdlflags like SDL_HWSURFACE(i found that this is the way checked in openlierox), (when using opengl lots of sdl stuff doesnt make sense, thats one source said). So no wonder it always finds im using software. If i disable opengl i still can get hwsurfaces, but thats on programs i write myself so nothing different, just a bit strange.  Further reading made me thing that the use of opengl in openlierox not very useful, in that it shouldn't/doesn't give any advantage. And the reason is that it doesn't seem to use any of opengl functionality. In auxlib.cpp when initializing graphics with opengl it uses  SDL_OPENGLBLIT. Witch is said to be obsolete and never a was a good idea. It allows blitting into opengl, and is slow. So if i understand correctly even if using opengl it still does everything trough sdl functions and renders opengl useles. And i actually get lower frame rate with opengl enabled than with it disabled (230 vs 270). Also if i comment out SDL_OPENGLBLIT flag and then compile game will not start (at least with opengl).
Sorry if i understood something wrong, just wanted to point out what seems to be happening in game.

For some time i was thinking joining the dev team, but i don't know i just think i'm not too skilled enough, and also i'm a large bit lazy so it probably would be not likely that i could contribute much :( .
But dunno what would devs suggest?

And i think this is a bit wrong place for all such talk, so sorry again. Just anded up talking about it here.

DarkCharlie

morphes' suggestions
« Reply #10 on: November 23, 2008, 01:28:39 am »
After doing some "investigation" :) i found some interesting things. If using opengl, and opengl get acceleration and other neat stuff you cant check for acceleration/hw surface using sdlflags like SDL_HWSURFACE(i found that this is the way checked in openlierox), (when using opengl lots of sdl stuff doesnt make sense, thats one source said). So no wonder it always finds im using software. If i disable opengl i still can get hwsurfaces, but thats on programs i write myself so nothing different, just a bit strange.  Further reading made me thing that the use of opengl in openlierox not very useful, in that it shouldn't/doesn't give any advantage. And the reason is that it doesn't seem to use any of opengl functionality. In auxlib.cpp when initializing graphics with opengl it uses  SDL_OPENGLBLIT. Witch is said to be obsolete and never a was a good idea. It allows blitting into opengl, and is slow. So if i understand correctly even if using opengl it still does everything trough sdl functions and renders opengl useles. And i actually get lower frame rate with opengl enabled than with it disabled (230 vs 270). Also if i comment out SDL_OPENGLBLIT flag and then compile game will not start (at least with opengl).
Sorry if i understood something wrong, just wanted to point out what seems to be happening in game.
Nothing to add, you are completelly right in this part. OLX's OpenGL handling is incorrect, but it surprisingly brings performance boost on some systems (for example Mac OS X). Don't ask me why, I don't know. All the graphics handling should be remade to support hardware/OGL/directx/whatever else backends efficiently. I've got an idea how to do it but I'm busy with the new GUI system at the moment.

Quote
For some time i was thinking joining the dev team, but i don't know i just think i'm not too skilled enough, and also i'm a large bit lazy so it probably would be not likely that i could contribute much :( .
But dunno what would devs suggest?
We would suggest you joining us because a little > nothing!

Quote
And i think this is a bit wrong place for all such talk, so sorry again. Just anded up talking about it here.

Indeed, I will split this topic up when I'm in mood for doing that  ;)

pelya

morphes' suggestions
« Reply #11 on: November 24, 2008, 12:14:54 pm »
Side note: OLX uses some weird single-buffered optimizations across the code, so it won't work well in double-buffered mode out of the box, and double-buffered mode is required for GFX acceleration I think, at least all games use it.
Also I've found some nice wrapper for OpenGL that mimics SDL API, so theoretically you should be able to make GL-accelerated game from SDL non-accelerated game, and OpenGL should be at least not slower than pure SDL calls (much faster with GFX accel), and is available virtually everywhere, even on handhelds. And there also similar Direct3D wrapper in the same folder.
That won't apply to OLX code of course :P you should fix it everywhere to make it compile and work.

morphles

morphes' suggestions
« Reply #12 on: November 27, 2008, 07:04:53 pm »
Seems it is/would be kinda hard to help with development,  got some duties so i didn't even post too for couple days. And theres quite some pile of code to understand to be able to do something :)
Where could i start? Or maybe i'll just stick with finding/reporting bugs and oddities. Don't know :(

Speaking about oddities. One day when playing on net one player showed me some weird stuff that i think definitely shouldn't be happening: When playing online (you must Not be host),  then when you get eliminated (out), but some other players are left playing in talk prompt you can write "/spectate" and you just "resurrect" with 0 lives, but resurrect nonetheless,  being able to kill an be killed. Don't know if this is reported he said he didn't report it so i thought i would do.

In other thread i asked if server runs full simulation, and you answered that it doesn't. And this seems not too good idea for me. (of course i might be wrong) Also you said that server can run full simulation if server side health is enabled, but iirc its not popular because gives lag-advantage for host or thats how i understood.  But then i was thinking about this kind of architecture i it seems for me that if not running full scale simulation the server uses more bandwidth - server gets data from everyone and then resends everyones data to everyone (thats how i understand, please correct me if needed). But if server ran full simulation then it would just need to get directions/actions/key presses from clients and then send data, and i think that this would cut servers download bandwidth. One other advantage that full simulation would give, that if done well/correctly the game would become deterministic and identical for all clients.  The thing that it would be deterministic would make "game recording" feature trivial to implement. You should just store random number generator seed, and players key preses.  Besides this would prevent cheating (although this problem seems marginal, since i haven't encountered any cheaters so far, as much as i know :) ). I know that i could give slight advantage to the host, but seems many games do this, and its not very problematic. Also if server ran as dedicated and everyone had to connect no one would get advantage.

Thats it for this time. Pleas correct me if i'm wrong somewhere. 

pelya

morphes' suggestions
« Reply #13 on: November 28, 2008, 11:32:15 am »
Warning: Textwall!  ;D

Seems it is/would be kinda hard to help with development,  got some duties so i didn't even post too for couple days. And theres quite some pile of code to understand to be able to do something :)
Where could i start? Or maybe i'll just stick with finding/reporting bugs and oddities. Don't know :(

You do not need to look deeply into the code to start, there's pretty clean class hierarchy - there's one global GameServer and one global CClient, if you're playing locally or hosting one is connected to another, if you're joining game only CClient is used. There are CWorm class, CMap class and CGameScript class - their usage should be obvious.
The ugliest thing in my opinion is GUI system. We already have one deprecated GUI system and two unfinished new GUI systems - the first one by me is binded to deprecated GUI and reuses existing widgets, second one by DC resides in SkinnedGui folder and has it's own skinnable widget set.
Good place to start will be adding another option to the game - you should have pretty big list of them, like "Do not allow worm to rope to the level ceiling, only to dirt/stone", or maybe "Weapons reloading always, 2x faster when you emptied ammo", or some general stuff like auto-updating server list and making beep when some server from your Favorites list appears or becomes Open, or make that "Damage done by player" thing - Beta9 clients should report who did damage to their worms and how much to the server, and server will send extended score info to Beta9 clients, and maybe calculate locally damage for non-Beta9 clients, which may be more or less wrong of course.
More complicated task is to increase FPS - you're making profiling build, and run OLX with profiler (there are lots of them for Linux, though I've had somekind success only with GProf), then you're looking what function takes most time to execute (currently it's font drawing) and optimize it. DC is currently doing that.
Another nice place to start will be new physics engine, ideally the same as in original Liero game, plus nasty things removed such as wallshooting or sliding on the ramp-like ceiling. You should copy existing PhysicsEngine class and edit it as you like - we have everything ready for it.
You can also extend dedicated server - there are lot of things to do there, like remove buggy CTF code from C++ and add it to Python scripts. You can reuse existing system which runs Python as separate process, but ideally we should link or dynamically load Python into OLX, then we can have nice scripting available to users from GUI. But that's not easy task.
Please do NOT try to implement new modding engine based on LUA or some else scripting language around. We already got two devs who tried that, failed and lost interest to OLX. You should be ready to spend no less than 3 months on it of you want to implement this. The easier and uglier way would be to extend existing engine with Guided Missile and Fan, then you should make another Mod Compiler (copypaste some OLX code typically). The nice way to do that would be to make another CGameScript class and make some virtual CGameScriptBase class, and derive both old and new ones from it.

Speaking about oddities. One day when playing on net one player showed me some weird stuff that i think definitely shouldn't be happening: When playing online (you must Not be host),  then when you get eliminated (out), but some other players are left playing in talk prompt you can write "/spectate" and you just "resurrect" with 0 lives, but resurrect nonetheless,  being able to kill an be killed. Don't know if this is reported he said he didn't report it so i thought i would do.

Griffin fixed that recently.

In other thread i asked if server runs full simulation, and you answered that it doesn't. And this seems not too good idea for me. (of course i might be wrong) Also you said that server can run full simulation if server side health is enabled, but iirc its not popular because gives lag-advantage for host or thats how i understood.  But then i was thinking about this kind of architecture i it seems for me that if not running full scale simulation the server uses more bandwidth - server gets data from everyone and then resends everyones data to everyone (thats how i understand, please correct me if needed). But if server ran full simulation then it would just need to get directions/actions/key presses from clients and then send data, and i think that this would cut servers download bandwidth. One other advantage that full simulation would give, that if done well/correctly the game would become deterministic and identical for all clients.  The thing that it would be deterministic would make "game recording" feature trivial to implement. You should just store random number generator seed, and players key preses.  Besides this would prevent cheating (although this problem seems marginal, since i haven't encountered any cheaters so far, as much as i know :) ). I know that i could give slight advantage to the host, but seems many games do this, and its not very problematic. Also if server ran as dedicated and everyone had to connect no one would get advantage.

The worm's own health is stored on client, you can cheat just by using some memory editor. Enabling SSH will just send WormDied packet when worm's health on server reaches zero, which may be totally not true for client.
All clients send to server updates with their coordinates and whether fire button pressed, the server sends to clients coordinates of other clients and list of projectiles that worms shooted - with 0LT it can grow huge. This list has some kinda random number attached, so all secondary projectiles created when primary one explodes should fly in the same pattern on all clients - they simulated on clients only, not sent over net. But the list does not contain timing info, so primary projectile explodes when game situation changed on different clients, and may not explode at all for some clients if they avoided it locally. Plus there is such nice thing in OLX as dirt - it is always different for all clients, the best situation is for connect-during-game feature - if you connect to Dirt map other worms may have all dirt destroyed but you will see it full of dirt, and others "slicing" through dirt as somekind of ghosts.
The "New net engine" I want to implement is exactly what you've said - I've implemented that in Orthodox mod (but screwed up somewhere and it's synced only for first game, then you have to restart OLX) - it is actually OpenLiero linked to OLX code and using it's net engine through my own mega-synced-net-wrapper, which sends only user keypresses over net. Maybe I'll finish it someday, if you wish to work on that feature check out revision 2273 - it's removed from later revisions. The only modification to do there is individual random number for each player (so whole game won't lag if some of players lags), and maybe delay in calculating gamestate for drawing, so other worms won't "teleport" randomly. Oh, it also copies whole CMap and CProjectile array when new packet arrives to re-calculate game state with new data - it is unnoticeable for OpenLiero, but may have heavy FPS drop on 0lt spammods. I've made functions for CMap that will remember only changed parts and revert them quickly, and I have some ideas how to optimize CProjectile array, but first I should implement net engine correcly working, even slow as hell, and did not even started yet.
« Last Edit: November 28, 2008, 11:36:34 am by pelya »

morphles

morphes' suggestions
« Reply #14 on: November 28, 2008, 06:09:13 pm »
I'll see if i can do something :) ah and i'll also need to learn use svn then.

what i'm thinking is option that would enable rope length changing (warn me if this is harder than i expect),  i'll try to implement this.

Also one more question, maybe i could find answer myself by looking somewhere in src, but i think i have a good guess. How olx does collision detection?  Using sdl surface intersection functionality or something like this?

DarkCharlie

morphes' suggestions
« Reply #15 on: November 28, 2008, 07:51:25 pm »
I'll see if i can do something :) ah and i'll also need to learn use svn then.

what i'm thinking is option that would enable rope length changing (warn me if this is harder than i expect),  i'll try to implement this.

Also one more question, maybe i could find answer myself by looking somewhere in src, but i think i have a good guess. How olx does collision detection?  Using sdl surface intersection functionality or something like this?

No, only rectangular collision - each object has a small collision rect (5x5 or 3x3 px) and an intersection is tested.

Welcome to the dev team!  ;)

morphles

Re: morphes' suggestions
« Reply #16 on: November 28, 2008, 08:24:10 pm »
I have done the rope part, but not the option part. :)

I can change rope length, but options system wasn't very clear so didn't add option yet. For now i added hard coded ropeRollSpeed into CWorm_simulate.cpp. I know its not nice.
Will work out hot to make it option in options.cfg. Then if set to 0 it will effectively be disabled. Now if to make server side option/check.. i have no idea how to do this, for now.
It works nicely, i networked game also (if im the host :) ), of course only i can do this nice feat for now :)

I guess i should now get svn account at sourceforge or something like that?
« Last Edit: November 28, 2008, 08:47:45 pm by morphles »

SteelSide

Re: morphes' suggestions
« Reply #17 on: November 29, 2008, 09:32:20 pm »
Yeah just get an account and then talk to albert, he'll grant you svn access.

If you check how mouseaiming was done for serverside checks, you can pretty much copy it.
Get yourselves to IRC asap, I'm lonely. (And please change nick from OpenLieroXor)

pelya

Re: morphes' suggestions
« Reply #18 on: December 01, 2008, 01:36:11 pm »
Yeah just get an account and then talk to albert, he'll grant you svn access.

If you check how mouseaiming was done for serverside checks, you can pretty much copy it.

Mouseaiming-enabled server sends UNRELIABLE packet to client, if client didn't get the packet he'll assume he's not allowed to do mouse aiming.
The correct way would be add class CServerNetEngineBeta9 derived from CServerNetEngineBeta8, and override there SendPrepareGame() function (as it was done in CServerNetEngineBeta7) - add another byte or int to the end of S2C_PREPAREGAME packet which will specify new rope length, and add parsing that data in CClientNetEngine the same way - make another class CClientNetEngineBeta9 derived from CClientNetEngineBeta7 which will parse that additional byte in overridden ParsePrepareGame().
Also you should add these new classes to CClient::setNetEngineFromServerVersion() and CServerConnection::setNetEngineFromClientVersion(), and add checks/kicking for non-Beta9 client into GameServer::checkVersionCompatibility().
You may also make the same for S2C_UPDATELOBBYGAME, but that's optional - we don't have where to put this info in GUI anyway, and I wanted to send all GameOptions::GameInfo class with somekindof loop specifying var name and type, not just picking individual variables like it is done now.
As for options you should just add another variable "RopeLength" into GameOptions::GameInfo class, and add line like "( tLXOptions->tGameInfo.RopeLength, "RopeLength", -1 )" into Options.cpp in appropriate place where "-1" means you're reading default value from mod. Our l33t options system will load/save this variable for you from this point, and will make it available for ded scripts.
With GUI system you should add another slider in Game Settings dialog in DeprecatedGUI/Menu_Local.cpp, it's ugly and messed up but I trust in you :D

morphles

Re: morphes' suggestions
« Reply #19 on: December 10, 2008, 08:57:00 pm »
Here comes more suggestions from me :)
And i'm slow to implement them... :(

Anyway i though some stuff that should be useful.
Lets start with problem that i perceive: openlierox has ALLOT
of user generated content(that is good), and when you have to choose something
like level or mod, you must scroll for very long(for lack of better expression) in pulldown lists and thats
not very nice.
I would suggest to make scroll boxes (like for player selection) for levels and mods, and edit boxes above them
when something is typed in edit box the contents of scroll box change - are filtered to show only items that have
the string typed in edit box(maybe just begins with that string). I understand that this needs quite some space
which is very problematic with host game screen (on local play you can just decrease size of words "LOCAL PLAY")
but it should be doable, and i think if its not now then some time later this will be very nice feature to have.

Second suggestion - start game in "empty", that is dirtless map, meaning the maps is the one that is selected but
it starts with all dirt in int already cleared. (on old original liero there was option to not regenerate map that was similar to this).

Third suggestion goes further in to future, like more suitable for hirudo. First the problem "duplication" of "mods", what i mean
there are mods of mods - there is some mod, and then it can gave some subset of weapons saved as weapon presets. One more thing
with this if i like some weapons from one mod and some from another theres no way to make my mod that would have those weapons
(in theory i could ask for mod sources and rebuild mod, sth like this, but well thats not how it should/could be). By now you could have guessed
that i want to suggest. That would that mod would not be binary blob, but that it would be like weapons preset, and instead there would
be weapon "binary blobs" placed somewhere, and you could "make" "mods" "on the fly". I know this would introduce some problems,
but i think it would be Much more flexible, and should be worth it.

Seems that's it for this time. But i definitely had something more in mind, just forgot. Oh well some time later.
For now say what you think about these things?


Edit: one of the the thing i had forgot. GUI for creating mods would be very good (i think thats good task for me, that i could/would/will do in some time).
and another one - i think modding system will need to be revamped anyway, since what does gravity rope length (which will be practically obsolete when i implement feature from orginal liero: changable rope length) and some stuff like this has to do with what is essentially a weapon set, these settings should be separate.
« Last Edit: December 10, 2008, 09:01:27 pm by morphles »

pelya

Re: morphes' suggestions
« Reply #20 on: December 11, 2008, 09:03:01 am »
All that stuff requires new GUI system. You may try to edit SkinnedGUI by DC, or edit mine half-finished system :D we should anyway import functions from it into SkinnedGUI - SkinnedGUI widgets has tons of options how to change widget looks, but they don't have any variables attached to the widgets, and in my system you attach in-game variables and action handlers to the widgets in XML file, so we can move widget coords out of the code. DC correct me if I'm wrong.
For mods - OLX loads mods in some pretty simple struct, and it has functions to save it to a file, so creating mod editor is only matter of attaching GUI to these functions, but GUI is not an easy part.
Pages: 1 2 [All]   Go Up
 

anything