I like the grav. bubble one! Could you make it so that once units float to the top of the bubble they slide off the sides?

I'll start brainstorming with my friends!
I'd gladly help you test any betas for WOF, because, at least to me, it sounds like one of the coolest mods ever.
Also, out of any of those that you listed, the anti-gravity bubble seems the coolest, and like it would have the most interesting effects/gameplay.
Cloak stealth is more of a cybran thing, so I don't think it would fit with the UEF very well. And the accuracy field seems quite interesting, however i'm not so sure how balanced it would be with things like t3 heavy arty.
Overall, best suited to the UEF would be the accuracy or build accelerator. The anti-gravity bubble seems more Aeon to me, similar to the idea of their tac missile defense.
Edit: New idea, maybe a speed-boost for units, that would significantly boost overall travel speed, but consume a load of energy. Useful for dodging tacs, czar crashes, or front line rushing. Effective with Commander, SCU, and most slower t3 units.

I don't understand what is happening with holograms, before DMS v7 and 4DC v08 they worked perfectly and didn't entail desync even in MP games (I played a lot of games with them myself) why can't we just revert to previous situation and keep the holograms which are a very cool addition to the game ?

Hi,

IT is rather strange that no one said about desyncs before these betas,
the only thing i really changed on them was how they are created and killed..
from the released version to the beta.. i added them as an intel type, liek phasing, and the sera crystals, they dont cause a desync, there is nothing in there code that is different to the holograms, only the end functions are different, and not the intel code.. this is solid..

the strange thing also is that it is the zero footprints making them desync..
the end test when i realised it was this, i removed the zero footprints and made them amph (for testing) the desync went away, i make them have zero footprints again, the desync came back..

WE AGREE 100% that the holograms are very cool and were sorry that they have to go.. BUT ok ill test later in mp with the old version...

Just looked at the old code, the old version of 4dc resin did, the holograms didnt use
a zero footprint, its only in the betas when i changed them to pass through everything that they started using zero footprints, they are the first things to use zero footprints i think.. that is why it doesnt desync, the main reason were removing them is because of the bumper cars they can potentually do,

like if 10 units are built that have 3 holograms each (which isnt alot) the close proximity of these 30 holograms would bumper car 100% of the time.. as we know the only way to make them pass through units that are not the same type is to make them have a certain hitbox size something like 3,1,3 and being amph, this hitbox is quite big for a unit that would usually need a hitbox of 0.8 or w/e fiting 30 units with a hitbox size of 3 into a radius of say 30-40 which is a common radius for holograms is just not good enough this is why they are not really viable. they are pretty uslesss IF they are not able to pass through units..

wouldnt you agree?

to make it so they can pass through units, can you make the footprint tiny and off set the foot print? so that either it is off the map or under/above the ground?

Ignore me if this is not possible

Shadow

To ShadowNB

The unit footprints (FP's) are not defined by the units directly but
by a predefined list. This list is rather limited and was setup
deliberately to ensure that the SIM wasn't being bogged down by an
excessive number of collision detections.

Just think of the FP's as being the area around the unit which no
other units may pass. While there are several hundered units in the
game, most units use a similar FP's to speed up the collsion
detection. Further more, some FP's have special flags that allow some
units to pass through others if the conditions are right. Units such
as experamentals are a prime example of this behavior. Now, just
because an experamental uses a particular FP doesnt mean that this FP
would be ideal for the holograms as the holograms are not as large as
most experamentals. What this comes down to is that the FP's need to
be either the same size or smaller then the unit using then to be
workable. But even then, working with FP's is pretty much guesswork as
the game engine does a bit of "averaging" when it comes to how that
particular FP is applied to a unit. This can make it extreamly
difficult to select the correct FP for some units.

In the end, this is why we chose to discard FP's and opt to forgo the
collision checking alltogether. In a sense we wanted to be able to
treat holograms as real units but at the same time remove some of the
restrictions normal units are bound to. Sometimes crazy ideas like
this works, othertimes it doesn't.... this is how most of the cool
stuff you play with gets made really.

Unfortunately, neither myself or Domino do much testing in the way of
Multiplayer and rely on player feedback to sort out such issues. (time
is an issue) Needless to say, over this last week we've jumped into a
few matches together to properly capture the moment of Dsync and find
the bug(s) responsible.

As for keeping holograms or kicking them to the curb.... We've
invested far to much time to just abandon them but at the same time do
not wish to do anything "half-arse" just to get it out the door. That
being said, expect the holograms to return but at a time when we know
for sure that we can make them perform as expected.

P.S. The old method i used to run / control the holograms was a SIM
hog and most of what Domino did was optimize the code for lightning
fast play.

Resin

RESIN SPEAKS! Domino must be possessed XD
On another note, could you make the footprint in the sky layer? (where airplanes fly?)
Or even in the orbital layer? (where satellites go?)
Or is it not possible to move the footprint relative to the unit itself.

lol,

but seriously although we can offset the hitbox, we really dont want to do that,

Would that not produce the desired effect, while also not interfering with anything else?

Hi,

Sorry been quiet been hammering stuff out here for the next released (cominh VERY soon)

this post is just to say...

ive umm fixed the GetAttacker() function... well not actually fixed the original but rather added a new function which returns who is attacking which ever unit..



will return a table of units which currently have that unit set as there target..
absolutely no strain on the sim, no crazy loops and its all updated in real time..
i think this function will come in rather usefull

i also added these just because im tired of looping all weapons to retrieve such info
when there is really no need to loop all weapons... these functions return said info WITHOUT looping all weapons.

GetWeaponTargets - returns a table of weapon labels with there targets. (if any)
UnitHasTarget - returns if a unit has a target.
WeaponHasTarget - returns if a unit weapon (label) has a target.
GetWeaponTarget - returns a weapons target. (by weapon label)

these are percific to weapons.

GetUnitWeaponState - returns the current state that the weapon (label) is currently in, VERY USEFULL.

Thx.

Sounds cool, looking forward to the new release! Good job Domino!

Hi,

http://www.mediafire.com/?3sj6zjbvb7bwucj

Last beta before we release these versions, IF you find a bug we havent fixed,
mention it now or it could be a while before we fix it (reason below)
sorry if we havent yet added the things we/i said we would add for this release
time is has been spent preparing DMS and ironing out the bugs, we dont want to delay the release of this stable release... so some things were omitted to save more bug fixing time..

Ok, after we release this version with mentioned bugs fixed were going to concentrate on the faf version and get that up and running, now although its not hard to switch the mods to faf conventions, it is time consuming and will require 100% concentration on one version for the time being, being that the faf version for DMS in particular is very different to the default DMS, many script changes have to be made.. after that is complete, we will continue the work here.. and then add the new stuff to the faf version which once code is in place it will be easy to maintain both mods..

to you the end user you will not see a differance, however regarding scripting some rules will apply to the faf version of DMS, notabley for file pathing.. ill let you know the details once i have finalized exactly what im going to do, dont worry though it will be easy to switch mods to use the faf version, however it is not a requirement
i will still be 100% supporting the default mod method of DMS which is the #1 priority at the moment.

ok so regarding this beta, if you see a bug or want something changing mention it now or forever hold they peace.

Thx

Dave.

I'll give it a thorough bug-test when I get back home tomorrow. I might even join FaF if DMS and 4dc are gonna be there.

Hi,

Luck, i posted this here instead of the 4dc thread cause it was a DMS error,

Just confirm there was a bug in the intel system, although it didnt cause errors, the way it worked was incorrect, now the intel system ive added is rather complex, but ill try to explain the simple answer.. it did however sometimes effect the cloak mesh.. also, for future referrance, the BO:U cloak code will trigger an override to the cloak effect, it doesnt cause an error or change the effect, however it will sometimes cause the cloak mesh effect to prematurely change or change late so keep that in mind in future.

ok so the problem was..

what i did was add support to easly change a units mesh, which is closely connected to the inteltypes, (cloak, cloakfield, radarstealth, sonarstealth, phasing) all that jazz, so when an intel type is enabled, the mesh will instantly and automaticly update based on the inteltype (we can also do it on the fly manually), custom intel meshes are catered for via bp overrides.. which works like this, we set up a new mesh in blueprints.lua for say cloak, so every unit now has a cloak mesh, but say for instance we want one unit to have a different cloak mesh, how do we do this without a blueprints.lua entry to discard the unit or to add the mesh for this unit after the original cloak mesh code is run, there is no need to do this, all you have to do is create the mesh blueprint and put it in your mods folder in /customunitmeshes/url0101_cloak_mesh.bp and this mesh effect will be used instead of the default bp entry for the mesh.. no bp entries are needed no specail code, it will just work with the mesh bp in the correct place and named correctly.

now the problem was that default intel field types like cloakfield were not adding there units inside the cloakfield to there field units table, so the function that adds the units in the field was continually trying to add cloakfield units to its table and updating there mesh, this is where the was for that, but upon finding this and fixing it, i came across another bug, that is kinda related to this, wherein if you add a custom intel type that has a mesh change BUT also changes the mesh of the units inside the field ( like cloakfield) there was a problem with it if the intel field gets enemy units ... this mesh would be applied to those enemy units also.. so i added a switch so that we can now define if the mesh change happens on the intel field units also.. suffice to say it now works as intended and we have more control over what units change mesh and when.

an intel type table definition is easy it looks like this..



i added priorities to the meshes, so one can take presidance over another.. if a unit has more than one intel type enabled that changes it mesh or if it enters a more than 1 intel field where that field changes its mesh.. one thing to note is that if the unit has a personal shield, the personal shield mesh will always take presidance over any other mesh.

Cheers

Cool beans!

Yeah I realized that the personal shield took precedence over other meshes the first time I put phasing on a shield on an Ahwassa. The shield would die so fast, and then the mesh would change to phasing.

Meshes are quite interesting...

-Luck

yes they are, they are driven by the shaders, which is what the effects are..
phasing, personal shields ect are just a different shader applied to the mesh.

Learning more and more about this game everyday... so sad that there's not much of a following for it anymore... But it seems recently, there's been a lot more people on Steam matchmaking, which is quite exciting. If only the game auto-downloaded mods when you connected to the host... It's still really hard to find people to play modded games with, or even just a custom map.

aye thats always been a problem, however if you join faf, they auto download the featured mods.

Hi,

have now testet with your last DMS version ....
Basicalky its runs nice and fix few problems with the latest v0.7 i haved seen ...
But its have an hughe bug.
Changed only the old v0.7 to your latest 0.8 - and played Aeon - shields not more working :\
If the shield is build - it is ON.But i dont see any energy usage of the shield - and i have the advanced stats "on" in the GATZ-UI mod ......
If i switch it off - i CANT switch it on again - it stays always off ...
As i have wrote - the only mod i changed was DMS from 0.7 to beta 0.8 ......

Regards
R-TEAM

Hi,

I would hazard a guess that the error in the log says that



basicly in DMS v8 i added support for multiple shields per unit (for directional shields or shield plating)

The only way i could achieve this was to give each shield an identifier obvioulsy for default shields this identifier is 'MyShield' which is also directly tied to the energy usage for a default shield i automaticly fill this in, so that each shield can use its own energy.. you will be seeing this problem because one of your mods has a new shield class which doesnt have the ShieldIdentifier = 'MyShield', in its unit.lua createshield function OR it is completely bypassing the default shield oncreate function in shield.lua.. if you can nail down which mod alters your games shields, i can and will offer a quick fix.

This is not a bug in DMS, its an incompatability with one of your mods..
i have changed the shields alot in DMS and it will cause incompatabilities with some shield mods, we think the changes i made to the shields are for the better, we now have alot more control regards to scripting on how the shield behaves.. if you crack open shield.lua in dms you will see all the new functions i added.. i also added a new shield class for creating multiple shields per unit.

Hi,

thanks Domino for the quick replay
Have first thinked it is the "ExperimentalShields V3" mod ... but have squareshieldwalls mod, and here it is the same - and this shields are not altered by the mod above ..
So i think it is the "nuke colide with sheild" mod.It have an hook for shield.lua :

...............#
-code removed - sorry - it was a little bit much -
...............#

Thanks to look into this

Regards
R-TEAM

My eyes! Use pastebin!

Ok that is a direct override of shield.lua and will 100% cause a conflict,

in your last post, remove all the code and put it in pastebin..

upload the mod somewhere and post the link, ill take a look at it,if it will take less than 10-15 mins to fix, ill alter that mod ( for your personal use ) so that it will work with DMS.

post the link to the download.

Hi,

thanks Domino.
You can DL the mod here : ftp://+++++
It is my private FTP server - anon login acceptet.(but only 1 at time )
If you like you can then upload the fixed mod here too - but upload is only available for anon in the root dir ( ftp://+++++ ) .

<removed links >

Regards
R-TEAM