A new variant on WZ2100 - (Abandoned)

[Avestron]

Maybe the work being done in Warschool and the new vehicle gfx will sway this as the unrealised potential of scavengers is unsurpassed. every faction in warzone is a scavenger to be literal with the term.

Sorry that I took so long to reply - was busy feeling deflated ^_~

the idea i like best is to give scavengers tank chassis in later levels so as to make them truly viable as lets face it scavs would also have obtained military hardware not just the project, collective, nexus and NP. also if they are given the capability to bolster the strength of ruins added to by the ability to garrison their infantry with firing capability thy would be too powerful to deal with effectively the problem is everyone down plays their strength e.g. they do not use synaptic link and as such are less susceptible to the Nexus intruder program than any other faction (with the exception of NP advanced research)

[/quote]

I personally would like to see scavs with shotguns (range between MG and Flamer - scatter shot (similar to flamer but not incendiary) and chainsaws (similar to mechanic except inflicting damage) to help tide them over for low levels - and sniper rifles for T2 (direct fire but assignable to sensor).

It never occured to me that we'd see scavs driving various historic and contemporary tank chassis' into battle ^_^ That would be cool - as would improved masonry for their bases.

- - - - - - -

I have thought up a way of introducing a 'miscellaneous' slot upon vehicles without being too subtle or insufficiently so. Put simply it would require a 'plate' set between the body of the tank and the turret - positioned such that it can be as extensive or not in appearance as one likes.

eg. extra kinetic armour plating can literally look like a layer of plates set over the top of the flat parts of the vehicle while an improved engine could be a ribbed layer - possibly with exhaust pipe details. Self-repair could be a cyan plating with a '+' sign on it - all these mild visual queues.

That brings parts to: propulsion - body - 'extra' - turret - weapons as per turret.

Don't mind me - just mumbling.

[new paradigm leader]

I have thought up a way of introducing a 'miscellaneous' slot upon vehicles without being too subtle or insufficiently so. Put simply it would require a 'plate' set between the body of the tank and the turret - positioned such that it can be as extensive or not in appearance as one likes.

eg. extra kinetic armour plating can literally look like a layer of plates set over the top of the flat parts of the vehicle while an improved engine could be a ribbed layer - possibly with exhaust pipe details. Self-repair could be a cyan plating with a '+' sign on it - all these mild visual queues.

That brings parts to: propulsion - body - 'extra' - turret - weapons as per turret.

Don't mind me - just mumbling.

Au contraire these ideas are very very good and would further propel scavenger in standard combat

[psychopompos]

speaking of scav snipers. look up the "XM109" anti-material rifle.
would also be useful if scav infantry where invisible (until about flamer range), unless moving.

would give them a real tactical advantage.

[new paradigm leader]

speaking of scav snipers. look up the "XM109" anti-material rifle.
would also be useful if scav infantry where invisible (until about flamer range), unless moving.

would give them a real tactical advantage.

umm how in hells name would that work?? two things they are scavengers who at first lack hardware
and two how would they have personal cloaking?

[XANAX]

umm how in hells name would that work?? two things they are scavengers who at first lack hardware
and two how would they have personal cloaking?

maybe these scavengers raided Area - 51

[Avestron]

Actually I agree that scavs should have a degree of personal anti-detection.

I mean - they are very small incoherent blots on the terrain ;c) Even we have a hard time seeing them, let alone the units ^_~

add terrain cover like poorly trees and bushes occupying squares and you would really have potential for ambush.

Snipers would need to be assigned to sensor and have a straight shot to work over long distances.

[XANAX]

Actually I agree that scavs should have a degree of personal anti-detection.

I mean - they are very small incoherent blots on the terrain ;c) Even we have a hard time seeing them, let alone the units ^_~

add terrain cover like poorly trees and bushes occupying squares and you would really have potential for ambush.

Snipers would need to be assigned to sensor and have a straight shot to work over long distances.

wheeled vehicles beware *shooting out tires*

[psychopompos]

umm how in hells name would that work?? two things they are scavengers who at first lack hardware
and two how would they have personal cloaking?

first... camouflage...
if they have been living and surviving on the surface & not been eliminated by project/paradigm level forces they need to have some way to hide their asses.
and cammo is the obvious answer, possibly make them translucent to denote their camouflage ability

