Michael-Z-Freeman / forgotten-hope-singleplayer

Automatically exported from code.google.com/p/forgotten-hope-singleplayer
0 stars 0 forks source link

Plugins fix for FH 2.4 #51

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Forgotten Hope has a system of plugins. Plugins are defined in mapdata.py file, 
stored in each level's folder, and are responsible for push-mode, ticket bleed, 
limiting kits, objectives (guns on Pointe du Hoc) and management of control and 
spawn points (e.g. "only team 2 can spawn on spawn point X").

I found that those plugins are completely broken in FH 2.4 singleplayer (SP) 
and co-op due to changes in 'perMapData.py' script and renaming of all SP and 
co-op objects (control points, spawn points and object spawners). As a result 
we have bots spawning in deep rear of enemy team, never-ending Ramelle's rounds 
and so on.

Long story short, I created a script, which repairs singleplayer's plugins in 
every mapdata.py, with the exception of the following plugins:
1) Kit limits (AFAIK, they don't work in singleplayer anyway).
2) Push-mode (Bots are not aware of push-mode and often attack uncapturable 
flags. I think, that such behavior ruins the game, but I'm opened to good 
arguments and can fix push-mode also).

With this issue I'm publishing fixed files as installer 'FH24 Plugins Fix.exe', 
attached below. The installer has an option of backup, so you don't need to 
backup files manually. Note, that on Windows Vista and Windows 7 you should run 
the installer as administrator, if your FH is installed in 'Program Files' 
folder.

For details of what plugins were fixed and where, see 'Fixed Plugins.xls' in 
attachments below.

Final note: I've tested some of the fixed maps (Anctoville, Brest, Giarabub, 
Pointe du Hoc, Sfakia and St Lo come to mind) with no issues. Ramelle still has 
American bots spawning in German rear, but to a lesser degree.

Original issue reported on code.google.com by gavrant on 29 Jan 2012 at 6:15

Attachments:

GoogleCodeExporter commented 9 years ago
Here's extended documentation for FH SP developers:

WHY PLUGINS ARE BROKEN IN 2.4 RELEASE
1) In 'python\game\perMapData.py' script line
    aliases = dict(sp1 = 'gpm_cq', sp2 = 'gpm_cq', sp3 = 'gpm_cq', gpm_coop = 'gpm_cq')
was replaced with
    aliases = {'sp1': 'gpm_sp1', 'sp2': 'gpm_sp2', 'sp3': 'gpm_sp3'}
So, in 2.3, if the game failed to find plugins for SP ('sp1', 'sp2', 'sp3') or 
co-op ('gpm_coop'), it used plugins for conquest ('gpm_cq'). In 2.4, if the 
game fails to find plugins for SP, it searches plugins for mysterious 
'gpm_sp1', 'gpm_sp2' and 'gpm_sp3' modes. Also note absence of co-op 
('gpm_coop') in 'aliases'.

2) In 2.3, all control points, spawn points and object spawners had the same 
internal name in conquest, singleplayer and co-op modes. In 2.4 they have 
different names for different game modes. The situation is worsened by the 
fact, that they were renamed in different fashion. For example, SP control 
points on El Alamein are called 'CP_64_SP_Something', while on Ramelle they are 
called 'Something_SP'. 

On most of the maps only conquest plugins are defined, so these changes 
effectively disabled plugins for SP and co-op.

HOW I FIXED PLUGINS
As I don't run any co-op server, I ignored co-op part. For SP, 2 ways of fixing 
the problem came to my mind:
1) Repair 'perMapData.py' and rename all SP objects in 'server.zip' for each 
level.
2) Add definition of SP plugins with proper object names to 'mapdata.py' for 
each level.
I chose second way, mainly because 28 'mapdata.py's weight far less than 28 
'server.zip's and so are easier to distribute.

