Messages

406

Troubleshooting / Morale bonus discrepancy...

« on: September 23, 2013, 12:56:14 pm »

SavedBattleGame::getMoraleModifier()

leadership bonuses are currently at

commander:   150
colonel:   125
captain:   115
sergeant:   110

but UfoPedia.org says these should be

commander:   35%
colonel:   20%
captain:   15%
sergeant:   10%



intentional? oversight? Am i missing something

407

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 22, 2013, 05:58:13 am »

tryReactionSnap() breaks the loop (through potential shooters) when it returns false. It returns true

Code: [Select]

if (action.weapon
&& action.weapon->getAmmoItem()
&& action.weapon->getAmmoItem()->getAmmoQuantity()
&& unit->getTimeUnits() >= action.TU)
hence, if any of those are false, the loop exits prematurely, possibly leaving some reactors that are eligible to fire unable to fire.


I've sparsed down my commit ( and at present still stand by it ) It looks like this:

Code: [Select]

for (std::vector<BattleUnit*>::iterator i = spotters.begin(); i != spotters.end(); ++i)
{
if (tryReactionSnap(reactor, unit))
{
result = true;
}

reactor = getReactor(spotters, unit);
if (reactor == unit)
{
break;
}
}
Note that getReactor() returns whoever has initiative.



& here's how the base mission went:

408

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 21, 2013, 11:10:53 pm »

tl;dr : my tests showed the current code getting 10- reaction shots on red's .Sav, mine getting 10+


checkReactionFire(unit)
- getSpottingUnits(vs unit)
- getReactor(spotters vs unit)
   - loop, getReactionScore(spotters)
   - if best score, reactor = spotter *
   - else, initiative returns to unit.


* here is where i put in a check in an attempt to make sure the same spotter is not returned as the reactor twice in a row. But it now seems unnecessary, since iterating over the spotters-vector will never re-iterate over a single unit anyway. Thanks red.


So we get back to checkReactionFire(), passing in the best reactor. Here is the most suspect code:

Code: [Select]

if (reactor != unit) https:// ok, getReactor() returns unit only when no one bests the initiative
{
while (true)
{
if (!tryReactionSnap(reactor, unit)) https:// aggro, targetting, etc.

break; https:// but if that guy can't do it, why break???
https:// Maybe the next guy in the spotters-vector can...
reactor = getReactor(spotters, unit); https:// here.

result = true; https:// yes a reaction was successfully made
if (reactor == unit) https:// ok. if getReactor returns the unit itself, initiative has gone back to unit.
break; https:// -> break
}
}


btw, There seems to be redundancies between canMakeSnap() and tryReactionSnap() -- checking weapon & ammo, eg.

Will amend my code, and try to amend the 'reaction Update' commit.... oh and this is gonna require *playtesting*  :p


ps. I just don't like it. I'd much rather see the spotters-vector getting iterated over in checkReactionFire(). Why? Because i believe checkReactionFire() gets called only once per tile (when unit gets to its next tile during movement) or once when it takes an action like shooting. But checkReactionFire() calls getReactor(), where the spotters-vector *is* iterated over, only if the previously-identified spotter succeeds in making a reaction shot.

it would seem to smooth things out to consolidate (refactor) what's there,


anyway, time to relax on an alienBase mission: 2 xcom down, 10 to go..

Pps. Am i the only guy who doesn't like "while(true)" loops ? <- hint hint

409

Programming / Re: A bug in battlescape and a fix for it

« on: September 21, 2013, 12:14:11 am »

"latent-seeding"

save a seed, but give the option to regenerate it

410

Programming / Re: A bug in battlescape and a fix for it

« on: September 20, 2013, 03:10:44 am »

