Planned randomize 'shotgun' effect

[TheKingOfSpace]

Give the shotgun a random, rather than fixed, aim offset from the output block, changed each reload cycle, and tighten the cone a bit so it's useful beyond three feet.

 

[Lecic]

Pretty sure the devs said they couldn't give shotguns a randomized pattern.

I'd be game for a pattern that's at least close to symmetrical, though.

 

[SkaireKrough]

If a random pattern is really not do-able then I would settle for a completely symmetrical pattern with a much tighter spread.

 

[EricBlank]

Agreed. I haven't been able to get much use out of this effect as it is now.

I've considered a rotary cannon with four rail-docked barrels each oriented in a different direction, but they'd each be quite small relative to whatever else I could fit in that space, and the spread is simply too loose anyway.

 

[AndyP]

Pretty sure the devs said they couldn't give shotguns a randomized pattern.

I'd be game for a pattern that's at least close to symmetrical, though.

Correct, a non-fixed pattern would require an exact sync of the pattern.

The amount of data is exploding then.
As any "module" has to calculate and transmit every single beam direction and send it to the clients, with every single emit.
(Not even sure how beams could compensate this semi-randomness, when they already emitted beam has to follow the mouse pointer, while new beams add a new random offset.

 

[Megacrafter127]

Correct, a non-fixed pattern would require an exact sync of the pattern.

The amount of data is exploding then.
As any "module" has to calculate and transmit every single beam direction and send it to the clients, with every single emit.
(Not even sure how beams could compensate this semi-randomness, when they already emitted beam has to follow the mouse pointer, while new beams add a new random offset.

There is a solution to the randomness though.
java.util.Random uses seeds. If the seed is the same, the random sequence will also be the same.
If each ship has its own Random instance for this purpose, which's seed is transmitted to the clients[8 bytes, so it doesn't explode], alongside the number of retrieves, that already happened[also 4 or 8 bytes], the amount of data wouldn't explode, it'd only be 12 or 16 additional bytes whenever the entity is loaded.(all this is assuming, that the Random instance is used EXCLUSIVELY for the pattern generation)
As for beams following the cursor: Simply having the pattern reset each time the 'cooldown' passes seems suitable IMO.

 

[AndyP]

There is a solution to the randomness though.
java.util.Random uses seeds. If the seed is the same, the random sequence will also be the same.
If each ship has its own Random instance for this purpose, which's seed is transmitted to the clients[8 bytes, so it doesn't explode], alongside the number of retrieves, that already happened[also 4 or 8 bytes], the amount of data wouldn't explode, it'd only be 12 or 16 additional bytes whenever the entity is loaded.(all this is assuming, that the Random instance is used EXCLUSIVELY for the pattern generation)
As for beams following the cursor: Simply having the pattern reset each time the 'cooldown' passes seems suitable IMO.

Well, this goes a bit beyond my knowledge about the actual code implemented for this.
However, this still sounds like we need a seed for each weapon group/emitter?
Also seeds sound like you have to generate angles and stuff from them, and as far as I know those angle calculations are relative expensive as they are floating point operations and should require some advanced math to work properly.

It may work better to have 4-8 patterns (2-3bit), + 4-8 rotations (2-3bit), so if the patterns look random enough it may look like "true random" as far you cannot expect the next set of angles and calculate with it. And 8 patterns, with 8 possible modifications (by rotation) result in 64 distinct patterns to use, that 'should' be enough.
However this is only theory, as most of my understanding on the game mechanics is from direct conversation with the devs, not 'reading' the code.

- Andy

 

[AtraUnam]

I've said it before and I'll say it again, spread should be determined by slave percentage, at 1% you get a really tight spread and at 100% you get the current "blowing tennis balls out of a bucket with a firecracker"

 

[Megacrafter127]

However, this still sounds like we need a seed for each weapon group/emitter?

Only 1 seed per entity, as each group will not fire simultaniously, but in an order[although it all happens in the same tick], and said order should be the same for server and client.
As for handling the angles:
All that needs to be done, is create a random vector, and to add it to the vector of a spreadless shot. This would also randomize the range of such a shot a littlebit, but if that is not wanted, the vector can be scaled down accordingly.
The precalculated patterns would also be a solution.

 

[cyberus111]

I've said it before and I'll say it again, spread should be determined by slave percentage, at 1% you get a really tight spread and at 100% you get the current "blowing tennis balls out of a bucket with a firecracker"

If what you're saying is for every 1% increase in slave the spread size increases by X then I like it with one caveat ... with only 10 projectiles and the block nature of the game at 3x3 you have 1 per block plus 1, 4x4 you have 6 open holes and 5x5 15 open holes with a 60% being open holes.

I would modify this idea by simply (!!!) using slave % steps (ie 5%, 10%, etc for instance), at each step you get the next grid size with 1 projectile per block. At some % point grid increase could/should increase projectiles per block IMHO.

 

[StormWing0]

There are some random vector equations that could be used for this. If you use the java Random class it shouldn't be that expensive to get working. Doing a random seed for each barrel group might be overkill as some have said so like MegaCrafter said use a single Random Seed for each primary Entity. The Primary Entity being the main Parent that has the other things docked to it. Say turrets on a ship are docked with the ship and the ship is docked with the nearby space station. The Station would be the Primary Entity since things are docked to it but it isn't docked with them. There could be 100 ships with 50 turrets each docked with the station but there'd only be one random seed for the whole group. Now if all the ships were undocked flying around you'd have 101 seeds, 1 for the station and 100 for the ships.

For this to fully work you need a "part of" relationship setup telling you who the main parent entity is in the group but since you already have most if not all of the code for that it doesn't need to be worried about too much. If an entity is part of another it grabs it's randomly seed, and if that one is part of another one it grabs the seed of the thing it is part of. So you could have a chain of 1000 chain-linked ships and the one that is the main one for the group would be the only one that gets a new random seed while the others just grab the main parent seed.

If you can find a way around doing massive recursion do so since you should only need to grab the parent pointer from the entity that was last attached in the chain example. So instead of using recursion to go through it each time to find the main parent in the chain you'd only use it if you needed to totally recalculate the chain and that'd only happen if the chain was broken somehow. So the First Link has the info grabbed by the Second Link, the Third Link just grabs the info from the Second Link since the Second Link already has the info so why recurse through the links if the last one has the info already?

 

[Megacrafter127]

like MegaCrafter said use a single Random Seed for each primary Entity. The Primary Entity being the main Parent that has the other things docked to it.

I would not recommend that, as I don't think it is fully guaranteed, that multiple entities keep their firing order. For a single entity, yes, but for multiple, no. Besides, the seed could be a value, that is already stored in the entity, like the time it was spawned.

 

[Winterhome]

I did a lot of modding for a game called Starsiege: Tribes, and a lot of popular mods for that game included "special" (complex projectile) spreadshot weapons. They worked by using a for loop and adding a random value to the X, Y, and Z rotation to each projectile spawn. It wasn't particularly horrid in terms of lag, even for a couple hundred projectiles being spawned at a time.


But from the sounds of it, we don't use simple projectile physics on Starmade. Are the client and the server that far off from eachother?