Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Looking around..

  1. #1
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default Looking around..

    James, Razo, JoTo and who else am I forgetting? I've been looking around here after a long while and you've done a great job so far since the topic on TMT.
    But I have a few (noobish) questions and some suggestions. Instead of dividing them into several threads, I'll just do it here.
    Forgive my ignorance concerning server administration. I spend a lot of my time scripting offline either for offline purposes or for other people to use on their server.
    It's been a while since I had server of my own. However I'm thinking about getting one once again.

    Q1: So I'm thinking about renting a server again. But that will mean that I can only access the main/ directory, will it be enough to make this work?

    Q2: Consequencially, I won't be able to use the launcher/auto-updater. Will it work without it, or do I need to change some things first?

    Q3: Should I wait for the new version to come along or go ahead with this one? Is it due to be released soon?
    I noticed some people complained anti-WH (or was it STWH?) is causing lag. I don't like lag... especially when my own scripts can produce enough of it as it is

    Q4: Will players running 1.11 be able to connect to a server running 1.12? Only if sv_pure is 1, will they be kicked?

    Q5: Okay, say anti-WH doesn't lag anymore. If I turn all these detections on, will it cause noticeable lag or does it depends on the servers ping?

    Q6: I presume banning is realtime? No restarting servers to have it take effect? If so, I think I will love this patch...

    On a side note: I see g_teambalance is obsolete in this version. Why? I was under the impression teambalancing was a relatively easy task since a nicely working teambalance logic can be created using only scripting.
    As for my suggestions:
    S1: Having the players name and IP available in script would be a modders heaven.

    S2: Ability to detect player key input, allowing me to check what keys he's pressing on his keyboard. Or maybe the other way around, checking to see if he pressed a certain button.
    Would be a more efficient and extensive than executing scripts whenever he presses secondary fire or the forward key in the statefiles...

    S3: Individual HUD elements. "huddraw_" commands offer the scripter 256 available and unique, new HUD elements to be drawn onto the HUD. Unfortunately, these are applied to every single player.
    Options range from position on screen to colour, to shader, to font, to alpha, to virtualsize (making it appear at about the same position on different resolutions) etc...
    Making individual HUD elements requires a workaround: stufftexting globalwidgetcommands which basically temporarily edit stock UI menus, which are then stufftexted to show. Problem is there are only 3 usable and hiding them happens slowly.
    Adding several more would resolve the issue, but would make it clientside.

    S4: Ability to read player config, or in other words: what cvar values he has set.

    S5: Inventory detection. 1 property that contains every weapon he can switch to. Modelname is sufficient. Additionally, something that indicated which one of the weapons he's currently holding (if any).
    Something that would also be interesting is the ammo he has for each of the 7 types (shotgun, bazooka, mg, smg, rifle, pistol and grenade).

    S6: Forgetting the most important one of them all. Detecting the player's state. We can detect if he's alive or not. But the term 'alive' isn't what it seems. If a player is in spectator, he is 'alive', even if the player has chosen a team, but not a weapon yet (thus he hasn't spawned), he is labelled as alive.
    So what I propose is simple, a property telling us whether the player is spectating, dead (ie. not a spectator, but neither spawned, this is the one thing they got right though) or alive (spawned and not dead) or choosing (not spectating, not dead, and not spawned: he's choosing a weapon).

    You can see a trend here? Why all my suggestions imply detection is because the $player entity as it is now, is a complete mystery to scripters. All we know is his coordinate position, his three-dimensional angle, his team, his health (which is as misleading as the 'isalive' command I talked about above) and his clientnumber.
    We have to use our imaginations to find workarounds to some of the missing information but some things are just impossible to obtain.

    S7: Adding kills and deaths. Adding a kill:death ratio to the scoreboard would also be a nice feature.

    S8: Teamkill detect and punisher. 3 strikes and you're out kind of thing. Strikes can fade over time. All cvar set?

    It is possible to detect the 'i-drop-nade-and-then-switch-team' phenomenon, even in script. I basically run a script from the grenade tiki files. In the new script the grenade is self and parm.owner is his owner. The owners current team gets saved along with a property indicating he has just thrown a grenade. When the nade explodes, it vanishes so self = NULL and then the script undoes the grenade property. Meanwhile another script gets run each time a player respawns. If that script detects that the player had just thrown a nade and his current team does not equal his previous team, followed by a sudden increase in kills, it is recorded as teamkill.

    This reminds me to point out a weird bug in the engine. I detect kills by glueing a trigger set to spawnflags 128 (which will make the trigger respond to damage only), slightly smaller than the boundingbox of the player. Each time a bullet/explosion/bash triggers it, the player the trigger is glued to, is checked for death. If death is detected, the trigger will deactivate and the script concludes that parm.other (origin of the last detected damage) is the killer and he receives +1 kill. This is not the problem, it works beautifully. The problem is when a bullet flies through a trigger set to damage (spawnflags 128 and all combinations), it becomes 'bugged'. It suddenly is capable of flying through solid models and doors, sometimes even walls.
    Not sure if you can ever find or fix this detail.
    I know you're planning to work on features and enhancements like this when all the fixes are done. Just a reminder in a way.
    They real reason I ask this is because I'm planning a huge mod, these features would facilitate some things, whilst
    making other things I plan on doing, possible.

    Anyway, great work so far!!

  2. #2

    Default

    Quote Originally Posted by Sor View Post
    Q1: So I'm thinking about renting a server again. But that will mean that I can only access the main/ directory, will it be enough to make this work?
    Most hosts will apply the patch if you create a support ticket. But if you rent a server here: http://escapedturkey.com/ you will have full access to the mohaa folder.
    :)

  3. #3
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Soo.. questions first

    A1. Unfortunately to make it work totally you would need auto-updater and it needs to be placed in mohaa base directory. But as said before. Most server providers will apply patch for you (you just have to check if they've done it properly)

    A2. It will work without it. You could always turn off auto-update. If you won't do this.. patch will try to update to newer version, but it won't be able to run updater.

    A3. You can go ahead with this version. You can turn of Anti-WH (it's causing lag and players blinking).

    A4. They will be able to connect. sv_pure doesn't work with this version. It will work in full release, but only 1.12 clients will be able to connect to full release 1.12 server. Right now players from 1.11 can connect 1.12 server, but there isn't sv_pure and sv_allowdownload

    A5. This will depend on servers ping. We have a lot of work to do to make it way better. For now it's best to turn it off.

    A6. Banning is real time. Some players had crash but its like 1% to happen. So right now banning works ok and it's real-time.

    A7. We didn't finish team-balance because we couldn't make it only with engine or we would need much more reversed functions. This can be done via scripts so if you want you can write team-balancer for our patch and we'll add it as an official feature of the patch (stock one, not a mod or something)

  4. #4
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Suggestions now:

    The very bad thing about our work is that we don't have any source code. Additionaly we don't know much about scripting engine (that comes with UberTools from IdSoftware). We would need to reverse engineer it from scratch etc. and this will take us lot of time.

    I already took a look at it. Right now we don't have an idea of how to add new functions (script commands) to game engine. The only option for us would be to replace existing ones or edit existing ones.

    I had few ideas in my head.

    1st one: replace one useless script function with our custom one. It would work like cvar_get. It would need player number and some additional param. And it would return a value. This could be doable.

    So you would usie it like that:

    Code:
    local.tmp = get_info( local.client_number, "ip");
    local.tmp = get_info( local.client_number, "name");
    local.tmp = get_info( local.client_number, "state");
    
    and so on..
    you would just need to keep track of the type of value that is returned (number, string, entity etc.)

    However, what stops me from doing this is a fact that I don't know yet how game can return different types to variable and how it's done etc.

    My 2nd idea is to edit huddraw_ functions to make them work for single client:

    it would need additional param - client number. This would make all currently available mods that use huddraw_ functions not to work. So modders would need to rewrite them. or something.

    It's seems hard right know to accomplish most of your suggestions, but I don't loose hope and I investigate a lot to get the idea of scripting engine and how it works.

    I reversed huddraw_ functions so I know how to send huddraw to only one client, this is 100% doable. I will just have to think about how to implement this into engine.

  5. #5
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default

    A4: So with the full release only 1.12 players will be able to connect regardless of sv_pure?

    A7: here's a teambalance script I wrote for my server years ago. I could be able to expand this to allow more options. Like only enabling it when the teams are larger than 3 people (or in percentage like 20% of the sv_maxclients).

    Also an option that disregards the condition that a player has to be dead in order for a teamswap to take place?

    Or an option that would alternate the teambalance. Instead of # of players, the amount of kills.
    Meaning that when team A has amassed a lot more kills than team B, a few players with substantial kill counts from team
    A are swapped to team B to balance the equation as much as possible. Additionally, a few noobs from team B could be forced to go to team A as compensation.

    Unfortunately, as mentioned in my previous post, detecting kills is a hurdle. I managed to stop most of the 'superbullets' by making the trigger not engulf the players eyes, since in reality bullets are calculated and shot from the eye bone. But by doing so, the trigger won't be able to detect most headshots.

    Code:
    main:
    	if (level.balance_running == 1)
    		end
    
    	println "[AIR TeamBalance]: Team Balance running!"
    
            // balance settings get loaded
    	local.balance = waitthread global/AIR/AIR_Control.scr::get_setting "balance"
    
    	while(local.balance == 1)
    	{
    		level.balance_running = 1
                    // main script detects cvar that changes the level.AIR setting(s) real-time
    		local.balance = level.AIR["balance"]
    		local.wait = level.AIR["balance_time"]
    
    		wait local.wait
    
    		if($player.size > 1)
    		{
    			local.team["allies"] = 0
    			local.team["axis"]= 0
    				
    			for(local.i = 1; local.i <= $player.size; local.i++)
    			{
    				if($player[local.i].dmteam != "spectator")
    				{
    					local.team[$player[local.i].dmteam]++
    				}
    			}
    
    			waitframe
    
    			if(local.team["allies"] !=  local.team["axis"]) 
    			{
                                   // if the difference is substantial (more than 1 thus ruling out uneven # of players), switch one player
                                   // the algorithm will repeat to see if another switch is necessary to balance
    				if(local.team["allies"] - local.team["axis"] > 1 || local.team["allies"] - local.team["axis"] < -1) 
    				{
    					if(local.team["allies"] > local.team["axis"])
    					{
    						local.guy = waitthread pick_random_player "allies" 
    						local.guy waitthread swap_team
    					}
    					else
    					{
    						local.guy = waitthread pick_random_player "axis" 
    						local.guy waitthread swap_team
    					}
    				}
    			}
    		}
    	}
    
    	level.balance_running = 0
    	println "[AIR TeamBalance]: Team Balance deactivated!"
    	
    end
    
    pick_random_player local.team:
    
    	local.got_him = 0
    
    	local.waiting = 0
    
    	while(local.got_him == 0)
    	{		
    		for (local.i = 1; local.i <= $player.size; local.i++)
    		{
    			if($player[local.i].dmteam == local.team && !(isalive $player[local.i]))
    			{
    				local.got_him = 1
    				end $player[local.i]
    			}
    
    			//no one seems to be dying... sick of waiting, just swap him already...
    			if (local.waiting >= 30)
    			{
    				if($player[local.i].dmteam == local.team)
    				{
    					local.got_him = 1
    					end $player[local.i]
    				}
    			}
    		}
    		local.waiting++
    		wait 1
    	}
    end
    
    swap_team:
    	//wait 1
    	local.team = self.dmteam
    	self auto_join_team
    	wait 1.5
    	if (self.dmteam != local.team)
    	{
    		self iprint "You were randomly picked to swap teams to even them out" 1
    	}
    end
    Last edited by Sor; December 27th, 2010 at 06:38 AM.

  6. #6
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default

    If editing existing commands is the only way, I think I can create a list of useless and even broken commands. Oh and there are plenty.
    The types are not really necessary, if they are all strings (which is most likely to be the default type) and we scripters know what value to expect, we can transform them ourselves:

    Imagine: local.a = "1"

    int ( local.a ) = 1
    float ( local.a ) = 1.000

    Or imagine local.a = 1

    string ( local.a ) = "1"

    Would editing / replacing them also mean renaming them? Else things could get confusing.
    But another question that pops to mind is this: if you can edit or replace them, can't you 'copy' one and then edit/replace that?
    If so, you can create new commands, right? Or am I oversimplifying this?

    EDIT: worst case scenario: you place all information into 1 cvar for every clientslot, each new bit of information in the same order and divided by ";". It is possible to split and transform that string into what we need.

    Just the ability to get that information would be bliss.
    Last edited by Sor; December 27th, 2010 at 06:56 AM.

  7. #7
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    thing with cvar is the easiest one atm but it's not nice.. could cause buffer overflow or something.

    I can't copy functions. The reason why I can't add anything is that all script commands are hardcoded into game engine. I would need to get into that more.

    I'm looking right now at game engine and I think it would be possible to add new variables to game. vars.

    Could be like:

    local.ammo = int(game.cl10_ammotype)

    where cl10 means: client number 10, after undersoce there would be vars like name, weapon name, weapon type etc.

  8. #8
    Administrator James's Avatar
    Join Date
    May 2010
    Location
    on the intraweb
    Posts
    3,180

    Default

    Razo, you still have that logfile from the source dump I sent you a while back? I believe there was a class or structure that had ALOT to do with the scripting, but I had a real pain in the ass figuring out how to reverse it. Maybe you can look into it. It was in the fgame.txt log file. I think if you do a search for player you should find it.

  9. #9
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default

    Cleanest way (but I suspect it would be a more difficult way...) would be to add those vars to the corresponding $player entities and updated whenever the value changes allowing simple checks:

    Code:
    local.currentweapon = $player[1].inventory_main
    local.rifleammo = $player[1].ammotype_rifle
    local.inventory = $player[1].inventory //= normal array? each slot containing a weapon the player has on its person, there is in fact a command ( :( not property ) called 'inventory' for players but it's broken as far as I know
    But if you went for the game. approach, may I suggest the moving the client number into an array?
    So I can easily check (self being the player):

    Code:
    local.ammo = int(game.ammotype[self.entnum])
    else I am required to do something like:

    Code:
    switch (self.entnum)
    {
       case 1:
          local.ammo = int (game.cl1_ammotype)
       break
             //........
      case 10:
          local.ammo = int (game.cl10_ammotype)
       break
    }
    EDIT: Structures? I have .chm document called 'Game Module Classes' which lists all structures and commands (with their parameters and a description) for AA and SH.

    Here it is:
    Game Module Classes.rar

    Contents lists the structures, by clicking on each one, reveals the commands that work for them. Commands are hierarchical and cumulative. Example structure: SimpleEntity -> Entity. Commands of SimpleEntity will also work for Entity but not the other way around.

    Index lists all commands alphabetically.

    And Search... searches the entire database for the given query. You can also use CTRL+F to find something on a page you're viewing.
    Last edited by Sor; December 27th, 2010 at 07:44 AM.

  10. #10
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Hey sor. What will happen if you will cast an array to string?

    AFAIK, arrays are just strings with special representation like:

    C code:
    Code:
    int array[5] = { 1, 2, 3, 4, 5 };
    MoH script:
    Code:
    local.array = 1::2::3::4::5;
    So doing a cast like this:
    Code:
    local.str = string(local.some_array);
    should result in something like:
    Code:
    local.str = value1::(5 6 7)::whatever::some_entity::etc
    am I right?

    If yes, then simply adding a string like this to gameVars (game.) should be ok to make arrays with values. We could export a lot of stuff from engine to scripts.

    I would just need to grab memory address of gameVars (which is a C++ class containing linked list of every var) and addresses of functions that allow to add stuff to that list. I could add new variables.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •