Warzone 2100 Forums

effigy wrote:... This would mean you don't design anything, but instead research a turret + hardcrete and you'll have all possibilities prebuilt. ...

I'd prefer to design structures and save the ones I use a lot as templates, that way my build menu doesn't get filled with stuff I don't want.

I assume path finding algorithm will need updating to avoid structures moving out of the way of passing vehicles

2Iluvalar: may be make another GUI for strctures for your idea, because "propulsion" is unnatural for structures
i will follow my first simple plan but i can make working branch for your plan as alternative
if we make "idea branch" working 100% then it can have chances to be

Do as you want Reg312,

But i believe i show you the way it will be in the futur. Such unification of structures and droids would solve so much problems. And the change made for that will be usable for other changes and other functionalities.

But i'm fully aware you might not apply all my idea in one shot, but each step you'll do it that side, will be one step less to do to the others...

if someone interested, my branch with structure design: https://github.com/crabster/warzone2100/tree/strd2
- contains working version (with minimum testing)
- contains lot of things for future fixes

Long-time plans:
1) Design cyborgs
2) Add more labels with unit parameters in design screen
3) defense model (bunker) with structure inside

Required help:
1) I need model for default structure design (hardpoint without texture, line green viper body)
2) Model for default cyborg design
3) More tesing in network games

You know how, when picking VTOL propulsion, you'd only be able to select from a list of VTOL weapons? Well, what if we could program the game to limit what propulsions we could pick from when designing our structures or cyborgs?

Like I said before:

Shadow Wolf TJC wrote:To my knowledge, kinetic/thermal armor (which does vary from structure type to structure type) was traditionally determined by the unit's body type, while unit type (Soft, Medium, Hard, and Bunker) was traditionally determined by the unit's propulsion type. (HP was determined by both the body and propulsion type.) Why not create 1 propulsion type for each of the structure types? That way, we can choose our structure bodies, and then have the proper propulsion type automatically chosen.

2Shadow Wolf TJC: no propulsion for structures, i simply removed propulsion button

Shadow Wolf TJC wrote:You know how, when picking VTOL propulsion, you'd only be able to select from a list of VTOL weapons?

we can do all
in current version i have funtion isVtolComponent() which checks numAttackRuns
but i dont see such way to select cyborg weapons, but, its not so hard to add new field in weapons.txt

Propulsions

I think structures should have a propulsion:

* Defence - for towers, sites, hardpoints, etc.
* Barrier - for traps, walls, gates
* Building - for factories, HQ, etc.

This way things like armour upgrades apply in the same way to everything in the game. For example:

* Composite alloys upgrade propulsions: V-Tol, tracked, HalfTrack, hover01, wheeled01
* Cyborg composite alloys upgrade propulsions: CyborgLegs (and in future CyborgJets)
* Building materials upgrade propulsions: Building
* Walls (hardcrete -> plasteel) upgrade propulsions: Defence, Barrier

I think there should also be a "Planet" propulsion for indestructible things such as boulders and oil resources, and a "Collectable" propulsion for things like artefacts and oil barrels. All other features (trees, wrecks, log cabins, etc) would use "Barrier" propulsion.

Propulsion will determine what sort of body and turret can be used. So CyborgLegs could only have cyborg bodies, Defence could only have things like towers, hardpoints, etc., and so on.

Bodies

The propulsion determines what sort of body you can use with it.

So a "Barrier" propulsion can have bodies such as tree, hardpoint, etc. It's just that human & AI players can only research things like "hardpoint" and not "tree" (so you'll never see the option to select a "tree" body unless using cheats).

The body will define the engine and weight, just like droid bodies do: http://guide.wz2100.net/bp/

In the case of defences, the rate at which the turrets can turn to target something could be determined by the engine?

2aubergine:
each body model of structure is directly refered to "propulsion", so i dont see in what cases players can select any propulsion for defense building, if you select "hardpoint", what propulsion you can select for it?? why?
....
as Iluvalar suggested earlier, you suggest to start designing from selecting propulsion
and i dont see any benefits there except that is beautifully from the standpoint of programming

by my logic game have following kinds of unit templates:
1) Tank
- subtype: vtol tank
- subtype: system turret (sensor, truck, repair etc.)
2) Cyborg
3) Defense
*base structures is not thing which should be designed, most things with base buildings are hardcoded and better dont touch it
*each kind of template can have own steps to design it
in current game we have only 1 propulsion for cyborgs and propulsion does not sense for defenses

i still dont know the best way to restrict specified weapons on specified buildings, but i know a lot of normal or bad ways to do it easily
my current idea is transform "size" of bodies to "body_subclass"
TANL_LIGHT, TANK_MEDIUM, TANK_HEAVY
TOWER, BUNKER, HARDPOINT, ARTILLERY_EMPLACEMENT, FORTRESS, PIT etc.
CYBORG_LIGHT. CYBORG_HEAVY
i not sure if its good idea, in next days i should decide

