CacusMapVote

[Higor]

CacusMapVote_test5.7z

(40.92 KiB) Downloaded 89 times

Added flood protection for "Mutate Map" binds.

CacusMapVote_test6.7z

(41.46 KiB) Downloaded 93 times

Supports XC_GameEngine's simple dynamic package loader.
Read Documentation (last section) for more details.

===========
BDBMapVote, MapVoteLA... some questions and a project.

As the title says, I have some questions on these things and I'd like to know about them before I put myself on a challenge.

I this MVLA14UUb13C.u file on a user server a few months ago... it's the mapvote seen in this thread: http://www.ut99.org/viewtopic.php?f=33&t=4671
The file mentioned above contains the whole menu system and WRI stuff, with all the serverside-only things stripped, in other words, running in a serverside package.
But it's something else that worries me, it's the whole history of this mutator.

-Who changed BDB to LA and why?
-Who worked on it from the very beginning to the very end of it?
-Why is the code always obfuscated on whatever release I find?

And about the projects...
If I decide to make my own ServerSide component that interacts with this client file, without even altering a bit of it.
-Does it make it right to do?
-Is it right to release the server part?
-Is it right to release the client part, cosidering most of that code went thru many hands anyways?

[Wises]

hiyah dude.

here's some extensive info on BDBMAPVOTE Original.. I found yesterday whilst we were upgrading MVX.

www.hot.ee/spaceball/MapVoteReadMe.htm

medor ut99 free has an un-obfuscated version .. of MVLA.. which funnily enough was not obfuscated apparently according to cr@tos over at UtAssault..

if you find the thread he actually details how-to unobfuscate it..

that version you seen in my post @ is from a Coder Named GUST (Japan)

he has many many many custom mods.. another good coder like you chaps.

but it is private.

I will post back more details later.

[player]

Who changed BDB to LA and why?

cratos: "it didn't work well with LeagueAS" #3

Who worked on it from the very beginning to the very end of it?

=> BDBMapVote, by Bruce Bickar aka BDB
==> MapVoteLA up to v13, by cratos @ utassault.net
===> MVLA14UUb*.u, MapVoteLA v14 Unofficial Update build * by gust @ Japan UT Community
afaik he is the first one to have decompiled LA13 successfully.
===> my decompilation of LA13: link
===> MapVoteLAv2, by kelly

Why is the code always obfuscated on whatever release I find?

I know little other than MapVoteLA so I'll focus my response on it.
for cratos: "I just removed the useless 'textcode' to make the package much smaller" #1
for gust: gust had adopted practice of server/client code separation well before MVLA14UU.
and as MVLA14UU is based on decompilation, there might be overlooked mistakes, i guess he'd rather not leave buggy codes circulating.
i think he is fine if you decompile his work, as long as you handle yourself whatever went wrong (eg. bug / faulty decompilation)

Does it make it right to do?

cratos approving decompilation of LA13 here #1
"Like MapvoteLA is an improvement on the original BDB mapvote? If that source wasn't open then we wouldn't have LA." #2
personally i think likewise and went ahead to decompile LA13.

Is it right to release the server part?
Is it right to release the client part, cosidering most of that code went thru many hands anyways?

I would suggest using another release name so you can have control over the release. If you can't decompile then you can rename it nonetheless
(eg. change GUID and edit nametable). just remember to give credit to original author.

[Higor]

