Sockets on units
Moderator: Moderators
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
I thought a bit about it and there should be two upgrade systems at least.
One is the socketed one which lets a unit attach another unit to a socket allowing Tiberian Sun turrets or very basic unit squads. The other one should be internal upgrades like the nuke building system.
Then there is need for additional COB functions, units need to know if an upgrade was built (or removed) and such. There have to be limits - how many upgrades are possible or how many times can you add the same upgrade and so on. It's quite a bit.
For example a squad could look like this:
You have a unit which is an empty model with some mounting points or sockets on it. Then (by script?) you mount a unit to a socket.
The upgradeable building is the same just that there's a model with sockets to mount additional buildings to.
Also I thought of adding a way to identify a unit by it's ID tag rather than height. Could prove useful.
One is the socketed one which lets a unit attach another unit to a socket allowing Tiberian Sun turrets or very basic unit squads. The other one should be internal upgrades like the nuke building system.
Then there is need for additional COB functions, units need to know if an upgrade was built (or removed) and such. There have to be limits - how many upgrades are possible or how many times can you add the same upgrade and so on. It's quite a bit.
For example a squad could look like this:
You have a unit which is an empty model with some mounting points or sockets on it. Then (by script?) you mount a unit to a socket.
The upgradeable building is the same just that there's a model with sockets to mount additional buildings to.
Also I thought of adding a way to identify a unit by it's ID tag rather than height. Could prove useful.
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Actually...
simply doing something like this might work:
Add an fbi tag or something that allows transports to transmit their orders down to whatever it is they're carrying. In addition, if the transported unit can do something it's carrier can't (ie shoot or move faster) then the parent can use their ability. In fact, this might be better as an 'IsUpgrade' tag wherein any unit that loads it transmits it orders down (rather than orders going parent to child in all cases - allows transports to use upgrades *and* transport ordinary units)
Some way to specify exactly what units a transport can carry (something like Armour.txt?)
And possibly a way for units to spawn other units (alternatively, script-forced building of units - say calling StartBuilding(unitid) or something)
simply doing something like this might work:
Add an fbi tag or something that allows transports to transmit their orders down to whatever it is they're carrying. In addition, if the transported unit can do something it's carrier can't (ie shoot or move faster) then the parent can use their ability. In fact, this might be better as an 'IsUpgrade' tag wherein any unit that loads it transmits it orders down (rather than orders going parent to child in all cases - allows transports to use upgrades *and* transport ordinary units)
Some way to specify exactly what units a transport can carry (something like Armour.txt?)
And possibly a way for units to spawn other units (alternatively, script-forced building of units - say calling StartBuilding(unitid) or something)
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Guess: But that still wouldn't allow building stuff on the sockets. Let's say I have a space station with eight open spaces and I want to add a living quarter to one of them. I'd have to build the module on the ground, tell the station to swoop down and grab it and the module would be inserted into a random socket. That would mean I could not define which socket is used which is pretty important for e.g. flying bases.
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Lets say we have these sockets per se. Then we should also have a new folder for sockets, so that sockets do not have to be defined as units. Now how are you going to define the socket menu for each unit? In the sidedata?
I'd like to see the socket idea happen if nothing more than multipurpose units that use the same chassis. We could take a battle tank, in a pinch we could build a nano turret to replace the gun. But wait, now how are we going to define the con menu of this unit?
Let's look at the squad unit. Is an enemy unit supposed to shoot each socket or will it be shooting into the middle of the squad? Fire fights among squads would look pretty gay this way. You'd need collision spheres for each socket and perhaps the targetting system should treat sockets as units... could be a real mess.
I see a lot of minor issues that could pop up if a kludge is used to put these in. Like it was said earlier, a well thought out way of implementing this will save a lot of hassles later on.
I'd like to see the socket idea happen if nothing more than multipurpose units that use the same chassis. We could take a battle tank, in a pinch we could build a nano turret to replace the gun. But wait, now how are we going to define the con menu of this unit?
Let's look at the squad unit. Is an enemy unit supposed to shoot each socket or will it be shooting into the middle of the squad? Fire fights among squads would look pretty gay this way. You'd need collision spheres for each socket and perhaps the targetting system should treat sockets as units... could be a real mess.
I see a lot of minor issues that could pop up if a kludge is used to put these in. Like it was said earlier, a well thought out way of implementing this will save a lot of hassles later on.
That means we loose the ability to take this feature and manipulate it into a second feature, units merging and breaking apart, and even compound units, possibly even an implementation of protoss style carriers.MadRat wrote:Lets say we have these sockets per se. Then we should also have a new folder for sockets, so that sockets do not have to be defined as units. Now how are you going to define the socket menu for each unit? In the sidedata?
I'd like to see the socket idea happen if nothing more than multipurpose units that use the same chassis. We could take a battle tank, in a pinch we could build a nano turret to replace the gun. But wait, now how are we going to define the con menu of this unit?
Let's look at the squad unit. Is an enemy unit supposed to shoot each socket or will it be shooting into the middle of the squad? Fire fights among squads would look pretty gay this way. You'd need collision spheres for each socket and perhaps the targetting system should treat sockets as units... could be a real mess.
I see a lot of minor issues that could pop up if a kludge is used to put these in. Like it was said earlier, a well thought out way of implementing this will save a lot of hassles later on.
Its also more work
Could you frame your response more. I'm not understanding the protoss example because I've never played Starcraft.AF wrote: That means we loose the ability to take this feature and manipulate it into a second feature, units merging and breaking apart, and even compound units, possibly even an implementation of protoss style carriers.
Its also more work
In teh Fbi file it could have a new tag
issocket= (0,1)
In canbuild we would have what builds the socket.
One problem I can see is the socket would have its origin built on the "socket" piece/origin on the unit, and so we wouldn't have a socket that can attach on top and sideways, on two different units, or on one.
issocket= (0,1)
In canbuild we would have what builds the socket.
One problem I can see is the socket would have its origin built on the "socket" piece/origin on the unit, and so we wouldn't have a socket that can attach on top and sideways, on two different units, or on one.
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Naah, a socket thing would be tagged as socketX=[some key] (the COB would have a QuerySocketX function that works like the other queries), a unit with sockets as socketed=[some key]. A socketed unit could have a tag buildonself which defines if it can put stuff into its own sockets or if it needs help for that. buildonothers would similarily define whether it could put stuff into other unit's sockets. [some key] would be something that defines what fits into a socket, it should both allow one socket to hold multiple "categories" of fillers as well as each filler to fit into multiple types of sockets (flag array?). Possibly a COB call could change the sockets a unit has attached to e.g. respect a total weight and deny the ability to build heavy turrets once the weight limit is too close.
If necessary a filler could be just spawned attached (i.e. like a loaded unit) to the queried piece instead of getting any ground space allocated to it. The filler could obviously opt to have its orders attached to the main unit, i.e. have stuff the main unit can't do show up in the main unit's menu and have all of the main unit's orders apply to the socket as well. Inheritance would always go to the first parent object that doesn't inherit so e.g. a unit with three large turrets that take individual orders can still have inheriting upgrades for each of these turrets that obey their turret's commands.
Inheritance would obviously apply only while a parent unit is present, if, for some reason, the unit is detached it will get its orders back. Normal (non-socket) units can inherit as well, they will only do the inheriting while loaded by an isfireplatform transport.
If necessary a filler could be just spawned attached (i.e. like a loaded unit) to the queried piece instead of getting any ground space allocated to it. The filler could obviously opt to have its orders attached to the main unit, i.e. have stuff the main unit can't do show up in the main unit's menu and have all of the main unit's orders apply to the socket as well. Inheritance would always go to the first parent object that doesn't inherit so e.g. a unit with three large turrets that take individual orders can still have inheriting upgrades for each of these turrets that obey their turret's commands.
Inheritance would obviously apply only while a parent unit is present, if, for some reason, the unit is detached it will get its orders back. Normal (non-socket) units can inherit as well, they will only do the inheriting while loaded by an isfireplatform transport.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
what im about to say is a little off-topic, but do you think that the factions could have different things to put in the sockets?
Ok, just say that an Arm player would be able to attach the weapon of the Penetrator (XTA version) onto the Com's shoulder, while a Core player could not use that weapon but have the weapon of a tank attached onto him which the Arm could not use.
Ok, just say that an Arm player would be able to attach the weapon of the Penetrator (XTA version) onto the Com's shoulder, while a Core player could not use that weapon but have the weapon of a tank attached onto him which the Arm could not use.