This topic contains 20 replies, has 0 voices, and was last updated by  The AI 10 years ago.

  • Author
    Posts
  • #5953

    Bobirov
    Participant

    @rommel wrote:

    I need the updated docs and the clock is already ticking. It’s hard for me to imagine that we have tags that no one has the knowlegde to implement but that seems to be the case.

    Alright, I spent a better portion of the day making some considerable changes to the Landscape Documentation to reflect changes made in v41. They are still incomplete, but there is a lot of new and updated info in them now. In particular, the object placement docs have a lot of new info. Also, the boid docs is basically a good outline for how a movable object will look in the XML.

    For example, I was under the impression that this version was to allow map specific changes to be made to the server.xml file, ie… number of bots, gravity, weapon sizes, etc.

    I’m not aware of such a change? Although I could be wrong. The scope of changes in v41 is so massive I’ve certainly lost track of what all is possible. 😛

    #45837

    Bobirov
    Participant

    @laptops Daddy wrote:

    ps:
    are powers of 2 and multiples of 16 important?

    For textures, yes, it has to be a power of 2 size. But for a heightmap, I don’t think that it matters (Apoc USA = 320×200). However, I think the safest bet is keep the heightmap a power of 2 and possibly square and use the defn file to stretch it to the size you want. But the engine is capable of handling non-square, non-poweroftwo type heightmaps in my experience.

    As to how important that all is for the competition, well, I dunno the answer to that. 😛

    #45838

    Rommel
    Participant

    Hi Rob:

    Thank you very much for the updates. Would it be possible to get up with the rest of those involved in the upgrade and nudge them into sharing what they changed and how it effects the coding?
    @bobirov wrote:

    @rommel wrote:

    I need the updated docs and the clock is already ticking. It’s hard for me to imagine that we have tags that no one has the knowlegde to implement but that seems to be the case.

    Alright, I spent a better portion of the day making some considerable changes to the Landscape Documentation to reflect changes made in v41. They are still incomplete, but there is a lot of new and updated info in them now. In particular, the object placement docs have a lot of new info. Also, the boid docs is basically a good outline for how a movable object will look in the XML.

    For example, I was under the impression that this version was to allow map specific changes to be made to the server.xml file, ie… number of bots, gravity, weapon sizes, etc.

    I’m not aware of such a change? Although I could be wrong. The scope of changes in v41 is so massive I’ve certainly lost track of what all is possible. 😛

    Something new that I’ve noticed but can’t find documentation to explain: When looking over the rules for a server, several of the items listed now have an asterisk after them. I have come to the conclusion that these are indicators that the default value is being used but it is new and it isn’t noted where I can find it. At first glance I thought that those were items that had been harvested from the current map. Still not sure but I know I can look over the default maps provided looking for an instance where gravity, etc., has been defined. I’m not too interested right now in exploring blindly (LOL) or in doing a line by line comparrison with the source code for the two latest versions (when I can see) trying to find the changes and how they have been implemented.

    I must go get some coffee now. Krieg ohne Hass

    Sincerely,

    Generalfeldmarschall Erwin J. E. Rommel

    #45839

    Rommel
    Participant

    The Wiki indicates that map size must be (evenly) divisable by eight. This only seems important if you intend to keep the defalut values of 8 for the xsnap and ysnap and want the left edge placements consistant with the right edge ect.. It seems that I made a test map 200 x 200 and made snaps on 10 which worked as expected but that snaps on 8 would give satisfactory results except for the 2 sides that got shorted by the grid. However, I’m not sure that I actually tried this. I always use a 256 X 256 height map, and as you noted, use the defn file to modify the size.

    @bobirov wrote:

    @laptops Daddy wrote:

    ps:
    are powers of 2 and multiples of 16 important?

    For textures, yes, it has to be a power of 2 size. But for a heightmap, I don’t think that it matters (Apoc USA = 320×200). However, I think the safest bet is keep the heightmap a power of 2 and possibly square and use the defn file t o stretch it to the size you want. But the engine is capable of handling non-square, non-poweroftwo type heightmaps in my experience.

    As to how important that all is for the competition, well, I dunno the answer to that. 😛

    #45840

    imported_gcamp
    Participant

    @laptops Daddy wrote:

    Could you confirm that a large size (say 512×512) map has a chance of making it into the main game?

    It’s not the speed of the map, its having to tell the clients any changes that have been made during a round when they connect thats the issue.
    This can be a lot of data.
    512*512 is basicaly 4* the amount of data to send than the current maps.

    That being said, once they have connected it doesn’t matter. But clients trying to connect may have to wait out the round without being able to see the map.

    #45841

    Laptops Daddy
    Participant

    so that’s a maybe?

    #45842

    Bobirov
    Participant

    @rommel wrote:

    Thank you very much for the updates. Would it be possible to get up with the rest of those involved in the upgrade and nudge them into sharing what they changed and how it effects the coding?

    Well lets see here, thats basically Gavin and to a much lesser extent, Cbx. Most of Cbx’s changes are all documented in the Accessory docs. And Gav tends to leave the documenting to people who can’t code worth a flip, (e.g. me). I’d rather he spent time using that big beautiful brain of his to smooth out the code anyways. 😉

    I assume you’re wanting to know about this bit from the v41 TODO:

    Added: Per-level options to allow levels to specify specific options e.g. Teams, No Walls etc..

    I see there is a new options file in the data/landscapes folder called optionstest.xml that looks like this:




    WallType
    WallNone


    Teams
    2


    TeamBallance
    TeamBallanceAuto


    I’m just not sure where you’re supposed to point to that from. Obviously from either the landscapes.xml file or possibly the maps defn or tex file. I haven’t poked around enough to figure out where it goes and what the tag is to call it. Perhaps Gav can enlighten us as to where and how we make calls to the new landscape specific options files. 🙂

    That’s a sweet feature too, can’t believe I didn’t notice that until now.

    #45843

    Bobirov
    Participant

    Also, I’ve seen references to the new landscape option “includes” and “include” in the texture and defn files. I’ve seen this mentioned in the v41 TODO, but I don’t see an example of actually using it anywhere.

    It can be called in a defn or tex file and looks like this:


    location of .xml

    Looking at it, this is how you point to the options files. It also looks like include file can contain just about any other kind of landscape XML definition as well. So you could have a single include file that has your options, placements, etc all in one file if you wanted to I think. Basically you should be able to have any combination of the following definitions in an include file: event, sound, music, options, placement or movement.

    Now that I’m figuring this stuff out, I’ll try to put it up on the wiki. And sorry about cluttering up this news post. Just trying to keep track of my findings as I go so I have some frame of reference to look back on when documenting this stuff. 😛

    #45844

    imported_gcamp
    Participant

    Thanks for the good work Bob, I’ll have a go at the wiki myself tomorrow.

    Yes, you are correct about the includes. I thought it was a bit silly having to have seperate files for each definition (options, placements, etc) so any definition (and any number of them) can be in one file. And all files can be included using the same include tag.

    #45845

    Rommel
    Participant

    I’m not sure but it appears that the activity level a map produces is still a concern. Preliminary testing using a 320 X 320 landscape with numerous factory placements keeps locking up the client. This is the same problem that a few Marvelously Mad Modders experinced in version 40.1d.

    Are we effectively utilizing client side calculations now or is the server still responsible for transmitting too much data to Fulfil My Desire For Fire? It seems I’m still required to structure my maps to prevent chain reactions due to the 512K buffer limit and was under the impression that this had been remedied with the 41.0 release.

    Perhaps the volume of text detailing the items awarded to multiple players destroying multiple objects is more than anyone anticipated. See the attached file for an example of the data generated by the second shot. It locked me up.@gcamp wrote:

    @laptops Daddy wrote:

    Could you confirm that a large size (say 512×512) map has a chance of making it into the main game?

    It’s not the speed of the map, its having to tell the clients any changes that have been made during a round when they connect thats the issue.
    This can be a lot of data.
    512*512 is basicaly 4* the amount of data to send than the current maps.

    That being said, once they have connected it doesn’t matter. But clients trying to connect may have to wait out the round without being able to see the map.

    The above mentioned problem with newly entering players wasn’t taken into account when I was working on the following client side ideas but perhaps this idea solves that problem:

    Load the next round map with the appropriate number of bots to simulate the current game field. Then give them the option to skip or get in some practice shots while the bots shoot it out until the real round is ready to begin. Shots are a good audio clue that the round is still in play if they want to do something else. When the current game round finishes: reloaded the map, and enter them into the game as a new entrant.

    I tried changing the wave file in 40.1d to alert me to a new round only to find that it was used by something else as well. Perhaps a distinctive sound file could be used to allow people to do something else while waiting for the next round to begin? How about:

      Da da da da da daaaah! CHARGE !

    or something equally obnoxius to alert a late entrant or someone skipping out that the next round is about to begin.

    Enough on that …. back to MY prolem: 😛

    We don’t need a large landscape to have a very volitile map, but we do need a way to exchange the data without crashing the clients. 😉 Can we trust the clients to do something like this:

    Screen draws, deaths, weapons awarded, etc., could still be calculated on the server as before but only the shot data:

    [Player ID – Weapon Fired – Rotation – Angle – Impact Location] would be transmitted to the established clients:

    United States – Baby Missile – 180 – 45 – (x-269, y-185, z-23)
    Joe – ShockWave – 302 – 60 – (x-275, y-105, z-12)
    Fred – Baby Roller – 136 – 23 – (x-256, y-173, z-15)

    The impact location could be replaced with the power but this is all of the information that should be required for the client to accurately replicate the shots fired and damage inflicted.

    The client would utilize the compiled shot data to calculate the screen draws, deaths, weapons awarded, etc., and the check value. The check value would be used to locate and disconnect those that calculate false shot results due to corrupted external files or a corrupted core.

      SHOT LOOP – Check Client Shot Data for Corrupt Core
      Normal shot timer begins.
      Normal Server shot data collection begins.
      Server checks client shots for valid weapons, power, ect..
      IF Bad Shot = True
      Warn client they are using a corrupted core and kick client.
      Update server and client files to reflect kicked client.
      Notify remaining clients of rejected shot (no wasted shots).
      RETURN to SHOT LOOP

    END IF
    Server calculates shot results and check value.
    Server sends compiled shot data to clients (no buffer overload).
    Server begins client check value collection.
    Client calculates shot results and check value.
    Client sends check value back to server.
    IF Client Check Value != Server Check Value

      Warn client they are using a corrupted core and kick client.
      Update server and client files to reflect kicked client.
      Notify remaining clients of rejected shot (no wasted shots).
      RETURN to SHOT LOOP

    END IFEND SHOT LOOP
    Shot Results are approved and play proceeds.
    Server files are updated normally using server calculated shot results.
    Client screen draws, deaths, awards, etc., utilize client side shot results.
    Continue with normal server and client operation.
    There are places that are not properly error checked in this example (such as: client count = 0) but it is not being presented as the final layout. This is only meant to provide food for thought.

    The first loop should provide adaquate protection for the valid players. The server approval of the check value and the second loop could be eliminated if it was deemed to be excessively slowing shot speed. In that case, the server calculated check value could be sent to the client with the shot data. The client could compare it’s calculated check value to the one recieved from the server and take the appropriate action.

    This may require additional server checks to monitor and/or update the client information as the first method was envisioned to ensure client trustworthynesss and allow the clients to do all client side updates.

    Either method should seriously lighten the bandwidth required by allowing most all of the game data to be generated on the client side if this hasn’t already been fully implemented. The loops should seldom be required and should be appropriately discounted in evaluating this proposal.

    If this proves to be an acceptable process, it should be possible to have a very large number of target objects explode at once, if that was desired, without causing a communication error and ruining an otherwise very exciting round. I am anxiously awaiting the ability to create something wicked.

    I think I’ll go eat now. Krieg ohne Hass

    Sincerely,

    Generalfeldmarschall Erwin J. E. Rommel

    #45846

    Bobirov
    Participant

    Note: I put up a wiki page for the new Include Files. Also tweaked the other pages a bit to reflect the fact that things can be constructed in include files as well as their old, individual files as well.

    #45847

    Rommel
    Participant

    Thanks Rob:

    Are you having any trouble with crashes due to over runniing the buffer on OpScorched, or do you use a buffer larger than 512K ?

    @bobirov wrote:

    Note: I put up a wiki page for the new Include Files. Also tweaked the other pages a bit to reflect the fact that things can be constructed in include files as well as their old, individual files as well.

    In checking the updated Wiki section on Object Placement Files earlier today I noticed that the second set of tags noted in red:

      …….
      …….
      …….


    had not been removed. I’m not sure if you changed that after I checked or if I’m just worn out but I can’t find the example I was going to cut and paste here. As I’m sure you know, the old maps won’t load unless these are removed.

    Also, the section on Texture Files still contains the old border section description (in red):

      data/textures/landscape/default/cubemap.bmp
      data/textures/landscape/default/water.bmp
      1.01.01.0
      data/textures/waves.bmp
      data/textures/waves.bmp
      5.0


    Instead of this one I copied from your Apoc maps:

      data/textures/landscape/tropical/cubemap.bmp
      data/textures/landscape/default/water.bmp
      0.00.00.0
      0.490.830.94
      0.00.00.0
      0.290.560.91
      1.01.01.0
      data/textures/foam.png
      5.0

    Thanks again for the document updates. You’ve nearly restrored my faith in humanity. 😉

    I’m think I’m too tired to eat now. 🙄 Krieg ohne Hass

    Sincerely,

    Generalfeldmarschall Erwin J. E. Rommel

    #45848

    Bobirov
    Participant

    @rommel wrote:

    Are you having any trouble with crashes due to over runniing the buffer on OpScorched, or do you use a buffer larger than 512K ?

    No, and no. Opscorched doesn’t have a lot going on at once or anything like that though, nothing like Apoc does anyways.

    #45849

    imported_gcamp
    Participant

    @rommel wrote:

    Are you having any trouble with crashes due to over runniing the buffer on OpScorched, or do you use a buffer larger than 512K ?

    I would be interested in what crashes or buffer is being overflowed?

    In v41 the only data sent between the client and server is :-
    1) Any changes to the initial landscape since the client connected
    (this is nothing for people that connect at the beginning of the round).
    2) The move that has been made (around 30 bytes or so)
    3) Any people connecting or disconnecting (again small bytes)
    4) Chat text

    All calculations and simulation are now done client side for the graphics, and server side to prevent cheating.

    If you have a v41 mod that is causing issues I would like to obtain a copy so I can debug the issues you are seeing.

    #45850

    imported_gcamp
    Participant

    Bob the wiki stuff looks great, is there any area that you would like me to have a go at, or any information that is lacking.

Viewing 15 posts - 1 through 15 (of 22 total)

You must be logged in to reply to this topic.