I created script, which does the following for each level:
1) Reads 'GamePlayObjects.con' for conquest and SP game modes in 'server.zip', 
extracts names and coordinates of every object there.
2) Reads 'mapdata.py', extracts conquest plugins, discarding 'limitKit' and 
'push'.
3) Adds to 'mapdata.py' containers with SP plugins, if they don't exist. 
Conquest's object names are replaced with SP names by searching an object with 
the same coordinates. Some objects have different coordinates in conquest and 
SP or doesn't exists in SP, so I had to search them manually or ignore them. 
List of ignored plugins:
anctoville_1944, linkCPs
alam_halfa, linkCPs 
(CP_64_AlamHalfa_Northern_dummy,CP_64_AlamHalfa_Southern_dummy,CP_64_AlamHalfa_A
lliedFirstWave_dummy,CP_64_AlamHalfa_AxisBase_dummy)
meuse_river, linkCPs
tunis_1943, teamSPs

Changes in 'mapdata.py' files, made by the script, are marked with comments: '# 
Singleplayer plugins fix for FH 2.4 - START' and '# Singleplayer plugins fix 
for FH 2.4 - END'

Original comment by gavrant on 29 Jan 2012 at 11:01

GoogleCodeExporter commented 9 years ago

Original comment by djbar...@djbarney.org on 7 Feb 2012 at 9:56

GoogleCodeExporter commented 9 years ago
Priority raised. Almost worth critical status but not quite.

Original comment by bf2...@gmail.com on 16 Feb 2012 at 7:32

GoogleCodeExporter commented 9 years ago
Here's version 1.0.4446.26693 of plugins fixer (Visual Studio has interesting 
manner of auto-generating version numbers).

RELEASE NOTES:
1) It's an alpha version, it DOESN'T update mapdata.py yet, but can be used to 
check levels for errors and to clean them up. See attached '2012-03-04 103752 
(villers_bocage).log' for example of errors and diagnostics reported by the 
application.
2) The application needs .NET Framework 4. This version is shipped with Visual 
Studio 2010 or you can download it from here: 
http://www.microsoft.com/download/en/details.aspx?id=17851. Also, IIRC, it can 
be installed through Windows Update.
3) Command line options:
    Plugins.exe level [config]
where  
'level' is full or relative path to level folder. 'server.zip' in the folder 
should be unpacked.
'config' is an optional path to config XML file. If omitted, the program will 
use default 'config.xml' in its folder. As of this version, config is barely 
used, so you can ignore it completely.
4) All console output is duplicated in log files, see '<date> <time> 
(<level>).log' files in 'logs' sub-folder near Plugins.exe.

QUESTION:
Some levels have 'flags.txt' files near 'GamePlayObjects.con', e.g. see 
Ramelle's 'GameModes\sp3\64'. What should I do with objects defined in this 
files? Ignore them? Add them to objects from 'GamePlayObjects.con'? Or replace 
'GamePlayObjects.con's objects with them?

ATTACHMENTS:
1) Plugins.zip - the application.
2) 2012-03-04 103752 (villers_bocage).log - example of log with common errors 
and warnings.
3) Source.zip - source code.

Original comment by gavrant on 9 Mar 2012 at 4:47

Attachments:

GoogleCodeExporter commented 9 years ago
Here's a fully working version - 1.0.4453.39069.

RELEASE NOTES:
Notes for this release are the same as for previous one (see comment 4 above) 
with the exception of config files part. See sample 'config.xml' in 
'Plugins.zip', comments there describe how to tune the application. 

WARNING:
Plugins.exe rebuilds 'mapdata.py' files from scratch. This means that all 
comments, indents, collections, etc. from original 'mapdata.py' will be lost. I 
don't know what reaction it will cause amongst developers, so it may be worth 
to consult with others before uploading modified 'mapdata.py's to SVN.

Original comment by gavrant on 11 Mar 2012 at 6:53

Attachments:

GoogleCodeExporter commented 9 years ago
Brilliant work ! I just downloaded and I'll test as soon as I can. So, when/if 
we get to that, are you saying the objectives can be fixed ? Or does this 
script already fix that ? Push mode. Some kind of fix for this, however 
imperfect might be nice considering what we have heard about for the 2.5 patch 
...

http://fhpubforum.warumdarum.de/index.php?topic=16944.msg244537#msg244537