i think (no doubt ther've been threads on this, there sure have on the 2k forum, heh ) that saving a global seed is more so that bugs can be tested consistently, rather than to prevent save-scrubbing.

Personally i'm in the camp that says, the seed should not be saved if the only reason it's there is to prevent 'cheating'.

and i think the RNG is a simple stock one ( I'd certainly like a better one... just 'cuz! )


If a guy really wants a different result, can he/she just change a digit in the .Sav? Or perhaps a *new option* : Save Seed. If seed not found when loading, generate a new one (but i think that should wait till after v.1 for reasons above)

or maybe use a 'latent-seed' /cough -> 'latency' ( pun intended    Anyway,

411

Offtopic / Re: Did you ever bother with those complex score screens?

« on: September 19, 2013, 11:30:33 pm »

I use the Graphs quite a bit -- all those analysts in the backroom... studying newspaper clippings.*

i wish there was a [Set] button tho, that notched current levels of activity per, just out the rightside of the table, so it'd be instantly noticeable "Yep, that one's up; send a patrol!!"


* requires building-facility to access Graphs page ;p

412

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 19, 2013, 04:01:24 am »

i was hoping to leave it to the battledevs, but if they're all on hiatus i'll just have to have a look myself... god help us all.

oh just plug it in, fire it up, and remember to save tu's

413

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 19, 2013, 12:31:11 am »

im not that clever <g>

But the quick result of a test was that one of my soldiers *did take 2 reaction shots* at a muton without the muton apparently moving between the first and second snap.

414

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 19, 2013, 12:12:51 am »

kevL, why do you need prevent units from multiple reaction shots?
In vanilla Xcom, multiple reaction shots was possible.

hey red, that's what might be still a bit .. wrong w/ my code ( in the context of what's already coded ).

What i didn't like, and the reason for that check, is that it (seems to do) a good job of stopping a unit from *unloading all its TU, all at once* after only 1 initiative check

the downside that you point out, is that /maybe/ a spotted unit would need to expend more of its TU before a spotter can make a second or third attempt to RF -- although I'm not actually sure about that in practice. That is, in the firefights i've been getting I have a 50/50 suspicion that soldiers are in fact taking more than one snap without the spotted unit expending more TU ( when he has the Initiative ). these things happen in pretty fast succession so it's hard to be sure atm...

hence it needs testing IG, by persons well acquainted w/ orig behavior (and ofc who like to reserve TU). ... goal is to preserve/implement strict rules of "initiative", as per ufopedia.org


- will try to set up a test to look more closely & get back....


[ edit ] i think I read that it's actually energy-expenditure that's supposed to trigger RF, but that's not quite right either because kneeling can act as trigger in vanilla. The call(s) to start reaction fire could be scrutinized, as well as this post-call stuff above

415

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 18, 2013, 07:57:26 pm »

yeh RF is (by far) the most exciting part of the game to me,

rule of thumb: reserve 2 snaps + crouch... am now trying to go up & down GravLifts w/out losing "_kneeling" status too.


maybe Sup or one of the Battledevs can check out the new code this weekend

416

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 17, 2013, 05:49:28 am »

i opened a PR w/ my stuff

Before doing that I did a test on a clean nightly with the supplemental code. 4 soldiers coming up on a UFO door. A muton appears and 3 guys shoot, then the muton takes one more step and we really let 'im have it 


so it should be good, but i'm always uncomfortable until it's vetted,

417

Open Feedback / Re: X-Com reaction fire mechanics

« on: September 17, 2013, 02:20:34 am »

I'm not a dev, just a contributor, & have changed this in my personal build to:

Code: [Select]

https://if (reactor != unit) --> gone. Handled below...

for (std::vector<BattleUnit* >::iterator i = spotters.begin(); i != spotters.end(); ++i)
{
if (reactor == unit) continue;

if (tryReactionSnap(reactor, unit))
{
result = true;
}

reactor = getReactor(spotters, unit);
}
It's been working really good this past month RL (although it's the first bit of c++ i ever did and can now sense problems with it), especially when combined with preventing reactors from taking multiple reaction shots, ie. emptying their TUs all at once but instead waiting till unit makes another move before firing more volleys, in TileEngine::getReactor()

Code: [Select]

if (!(*i)->isOut()
&& canMakeSnap((*i), unit)
&& (*i)->getReactionScore() > bestScore
&& (*i) != bu) https:// kL, stop unit from reacting twice (unless target uses more TU, hopefully)
{
bestScore = (*i)->getReactionScore();
bu = (*i);
}

with those two changes i've been getting firefights very similar to the original.

418

Programming / Re: Features: Show chance to hitting and the throw trajectory

« on: September 16, 2013, 12:03:29 am »

add:
i also like the earlier forms where it disappears behind/beneath walls & objects

(otherwise my eyes are on a roller coaster going up onto walls etc)

and goes translucent on floors that the thrower can't see, perhaps, or that the explosion won't reach. i guess



/yap!

419

Programming / Re: memLeak when priming grenades?

« on: September 14, 2013, 02:39:12 am »

ok, thanks Sup.

will keep trudgin on then,

420

Programming / memLeak when priming grenades?

« on: September 13, 2013, 11:30:48 pm »

I'm just learning c++ (don't laugh unless you want to)

i have a lot of experience with NwScript (don't underestimate it..)


So, in PrimeGrenadeState.cpp, I come across the destructor and notice it doesn't explicitly delete _title, _window, _bg, etc. Yet in other destructors, eg. Inventory.cpp, I notice that these 'new' subobjects are explicitly deleted. So i'm wondering:

is that a memory leak?


[ edit ] I'm guessing, not, because in BattlescapeState.cpp i see a bunch of 'news' that are also not explicitly deleted (yet some are..) in the destructor. Perhaps some of those subobjects are automatically deleted when the object itself is deleted...