second...
the xm109 will be ancient tech by 2100, and they will need 25/30mm anti material rifles at the very least to deal with better equipped forces.
arguably you could start them off with .50s and other assault weapons.
but regardless, the rifle type i am talking about would be essential to survival for these groups!
as it is essentially a sniper rifle that can put a round through a medium armoured vehicle!

concealment, range, penetration, cheaper then a vehicle.
everything you need as a small partisan/guerrilla force.

the annoying thing would be, would wz support such 'invisable' units?

[Avestron]

I could be recollecting phantoms but I am under the impression that the code 'could' support units with personal counter-sensor abilities.

I do not think that translucence would generally be necessary - just have the units 'ripple out' at a shorter distance than would be the case.

- - - - -

Now on a different note I would like to return to the question of bridges in the game.

It is my opinion that the way forward here would be to treat hardcrete as a layerable and upgradable structure in its own right.

Constructing hardcrete upon bare terrain leads to a hardcrete surface of height zero - similar to VTOL pads.

Constructing hardcrete upon a hardcrete surface results in a hardcrete wall of bunker height

Further upgrading this hardcrete leads to a hardcrete wall similar to that normally seen.

Further upgrading this hardcrete wall leads to a height 3 hardcrete wall - and this is the limit for a truck on height zero.

Hardcrete can further be heightened if a truck is with 3 height levels of the wall.

- - -

Now comes the fun part:

A hardcrete surface is effectively a road surface. Wheeled vehicles are able to progress faster upon this surface

- - -

A hardcrete wall of 3 layers or more can be made accessible to small units - it generates a tunnel at a cost of some durability. This permits a wall to allow cyborgs through but no vehicle units. (Improved Engineering)

- - -

A hardcrete wall of levels 1 and over can be modified to be traversable - this results in the wall having a fence crown with crown missing where adjacent to other similarly modified hardcrete - creating a road surface that units can travel on. (improved engineering)

- - -

A hardcrete wall of 3 levels or higher can be extended from atop its walls via a truck - creating a hanging hardcrete layer. After being made suitable for travel a truck may drive upon this surface and extend this overhang to a 2nd tile.

(an accessible wall may also be constructed upon) (advanced engineering)

In order to extend it further this second tile must be further upgraded with a support tower - resulting in a bridge with a tower every other square. (improved engineering)

Advanced engineering permits an additional space between support towers (and there is no rules against fully upgrading a bridge with towers to block passage)

When it comes to the down ramp - presuming that construction has to be completed from atop a bridge - that is the hard part - either invest upgrades into a section until it hits the water or add a button specifically to lower the level of an existing overhang and then upgrade it downwards

i.e. build final overhang -> lower level of overhang and make it upgradeable downwards -> upgradethe wall to the ground

Or a button to specifically create an off-ramp (with all costs calculated by AI)

- - - - - - -

HP calculations:

Level - HP

0 - 350 (no team colors - not automatically targeted)
1 - 500
2 - 650
3 - 750
4 - 850
5 - 900
6 - 950
7 - 975
8 - 1000

Modifiers:

Overhang = -50% Tower supported = +25% (overhang with tower support = -25% hp overall)

Accessibility mod = no modifier
Access tunnel = -15% hp

- - - - - - -

Hardcrete synergy - a hardcrete wall gains improved anti kinetic energy of 'X' for every hardcrete wall adjacent to it (maximum 4 increases - i.e. 4 walls)

[Avestron]

Yes its somewhat dead here but better to revive it than opening new threads every time (and the ideas threads seem too akin to a mass grave).

I've been thinking of how player control of units can be improved and I focused upon the following tow scenarios:

1.) A single unit: - I always find it rather frustrating that a unit seems unable to navigate a tight spot without disturbing units to either side of that path - as well as being unable tofully control where that unit is going to stop and when (even tracked vehicles have a turn arch rather than 360 on the spot turning)

I think that it would be beneficial if single units and groups of units (mouse drag selected) could be micromanaged via the keyboard. Meaning that a player can select units and use the numerical pad (with num-lock off) or the directional keys to micromanage navigation.

All numbers except 5 represents a generic direction - combined uses of direction keys can also result in diagonal movement.

Number 5 represents 'all stop'. Units will keep moving until a mouse click upon terrain (overriding indefinite movement mode) or number 5 for all stop.

- - - - - - -