Reg312 wrote:i still dont know the best way to restrict specified weapons on specified buildings, but i know a lot of normal or bad ways to do it easily
my current idea is transform "size" of bodies to "body_subclass"
TANL_LIGHT, TANK_MEDIUM, TANK_HEAVY
TOWER, BUNKER, HARDPOINT, ARTILLERY_EMPLACEMENT, FORTRESS, PIT etc.
CYBORG_LIGHT. CYBORG_HEAVY
i not sure if its good idea, in next days i should decide

Are you sure you want to carry on with this idea? I mean, what's so bad about keeping certain weapons, bodies, or propulsions from being designable, even if we want to make structures and Cyborgs designable?

For structure-only weapons, such as fortress weapons and EMP Mortars, couldn't you just keep those weapons from being designable? There aren't that many weapons that are too big to fit on anything smaller than a fortresses, and there aren't that many weapons that would be worth mounting on something as big and expensive as a fortress, so why need to design them?

2Shadow Wolf TJC: in current WZ we have a lot of restrictions for structure-weapon pair
- avoid strong weapons on bunkers
- artillery only on weak emplacements (how about ripple rocket bunker?)
- big guns - fortresses
- invisible guns (inside bunkers) - heavy mg, assault gun
- mortars - in pit
- sensors only on specified towers

and yes, i'm sure, all weapons/bodies should be designable with following benefits:
1) Remove bunch of research items, if you have weapon and hardpoint, its logically clear what you not need research it again as structure
2) Free space in list of defenses, player can easily remove old/unused template and keep only neccesary defenses in the list of strctures to build
3) More and more possibilities for improving game
for example, someone can make nexus-like fortresses
in current game each new defensive structure is headache
4) main reason: its funny, and i'm sure players will get fun with designing fortresses with big guns

2aubergine: do you know how hard turn AI's to use designed strctures?

@Reg312: Keeping the code clean and consistent is vital IMHO. Currently there are lots of very different ways to do lots of very similar things, and making things a bit more consistent in the code will really help with future development, etc. The user interface doesn't need to reflect how the underlying code works though - so if you didn't want to have "Building", "Defence" and "Barrier" propulsions shown to end users those could be hidden away and automatically selected based on the body selected (eg. Hardpoint knows it belongs on a Defence propulsion).

Also, more consistent code will make life a lot easier for anyone who wants to do mods or coding, not just AI scripters, IMHO.

For example: In terms of working out what armour upgrades would apply to which propulsion, you can use bit arithmetic - so each propulsion type gets assigned to a specific bit in a 16-bit number. You can then use the same bit masks to define which bodies and turrets can be used for a particular propulsion type. It might be that we need a few extra propulsion types, eg. Bastion for the big fortress defences, so that only the huge turrets can go on those.

This is something I've been dabbling recently in terms of making it easier for my AI script to know which research (for example) applies to which things: https://warzone.atlassian.net/wiki/disp ... ropulsions

I'll try and get my big spreadsheet finished this week as that will show what I'm trying to achieve overall. I think we could arrive at a much more concise, centralised and easy way of defining technologies and many other aspects of the game.

@Reg312: Have it your way then, though if they decide that putting fortress weapons on units or structures that look like they would be too small to support them would look ridiculous, or would unbalance the game, then they may decide to keep them undesignable for a future beta, even when players would still be allowed to design their own structures or Cyborgs.

For the mod that I'm working on, I'm planning on adding an expensive research item (somewhere around $150) that, while it would not provide the player with any new components, units, structures, or upgrades, would serve as a prerequisite for researching all of the fortresses in the game, which would be made cheaper to research in turn. It would be as if you were researching a modular fortress body before you were researching each of the fortresses' weapons.

2Shadow Wolf TJC: as i've said: each structure should have own set of aviable weapons. My screenshot with X-cannon on tower was just a joke and it should be in game
and better stop work on mod and help me with my patch
i need fit designed structures(defenses) to current WZ balance
for example, if we have Heavy Cannon Hardpoint, then designed one should have same or almost same stats as in current WZ stats. also formula (simple sum of body and weapons) of structure HP and build time should be checked and may be adjusted to fit current balance

2aubergine: i'm not sure what i corrent understand whole your suggestion
in wz code STRUCTURE and DROID is two different objects (classes)
adding propulsion to structures sounds weird for me
what i dont like in your (and Iluvalar's) idea, is using "propulsion" terminology for structures,
so first step should is to provide concept with clean terminology.

current logic of my patch is: 1) create droid template with "structure type" 2) convert droid template to structure_stat object

i'm very new in WZ code, so i'm trying change only minimum necessary lines and use maximum of current working code
i have only one way to learn WZ code - is implement such things,
and may be later, when i will get full understanding of code, i can say is it good idea or not with "propulsion" for all object and how it is implementable or not

so, if you still want push this idea, please provide clear steps, and first what mean word "propulsion" for features, strctures (hills?. how about damagable hills? )
also i dont understand, why we need use 16-bit mask, i think we can use any data table with any number of columns and rows,

aubergine wrote:@Reg312: Keeping the code clean and consistent is vital IMHO.

