Page 2 of 3
Posted: Fri Oct 08, 2010 3:22 am
by Merr
junk2drive wrote:Dooh! I hate it when I do stuff like that. Thanks
Yeah ... Join the club! .... 80% of my time is spent ensuring everything is where it's suppose to be.
I looked at everything else ... looks ok.
Also, I noticed you still have the FUNCTIONS.bsf in your Japan directory. You don't it because you c/p the functions into your scenarioBSF.
Like adherbal said, my way wasn't the cleanest way ... If it works for you, then fine. Since you're committed on this way I'd hate to see you struggle and go back to the cleaner way.
Posted: Fri Oct 08, 2010 3:30 am
by junk2drive
I moved your scripts folder into the battles folder and the sniper still doesn't fire until I am at 2 sq. And then, with ambush, he still doesn't get a kill. I have him at elite. (I think, you better check)
Posted: Fri Oct 08, 2010 4:28 am
by Merr
junk2drive wrote:I moved your scripts folder into the battles folder and the sniper still doesn't fire until I am at 2 sq. And then, with ambush, he still doesn't get a kill. I have him at elite. (I think, you better check)
Works fine for me. It's not the sniper logic, it might be your sniper's location...
Check the LOS of that map, where you have the sniper ... The "rough" can block LOS.
The best placement for a sniper would be to allow for clear shots out to 6 tiles ... I think you got the sniper too close to the front.
Remember ... The Enemy Sniper will use snipershot on his turn ... if he can't see you, he won't shoot.
Sometimes he won't shoot, yes ... but that's the complicated logic driving that. I forced him to shoot but sometimes he might not.
I played the scenario a few times ... The sniper shot on every turn.
Now, if you hate his HeReactionRange, change it from 2 to 6 ... but, I would suggest changing his AmbushSkill to read 100, meaning he won't reveal himself at all, 0% chance.
Posted: Fri Oct 08, 2010 4:52 am
by Merr
junk2drive wrote: And then, with ambush, he still doesn't get a kill.
To remind you, when he "ambushes" it's not a SniperShot ... it's the HEattack array [0]-[1] and the HE_effectiveness array [0]-[4] ...
If you feel he's not killing enough (when reacting) then bump up the numbers ... compare them to an infantry squad.
I lowered them because he's a 1-man unit ... Some of those values change effectivess by the (base) number of men, compared to the (actual) number of men.
Meaning, if you have 5 men @ 100, you got 1 man dead, it's now 80 ... 2 men dead and it's 60, etc.
Now ... I could code the sniper to use the "one-shot-one-kill" during a reaction, but ...
I use HEreaction because the sniper is basically using "snap-shots" on a moving target.
The SniperSHot (one-shot-one-kill) is a nice, relaxed, well aimed shot ... as it should be.
Posted: Fri Oct 08, 2010 4:58 am
by junk2drive
OK, my perception was off.
I'll put him somewhere else.
Posted: Fri Oct 08, 2010 5:14 am
by Merr
junk2drive wrote:OK, my perception was off.
I'll put him somewhere else.
The LOS is quirky in BA.
If you want to mess with the sniper to suit your fancy (tweaks), setup a flat test scenario, throw the sniper in the forest, and walk your men up slowly.
This what I did over and over and over again ... until I was sick of hearing "SNIPER!" every turn.
I encourage players to tweak the units ... You are the guinea pig since it's your first scenario with the new unit.
I expect your perception to be off without an explanation as to what's going on.
Rob
Posted: Fri Oct 08, 2010 11:34 am
by junk2drive
What I meant by perception is that when I read elite gets one shot one kill, I perceived that as every shot. I didn't think about all the other kinds of interactions between units. Your explanation makes sense.
I removed the functions.bsf from my main folder also.
Posted: Fri Oct 08, 2010 12:54 pm
by junk2drive
I used your bsf so that I could get turns and kills info. I moved the sniper. In this shot, I moved the scouts from the marsh/corn to the blocking tree. I checked LOS with the 1 key before I moved and all past the blocking tree was not highlighted. Now the scouts are in the tree hex and the sniper and another squad appear on map. Checking LOS I should not be able to see them.

