Icon Distance

[Argh]

Anybody know why the distance variable no longer works?

I.E., in icontypes.tdf:

[seemefar]
{
bitmap=icons/neverseeme.tga;
size=2;
radiusadjust=1;
distance=4;
}

Does not equal four times distance.

Instead, it appears that there is some cutoff based on the size of the hitsphere going on. Anybody know what was changed, and why? There's nothing in the changelog about it, and it's pretty important, for performance reasons, that this feature works correctly.

[KDR_11k]

It was always based on the hitsphere size though at least in the past the distance was a multiplier for that. No idea if it broke since then.

[Argh]

Seems to be. No setting has the least effect now. Rather annoying, messing with hitspheres has knock-on effects all over the place.

[Pressure Line]

quickly looked at the source. it looks liek the code is still in there and working.

you state its for performance reasons (im guessing WorldBuilder stuff) if so you appear to be doing it wrong? that setting would cause the unit not to iconise until it is 4x as far away from the camera is it would at distance = 1. or i may have read too much into what you are trying to do. ^_^

[Argh]

It was just an example. And it doesn't work when tested over here. Changing it to 0.25 doesn't result in earlier removal from the scene, for example.

It doesn't seem to do anything at all.

One thing about this that may be the issue... is that the icontypes are all defined in one module, but that UnitDef's in another. I.E., I define them in P.U.R.E., not in World Builder.

If that is what's causing the problem, then there are deeper issues here. That should work.

VFS should not be looking for a local file for that. It should be using the iconTypes table, which should be constructed before any UnitDefs are even defined.

I don't suppose it's too late to say, also, that if more than one TDF defines stuff that should be loaded before unitDefs are even evaluated (i.e., you have more than one armor.txt, etc.)... they should get added to one another, not override each other, unless there's a name collision (imo).

[Pressure Line]

Whatever you are doing, its obviously rong Because distance works fine for me.



mech on the left has distance = 1, mech on the right has distance = 0.25. other than the icon type, the unitdefs (and the s3o) are identical.

[lurker]

VFS should not be looking for a local file for that. It should be using the iconTypes table, which should be constructed before any UnitDefs are even defined.

I don't suppose it's too late to say, also, that if more than one TDF defines stuff that should be loaded before unitDefs are even evaluated (i.e., you have more than one armor.txt, etc.)... they should get added to one another, not override each other, unless there's a name collision (imo).

VFS is how spring loads files. Virtual FILE system. It doesn't even know what lua is, let alone tables. Why do you insist on random jargon?

Only one file can have a particular name. Have two icontypes.tdf, and the most recent one gets used. It would be possible for icontypes.lua to do combination work if files from a single archive could be requested from the VFS, but they can't yet. One method you could use is a custom icontypes.lua in worldbuilder that loads icontypes.tdf and then adds onto it. If you only have a single icontypes.lua, then you should know that there is no code that would cause interference with unitdefs or cares about what archive they come from at all, so that guess is wrong.

Also, I have no idea why you would say that icontypes should load before unitdefs. As it happens defs.lua grabs unitdefs first before returning them both to spring at the same time, but it could go in either order easily.

[Argh]

1. PL, post some files, because it surely doesn't work like that over here. I'd like to see where I went "rong".

2. I'm talking about VFS, because that's where stuff gets overwritten that should be combined during the Lua period. Hope that makes things more clear, here.

That issue isn't just about the icon distance. It's about supporting modularity better.

This may just require some minor changes on the Lua end- I'll look into that.

[lurker]

But you can't combine files at the VFS level, that's like supergluing your CDs together. The lua that loads everything needs to combine, and the changes needed to VFS are simply to let you pass in an archive name for mode.

Argh, I guess you missed this part of my post: Do you have an icontypes.tdf in more than one module?

[Argh]

It would have been possible, had the TDF parser not become a Lua converter, but now it'll just have to be done with Lua. Not that big of a deal.

[lurker]

It's entirely possible, even easy, to combine files, but not at the file system level. It needs to be a smart converter whether C++ or lua.

[Tobi]

You could make the single file read all files in a directory and combine them together.

Then, as long as you devise some naming convention that will not make the files in archives that depend on each other clash with each other, you can have smart combination of such tables in current engine.

(e.g. similar to conf.d directories on (at least) Debian based Linux distros; also similar to how units are done in Spring.)

[Pressure Line]

The two icon defs.

Code: Select all

	[cyclops]
	{
		bitmap=icons/cyclops.png;
		size=2.0;
		distance=0.25;
	}

Code: Select all

	[cyclopsfar]
	{
		bitmap=icons/cyclops.png;
		size=2.0;
		distance=1;
	}

Both in the same file, in the same archive. I don't know why you would think that the files would be combined, since you are effectively using a mutator, and mutators do not work like that.

[Argh]

The reason I'm nattering on about mutators is a side-issue.

When you have multiple copies of certain files, it'd be better to add them together- i.e., if you have two copies of Resources.tdf, for example, where you really only have 3 files that are different... it'd be nice to combine them cleanly when the game runs, so that modules are easier to construct and maintain. Gotta remember, guys, P.U.R.E. / World Builder / Skirmish (something new I'm doing) are a lot of different modules. It's getting harder and harder to keep track of who does what, and I need to restructure things and move away from the current standard to support it better, because I'm quite certain that modular builds are the future.

That's an issue I'll look at when I'm done with version 1.2. Bit too busy atm, but I'll be happy to share the resulting work with everybody when I get to that. I'm sure it's simple to do.

[yuritch]

Combining files engine-side would be a bad idea. Reason: we (the S44 team) have put out a few patches that were overriding some files from our 'base' game archive to fix things (easier to dl 3 MB patch for the 71 MB main archive than the whole new archive). Some of those overrides were concerning buildtrees and icons, and any sort of auto-combining would have made a real mess of them.
Making it possible to combine such lists by means of custom lua is another thing entirely, that would be useful indeed - in that case the game developer knows what he's going to combine and what will just be overridden.

[smoth]

your icons could also be getting messed up because someone reverted a patch and aircraft YET AGAIN have 1/2 their hit sphere.