2.) Assigned units - Isn't it annoying when your sensor assigned mortar team gets rushed and you are too slow to react because precious time is lost moving the sensor vehicle sufficiently out of range for the mortars to follow? Sure you could assign the assigned units to a different number grouping and unassign them for a less slow escape but isn't it time that better navigation were built in?

I am of the opinion that the simplest and most effective way to impliment this is to have the opposite mouse button (right for left or left for right) control movements and actions of the 'assigned' units only.

This would vastly improve control - you can dictate that your assigned units move to the left of your sensor and then to the right of your sensor - without ever moving your sensor or needing to have them assigned to group to unassign them wholesale. You could retreat them 'as' your sensor tank struggles to get by them.

You could also better control commander-assigned units - making it easier to reposition the fighting force in relation to the commander.

This does not produce an issue deselecting the group as all it takes is either a click upon a friendly unit or a mouse drag upon empty terrain.

[Avestron]

Oh man, its been a very long time.

And looking through this thread again I realize how little I've done from that which I had hoped - zero.

(and before anybody comments about reviving a dead topic - it was either this or start a new thread - although I do request a move to 'ideas & suggestions')

/\/\/\/\/\

I do like the direction that WZ2100 has taken with its recent versions - but I am frankly surprised that the vast majority of the add-ons haven't been incorporated yet. This is something of a pity as I am certain that a lot of creativity is stifled by this situation where the core code doesn't allow slot-on mods that can be loaded and unloaded at will.

/\/\/\/\/\

However I haven't just come to criticise the efforts of others and rue the lack of effort on my own part. Yeps suggestions there are to add - specifically for path-finding.


1 - Traffic Jam Management - When the AI recognizes that a cluster of units have been actively moving but have not actually achieved any distance in a pre-allocated amount of time, it goes into scatter management.

As the name suggests it involves taking the center of the traffic jam and assigning each traffic jam participant to individually scatter to a pre-allocated matrix, outer models first.

Once scatter action is completed then the units are re-assigned their task, repeated use should result in shuffling.

2 - Odessey Management - When large quantities of units are assigned to move any significant amount of distance, the AI seeks to assign multiple paths, automatically assigning segments of the unit total to each. These paths are more or less side-by side and should reduce the serial line effect of a group of units in motion, one after the other.

3 - Repair Management - It is very annoying when units destined for repair are ungrouped. Why not automatically assign such groups a negative number when repair reflex is engaged and simply switch them back once they are discharged from the repair line?

[Andrie]

Use this mod maker: viewtopic.php?f=5&t=8726&start=30 just go down.

[Avestron]

Thank you for pointing out this mod maker application.

It seems like a very good way to adjust existing stats, granted, and it does provide insight into the way that VTOL ammunition is determined.

As I understand it, a more logistical variant of warzone where units harbour ammunition levels based on core propulsion power and propulsion means would, if strictly based upon the existing core code, require foundation upon the VTOL Attack Runs integer.

With the difference that non-VTOL units would not necessarily have to drive past units in order to attack again.

In this event it would be the Command Center and Repair Depots that would provide a means of re-supplying. To a lesser extent repair droids.

Another alternative would be establishing of re-supply depots/ ammunition dumps, and specific resupply turrets.

The exception would be energy weapons which would act independently but have a charge time.

Base structures would also have supply limits but would regenerate at a rate related to proximity to an ammunition dump.

/\/\/\/\/\

Another variant - population centers.

As WZ currently goes, the present trend is to recycle units with some experience for better units with that experience. This is fine except that there is no representation (that I have ever noted) of how many units of experience are stored in queue for respawning in the next generation of models.

I was thinking that one way of getting around this would be to tie this to the command center - listing the number of units of specific experience levels are in the queue.

Another interesting concept would be the ability to construct training academies that each are able to produce 5 'units' of limited experience up to regular (and then following upgrade). Such would be a very slow process with each level of experience taking twice the time the previous one took.

Exactly how this could be implimented in a mod, I'll have to look more into Andrie's link earlier - but in the meantime I think I'll look into c++.

(more ramblings - please ignore)

[Rman Virgil]

.

...but in the meantime I think I'll look into c++.

C89... if it's the WZ source your thinking of doing something with presently.

.

[Avestron]

No - I figure c++ will be a good foundation for myself - and am hoping it'll be relatively simple to move to c# (c89?) later.

Hence why I refer to everything as ramblings now ^_~