PDA

View Full Version : s3oc Counters Broke


HugeLunatic
23rd Jan 2010, 09:37 PM
Counters made with either version 0912-13 or 0911-28 both have corner counter issues. I can't get any older versions to work to find out where this started, since at one point it did since srikandi had done a counter.

In version 0912-13 - the corner counter texture reverts to I think the default texture of the clone. The counter base texture appears to be applied correctly, however the countertop texture looks like to changes direction. I cloned the Mission counter and the inset countertop goes blue, like no texture.

In version 0911-28 - the corner counter is black.

I haven't tested any other counters yet. I did uninstall WA to see if the cloner issue was affected by that but so far it doesn't appear to be so.

In both cases neither is cast-able.

Inge Jones
24th Jan 2010, 02:25 PM
Partly confirmed. The counter reverts to default when it turns into a corner counter, and is no longer CASTable. I didn't get "going blue" or black or anything.

This *used to* work. All the older versions are available in the same place as the current, should you ever want them.

HugeLunatic
24th Jan 2010, 04:24 PM
I have I think all previous versions still, problem is none will run. I get the standard "this app has quit working" and windows is trying to find the problem.

I have no idea why, nothing has changed on my computer. .Net is still all versions, Visual C++ redistrubutable/Runtime are still there. I use the manual install versions, always have. I thought uninstalling WA was maybe the issue, but it has not helped. I would really like to track down the version that it worked in.

pljones
24th Jan 2010, 04:35 PM
If you could, that would be very helpful.

Inge Jones
24th Jan 2010, 04:54 PM
Hmm if you still have the patch in that came out around the time of WA you won't be able to make good counters with a pre-December 13th version, they will probably cause blue-lotting or some other graphical glitch. So it would need someone with quite an early game configuration to run this test.

I am hoping Peter might have a eureka moment and spot an obvious code error.

HugeLunatic
24th Jan 2010, 05:57 PM
I've uninstalled everything, and as soon as MS Security Essentials is done scanning I will reinstall, and patch only if necessary. Work my way up through versions to find the error. I am not creating anything for sharing and am not worried about blue lotting. Only finding this particular issue.

I just hope the reinstall fixes the reason why older versions won't run. Maybe an issue with patch 1.7.9 and older versions.


ETA: Updating with s3oc version 0909-13 appears to have the counters work correctly, and the 0909-19 version gives me a corner counter that is black. This is on an unpatched base game.

Inge Jones
24th Jan 2010, 09:31 PM
The black corners can be fixed with Delphy's bluelotbuster. So does this mean Peter broke the TXTCs after they had been ok? I thought they were broken from the outset.

pljones
24th Jan 2010, 10:12 PM
Updating with s3oc version 0909-13 appears to have the counters work correctly, and the 0909-19 version gives me a corner counter that is black. This is on an unpatched base game.That's cut the range down a lot, thanks!

Inge Jones
25th Jan 2010, 04:47 PM
Unfortunately, for me, 0909-13 still has uncastable reverting corners - using fully patched and EP'd game.

What I did was renamed the Deltabuilds so that I could run early s3ocs ok, then named them back correctly before running my game.

The black counter is to do with the broken TXTCs (the bluelotters) and can be fixed with the Dashboard. But the uncastable counters I am now wondering is some problem introduced by or revealed by the patch.

Inge Jones
25th Jan 2010, 06:53 PM
I've been all the way back to 23rd August and it's still that way. I wonder whenever it *did* work?

HugeLunatic
25th Jan 2010, 06:53 PM
Ok, so I tested some more. I have no idea why yesterday the counter worked and recolored. Today it doesn't. I know I'm looking at the right version of the clone since I put the s3oc version as the name of the counter. But anyway.

I have an unpatched game at the moment. I had the black counter in the corner and was uncastable. I fixed it with the dashboard, and yes it did say it was corrupt. So now the corner reverts to default texture and is uncastable.

This is version 0909-13 and my game version is 1.4.6, no patches.

pljones
25th Jan 2010, 10:27 PM
0908-08-1553 was the first general release with MDLRs cloneable... internally we have about 24 versions between then at 23 August :D