some things can be clean for some people and messy for another people, so i dont know ideal code, but i believe in ideal game
in my ideal game structures should be designable

@Reg312:

In my research in to the tech tree and structures, etc., I've noticed that there is a commonality in that upgrades are applied to things based on propulsion.

So while the end user might not care about propulsion from their gameplay perspective (and propulsion on structures can be hidden away from them), from a coder perspective propulsion on structures would bring a much higher level of consistency to the way things are coded.

I'll say this again: Structure propulsion can be completely hidden away from end users in the game. End users don't need to see or know anything about propulsion for their structures.

"Propulsion" is the best word anyone can think of for now, but in the case of structures it can be thought of as "foundations".

A propulsion therefore defines:

* What sort of bodies can be applied
* What sort of turrets can be applied

The body defines:

* How many turrets can be applied

In terms of the 16 bit mask, its to allow much simpler way of comparing things. So I could have a constant that represents all the land-vehicle propulsions (hover, wheel, etc) and use bitwise operators to check other things against that to know they are a vehicle. The alternatives are much too messy to entertain from what I can see, unless you know otherwise.

Example: Let's say we have a wide spectrum sensor turret.

I know that can be applied to these propulsions:

* Droid propulsions: hover01, wheeled01, tracked01, HalfTrack
* Structure propulsions: defence

So the sensor would have a bit mask with a 1 in the relevant bits that represent each of those propulsions.

Then, in the designer, if I've chosen one of those propulsions (or it's been chosen for me based on body I've chosen - such as hardpoint) the list of available turrets can be filtered to just those applicable to the propulsion I've selected.

I must stress that I'm still wading through data to build my spreadsheet and only then will a clearer picture emerge as to what the best approach is. But what is above is where things currently stand based on my understanding of the most concise way to link things together to suit a multitude of different purposes.

It's going to be at least a week, maybe 2 weeks, before I get my spreadsheet finished and am in a position to fully explain my idea. I have about 40 hours of digging through data still to do to fill in all the cells in my spreadsheet. Then I have probably another 20-40 hours of testing stuff out to see where my ideas break, and only then will I really be able to present a fully thought-out approach for how things can be done in the future.

Also, here is a list of bodies I've identified so far:

Bodies applicable to "Vehicle" (which include wheeled01, tracked, v-tol, etc) propulsion:

* BODY_BUG
* BODY_COBRA
* BODY_DRAGON
* BODY_LEOPARD
* BODY_MANTIS
* BODY_PANTHER
* BODY_PYTHON
* BODY_RETALIATION
* BODY_RETRIBUTION
* BODY_SCORPION
* BODY_TIGER
* BODY_VENGEANCE
* BODY_VIPER
* BODY_WYVERN

Bodies applicable to "Borg" propulsion (which includes CyborgLegs and CyborgJump):

* BODY_CYBORG
* BODY_SUPERCYBORG

Bodies that apply to "Transport" propulsion (or maybe VTOL - more investigation needed):

* BODY_HEAVYTRANSPORT
* BODY_LIGHTTRANSPORT

There are obviously a few droid-related bodies missing - for example scavenger vehicles and people.

Bodies applicable to "Defence" propulsion:

* BODY_BASTION (fortress)
* BODY_BATTERY
* BODY_BUNKER
* BODY_EMPLACEMENT
* BODY_HARDPOINT
* BODY_PIT
* BODY_SITE
* BODY_TOWER
* BODY_WOODTOWER (I'm not sure if this tower is made of wood, but it looks like it is)

Note: I think it's OK to allow things like X-Cannon to be put on a wood tower, so long as the engine in the body (the wood tower) has an effect on aiming speed of the weapon. So, just as putting a very big weapon on a small droid (eg. Archangel missiles on a bug hovercraft) makes the droid go really, really slow, the same sort of thing should happen to defences: Put a big weapon on a small defence and the weapon takes a very long time to turn and tilt to target the enemy. The person designing their structures then has to compromise between production costs (eg. bastion body will cost more than a wood tower body) and turret agility (how fast the turret can turn to aim at it's target). There are other factors too such as line of sight - I could happily put a sensor on to a Battery or Emplacement body, but being closer to the ground it's going to be less effective than if I put it on a tower. But this does give me lots of room as a player to experiment with different structure designs and save the ones I like as a template.

Bodies applicable to "Barrier" propulsion:

* BODY_GATE
* BODY_TANKTRAP
* BODY_WALL

I've not yet worked out if a distinct body is needed for corner walls? None of the turrets have the "Barrier" propulsion bit set on them = you can't build turrets on Barriers. For this reason, Barriers should become available as soon as you research their bodies (and the barrier propulsion tech should be pre-researched for all players in rules.js).

Bodies applicable to "Building" propulsion:

* BODY_COMMANDRELAY -- I'll just list this one example of a building (non-defence/barrier) body

Each of the buildings gets it's own body. The "Building" propulsion can have turrets placed on it, however most of the bodies will define zero turret slots = can't build turrets on them. But, for things like HQ then you might be able to build some turrets on it. (Needs further thought)