[Micky C]

TerminX, on 11 July 2017 - 01:58 PM, said:

Would any of you have problems if I lowered MAXTILES down to a more reasonable number?

The AMC TC is currently up to around 24000. I still worry that we'll hit the 30720 limit, since we're currently at Episode 3 out of a 5 Episode plan, and certain additions such as new characters/enemies/effects can take up a LOT of tiles.

[Mark]

I guess you'll have to find yourself another engine to run AMC on so the devs can reduce the number for the rest of us.

[Striker]

Micky C, on 11 July 2017 - 04:24 PM, said:

The AMC TC is currently up to around 24000. I still worry that we'll hit the 30720 limit, since we're currently at Episode 3 out of a 5 Episode plan, and certain additions such as new characters/enemies/effects can take up a LOT of tiles.

If you use tilefromtexture, you may be able to save a few tiles by fitting some stuff into the unused gaps in the official tiles if you're not doing that already. That's what I've been doing with StrikerDM.

[Micky C]

Striker, on 11 July 2017 - 05:49 PM, said:

If you use tilefromtexture, you may be able to save a few tiles by fitting some stuff into the unused gaps in the official tiles if you're not doing that already. That's what I've been doing with StrikerDM.

We're already doing that. The TC started off in the era when the limit was only ~16000 tiles, so space was used very efficiently. We're making use of the per-map art feature a bit (which doesn't count towards the max) for once-off art which takes some pressure off, but we can't do that for most of the art.

[Jblade]

We're up to tiles092; the only limit we're not nearly hitting is the voxel limit essentially.

[Sanek]

 Jblade, on 13 July 2017 - 06:37 AM, said:

We're up to tiles092

That's why I've never made the AMC TC map, even if I wanted to. There's so much stuff you don't know what to choose!

[TerminX]

 Jblade, on 13 July 2017 - 06:37 AM, said:

We're up to tiles092; the only limit we're not nearly hitting is the voxel limit essentially.

OK, you're still under the limit of what I've decided to lower it to.

[Jblade]

Also I'm not sure what the changes to CON arrays were but a lot of them aren't working properly after rev 6343; before that they work fine, after I get this spammed to the console:

ifvare: invalid array index SPECIALIST_EQUIPMENT[77]

and so on and so on; I'm not doing anything exotic with the array and its size is defined as 128 in the con files.

The code line is simply:

ifvare SPECIALIST_EQUIPMENT[77] 2

so I'm not sure if reading directly from the array like that is the problem or what but I'll see if I can find more information.

[icecoldduke]

 Hendricks266, on 11 July 2017 - 04:12 PM, said:

We need to make it dynamic, starting at the DOS MAXTILES (6144) and reallocating up to the current MAXTILES gradually. That's the real solution. Same with voxels. Same with everything really, just up to the point where it breaks Ken's hacks of stuffing multiple return values into one 32-bit integer.

Instead of making some complicated system, just expose a magic number somewhere that mods can edit.

[Mark]

Is lowering Maxtiles something to make programming easier down the road or is there some performance/load times gained in lowering too.

[Mblackwell]

Yes.

[Mark]

wise guy

[Hendricks266]

 icecoldduke, on 14 July 2017 - 07:24 AM, said:

Instead of making some complicated system, just expose a magic number somewhere that mods can edit.

You don't know what you're talking about.

[icecoldduke]

 Hendricks266, on 14 July 2017 - 08:08 AM, said:

You don't know what you're talking about.

Can you elaborate?

[Hendricks266]

Automatically determining the proper value would be trivial, and it will always be both not too large and not too small.

[icecoldduke]

 Hendricks266, on 14 July 2017 - 08:15 AM, said:

Automatically determining the proper value would be trivial, and it will always be both not too large and not too small.

I just think its over complicating the problem at hand. Let mods figure out how many tiles they need and move on. You don't have to make everything automatic . That's just my opinion.

[Hendricks266]

 icecoldduke, on 14 July 2017 - 08:16 AM, said:

I just think its over complicating the problem at hand. Let mods figure out how many tiles they need and move on. You don't have to make everything automatic . That's just my opinion.

Users can and will get it wrong. Besides, there is always the matter of retrofitting.

My idea is a trivial solution to a trivial problem. Your idea is taking a cop-out when one is not even called for. I don't know what more to say.

[Mblackwell]

While the dynamic solution may be a bit more work up front it also means that it will always be exactly correct in every mod.

[icecoldduke]

 Mblackwell, on 14 July 2017 - 05:06 PM, said:

While the dynamic solution may be a bit more work up front it also means that it will always be exactly correct in every mod.

I guess I don't see the benefit of going down this route vs just creating a hard limit that modders can change. It seems like a decent amount of work, with little benefit .

[Micky C]

 TerminX, on 13 July 2017 - 12:13 PM, said:

OK, you're still under the limit of what I've decided to lower it to.

What is the new limit?

[TerminX]

 Jblade, on 14 July 2017 - 03:57 AM, said:

Also I'm not sure what the changes to CON arrays were but a lot of them aren't working properly after rev 6343; before that they work fine, after I get this spammed to the console:

ifvare: invalid array index SPECIALIST_EQUIPMENT[77]

and so on and so on; I'm not doing anything exotic with the array and its size is defined as 128 in the con files.

The code line is simply:

ifvare SPECIALIST_EQUIPMENT[77] 2

so I'm not sure if reading directly from the array like that is the problem or what but I'll see if I can find more information.

Would you mind putting together a simple test CON that exhibits this problem? The array features are working properly here and I was unable to reproduce it by adding a similar line to one of the projects I'm working on.

 Micky C, on 14 July 2017 - 06:22 PM, said:

What is the new limit?

24576.

[Jblade]

We're gonna have to wait till Hendricks adds that dynamic allocation system or whichever in that case, since that's not gonna be anywhere near enough to support 2 more episodes after this one. I won't argue it since I understand you're focusing on Ion Maiden development which is a bigger priority.

I'll see if I can isolate this problem or find a better example.

[Jblade]

I just did a quick test with getarraysize and it's reporting that the array size is 64 when I know it's bigger than that; it's using 81 so far and the defined size for the array is 128. This is an array that I save to disk and read from it as well, so is it possible that the issue is located there? I'm still looking into it and seeing what I can find.

[Jblade]

Just tested the new snapshot, unfortunately the bug is still present - I've put together a little example CON code that just reads the array file, is there a preferred place you want me to host it or do you want me to e-mail it to you? From the looks of it, something is setting the array size to 64 no matter what it's being set to. Even resizearray doesn't seem to fix this.

[Hendricks266]

You can up it to the AMC TC svn.

[Jblade]

Alrighty, done - you can find it as array bug.zip

[Hendricks266]

I haven't looked at it yet, but TX has kept trying to push fixes. Does r6372 help?

[Jblade]

Unfortunately not - I just tested it in the example zip I provided and it's still producing the message.

[Chip]

I seem to be getting an almost consistent crash with my own personal mod at a particular point in the same map. The problem is the error reported in Eduke32.txt doesn't suggest it's a CON file error but the problem started occurring when I moved to Windows 10. However, at the same time I had made CON changes but still was using the same snapshot so I'm unsure what's exactly going on. I have coded something so badly that the game can't detect it being a CON error? Is Windows 10 not liking something? Has the error always been here but Windows 7 just ignored it?

Anyway, the error is just 2 lines and is only reported when running Polymer. If I run Polymost then it doesn't catch anything (in fact it even cuts out half way through writing the txt file when running Polymost and you can see the last line written is incomplete)

Here's what Polymer records:

current actor: 1103 (1250)
g_errorLineNum: 2027, g_tw: 124

Is this a CON error? Is the number 1250 the picnum of actor 1103? (Which would make it the horizontal steam sprite.)

I tried using the latest snapshot but the issue still occurs. Furthermore, this issue only happens late on in the map. The area that causes this crash is perfectly fine early on.

Update: While playing around I've managed to get to the exact location - it's a crack sector but it doesn't crash while viewing the map. Again, this sector was fine earlier on in the playthrough but now crashes and says the line mentioned above.

[Danukem]

Quote

r6372 | terminx | 2017-07-20 01:57:50 -0700 (Thu, 20 Jul 2017) | 1 line

Another attempt at fixing the problems caused by my recent changes to gamearrays]

Any reports on whether this attempted fix was successful? Jblade?