My personal opinion is that FH SP/Coop should be looked at as a training 
facility for MP. For single players and MP teams using the bots to train them. 
Seeing as I have not played in MP that much (if at all) I'm not sure how 
relevant this is but I suspect there is something to this. Coop is also easier 
and more configurable than simple SP to start a game. Another thing, I think 
Void is using the SP modes for various ESAI setups. He is obviously aware of 
this issue entry so that can be sorted out.

Good work !

Original comment by djbar...@djbarney.org on 13 Mar 2012 at 5:02

GoogleCodeExporter commented 9 years ago
DJ Barney, please, note that if you want to test it in 2.4, you should download 
'FH24 Plugins Fix.exe' attached to the first post. All comments and files below 
are for Void, for his work on coming 2.45 and 2.5 (most of the issue's 
communication between me and Void goes through PMs on the forum, that's why I 
bombarded you with questions about tracker's notifications).

And yes, 'FH24 Plugins Fix.exe' will fix ticket bleed on Ramelle mentioned by 
Natty, but not push mode in its true meaning - red crosses and green circles on 
the map (see explanation in the first post).

Original comment by gavrant on 13 Mar 2012 at 6:40

GoogleCodeExporter commented 9 years ago
Thanks, I'll try the correct download.

I suppose there could be a workaround for the bots on push mode, or some kind 
of compromise. Many at BFSP have probably looked at this over the years. But 
wasn't it Forgotten Hope that achieved the "impossible" in a few areas ? Like 
custom shaders as well as the anti-aliasing using the Nvidia control panel 
which is very fast. I'm sure there are other things they achieved. I remain 
inspired.

Original comment by djbar...@djbarney.org on 13 Mar 2012 at 9:06

GoogleCodeExporter commented 9 years ago
For clarity: 'FH24 Plugins Fix.exe' contains fixed files for 2.4 SP (not co-op 
and without push mode), 'plugins.zip' contains a tool for fixing files, you can 
use it to fix SP and co-op on any current or future FH release, including push 
mode, but levels often require manual tuning of the tool. 

As for push mode, AFAIK, its support by AI is possible with some tweaking 
(ESAI?), we just should wait for someone to do the tweaking. Until then I chose 
to ignore push in 'FH24 Plugins Fix.exe'.

Original comment by gavrant on 13 Mar 2012 at 10:22

GoogleCodeExporter commented 9 years ago
I have (at last!) started looking at the Python scripts so glad I held off on 
installing this as it probably would not have made sense to me. I can already 
see the potential for using aiFixups.py for solving some development problems 
that can't be solved by editing .con files alone. So need to apply your fixes 
first and continue from there :)

Original comment by djbar...@djbarney.org on 26 May 2012 at 6:49

GoogleCodeExporter commented 9 years ago
Sorry, DJ Barney, but after a week or so since your last comment I still don't 
see connection between aiFixups.py and mapdata.py. Files above mostly deal with 
control point-spawn point linkage and ticket bleed on each map, while 
aiFixups.py adapts some objects for SP and Co-op as a whole. IMO installing my 
fixes doesn't affect your work with aiFixups.py.

Original comment by gavrant on 5 Jun 2012 at 6:32

GoogleCodeExporter commented 9 years ago
OK, apologies for any misunderstanding. I'm still learning the Python setup. 
BTW I applied the installation .exe, but on Operation Supercharge the British 
side could no longer take one of the bases. Anyway, I probably need to do some 
manual tuning of it as you mention above.

Original comment by djbar...@djbarney.org on 5 Jun 2012 at 8:56

GoogleCodeExporter commented 9 years ago
I didn't fix Supercharge because it has only kit limits and push mode defined. 
See my first post above for reasons why I ignored kit limits and push mode, 
also see 'Fixed Plugins.xls' file there for list of fixed maps.

I recommend to test Pointe du Hoc. There is remarkable German spawn point 
there, between Observation Bunker and Flak flags. It should disappear when 
Americans capture Bunker. And Americans should get 'Destroy Guns' objective 
(small stars on minimap) after they capture Farm.

Also you should notice more sane ticket bleed on many maps (the maps are listed 
in the same 'Fixed Plugins.xls' file mentioned above).

Original comment by gavrant on 5 Jun 2012 at 10:35