Jump to content

bb_

WFG Programming Team
  • Posts

    262
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by bb_

  1. Given the lobby changes to hide your IP from the lobby, we might be able to trisect which lobby user is malicious (and then act upon that). For the host who experiences a DDOS, please attach your mainlog.html to this thread (see https://trac.wildfiregames.com/wiki/GameDataPaths for where to find it). Make sure you to save the mainlog before you start 0ad again, since it will be overwritten. In that file all connection attempts are present, see the lines of the form

    XmppClient: Recieved request for connection data from {username}

    If one can change their IP address before the game, we have even more information (since the malicious user might store the IP to use later).

    • Like 2
  2. 18 minutes ago, Stan` said:
    10 hours ago, MoLAoS said:

    Separately, do you know whether the map check for building is defined in C++ or JS? Like if I want to have buildings that can only be built on specific tiles or one that is built on a tree or rock or on some other map object, where is that code stored?

    That's js.

    Not entirely accurate: you can pick up the code flow in buildRestriction.js (CheckPlacement), but the actual checks you are in the Obstruction cpp component (which is called from buildRestrictions, see the CheckFoundations calls).

     

    10 hours ago, MoLAoS said:

    Okay so make a Guild component with that stuff and add a getGuild function to Entity?

    What would you need the "getGuild" function for? You can query the guild component just like any other component: Engine.QueryInterface(entityID, IID), where the IID is the IID of the component so for the guild you will probably use IID_Guild, you define this by ending your new component with Engine.RegisterComponentType(IID_Guild, "Guild", Guild); Assuming you name the component Guild and use "Guild" for the templates.

    • Thanks 1
  3. 1 hour ago, MoLAoS said:

    Also can you assign unit/structure ownership to other units and structures or only the player?

    In the vanilla game, the ownership is handled by the ownership component, which assigns it to a player. Changing this to other entities requires cpp changes (as ownership is a cpp component (*cmpOwnership.*)). Not entirely sure what you want to do though. Any entity can call any entities components already. So if you e.g. wish to let one building issue a research in another building, you can simply do so by directly adding it in the queue: Query the ProductionQueue and call the "add to queue" function (don't know its name by heard, but should be easily found in ProductionQueue.js).

    If you want such a "Guild" building: make a Guild component which you add to the relevant building and let that handle whatever you want to let it do. (As advice make it a JS component, that makes querying other components much simpler)

     

    1 hour ago, MoLAoS said:

    How do I check whether a player has a unit created.

    You can use the RangeManager for querying all units of a player. From javaScript code this can be done by

    Engine.QueryInterface(SYSTEM_ENTITY, IID_RangeManager).GetEntitiesByPlayer(playerID)

    From cpp code it works the same: query the component and call `GetEntitiesByPlayer` with the relevant playerID. From the return data (its an array) you then can check whatever condition on the entity.

     

    1 hour ago, MoLAoS said:

    Additionally is there an existing function to check if a specific building had a unit garrisoned.

    Query the GarrissonHolder and call `GetEntities`. It will return you all units inside.

  4. Global function? You mean any call that starts with "Engine". Those are the cpp interface function, defined in the various interface files. The cpp files are in the source directory of the game (at least if you have downloaded the source, I hope you would work on top of the svn/dev version, see https://trac.wildfiregames.com/wiki/BuildInstructions). Any other global function could be in the globalscripts (grepping is usually a good idea).

    • Like 1
  5. Following the thread below, @wraitii and myself have tried out several ideas to limit the possibility of dancing. In fact 8 different patches have been worked out by the two of us. A thankyou goes to @ValihrAnt and @Feldfeld for some preliminary testing. Links to all the patches are available in the relevant ticket https://trac.wildfiregames.com/ticket/5106.

     

    TL;DR. As it stands now two patches have been committed. Firstly https://code.wildfiregames.com/D2913 by wraitii to stop the case of patrol dancing (arguably the easiest way of dancing). This will make units patrolling wait a few seconds on each waypoint. So at the waypoints the unit is immobile and thus will be hit by arrows. Patrolling units will keep responding to nearby attackers, even if they are standing still at the waypoint. Secondly https://code.wildfiregames.com/D2837 by myself, to limit the dancing possibilities for all moves. This patch lets unit take time to rotate while moving. Hence the unit will be shortly immobile each time it turns. Again arrows will hit the target much easier each time the unit rotates, and thus dancing should be limited. Notice the rotation time takes effect on ALL moves and ALL rotations during the move. So big masses of units will slightly clutter en move slower (one can use formations, which have a much better performance compared to A23b, to counter this).

     

    Albeit we hope dancing is fixed now, there is no way for us to be sure. The best way to get more certainty is for you, the experienced dancer, to try out the svn version and dance away. Bring your best dance moves to the contest and please upload any replays showing your dancing skills in svn.

    In case dancing is still intrusive in gameplay, some additional fixes are in stand-by.

    • Like 4
  6. 3 minutes ago, Nescio said:

    Doesn't it actually run twice a week, on Monday mornings too?

    Hmmm, I see the updates on some other days too indeed. Maybe. Could also have been manual updates/script reloads etc.

     

    5 minutes ago, gameboy said:

    But 'Learn To Play' hasn't been updated yet

    It HAS been updated ON TRANSIFEX. If someone (which could be you) translates it there, the translation will automaticly be ingame soon.

  7. Sure the translation hasn't been updated in game. But it should be available to translate at https://www.transifex.com/wildfire-games/0ad/dashboard/. The translation will then appear ingame at the next update. The update script runs every week (friday morning), and in some cases (in particular near releases) we run it manually.

    1 minute ago, Angen said:

    one is getting changes in svn strings to transifex, that's not visible on svn update (as far as I know) 

    It is done at the same time afaik. The translation update also updates the .pot files. Those are the source files of the translation i.e, they contain the english strings which need to be translated. The .pot files are also in svn (as you can see in the commit), and I think they are created and uploaded to transifex from the same script. We also pull the translations from transifex (i.e., get the .po files containing the actual translations) at the same time.

  8. > Is there a way to make some functionality to deregister from lobby after game starts? That could help.

    This is possible, in fact it is even possible to hack some naive way into the A23 lobby. Note to someone coding it: make sure dropped players can return. Late observers maybe less important. @badosuto do this one needs to adapt the lobby bots: only send the games which satisfy certain conditions to the clients. To actually implement it in the lobby, we should update the lobby bots we run. I am not able to do this but I guess user1 can (and otherwise I can ping other ppl). I think the easiest way to propose the change is making a phab revision with the changes (a mod won't work for this issue, since we need to change the serverside).

    Also a proactive ddos'er can still store the ip's of games being hosted and kill them when they disappear (obviously it will make it harder for the ddos'er).

    • Like 1
  9. Even though we would like to do something, we really cannot do much. Since your IP in the lobby is made public, everyone can figure that out. Yes it has been made harder to figure it out in svn, but in theory one always can figure it out. When someone is DDOS'ing your network. That is 100% out of our control.

    I only can give some advice:

    - Try setting another port when hosting your game (a stupid DDOS dude would only try the default, so might help a bit)

    - Use direct hosting/joining (you will need to share your IP via some other platform)

    - Contact your ISP, maybe they can blacklist some IP's

  10. 4 hours ago, Grapjas said:

    Edit: In the current state ridges can be abused with ungarrison from ships (AI doesnt do this though), however the units will likely get stuck. Ungarrison range seems to be huge. I'll fix later somehow 

    ships have a rather large ungarrison range, this is done to make ungarrisoning the units work smoothly.

     

    4 hours ago, Grapjas said:

    Ps: does anyone know why i have red waves in the water?

    https://trac.wildfiregames.com/ticket/2692

  11. Nice work!! If you are interested, we could make this part of the vanilla game. Feel free to submit a patch at code.wildfiregames.com. Some comments on your code: you seem to duplicate some lists, it would be nice to reduce that duplication (also it would be nice to unduplicate some of the chat handling of the vanilla). Maybe one can use (exerts from) https://github.com/hpcodecraft/ASCIImoji somehow? Especially the dictionary in https://github.com/hpcodecraft/ASCIImoji/blob/master/src/asciimoji.js seems useful.

  12. In addendum of the previous post: The lag will increase for everyone. Currently there is only command lag (commands are executed only 2 turns after they have been issued). But now you will also see the simstate a turn (or two maybe, need to think about that harder) behind, hence your commands are based on info of turn n-1 (or n-2), while the are processed at n+2. So There will be an additional turn (or two) for every command, causing more lag for everyone.

×
×
  • Create New...