|
|
Post by Jagged Steel on May 14, 2014 0:16:44 GMT 1
Great news,Mogwaii, thanks for giving a full report. For comparison, what are the ping #s you guys see when you are on Gamespy? IP has always been a bit faster than Gamespy, for the simple reason that with Gamespy or Openspy they act as a clearinghouse for the chat during the game. This requires each player to send data back and forth to the Game or Openspy server. This is mainly for the ability to whisper from the chat room to players who are in games. The actual game is of course run only on the players PCs, and the game data does not travel to the Gamespy server. When you do a direct IP game the chat is sent directly from one player to the other and the whisper feature and such of Gamespy is not employed.
What I see are some great numbers, all in all. To me personally those are actually stellar ping numbers, it is very common for me to play people @ ~300 ping. This is because I am in the USA and most BKrs are in Europe. Anything under 300 for a transatlantic BK ping is pretty rare. Especially for me, as I am on the West side of the USA.
P.S: I have one small error to report with the new patch. The text Gamespy in the upper left corner of the Game Hosting room does not get changed to Openspy. I checked through and that is the only place that does not get changed I could find
.
|
|
|
|
Post by Major Pain on May 14, 2014 0:41:35 GMT 1
Update:
I've been working to change the Multiplayer Chat functions. The Chat window code is written in xml code and pretty straight forward. part of the issue at the moment is breaking down the code as to how the developers defined the message box and player list locations in regard to the graphic screen. They defined each 'box' as a region, and defined the scroll elevators as areas. The scroll buttons seem to be another type of static region.
This is important since making a change to the chat window has to be applied universally. Once the new code is written, all players would have to use the same version, or a issues could occur. I'm currently testing some changes, but until it is tested under real environmental use with others, it would be considered unstable. So far, the elevators seem to be working as modified.
Part of my purpose for this change is the limited number of characters that can be typed into the chat editor. I had modified that previously, but still needed to expand the chat area so it flows better. I'm currently trying to modify the fonts used, and perhaps scale them down to about 75% of current.
The Player list has a couple of things going on. One is the Player Relationship to the user, the second is the Player's status, like in chat, away of keyboard, etc. This function has a significant bug in the code, and I suspect this has been a long standing issue that has just been ignored or not focused on. Another issue is the Whisper function; It also seems to have its own bug. I found the problem accidently in the code but have yet to apply a correction. There seems to be a flag missing that prevents whisper messages from being displayed from all of the members in chat. So hopefully, I can resolve this issue.
The graphics as to the colors of characters uses Hex Color Codes with a transparency tag in the last two digits. This is a basic Binary Octal Code and can be modified. I'm hoping to make it possible for the user to apply changes to the color more to their liking. So if you want to change the fonts to a light blue, rather than the egg-white, it would be possible. The choices might be the only limiting factor, since only lighter colors can be applied due to the interface screen using a dark gray-green background. The interface graphic is representative of slightly rusted steel. This is within the original theme of Blitzkrieg of course.
As mentioned, before the Chat Updates can be introduced into the community, it would require that all users have the same version. Because of the significant changes, two versions would not allow the user without the new version to see anything in Chat. This is due to the way the new Chat Functions are handled by the interface code.
So I would like the community's thoughts on this subject. Should I continue the project or put it on the shelf for the time being?
I am concerned that MP users will be slow to apply the update. The current Chat interface works exactly as it did in GameSpy, LAN or Internet. The new one would overlay over the current one and only be applied to specific files on the users folders and function much the same way. The Interface Screen would be different, but within the same theme. It would also expand the number of characters that could be typed in a sentence in either the Player Interface or a game. Another new feature would be allowing the Player to talk or whisper to the Staging Area, which is the very same Player Interface.
What say you guys?
|
|
|
|
Post by Major Pain on May 14, 2014 0:48:43 GMT 1
I have one small error to report with the new patch. The text Gamespy in the upper left corner of the Game Hosting room does not get changed to Openspy. I checked through and that is the only place that does not get changed I could find . I must have missed that one. I'll look into it right away... Currently we have applied Overlay_BETA2. I have one other reported small issue with this one. Any other issues should be reported to me directly so changes can be introduced before we release BETA3. The purpose of the Overlay is to change all GAMESPY references to OPENSPY. I think we are about 99.5% done now. |
|
|
|
Post by Jagged Steel on May 14, 2014 1:01:12 GMT 1
I think that for the near future maintaining complete backwards compatibility is essential. I personally would love to see the things you are working on implemented, but for the purposes of having Openspy serve as a lifeboat for the Multiplayers keeping things as close as possible to what they have known for the last decade is the best bet. It is hard enough trying to convince a lot of those guys that Openspy really does work, and that it truly is easy to implement. A lot of these guys are not tech savvy in the slightest, and are pretty much luddites when it comes to Blitzkrieg. If Gamespy chat did not suck so bad (No links, no cut&paste, limited characters, no posting of pics, etc) getting multiplayers to migrate over to Openspy would be easy.
The ideas you have for fixing up BK Multiplayer should in my opinion perhaps be rolled into a package in the future , perhaps even including some fixes to known issues with certain unit .xmls and such. Of course if you are going that far you might as well include most or all of your units in there as well....
P.S: The wonky chat/whipser setup of Gamespy for BK has always been a huge issue. The ability to whisper from the lobby to players in a game has never been much use because the guy in a game or in a staging room can not talk back. What the whisper is mostly used for is by players harassing other players, whispering over and over to them while they are in a game. The other even bigger issue has always been the screwed up chat between someone hosting a game with a custom map and someone who is downloading the map . The downloads are incredibly slow for such a tiny file (we are talking 3-5 minutes) and the downloader(s) can type and their chat will be seen by the host, but the host only, and the host can not talk to the guys who are stuck downloading . 3-5 minutes is hella long time to gamers and lots of them get discouraged and give up, thinking that something must be wrong because no one is answering their chats.
|
|
|
|
Post by Major Pain on May 14, 2014 3:20:41 GMT 1
I've located the code that handles the chat between the Staging Room and the download area. The code was never implemented in the final released versions of Vanilla BK. Of course the code was never released in any Multiplayer version.
To change this so players/users can chat between all areas will require the addition of new code. For some reason, they did not provide the conduit that opens this up. The fact that the Whisper capability is possible to the Host during download or game, was there for the purpose of advising the host that a player is available. But I do not see a function for a new player to be added to a game, or to replace a player that wishes to withdraw. Since I don't have Multiplayer experience, I don't know if that is ever an issue.
Part of the problem with the code is how it handles the messages between users. Each message is treated like a string, not as text. This is why you cannot copy/paste in chat. I'm thinking this can be changed, but for some reason the developers had a reason to do it this way. Because I can't find out why, I can only surmise. Handling the message as a string makes does make sense, because the code is much easier to process. There is no stack or buffer issue as might occur on earlier machines by having to use resource memory. The basic function just collects the typed message into a primitive string function and posts it. It uses the same function for all users.
We must remember that when BK was released in 2002/03, PCs were still quite in their infancy. Graphics were primitive by today's standards and memory was a limiting factor both for the PC Resources and Graphics. Today, there are many things we have already done to exploit improvements to the game on modern computers. We are only scratching the surface so far. Changes in the code will allow further advancements and there does not seem to be much that cannot be changed. But the code as written, still reflects the systems of the day and creates limits on what can be done.
Most of the code exists in the UI Folder in the game folders. Changes for the purpose of Single Player games will likely be the easiest to implement. But because the same code does affect multiplayer games, this will create new issues. All menu interface resources are shared by both Single Player and Multiplayer. So without a sweeping change in the community, Multiplayers will not benefit and cannot implement the changes if others have not.
Having explored the various parts of the code for the last seven years or so, I'm convinced there is much more we can do. The game has always been an Open Architecture platform, and NIVAL provided us generous license to change the game. So in my mind, any file, graphic, code that exists in the folders is fair game. What so far is off-limits is the game engine itself... The Enigma Game Engine (also called the Blitzkrieg Game Engine). This includes the Map Editor and Resource Editor. The Game Engine .dll files (Direct Library Files) are a shared resource within the Engine itself and cannot be modified under copyright.
As part of my research, I have found that the code is already within our grasp to make some hefty changes. Some of the things that frustrate us can be changed. But again, I must offer a warning that Multiplayers cannot use these changes until there is widespread interest. As Jagged Steel points out, that will be a difficult and perhaps impossible process. Before I got involved in the Multiplayer part of BK recently, it had not occurred to me that the two platforms would move together using the same resources. So now I need to rethink some of the changes.
Now this does not affect Burning Horizon, Rolling Thunder or any other version that does not have the Multiplayer option. All of the BK releases use the same code, but some has been modified for specific parts of those releases. They all use the same Menu Interfaces and game resources. It is possible to change non-Multiplayer releases to Multiplayer by simply 'turning the MP code on', but unless the users have other players that share the exact same resources, it is pointless. This is clearly seen with the Rolling Thunder 1.3 patch which was released for the purpose of Rolling Thunder Multiplayer by LAN or Internet. It did not open the GameSpy option, but the code is there to do it.
This is exactly why it is imperative that any changes to the Multiplayer Interfaces must add the version of BK each Player is using. Example: Player ZORRO is using RT while Player XRAY is using Vanilla. They cannot play each other since the Resource Files are different. It would be possible for Player ZORRO to block some resources to only access the Vanilla Resource, but he would need to know how to do that and exactly where they reside. These of course are usually in .pak files, but today's players many times extract their files directly to the folders. If all players did this, the cross platform play would be easier to implement. Multiplayer would only use the original files and not any from RT or any newer version.
About extracting your game files. Why do we continue to not do this? I understand the purpose of MODS and sharing resources between players, smaller file sizes and the compactibility.
As I mentioned, BK was released in the day that PCs were somewhat limited and basic. Todays Computers are vastly superior. Internal Drives are perhaps 100 to 500 times larger than those in 2002/03. The cost has come down so much, that Drive Space is no longer an issue like 10 years ago. So extracting the game files just makes a lot of sense. They are open to you, and you can make changes as you see fit. It also makes it much easier to add new objects and models. Of course, Extracted Mods might make it difficult for you to locate these files. And even if you do not wish to extract the .pak files, you can easily look at what is there using 7-Zip or many other zip based programs.
Having said that, some of the Multiplayer issues might be solved if files are extracted. The code is designed to check each players resources... looking at each players files on objects and models used in a game. It does not waste time checking every file, only what is going to be used. If a difference is detected, the game will not run. The code does not handle this very well, so changes could be added that improves this function. Rather than a possible freeze or crash, it would default back to the Staging Area with a report to each player why the game failed to run. This would also apply to MODS. The MOD is timestamped for checksum verification. If the MOD has been changed, it will have a different timestamp so the checksum fails. Vanilla multiplayer cannot do this on the original game .pak and files. The Anthology .pak files are vastly different than what was released for the Original Blitzkrieg, so it must analyze the resources directly by entry.
My post really crosses into several areas of BK, but I posted here because Multiplayer is very much affected. Since we are trying to make it possible for Multiplayers to continue on a new server... other changes might be required beyond the Overlays that reflect the changes underway.
The future of BK-I depends on us and what we are prepared to do.
|
|
Mogwaii
Stariji vodnik
Pseudo n°2 : Adonaiis
Posts: 53 
|
Post by Mogwaii on May 15, 2014 21:51:11 GMT 1
Hello everyone, Well, I must admit not having the knowledge to support you on a subject such as this one, but it seems indeed very interesting and promising to work the source code of the game directly. I will of course support. I add this new test report : We again played a game session, on our Mod Offikrieg. We were this time three participants, and we have play 2H06. My comrades did not seem to lag, I noticed some subjective latencies early in the game. We had a lot of units on the map, but the game was quite playable, as Gamespy. I think we will conduct a test of the same map on Gamespy session to compare pings Gamespy Vs Openspy! For this, I had a ping of 35/47 with the host (Fricotin) and 113/128 with the second participant (GregFr). So, good ping ! |
|
|
|
Post by Major Pain on May 18, 2014 3:28:25 GMT 1
OK... after completely checking the OpenSpy_Overlay_BETA2, I have found the problem with the GameList Menu Screen. It was entirely my own fault and my oversight. There is nothing wrong with the code or program... and nothing wrong with OpenSpy. When I created the Overlay, I placed the Re-written file for OpenSpy in the wrong folder. A simple mistake given the huge number of files that I had to look through. I finally found the issue after the Patch did not work on my own laptop. It is then it dawned on me that there had to be a folder issue in my work. So my deepest apologies for the oversight. I have forwarded BETA3 to a couple of guys so they can see if it now works. Please post a screenshot of the Games List Page to show the correction. From my updated laptop:  |
|
|
|
Post by mortbertjh on May 18, 2014 10:11:22 GMT 1
Version2 in first page
|
|
|
|
Post by Major Pain on May 18, 2014 17:03:15 GMT 1
Thank you sir...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 2, 2014 14:20:49 GMT 1
Hi guys, is there any way I can translate the patch into Spanish?
|
|
|
|
Post by Jagged Steel on Jun 2, 2014 14:32:48 GMT 1
Hi guys, is there any way I can translate the patch into Spanish? This would be a good thing, there are quite a few Spanish speaking BK Multiplayers. I have walked through several with my pigeon Spanish, but it has been difficult. Not nearly as difficult as trying to explain this to the Russian speaking players, but still hard. I really don't think the patch itself has anything that needs to be translated (it only changes text from Gamespy to Openspy), but instructions on how to locate the Blitzkrieg/Run folder (Right clicking the BK shortcut and opening file location seems to be the most fool proof way) and what to do when it is placed there would be a good thing. In the other Openspy thread here I have a tutorial on how to do this in English, feel free to copy that one (it has pictures) and translate it. This has already been done in French. A German version is needed as well, although the average German speaker seems to know enough English to understand the instructions. Edit to add: Now that I have thought about it for a minute, the text in the pop-up window instructing how to engage the patch could be translated. If this is not practical, perhaps a pictorial translation showing exactly what the patch option window is conveying would be useful. |
|
|
|
Post by Major Pain on Jun 17, 2014 3:40:54 GMT 1
Let me add this... The help files on the Interface could be translated and would be helpful. Great suggestion! The buttons and other text we could also change, but this is usually just a word or two, like Chat, Server, or Game List. We can certainly do this. I will be glad to share the Source Files to Kevin and others who may wish to provide translation. I need to wait for NIVAL's final approval on the Code Changes for the new BK Anthology Patch. Once that is complete, then we can proceed. Those interested in translating text files... contact me by email. majorpain.one@gmail.com |
|
|
|
Post by Major Pain on Jun 25, 2014 13:19:50 GMT 1
UPDATE:
My conversation with the guys at NIVAL has been going well. Yesterday I received the Agreement which provides the necessary permission and adoption of the Interface Code I have written and submitted.
The Agreement states that GameSpy will not longer be the Proprietary Server... which terminated service as of May 31st 2014.
As of June 24th, 2014, OpenSpy will become the Official Blitzkrieg Proprietary Server, by this Agreement.
By the Agreement, NIVAL will adopt, own and copyright the code I have written that will continue to provide the Proprietary Server Multiplayer Option.
By the Agreement, and as we have always stated, The Blitzkrieg Team that has made this possible, and the Blitzkrieg Multiplayer Community will provide technical and other support to the OpenSpy Team as issues arise or conditions exist where the Community needs to work on solutions. This could include MODS or General Support in the future. This includes any DLC which is developed for the purpose of Multiplayer.
By the Agreement, the Modified Multiplayer Interface Code can be applied to the current version of Anthology which is available at GOG.com, and can be extended for use in Burning Horizon and Rolling Thunder... which have never had this option. Also, all previous NIVAL releases of Blitzkrieg are included in the Agreement. It is my intention to provide the new code as an Incorporated Patch to GOG.com for Anthology. This would be a .pak file.
By the Agreement, the Code Patch will be made available to all Blitzkrieg Players that want it, without regard to the version of the game they own, or where it was purchased. NIVAL has amended the EULA for this purpose. Also, Players may not be charged for the Code patch (excluding new Anthology Purchases through GOG). No commercial application will be permissible as to the distribution of the Patch.
Now is the time for the entire Blitzkrieg Community to come together. The solution is at hand which solves the GameSpy Server shutdown and makes it possible for the Multiplayer Community to continue to utilize the Proprietary Server Option in Blitzkrieg at OpenSpy. The Code can be applied to other Blitzkrieg releases, which I will do as need and opportunity or need arises. My hope is your comments and desires will drive this new option.
This modification will be known as the BK Anthology 1.3 MP Patch
MP does not stand for Major Pain, but Multiplayer... I just thought I should point that out.
It is my intention to make the BK Anthology 1.3 MP Patch available around July 5th. Various servers and sites will be used for the purpose of downloading the Patch. The Agreement has to be approved and signed, and testing conducted to ensure there are no unknown issues.
Stuff you need to know:
All patched Anthology Releases will become Version 1.3.0. This is necessary since the Patch includes a new Proprietary Server assignment and modified code in regard to the Multiplayer Interface.
Previous versions of Blitzkrieg will be upgraded to Version 1.3.x depending on the release date and version of Enigma Engine and game.exe.
Patched Blitzkrieg (Vanilla) will be Version 1.3.0. Note: Anthology uses the same game.exe for BH/RT.
Patched Burning Horizon will be Version 1.3.1. Note: There may be some issues in original versions of this release which will require additional Patches. It may require a change to the game.exe and the 1.2 Patch.
Patched Rolling Thunder will be Version 1.3.2. Note: The most recent RT Version is 1.2, although 1.3 was released for Multiplayer LAN.
The other releases will be determined as mentioned above.
Players that do not use the Multiplayer Options do not need this patch. There is nothing included in the Patch that changes GamePlay or provides additional single player game options.
Stay Tuned for another Update...
|
|
|
|
Post by bloodwork on Jun 27, 2014 23:49:25 GMT 1
Retail Anthology can be considered the same as the GOG Anthology version, right?
|
|
|
|
Post by Major Pain on Jun 28, 2014 4:15:22 GMT 1
Yes... both are Currently Version 1.2
Slight change in Version Assignments:
The base patch is 1.3.0: The Version assignment depends on the Title Release. This is due to game engine differences or game database collection. Example: Original BH is not does not cross platform with original RT. DATABASE collection and Scenario Source files are different. In 2008 BH was upgrade to RT Standard for Anthology. In Anthology version 1.3.1 BH & RT are supported. If you have original (CD) BH or RT then separate Patches are required. This opens the Multiplayer Proprietary Server Option on both. The Source code is the same, but the game engines are different - different .dll collection. It is possible to upgrade BH to RT standard with a BH patch, but this is still in development.
Very early Anthology in 2008 were 1.1 and need 1.2 patch. if you have Map Editor 1.4 you have 1.2 patch. Your menu screen will show the version. If 1.2, this patch will upgrade it to version 1.3.1.
If you only patch Retail or DLC Rolling Thunder, patch will update to 1.3.3.
If you have patch Retail or DLC Burning Horizon, patch will update to 1.3.2
If you do not play multiplayer, the patch is not required and version can remain at 1.2
Other:
Stalingrad = assigned version 1.3.4 Game Engine changes / code requires different index files and cannot be used on any other version. Not supported at this time. If this title is again released, patch can be developed fully. / ? New Release unknown.
Talvisota: Icy Hell = not supported at this time: Game Engine changes / but assigned Version 1.3.5 Likely to not see new release on this one.
Mission Barbarossa and Mission Kursk require Patch 1.3.1 (Anthology): These may be released in the future as DLC.
Panzerkrieg, Burning Horizon 2 (BK1): update to 1.3.8 / Game Engine change ? New Release unknown.
I'm very sorry this process seems to be moving slowly. This is new ground for NIVAL and this community, so many small issues to resolve and each must be correct.
I will announce now that discussion has covered additional game code modifications for future consideration. If this goes well and can be worked out, we may be permitted to make moderate gameplay changes in the command parameters (1.xml), indexing and minor changes to const. xml which control most range issues.
Input from this community will be collected as to the most desired changes. After data is collected, then the most desired changes will be provided to NIVAL for consideration.
If I get permission to modify the codes, then there will be a required testing period before fully produced and released.
Since the database collection which creates a reference file from the objects.xml and modobjects.xml files may be slightly modified, cross platform version play in multiplayer will not be possible. The checksum comparison will 'boot' both players back to GameList Screen, in theory. This has not been tested, so I have to theorize as to Version mismatch.
Minor gameplay changes are not really an issue... those changes have been going on for years, ranges, sights and changes to const.xml. What is at work here are changes code that is Hard-Coded and not accessible generally from within the game files. As most of you understand, everything in BK is based on 'C' 'modular' code with a vast amount dependant upon BINARY Code (Radix and Octals). If you have followed my writings and tutorials, then you understand Binary Code and how it works... 0s and 1s.
If this becomes possible, then new patches will be required for Version 1.4.x following the same Game Engine assignments.
Example: Anthology becomes Version 1.4.1.
|
|