I am writing the Server code (missing from gust's menu interface) from scratch, it should provide the same functionality and frontend as MVLA14UU, but with a whole different 'engine' behind it.
And that's what I meant if it's right to release something that handles someone else's frontend, and if it's even right to release it with said frontend without even altering a single byte (always crediting the author(s) which appear to be many).

Right now the controller can spawn the frontend's welcome window, the hardest part hasn't even been started yet but it's something.

[player]

i can see what u are doing. so i was suggesting to rename gust's mvla14uub*.u to something else, then you can credit gust for the GUI (apart from other coders..), and focus on working your own version of serverside code. even if anything went wrong, it is your release which is taking the blame only, & u need not worry of defaming any previous coders. on the other hand, if it goes well, then great, u've given credit to previous coders already and u deserved praise.

in addition to MapVoteLA13, gust decompiled UTPure7GVA & UTProMod for customization, i think he really has no good reason to oppose ur work, so don't worry on that regards. u have my word, i used to play on his server to know those.

[JackGriffin]

The LAv2 I did was simply to stretch the usable space in the voting window so you could read map names and make larger arrays for the map lists. I was intensely uncomfortable with making any functionality changes without permission so there is nothing new to be found in my version that you won't do yourself right off.

[Higor]

Took some brainstorming understanding the mechanics of this mapvote by just looking at the frontend and I can make a small list of remarkable things:

---- Each unique map is listed once in the maplist.
I am intrigued at how map prefixes were deprecated in this new frontend, basically you now submit a vote on the real map name and a rule tag on it, said system is also used in the MapList inis.
This brings a nice change here, and that is, that we're talking about 4096 unique maps now instead of same map with different prefixes using various slots.

---- Usage of a HTTP channel to send the map list.
By opening an extra port on the server, now the clients may retrieve the map list from the server using a custom TCPLink actor, the server using any possible method to acknowledge can send the map list, rule list, and other settings either from UT via Backend HTTP channel or simply an external app reading the INI, this opens up to many possibilities.

---- Local storage of map lists
A fingerprint is generated when map list has been processed, it's most likely a digest of some kind allowing to let clients know if said map/rule list has changed during game sessions.
Said entries are saved to INI under [digest] section in MapVoteCache.ini and if the server sends a known 'digest', instead of opening a channel to transfer the map list, the client will load from said INI the cached map list.


Since the backend is a server-only package, the way to treat the package will be pretty much the same as FerBotZ, where the admin can choose a version/flavor without sending anything to the clients.
For the record, I'm doing all this without creating package dependancy from my backend so it would (in theory) work with future frontend versions, provided they ever come up.

Onto my backend, I plan to add a ServerPackages override mechanism using various lists: Main, GameBased, RuleBased.
This way the mapvote wouldn't need to rely on external tools to guess and change said list.

Will keep you guys posted from my progress.

[Higor]

The backend's internal map list generator is working so far, differences to original MVLA:

- All GameModes have their FilterCode cached, if more than one GameMode uses a filter set, said filter set will merge both (or more) GameMode indexes (seen as ;00;01).
- All individual FilterCodes (seen as dm, ctf) have their starting index and ending index on the filter array stored for faster iterations.
- Same is done for Exclude Filters.
- Instead of looping the map list for each game mode, the entire map directory is looped and then the game filters (that have game mode(s) indexes precached) are checked on each individual map.

The result is a much faster map list generation on the server.
No progress in interaction with the frontend yet, in order to trigger a map list generation I have to use debug commands to edit the actors as seen below.

[Higor]

Some interaction between both ends now, still nothing visible but somewhat interesting.

The HTTP transfer of the maplist works 100% fine, as soon as a player joins, the MapListCache actor (frontend) is sent to the client with the corresponding HTTP address he should connect.
Each connection will transfer about 1000 bytes of data every 0.5 second until the whole maplist and rule set are loaded on cache.

In order to make the frontend's HTTPMapListReceiver to work, I had to create a custom WebApplication object that processes the queries coming from this client actor.
WebApplication(s) are created when the UWeb.WebServer actor is spawned on multiplayer games and WebServer is enabled, as some remember WebServer's default application is the web based UTServerAdmin.
That WebServer made things pretty damn easy to finish as it already handles the whole HTTP connection setup state.

My WebServer config looks somewhat like this: (you may want to remove the other applications)

Code: Select all

[Engine.GameEngine]
ServerActors=UWeb.WebServer

[UWeb.WebServer]
Applications[0]=UTServerAdmin.UTServerAdmin
ApplicationPaths[0]=/ServerAdmin
Applications[1]=UTServerAdmin.UTImageServer
ApplicationPaths[1]=/images
Applications[2]=CacusMapVote.CacusMapListServer
ApplicationPaths[2]=/MapList
DefaultApplication=2
bEnabled=True
ListenPort=27011

[CacusMapVote.CacusMapVote]
HTTPMapListLocation="http://192.168.1.2:27011/MapList"

The WAN ip should go there for an actual server.

I'm also adding some small serverside security measures to the MapList app to prevent overflow, like checking the incoming IP to see if it matches that of the current players and not allowing more than 5 connections per second (per ip).

[spark]

Hola Higor, no entiendo mucho el ingles, pero quisiera preguntar, lo que intentas es hacer un mapvote que al momento de darle clic en un GameType automaticamente aparesca el maplist de ese GameType? Eso seria asombroso! saludos!

[Wises]

looking/sounding good Higor!.

interesting how you are using the WebServer Part of the Engine to send receive the MapList.. just wondering if this would cause lag when sending to full load on server 12-16 players as such... kind of like having several webAdmins all online at once ... I guess..

interesting..

[Higor]

I gotta figure out how to activate the cache in the frontend, once that's done, there won't be any need to re-send the maplist a second time.

[Wises]

when we developing MVX i had discussed idea's where a checksum were to be created after the maplist(s) were sent to clients..
this checksum in theory could be sent to server from clients.. and if it did not compare to the serversides Checksum , then it would resend / request the maplist(s)..

assuming that something like this may/not be feasible?>

thoughts are if / when admin updates the MapList... what would happen? Ideally it would only send through the changes to the client's but I don't know if that is really possible.

hence the checksum concept... above.

[Feralidragon]

Or it could be more advanced than that and use the hash to create a checkpoint instead which you can generate a delta from, so whenever there are new maps or maps removed, the whole list doesn't have to be sent, but rather just the new maps and the information of the removed ones.

[SC]-[WARTZ_{HoF}]

Or it could be more advanced than that and use the hash to create a checkpoint instead which you can generate a delta from, so whenever there are new maps or maps removed, the whole list doesn't have to be sent, but rather just the new maps and the information of the removed ones.

That sir would be an ideal way to handle the add and removal of maps in the map directory for a mapvote.