They're still saved to file and rounded as Ints. no fractions stored.
I did try a few more formulas, and found an idea that did exactly
balance the price up to price-down.
I'm trying it on my mod-servers in v41, and it seems to be doing ok.
Instead of trying to cut apart the growth, I use it; The item chosen is
increased by the number of matching items, and then Each matching
item is lowered by 1. Both sides equal.
Multiplying by the market-factor to double or more the
growth.. still makes both sides even.

The difference, is that rather than simply not displaying the
water, Tattoine is made without water in the texture.
The system does not need to think about whether a tank is Under
water for fuel, whether bullets impact water, whether napalm fizzles..etc.


Saw someone pick it up few min ago. If it was you, you'll see it yourself.
Not sure how to solve this one then, as some features are intended
to be on-screen permanantly reguardless of perspective or distance.

Quite possibly we've just twisted the engines abilities in ways that
weren't expected, and Definately not the most efficient for those
that simply want lob a bomb.
However, since players find most maps in swars to give them faster fps
than elsewhere, it may be that what we've made isn't totally innefficient.

That can't be it, those things are only done during the shot phase.



The idea would be to break the large objects into smaller ones. That when put together still make the larger object. However, I've put in a hack that should make it work.

Heh. i'd love to try.. but my master modeler's wandered off.

For you, it's coding. If I did it.. then it becomes a hack.

Such as adding the line into the TankAICurrentMove::makeMoveShot
if (totalFuel <= 5) return false;
So they stop trying to use the last fumes repeatedly.

Or testing thier vision by increasing thier totalDistance factor, so that
bots sitting on the other side of the map, aren't shooting lasers straight
up..

Which is the next thing I need to solve... Bots with no other option,
attempt to snipe straight up if they have the weapon.


But as for the map objects, Thanks a ton. They do look correct now.
Maybe when these reworkings are farther along, I'll see about redoing
the maps to not need so much special attention.

Added.



Think this may be a rounding issue that may also be fixed.

Wicked.
They did look rather silly, sitting there spinning thier wheels.

As long as what we make looks like what I intended, I'll let the graphic
details be worked on by those that can tell the difference. I'd rather poke
and examine the actual game-play aspects.

At Revision 76.

Generating Code...
Compiling...
snprintf.c
Linking...
LUAWrapper.obj : error LNK2019: unresolved external symbol "public: __thiscall LUAScript::LUAScript(class LUAWrapper *)" (??0LUAScript@@QAE@PAVLUAWrapper@@@Z) referenced in function "public: class LUAScript * __thiscall LUAWrapper::createScript(void)" (?createScript@LUAWrapper@@QAEPAVLUAScript@@XZ)

D:\GAMES\S3Dbak\Scorchedv42\scorched\Release\scorcheds.exe : fatal error LNK1120: 1 unresolved externals

LUA.
Am I missing some components?

I got the same thing.

I get
loslib.o: In function `os_tmpname(lua_State*)':
loslib.cpp:(.text+0x886): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
LUAWrapper.o: In function `LUAWrapper::createScript()':
LUAWrapper.cpp:(.text+0x4c): undefined reference to `LUAScript::LUAScript(LUAWrapper*)'
collect2: ld returned 1 exit status
on linux

Even Linux's error messages have to be different.

Yes.

k. worked this rev.

now that it's in, what's it all about. and how can we help break //// i mean Test it..

Sorry forgot to add some files to the server.

I've added some scripting support for the weapons. Something I've been wanting to try out. Should allow very complicated weapons without having to put thousands of xml tags in.

Have a look at the definition for the "Test Script" weapon in the accessories.xml file. This basicaly says call script data\lua\accessories\test.lua starting with function runWeapon, and defines a global variable testvar1 as a test.

If you look in the script file it should give you a general idea of what the idea is. This script file currently has a whole load of testing functions in it.

giggle.. more complex weaponry? you know me so well.
I'll definately be burning this one to it's limits.

Anything that can let me cut my thousand-line weapons to much
smaller is a thrill to explore.

Examining test-script now.

I have a side question that isn't really related to code, play, or graphics.

In the mod of merge, there is a weapon that refuses to be added to the
stats-SQL base, although kills are still attributed to it.
It's name is simply Jack-Hammer, no special chars or anything.

I've blanked and reset the stats a few times over ther years, yet the
same weapon refuses to be stored while more oddly named weapons
are. What could be causing this?

I'm getting crashes again with rev 85. I'll see if doing some debugging brings anything up.