Patching extra functionality into <gamemd.exe>

[jonwil]

ok, I got the bridges destroying.
Now to implement repair hut code.

[jonwil]

Last things to do for bridges:
1.Fix any IEs or other bugs that exist
2.Find out why this is happening:

(as you can see, the piece of overlay near the lower bridge end is being drawn wrong)
and 3.Implement repair code.

That second one might be hard to fix and I may not be able to fix it (the bridge still works just fine, you can even shoot the section to blow it up) it just draws wrong.

[jonwil]

I think I might know whats causing that issue (based on tests I have run)
If you open the railbrdg.tem file (from the test rail bridge mix file) in one copy of xcc mixer and the bridge.tem file in another copy.
Then scroll down untill you can see the last 2 images for the first direction.
The first of these is the one that is causing the graphics glitch.
If you compare it, you will notice that the train bridge image is slightly larger and also moved relative to the road bridge image. It could be that this is a little off kilter and thats causing the issue.
The other possibility is that there is some subtle difference between the wooden bridge and the concrete bridge that I have not yet found.
In any case, its wierd that this only happens for the new overlay and not for the old ones and only for this one tile and no others.
If anyone has any ideas what to try (suggestions etc) please do let me know.

Here is my latest test build for you to play with:
http://users.tpgi.com.au/adsloptd/gamemn.zip

[Bobingabout]

if the graphics in the file are in a different place in the SHP, that would cause some graphic drawing glitches...

[jonwil]

After doing various tests and stuff, I can now say that (as far as I can tell) the train bridges work.
Wood bridges still work.
As do road bridges and both kinds of small bridge.

[jonwil]

ok, I put my latest build at http://users.tpgi.com.au/adsloptd/gamemn.zip
This is for testing purposes and also so that PaD can take it and put it along with whatever he has and we can work towards making a new release...

[Renegade]

Dude. Cut down on double-posting.
Of the last 6 posts, 5 were yours. That's not necessary.

[Bobingabout]

he's posting news, i say its fine... but i still recomend editing the last post you posted if it was less than 24 hours ago, and nobody else has posted. i think thats what renegade is trying to say.

i mean there was less than a 6 hour gap between the first and 3rd in your tripple post, that could have all been 1 post...

[pd]

Awwww currently, I'm kinda dead (physical education... I'm not the best at it )

Anyway, I'll get that exe later to make some merger with can make one exe out of our two.

From my side I can firstly say that the FourthPowerPlant= tag now works,
secondly, I'm just implementing the feature of having infinite fully customizable Psychic Dominator clones (would mean Ion Cannon btw).

[Blade]

A nice feature would be to let you set what lighting scheme to use for the dominator clones, no change, lightening storm or dominator lighting. Of course if thats already how it works, its already great

[Renegade]

If the last posting was more than 24 hours ago, I can accept it. I still don't like it, but I won't be mad about it. Yet this was ridiculous.
Delay from the second to the third post: 1:20 hours
Delay from the fourth to the fifth post: 4:05 hours
I mean, seriously. Not necessary. Edit button. Big, bright and not evil.
I'm not saying this for fun or to satisfy my despotic needs, but because especially in long threads like this, readabilty is a key-factor. Plus, every byte is sizing up my database

On topic: l33t, more Dominitors

[pd]

A nice feature would be to let you set what lighting scheme to use for the dominator clones

Thanks to FS-21, who told me that that stuff can be defined for each map.
I just followed the tags and I think you will be able to define the lighting as well

[CannisRabidus]

To support this, then a bug with lighting has to be addressed.

Some map lighting values which set one or more saturation values to greater than 100% do not get properly reset when a dominator lighting effect is finished (bug seems to be limited to the dominator and does not include the weather storm. Might have something to do with ambient change rate). The result is after a dominator effect is done, the map lighting can end up being set so that the map lags like a sonuvabitch.

A mpamaker can use a combination of map lighting and dominator lighting which avoids this, but if mods are going to introduce new lighting settings then this lag effect might be inadvertently introduced on some maps.

Also dominator lighting (depends on spsecific settings) can create weird effects on areas of a map if a raderuption weapon is used in those areas during the period that the dominator lighting is active. Stop using the rad eruption weapon, and the cells where the rad was in effect end up looking real ugly until the next dominator lighting effect. Again this could be an ambient change rate problem.

Another consideration is competing light settings. What happens if dominator 1 is activated, and dominator 2 is activated a couple of seconds later, followed by dominator 3 a few seconds after that?

[~Guest~]

What happens if a weather storm and a dominator are activated within seconds of each other?

[Bobingabout]

although its all possible, i think we getting a little paranoid...