Inge Jones
26th Jan 2010, 01:17 PM
Ok, this is not the problem it looked like. I mean it's a problem but not a new event. I had forgotten that it has always been the case you need to untick "Default Resources Only" when cloning a modular item. Unticking this causes all releases of cloner up to and including the December 13th (the current "public" release) to create correct corner cabinets.

I have not yet tested later versions.

Obviously the ideal is for us to identify what resources should have been considered default for a modular, and that is now on the to do list.

HugeLunatic
26th Jan 2010, 04:45 PM
I did some quick testing. It appears to need the xml files included for the counters to be castable. There are three and it seems they need all three. I tried with just the corner xml and it wasnt' castable.

I had some difficulties deleting resources and retaining the 2nd and 3rd color choices when I cloned with default box unticked. They would go to the shiny metal black texture in game, but were still castable. So by deleting img's and/or xml for those img's the other default recolors disappeared, even though those resources weren't included anyway with the default box ticked. So I'm not sure what's up with that part.

So what I did was clone normally the counter, then cloned the same counter with default unticked. Took the three xml's and imported into the one with defaults only ticked. Changed the instance numbers to match the corresponding counter MLOD.

Appears to work normally. I have an unpatched game and I was using version 0912-13. I hope this helps to narrow down the issue and we can get good clones for counters. :) Now off to do real work. LoL

Inge Jones
26th Jan 2010, 04:47 PM
What about the actual contents of the xml files? Don't they have references to other resources, and don't those references have to be updated to point to the renumbered resources in the package? Presumably not, if it worked for you, but I find it worrying and wonder what they're actually doing, lol.

pljones
26th Jan 2010, 06:26 PM
Well done! :)

Just for the sake of absolute clarity, could you quote the resource details (type, group, instance number) of the MDLR and the three XML files you're refering to? Thanks!

(I can happily parse and renumber stuff in XML just as easily as any other file, I think.)

Inge Jones
26th Jan 2010, 06:45 PM
Peter, do you think there is a case for getting in those xmls anyway now for all objects? We were always in two minds.

pljones
26th Jan 2010, 07:06 PM
I'll know more when I look at them... I can't remember right now. :)

HugeLunatic
26th Jan 2010, 08:04 PM
Well the instance number is different than the original counters since they have been renumbered, so I'm unsure of how helpful that would be. I'm just going to attach a working counter package, with cloner version and my game version as stated previously. It's in the catalog and is $5.

Let's hope my brain is comprehending this TGI thing:

MDLR 0xcf9a4ace.0x00000000.0x05d1d6b1e10d6c03
XML 0x333406c.0x00000001.0xb6ead297d7fdf7a5
XML 0x333406c.0x00000001.0x389661153ef3c4ba
XML 0x333406c.0x00000001.0x504ab04251c919c7

Each XML instance matches the corresponding MLOD/MODL.
ie:
MLOD/MLOD counterBaseContemporary has instance 0x05d1d6b1e10d6c03
XML counterBaseContemporary has instance 0x05d1d6b1e10d6c03

There are values in the xml files that are quite possibly incorrect. I think the key might be that I cloned the same counter and that is why it works. It references the same default colors. I don't know, I'm not that smart. :)

My testing methods are more of a "lets delete this and change this and see what it does." ;) And I'm happy to keep going like this if it produces a tangible direction to look for errors.

pljones
27th Jan 2010, 08:06 AM
Well the instance number is different than the original counters since they have been renumbered, so I'm unsure of how helpful that would beI meant the original values...
Each XML instance matches the corresponding MLOD/MODL.But this'll do me. :up:
My testing methods are more of a "lets delete this and change this and see what it does."That's about the only method I could think of -- you beat us to it! :)

Inge Jones
27th Jan 2010, 08:26 AM
Peter I already had this resource/connection on the flow diagram. It's one we thought hard about including before deciding not to. We just have to reverse that decision.

pljones
27th Jan 2010, 07:32 PM
It's one we thought hard about including before deciding not to.Sometimes nothing beats trying it in practice.

pljones
30th Jan 2010, 01:37 PM
QA version that's about to appear seems to have fixed this.