Posted: Fri Oct 08, 2010 1:38 pm
by adherbal
Looks cool. A minor suggestion for the caves: for the "invisible/in FoW" texture, only make the cave entry (rocks) texture darker/greyer, while the grass texture remains the same. Or at least fade grey to green toward the base of the model, so the connection between object & terrain is more seemless. IMO It looks a little too artificial atm. Some grass & vegetation objects around the edges of the cave object would also improve its integration in the terrain.
It's all eye candy though, suppose you have more interesting things to work on first.
Posted: Fri Oct 08, 2010 1:55 pm
by junk2drive
Tim1966 made them for me so I am at his mercy.
They look good when lit up. That only happens when the unit inside is spotted.
Currently they
hide, not on map at all,
grey, unit inside not detected
grey, damaged
green transparent, unit inside
green solid, unoccupied
Maybe we need another dds state besides M, D, D_M
Posted: Sun Oct 10, 2010 3:37 pm
by junk2drive
I think the AI sniper should be more deadly on reaction and I haven't seen the AI use him yet as I have only done a dig in agg so far. I don't want to mod my numbers as I would like to stay in step with your adjustments and visions.
I am ready to use the A0 B0 C0, minefields and snipers in a 5 battle campaign. Are you done with them?
I am stuck with the 130 line csv limit at the moment.
Posted: Mon Oct 11, 2010 12:10 am
by junk2drive
I spent a lot of time today making csv's with no units, US/JA, US/JA/leaders/mines. Then the text1.
I created leaders and minefields for Allies and Axis.
Ready to test my first battle with all of the above, no promotions and snipers too.
Posted: Mon Oct 11, 2010 12:52 pm
by junk2drive
Played my first battle several times.
MoraleTools has the promotions, removed. US all regular, JA all elite.
Rally works great. You have to keep your platoons together and if more than one squad gets shot up you have to decide which one gets rallied. Suggest BN and CO get larger radius.
Wishlist: ability to name squads and units. A terrain type that cuts sighting/being spotted (tall grass, brush).
Minefield markers turn and fire at you. That's ok as long as the player understands that this represents his unit in an area of mines with a chance of hitting one. Maybe a different explosion type?
Now, if you hate his HeReactionRange, change it from 2 to 6 ... but, I would suggest changing his AmbushSkill to read 100, meaning he won't reveal himself at all, 0% chance.
On my last try, I increased HERR to 6 and AS to 90. One sniper revealed himself, another did not. I think of them as sharpshooters so that being good shots on reaction is believable.
All of the above changes the flavour of the game and tactics.
Posted: Sat Oct 16, 2010 3:47 am
by Merr
junk2drive wrote: Suggest BN and CO get larger radius.
Right now, the code for rally uses LOS and rally range... meaning, the unit has to be in LOS and within the rally range. The BN and CO (I think) have a max range of 6, which coincides with the max LOS range.
If you want, I can redo the code based solely on range (known as tile-step) instead of LOS. We can also look at range having a % chance for success, meaning the farther out the worse odds for a successful rally. Think of it like JTCS, when it comes to "ammo", they use a chance based on the units HQ distance. Something to think about, but, requires a bunch of code changes, as you know.
junk2drive wrote:Minefield markers turn and fire at you. That's ok as long as the player understands that this represents his unit in an area of mines with a chance of hitting one. Maybe a different explosion type?
The reason why the minefields turn and fire is because you forgot to "destroy" them in turn -1. For the minefields to work properly and be cleared, you have to add this code to FUNCTION StartTurn(side) ... remember, this will inflate the casualty report at the end battle screen ;
Code: Select all
if( GetTurn() == -1 )
{
int i ;
int id ;
int x ;
int y ;
int unit ;
for(i=0;i<GetUnitCount(1);i++)
{
id = GetUnitID(1, i) ;
x = GetUnitX(id) ;
y = GetUnitY(id) ;
unit = GetUnitOnTile(x,y) ;
if( (IsUnitType(unit,"MineField") == 1 ) )
{
DestroyUnit(unit, 255) ;
}
}
}
Also, I read you have problems with your funny ammo crates .... but I won't be able to help until I get back into town.
Merr
Posted: Sat Oct 16, 2010 4:01 am
by junk2drive
I had to go back and read my posts to see what you were talking about, lol.
Actually I find that snipers, rally, and minefields are working quite well. Try my latest battle when you have time.
Maybe Pip will get me the s3f for the crates and someone can fix them. I suppose I will need all the s3f at some point.
Posted: Mon Nov 01, 2010 6:53 pm
by junk2drive
In the bulldoze.bsf you have minefields and barbedwire listed.
I have the barbed wire in objects, not units. They work fine as objects but if course can't be cleared. Were you planning for the future?
Posted: Wed Nov 03, 2010 2:35 am
by Merr
junk2drive wrote:In the bulldoze.bsf you have minefields and barbedwire listed.
I have the barbed wire in objects, not units. They work fine as objects but if course can't be cleared. Were you planning for the future?
When I wrote the code for minefields I added the barbedwire thinking I could have the same "clearing" effect. After awhile, I decided to leave it out and look at other ways of doing barbedwire.
Since we can alter the terrain file now I was thinking barbed wire as this ;
- creating a new tile that costs almost the entire infantry units AP.
- placing this new tile under the barbedwire object.
- can't be cleared, the barbedwire is nothing more than a hinderance to movement.
With that in mind, I was looking at other obstacles, like Roadblocks, using the same idea.
Now, last month I asked Pip about the tile code and he mentioned using Globals when changing tile's. So, it sounds like it's possible to "clear" barbed tiles, ie replacing the tile with another tile. It would be alot easier if we had new scripts available to us when working with objects ... functions like ;
- AddObject
- RemoveObject
These would be alot easier to use since we don't have to define them as "units".
Also, adding objects can lead the way to a random map (someday).
Merr
Posted: Wed Nov 03, 2010 2:42 am
by junk2drive
Creating Kunai and trying to fix Ford showed me a few things.
Your barbed wire tile should use most of the AP, giving the player a choice of moving up to the wire and waiting, or moving to or through it. Then if ending movement on the tile, cover is the same as water, 0% to reflect the vulnerability while trapped in the wire.
Posted: Wed Nov 03, 2010 2:58 am
by Merr
junk2drive wrote:Creating Kunai and trying to fix Ford showed me a few things.
Your barbed wire tile should use most of the AP, giving the player a choice of moving up to the wire and waiting, or moving to or through it. Then if ending movement on the tile, cover is the same as water, 0% to reflect the vulnerability while trapped in the wire.
Yes, good idea, should be no cover bonus at all.
Were you able to follow my little tut on fixing the Ford?
viewtopic.php?t=18778&highlight=ford
Might as well create a new barbedwire tile (a unique texture would be good too) and see how that fairs.
Posted: Wed Nov 03, 2010 3:03 am
by junk2drive
I read the thread on ford. I then tried to fix the existing texts. Gave up as I don't have a need for it yet. Placing a rough overlay works, although gives a cover bonus.
While you are at it (terrain tiles) we need mud that slows troops and AFVs.
There is rubble overlays (or objects?) but I don't think they block.