Have made a few custom recyclers and they give some issues ..
When I have a recy-vehicle set up say ivrecy_1 and it uses classlabel "ivrecy" there is no problem, however when I create ivrecy_2 which uses ivrecy_1 as classlabel the game crashes with the following:
---- Battlezone II Log File ----
//=====================================================
App version: Patch 1.3TechAlpha5 EDITOR Apr 23 2009 13:39:30
Windows version: Windows Version: 5.1.2600 'Service Pack 2' PlatformID=2
Last few battlezone.log lines (may or may not be relevant):
DIAG| runcodes:113 |11:54:04|27234 |[Edit] Clearing runcode [object]
DIAG| MissionHandler:1269 |11:54:04|27234 |Expanded game UI file of 'bzeditor_exit_1024x768.cfg' not found. Using default of 'bzeditor_exit.cfg'
DIAG| runcodes:154 |11:54:04|27234 |[Mission] Entering run code [RUN]
DIAG| runcodes:154 |11:54:04|27234 |[View] Entering run code [COCKPIT]
(done)
Exception code: C0000005 (ACCESS VIOLATION) READING from 8F3E7DA7h
Message : Exception
Error occurred at 4/30/2009 11:54:46.
D:\Battlezone II v1.3ta5\BZ2Edit.exe, run by Red.
D:\Battlezone II v1.3ta5\BZ2Edit.exe, run by Red.
CPU: 2 processor(s), AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
x86 Family 15 Model 107 Stepping 1
Process Memory : 1602 MB free out of 2048 MB total
Physical memory: 2673 MB free out of 3328 MB total
Page(swap) file: 3708 MB free out of 4190 MB total
This exe is using 278 MB, peak use 278 MB
Fault address: 785738CC 01:000528CC C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.dll
Registers:
EAX:8F3E7DA7
EBX:0060A202
ECX:7FFFFFFE
EDX:0D740073
ESI:00000008
EDI:8F3E7DA7
CS:EIP:001B:785738CC
SS:ESP:0023:0206F588 EBP:0206F80C
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010202
Call stack:
Address Return Function SourceFile
785738CC 00000000 785547C9 vcwprintf_s+0x00004B17
785547C9 00000000 785548C9 vsnprintf+0x000000AB
785548C9 00000000 78554913 vsprintf_s_l+0x0000005B
78554913 00000000 004076F0 vsprintf_s+0x00000018
004076F0 00000000 00487D40 sprintf_s<64>+0x00000015
00487D40 00000000 0049322B Factory::Init+0x00000063
0049322B 00000000 0048490E GameObjectClass::Build+0x0000004D
0048490E 00000000 004B3F2E DeployBuilding::SimulateDeployed+0x000000FC
004B3F2E 00000000 004F5075 TrackedDeployable::Simulate+0x000002D4
004F5075 00000000 0046327E ENTITY::SimulateAllLocal+0x0000018C
0046327E 00000000 00463D55 MoveOneTurn+0x00000168
00463D55 00000000 00576510 MissionHandler::State::RunState::Process+0x00000333
00576510 00000000 004619BE RunCodes::Process+0x0000019E
004619BE 00000000 00576510 MissionHandler::Process+0x00000011
00576510 00000000 00575F68 RunCodes::Process+0x0000019E
00575F68 00000000 00449D60 Main::MessagePump+0x00000051
00449D60 00000000 00449A4F HandledMain+0x0000043B
00449A4F 00000000 004470E2 HandledMain+0x0000012A
004470E2 00000000 005BAED7 WinMain+0x00000059
005BAED7 00000000 7C816D4F memcmp+0x00000191
7C816D4F 00000000 00000000 RegisterWaitForInputIdle+0x00000049
When I change the classlabel to the default recy "ivrecy" the error can also happen but very random.
The interesting thing is that the building variant does work properly with a different classlabel.
I first noticed the error when actually building the tech-tree to check if factories would interfear with each other, which they do not.
As a test I also set up 5 recyveh. and deployed them 1 by 1 next to each other to make sure it wasnt caused by deploying a recy adjacent to an existing base, 5 recy's in a row works just fine :)
These are the recy's I'm currently using:
Base ivrecy:
[GameObjectClass]
classLabel = "ivrecy"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ivrecy_rs1"
provideName4 = "producer"
provideName5 = "nonhoverunit"
////////////////////////////////////
[CraftClass]
[TrackedVehicleClass]
[TrackedDeployableClass]
[DeployBuildingClass]
deployName = "ibrecy_rs1"
[RecyclerVehicleClass]
Base ibrecy:
[GameObjectClass]
classLabel = "ibrecy"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ibrecy_rs1"
provideName4 = "producer"
provideName5 = "basebuilding"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
buildItem2 = "ivscout_rs1"
buildItem3 = "ivturr_rs1"
buildItem5 = "ivcons_rs1"
buildItem8 = "ivscout_rs1m"
buildEmptyItem = 8
[BuildGroup6]
buildlabel = "Service Trucks"
buildItem1 = "ivserv_rs1"
buildItem2 = "ivserv_rs2"
[RecyclerClass]
Secondary ivrecy (working):
[GameObjectClass]
baseName = "ivrecy_rs1f"
classLabel = "ivrecy"// "ivrecy_rs1" <- crashes game on deploying recy!!!
unitName = "Field Recycler"
unitIcon = "icon_ivrecy.tga"
scrapCost = 120
scrapValue = 40
buildTime = 60.0
/////// REQUIREMENTS ///////////////
requireCount = 3
requireName1 = "ibfact"
requireText1 = "Build Factory"
requireName2 = "ibtrain"
requireText2 = "Build Training"
requireName3 = "ibtcen"
requireText3 = "Build Tech Cen"
////////////////////////////////////
limitclass1 = "fieldrecy"
limitclass1Count = 1
limitclass1Text = "Only One Allowed"
/////// PROVIDES ///////////////////
provideCount = 6
provideName3 = "ivrecy_rs1f"
provideName4 = "producer"
provideName5 = "nonhoverunit"
provideName6 = "fieldrecy"
////////////////////////////////////
[CraftClass]
[TrackedVehicleClass]
[TrackedDeployableClass]
[DeployBuildingClass]
deployName = "ibrecy_rs1f"
[RecyclerVehicleClass]
Secondary ibrecy:
[GameObjectClass]
baseName = "ibrecy_rs1f"
classLabel = "ibrecy_rs1" // or "ibrecy" <- both work, diff. is if I need to set up custom units again.
unitName = "Field Recycler"
/////// PROVIDES ///////////////////
provideCount = 6
provideName3 = "ibrecy_rs1f"
provideName4 = "producer"
provideName5 = "basebuilding"
provideName6 = "fieldrecy"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
baseSlot = 4
buildItem5 = "ivcons_rs1f"
[RecyclerClass]
An other minor thing is that the limitation of the recy:
limitclass1 = "fieldrecy"
limitclass1Count = 1
limitclass1Text = "Only One Allowed"
makes the factory say:
Only One Allowed
Only One Allowed
while a ivrecy_rs1f exists, but only shows 1 line when ibrecy_rs1f exists, as if I have 2 line specified like:
limitclass1 = "ivrecy_rs1f"
limitclass1Count = 1
limitclass1Text = "Only One Allowed"
limitclass2 = "ibrecy_rs1f"
limitclass2Count = 1
limitclass2Text = "Only One Allowed"
But I havent done it like that to try and prevent the double message from the factory when the first limitation exists, but doesnt seem to make a difference ....
ps: if you make an object look for itself, you get this (checked it to make sure I didnt make such mistake somewhere):
(http://members.ziggo.nl/red_spot/crash.jpg)
(you will need to use taskmanager to close BZ2 after this, if it lets you)
[GameObjectClass]
baseName = "ibrecy_rs1f"
classLabel = "ibrecy_rs1"
you cant have a classlabel in the same ODF. that class label needs to be "ibrecy" for starters
Probably an inheritance bug.
Quote from: TheJamsh on April 30, 2009, 10:30:35 AM
[GameObjectClass]
baseName = "ibrecy_rs1f"
classLabel = "ibrecy_rs1"
you cant have a classlabel in the same ODF. that class label needs to be "ibrecy" for starters
That part works like a charm. The basename points to an .inf file for descriptions and a .tga for an icon incase of units or towers.
Also from the patch13.pak:
[GameObjectClass]
classLabel = "ibrecyghb"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ibrecycm1"
provideName4 = "VIRTUAL_CLASS_RECYCLER"
provideName5 = "VIRTUAL_CLASS_RECYCLERBUILDING"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
[BuildGroup5]
buildItem1 = "ivconscm1"
[BuildGroup6]
buildlabel = "Service Trucks"
buildItem1 = "ivserv"
buildItem2 = "ivservcmd"
buildItem3 = "ivservins"
[RecyclerClass]
[Lod1]The commando B recy pointing to the GH-recy ....
Thats also why I dont understand how this does work:
[GameObjectClass]
classLabel = "ivrecyghb"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ivrecycm1"
provideName4 = "VIRTUAL_CLASS_RECYCLER"
provideName5 = "VIRTUAL_CLASS_RECYCLERVEHICLE"
////////////////////////////////////
[CraftClass]
[TrackedVehicleClass]
[TrackedDeployableClass]
[DeployBuildingClass]
deployName = "ibrecycm1"
[RecyclerVehicleClass]Commando B recy-vehicle pointing to the GH-recy. Its the same as what I'm trying to do, the difference is only a name and basename, where the name and basename dont seem to cause the issue itself ..
I'll try your suggestion TJ, if only for making sure that doesnt cause it ..
no what i mean is, lets say youre filename for the recycler is:
ivrecy_1.odf
you CANT inherit that ODF into itself, you need to use classlabel = "ivrecy" or something, not "ivrecy_1".
Commandos recycler is pointing to the GH recycler because he is taking some ideas from it without having to make more files of his own. the baseName doesnt make a difference to ODF inheritance. youre bug is definately inheritance related.
It looks to me like you have an invalid filename, a classlabel or a deployName: somewhere is pointing to something that doesn't exist.
Edit youre first post so i know what the filenames are...
Just ran a few more tests.
When removing the basename labels the issue continues.
However when I leave ivrecy_rs1f with classlabel ivrecy_rs1 and change the building to use the default ibrecy than it does work.
It seems one needs to point to the default directly, but that still doesnt explain why it works for the commando recy variants ...
===
I know TJ, thats what the last image of the first post shows. The names of the objects are the same as 'provideName3'.
The objects are properly linked, I'm sure of it as it works when only linking the vehicle or only linking the building and I can build both from the editor, or have a cons/fact create them. I just cant deploy the recy when both vehicle and building point to a custom recy, the base recy, which itself points to the vanilla recy. Its the same method as commando uses for his recy, I only added a name and informationdetails.
Yeh its a deploy name thing then... if you cant deploy it. If the deployName isnt valid, it wont deploy.
see for yourself:
error just happend:
---- Battlezone II Log File ----
//=====================================================
App version: Patch 1.3TechAlpha5 EDITOR Apr 23 2009 13:39:30
Windows version: Windows Version: 5.1.2600 'Service Pack 2' PlatformID=2
Last few battlezone.log lines (may or may not be relevant):
DIAG| runcodes:113 |13:20:31|36406 |[Edit] Clearing runcode [object]
DIAG| MissionHandler:1269 |13:20:31|36406 |Expanded game UI file of 'bzeditor_exit_1024x768.cfg' not found. Using default of 'bzeditor_exit.cfg'
DIAG| runcodes:154 |13:20:31|36406 |[Mission] Entering run code [RUN]
DIAG| runcodes:154 |13:20:31|36406 |[View] Entering run code [COCKPIT]
(done)
Exception code: C0000005 (ACCESS VIOLATION) READING from 8F3E7DA7h
Message : Exception
Error occurred at 4/30/2009 13:20:58.
D:\Battlezone II v1.3ta5\BZ2Edit.exe, run by Red.
D:\Battlezone II v1.3ta5\BZ2Edit.exe, run by Red.
CPU: 2 processor(s), AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
x86 Family 15 Model 107 Stepping 1
Process Memory : 1602 MB free out of 2048 MB total
Physical memory: 2661 MB free out of 3328 MB total
Page(swap) file: 3705 MB free out of 4190 MB total
This exe is using 278 MB, peak use 278 MB
Fault address: 785738CC 01:000528CC C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_6f74963e\MSVCR90.dll
Registers:
EAX:8F3E7DA7
EBX:0060A202
ECX:7FFFFFFE
EDX:09F42C73
ESI:00000008
EDI:8F3E7DA7
CS:EIP:001B:785738CC
SS:ESP:0023:0206F588 EBP:0206F80C
DS:0023 ES:0023 FS:003B GS:0000
Flags:00010202
Call stack:
Address Return Function SourceFile
785738CC 00000000 785547C9 vcwprintf_s+0x00004B17
785547C9 00000000 785548C9 vsnprintf+0x000000AB
785548C9 00000000 78554913 vsprintf_s_l+0x0000005B
78554913 00000000 004076F0 vsprintf_s+0x00000018
004076F0 00000000 00487D40 sprintf_s<64>+0x00000015
00487D40 00000000 0049322B Factory::Init+0x00000063
0049322B 00000000 0048490E GameObjectClass::Build+0x0000004D
0048490E 00000000 004B3F2E DeployBuilding::SimulateDeployed+0x000000FC
004B3F2E 00000000 004F5075 TrackedDeployable::Simulate+0x000002D4
004F5075 00000000 0046327E ENTITY::SimulateAllLocal+0x0000018C
0046327E 00000000 00463D55 MoveOneTurn+0x00000168
00463D55 00000000 00576510 MissionHandler::State::RunState::Process+0x00000333
00576510 00000000 004619BE RunCodes::Process+0x0000019E
004619BE 00000000 00576510 MissionHandler::Process+0x00000011
00576510 00000000 00575F68 RunCodes::Process+0x0000019E
00575F68 00000000 00449D60 Main::MessagePump+0x00000051
00449D60 00000000 00449A4F HandledMain+0x0000043B
00449A4F 00000000 004470E2 HandledMain+0x0000012A
004470E2 00000000 005BAED7 WinMain+0x00000059
005BAED7 00000000 7C816D4F memcmp+0x00000191
7C816D4F 00000000 00000000 RegisterWaitForInputIdle+0x00000049
Using the following odf's
ivrecy_rs1f:
[GameObjectClass]
//baseName = "ivrecy_rs1f"
classLabel = "ivrecy_rs1"
//unitName = "Field Recycler"
//unitIcon = "icon_ivrecy.tga"
//scrapCost = 120
//scrapValue = 40
//buildTime = 60.0
/////// REQUIREMENTS ///////////////
requireCount = 3
requireName1 = "ibfact"
requireText1 = "Build Factory"
requireName2 = "ibtrain"
requireText2 = "Build Training"
requireName3 = "ibtcen"
requireText3 = "Build Tech Cen"
////////////////////////////////////
limitclass1 = "fieldrecy"
limitclass1Count = 1
limitclass1Text = "Only One Allowed"
/////// PROVIDES ///////////////////
provideCount = 6
provideName3 = "ivrecy_rs1f"
provideName4 = "producer"
provideName5 = "nonhoverunit"
provideName6 = "fieldrecy"
////////////////////////////////////
[CraftClass]
[TrackedVehicleClass]
[TrackedDeployableClass]
[DeployBuildingClass]
deployName = "ibrecy_rs1f"
[RecyclerVehicleClass]
ibrecy_rs1f:
[GameObjectClass]
//baseName = "ibrecy_rs1f"
classLabel = "ibrecy_rs1"
//unitName = "Field Recycler"
/////// PROVIDES ///////////////////
provideCount = 6
provideName3 = "ibrecy_rs1f"
provideName4 = "producer"
provideName5 = "basebuilding"
provideName6 = "fieldrecy"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
//baseSlot = 4
buildItem1 = "ivscav"
buildItem2 = "ivscout"
[RecyclerClass]
That eliminates any problems within these odf's themselves I'd say, expect for the classlabel, so far.
Now lets try again with empty ivrecy_rs1 and ibrecy_rs1 odf's to eliminate it being an issue with those odf's
.. er .. dont know what causes this but when deploying above ivrecy_rs1f:
this causes a crash:
ibrecy_rs1:
[GameObjectClass]
classLabel = "ibrecy"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ibrecy_rs1"
provideName4 = "producer"
provideName5 = "basebuilding"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
buildItem5 = "ivcons_rs1"
[RecyclerClass]
This does not cause a crash:
ibrecy_rs1:
[GameObjectClass]
classLabel = "ibrecy"
/////// PROVIDES ///////////////////
provideCount = 5
provideName3 = "ibrecy_rs1"
provideName4 = "producer"
provideName5 = "basebuilding"
////////////////////////////////////
[PoweredBuildingClass]
[BuildingClass]
[FactoryClass]
//buildItem5 = "ivcons_rs1"
[RecyclerClass]
just commented out the cons, but the cons has previously build the entire base ... so the cons on its own is ok as well ... :s
Ok, I think I have found what caused the issue.
When I use the full iv/brecy_rs1f odf's (with names etc) but the custom cons in the ibrecy_rs1 odf has everything commented out I get this:
(http://members.ziggo.nl/red_spot/test1.jpg)
However when I leave the test-setup the custom cons has uncommented I get this:
(http://members.ziggo.nl/red_spot/test2.jpg)
Followed by a crash ...
The cons issues was it has ibfact_rs1f in its buildmenu which is linked to the base factory ibfact_rs1
Then when I go into ibfact_rs1 and comment out the option to actually build ivrecy_rs1f it again works.
The line in ibfact_rs1 is:
buildItem10 = "ivrecy_rs1f"
If I add to ibfact_rs1f:
buildItem10 = ""
Its still crashes, however if I add the following to ibfact_rs1:
buildItem10 = "ivrecy"
It does work ....
So to me it does seem all the assets itself are ok, it just that the game doesnt seem to like me being able to have a recy that can build a cons that can build a factory that can build the exact same recy as we started with ... sort of makes sence, but surelly didnt expect it ..
What still bugs me is that even if I do not allow you to build ibfact_rs1 which has the option to build the recy, but do allow the construction of ibfact_rs1f which is linked to ibfact_rs1 but has the buildoption cancelled out, the deployment of the recy still crashes the game.
Weird, removing the option to build a recy stops the issues. Leaving in the option to build a recy and making the revy-veh. or the recy-building point to the vanilla recy by classlabel also stops the issue ...
edit: Greenheart, Commando, if you do read this. Is this perhaps the reason you allowed the humans to build a vanilla recy instead of the same recy as the starting recy, or was that more intended as 'you lost your first recy so the second has less options' ?
dont quite follow what youre trying to do... but apparently you've fixed it.
first question... how the HELL did you get 'hold' to show up for deploy building class? that shouldn't be there...
Causing it to loop through inheriting odfs ? You don't have to use inheritance.
He probably used "trackeddeployableclass" instead of 'recyclervehicle" for classlabel, Jamsh.
Quote from: General BlackDragon on April 30, 2009, 02:37:55 PM
He probably used "trackeddeployableclass" instead of 'recyclervehicle" for classlabel, Jamsh.
Nope, its linked to the vanilla recy, but has some issues with not direct linking to the original odf's.
When the 'hold' command shows I'm guaranteed of a crash ...
What I did to solve it was simply make sure there are no more indirect links between odf's, meaning if B uses A as classlabel than C will not use B as classlabel but simply uses A as classlabel and gets the modifications found in B copied over.
===
TJ, what I'm trying to do is get 1 custom recy to build up a base where as last you get the option to build 1 extra recy with slightly less options. This all works if the 2nd recy doesnt have a custom factory, or uses the vanilla recy as classlabel, at least thats how it seems to work.
I'm not really sure how it is cause to tell you the truth just that it seems to work as long as I dont double-link the recy using the classlabel-flag.