ติดตั้ง Steam
เข้าสู่ระบบ
|
ภาษา
简体中文 (จีนตัวย่อ)
繁體中文 (จีนตัวเต็ม)
日本語 (ญี่ปุ่น)
한국어 (เกาหลี)
български (บัลแกเรีย)
Čeština (เช็ก)
Dansk (เดนมาร์ก)
Deutsch (เยอรมัน)
English (อังกฤษ)
Español - España (สเปน)
Español - Latinoamérica (สเปน - ลาตินอเมริกา)
Ελληνικά (กรีก)
Français (ฝรั่งเศส)
Italiano (อิตาลี)
Bahasa Indonesia (อินโดนีเซีย)
Magyar (ฮังการี)
Nederlands (ดัตช์)
Norsk (นอร์เวย์)
Polski (โปแลนด์)
Português (โปรตุเกส - โปรตุเกส)
Português - Brasil (โปรตุเกส - บราซิล)
Română (โรมาเนีย)
Русский (รัสเซีย)
Suomi (ฟินแลนด์)
Svenska (สวีเดน)
Türkçe (ตุรกี)
Tiếng Việt (เวียดนาม)
Українська (ยูเครน)
รายงานปัญหาเกี่ยวกับการแปลภาษา
0 
รายงานโพสต์นี้
In the early game, the "offensive tunnel" is placed in a position to maximise map control. Once tech points are secured by either team those kinds of positions aren't considered. What I might do is forcibly mark the tunnel for replacement when that happens. It also requires an alien (or Drifter) to discover marine buildings (because it uses the memories system,) to add new tunnel considerations to the system, so playing in an empty game means only half of it is working.
I've fixed the error for the next update - turns out I've never tested with an empty game.
Thanks for the feedback.
P.S.: Your Marine Commbot can't build everywhere, you already know that. I solved the problem by setting the drop from the Commstation near Phasegate directly to Techpoint:GetOrigin rather than cs:GetOrigin. There were also problems with the drop of armories etc., which is why I always had the Phasegate placed close to the Techpoint, as I noticed that the comm can always drop the structures. Here is the relevant code for setting the gate on the TP:
local function FindBuildPosition(techId, origin, initialDist, maxDist, increment)
local buildPos = nil
local angleIncrement = math.pi / 32 -- Even smaller increments for the angle
while not buildPos do
for radius = initialDist, maxDist, increment do
for angle = 0, 2 * math.pi, angleIncrement do
local xOffset = radius * math.cos(angle)
local zOffset = radius * math.sin(angle)
local tryPos = Vector(origin.x + xOffset, origin.y, origin.z + zOffset)
buildPos = GetRandomBuildPosition(techId, tryPos, increment)
if buildPos then
return buildPos
end
end
end
return buildPos
end
and here is the code for the commstation, which is calculated from the next phasegate nearby:
function(bot, brain, com)
local name = kMarineComBrainTypes[kMarineComBrainTypes.BuildCommandStation_NearControlledTechPoint]
local senses = brain:GetSenses()
local comTeam = com:GetTeamNumber()
local doables = senses:Get("doableTechIds")
local weight = 0
local buildPos
local isZeroIPs = #senses:Get("activeInfantryPortals") <= 0
if doables[kTechId.CommandStation] and not isZeroIPs and senses:Get("mainPhaseGate") and #senses:Get("phaseGates") then
local emptyTechPoints = senses:Get("safeTechPoints")
for _, techPoint in ipairs(emptyTechPoints) do
local commandstations = GetEntitiesForTeamByLocation("CommandStation", comTeam, techPoint:GetLocationId())
if #commandstations <= 0 then
-- Position des TechPoints direkt verwenden
buildPos = techPoint:GetOrigin()
if buildPos then
weight = GetMarineComBaselineWeight(kMarineComBrainTypes.BuildCommandStation_NearControlledTechPoint)
break
end
end
end
end
return {
name = name,
weight = weight,
perform = function(move, bot, brain, player, action)
if buildPos then
brain:ExecuteTechId(com, kTechId.CommandStation, buildPos, com)
end
end
}
end, -- Build CommandStation (Near PhaseGate)
and here the code for phasegate at techpoint:
function(bot, brain, com)
local name = kMarineComBrainTypes[kMarineComBrainTypes.BuildPhaseGate_NearControlledTechPoint]
local senses = brain:GetSenses()
local comTeam = com:GetTeamNumber()
local doables = senses:Get("doableTechIds")
local kMaxPhaseGates = 8
local weight = 0
local buildPos
local isZeroIPs = #senses:Get("activeInfantryPortals") <= 0
if doables[kTechId.PhaseGate] and not isZeroIPs and senses:Get("mainPhaseGate") and #senses:Get("phaseGates") < kMaxPhaseGates then
local emptyTechPoints = senses:Get("safeTechPoints")
for _, techPoint in ipairs(emptyTechPoints) do
local phaseGates = GetEntitiesForTeamByLocation("PhaseGate", comTeam, techPoint:GetLocationId())
if #phaseGates <= 0 then
buildPos = FindBuildPosition(kTechId.PhaseGate, techPoint:GetOrigin(), 3, 20, 1)
if buildPos then
weight = GetMarineComBaselineWeight(kMarineComBrainTypes.BuildPhaseGate_NearControlledTechPoint)
break
end
end
end
end
return {
name = name,
weight = weight,
perform = function(move, bot, brain, player, action)
brain:ExecuteTechId(com, kTechId.PhaseGate, buildPos, com)
end
}
end, -- BuildPhaseGate (Near Controlled TechPoint)
I hope this solve the problem for you.
I think what you were seeing was the artificial limit I have in place (not building second bases until res >= 40). It only drops the phase gate immediately.
Maybe it needs some tuning if it's taking too long. Perhaps 30 would be a better number.
The reason I did this was so marines can rush jetpacks by 12-13 minutes. Dropping an entire second base + extra buildings can cost over 100 res.
I managed to track down the cause of the alien commander getting locked out of building. It was actually a vanilla bug triggered by a marine ejecting out of an exosuit. It permanently marks that room as unsafe for building.
If you hop in and out of an exo a bunch of times, then run dump_locgroups in console you can see the area is marked as having a ton of marines even though there are none.
I have a fix in progress now.
Also.
Hydras are coming soon, yeaaha!
I always saw the build bug in ns2_descent in Hydroanalyse.
The thing with the res for the 2nd base and the speeding up of researching the tech tree makes sense. I stuck very closely to the template in my bots mod.
Could that be the reason for the exo?
kMarinesNearbyRange = 200 in MarineCommanderBrain_Utility. I did it like that so that the marines don't have to be there directly and no matter where a marine is on the map, a structure can always be dropped. Then they get the move command. Originally it was at 12. It's just a theory.
gorge: you're with his toys :-D! one mine per gorge? then his bile mine could be placed at a point in the direction where the ARCs are going so that they roll over them. so if they are active then place a mine > 15 - 20. but I haven't played online for a long time and don't know exactly how a good Gorge player did it. maybe he can't damage ARCs with it...
ns2 wiki:
Creates an unbuilt bile mine on any surface
Detonates when close
Can be manually detonated with spit
Only deals damage to marine armor and marine structures
how about these suggestions from me:
maybe he can build it when a group of marines comes closer when the distance is >=20 and then drop it, and when the marines come closer and the bile mine is maybe also hidden from a shade and then shoot it with spit when the marines are in its detonation radius. or hide at key points when a shade is built and at a place where the marines are closest together, e.g. at powerpoints.
and from the AI:
Defend Key Points: Place the Bile Mine near strategically important points such as resource extractors (resource nodes) or main structures to defend them and prevent Marines from destroying them.
Chokepoints: Place the Bile Mine in narrow corridors or passages that enemies have to go through. This increases the chance of them falling into the trap and taking damage.
Proximity to Hives: Position the Bile Mine near Hives to better defend them and make it harder for Marines to access them.
Behind Corners and Cover: Place the Bile Mine in places that are hard to see or reach, such as behind corners or in cover. This will protect the mine from direct attacks and increase its lifespan.
Support from other structures: Make sure the Bile Mine is near other defensive structures such as hydrans or whips to create a stronger defensive position.
Surprise Effects: Place the Bile Mine in unexpected places to allow surprise attacks on invading Marines.
and again from me:
Web:
for the Gorge Web between two choke points or passages (doors, entrances, exits)
at important locations like techpoints or hive or double RT. (the only bot that used this was the old wichbot from ns1 and it was pretty good at it)
Build Clog:
According to the devs there were problems with the bots because they couldn't recognize them as obstacles and got stuck on them, but maybe you could use it in the Marine base to make the phasegate inaccessible etc... or they could use it to close off entire areas like Nanogrid Double RT etc if they could recognize them as obstacles.
Build Hydra:
Hydras are often dropped at double RTs or at important locations like the hive I believe. The problem is that they need to be in a good position where they can surprise you first. You could also do it like the marines with the mines, only limit the hydras to 3 per gorge. 2 or 3 for harvester, hive, tunnel...
Maybe a priority for certain areas or structures when they are captured or available, like the original tunnel drop at safe TP. (neutral tech points or harvesters if no double res available, 2 hydras per gorge to a single harvester???? is that effective then????)
I hope that helps a bit.
it's seems to be fixed now with your construction logic!
I simply combined the methods from my code and yours and now the com can build in hydroanalysis or wherever else.
copy and paste and of course test it!
local function GetBuildPositionAtTechPoint(com, senses, techId, preReq)
local team = com:GetTeamNumber()
local buildClass = kTechId[techId]
local techPoints = senses:Get("safeTechPoints")
for _, techPoint in ipairs(techPoints) do
local locationId = techPoint:GetLocationId()
if (not preReq or IsBuildingInLocation(preReq, locationId, team))
and not IsBuildingInLocation(buildClass, locationId, team) then
if techId == kTechId.CommandStation then
return techPoint:GetOrigin()
end
-- Erweiterung der Positionsbestimmung für mehr Flexibilität
local buildPos = GetRandomBuildPosition(techId, techPoint:GetOrigin(), kMaxBuildDistance)
-- Wenn keine Position gefunden wurde, erweitern wir die Suche innerhalb des Radius
if not buildPos then
for radius = 1, kMaxBuildDistance, 1 do
for angle = 0, 2 * math.pi, math.pi / 32 do
local xOffset = radius * math.cos(angle)
local zOffset = radius * math.sin(angle)
local tryPos = Vector(techPoint:GetOrigin().x + xOffset, techPoint:GetOrigin().y, techPoint:GetOrigin().z + zOffset)
buildPos = GetRandomBuildPosition(techId, tryPos, 1)
if buildPos then
return buildPos
end
end
end
end
if buildPos then
return buildPos
end
end
end
return nil
end
Is that the problem when he tries to retreat and flies up and down? If he gets too frantic does he fly to the ceiling or spin in circles????
BotMotion.lua 576
-- gentle up/down gliding flight pattern
local height = 1.3 + (math.sin(now * 1.45) + math.cos(now * 2.15)) * 0.45
desiredHeight = heightMean + height
end
maybe you understand these lines better.
Well I just found out the hard way that ARC turrets don't set off bile mines. But at least I got them working. I'm going to have a shot at webs, do some testing and polish then release an update. Shouldn't take much longer than a week.
It's possible to augment the existing pathing, but not redevelop it because many functions are implemented in C++. I do however think vents are possible, but it's not going to be easy. I also have an idea in my head for getting bots out of stuck positions like double in ns2_tanith. I think obstacle hopping (double in ns2_veil) is definitely possible. I also think giving Lerks full freedom of flight is possible.
I'll look into the obs count, that would've been a change I made way back in October so I can't remember. IMO the tech limit is annoying and I wish they never added it, or at least made it a bit higher. NS1 had far less building restrictions. I miss Gorge vent shacks.
As for building positions, I've completely lost patience with UWE's GetRandomBuildPosition function because it breaks on maps with any kind of height variation. Turns out a circular search on non-flat ground doesn't work very well.
The completely revised nav system will probably never work, but it's good that you still have ideas and the skills. One of my suggestions would have been, if the improved navmesh doesn't work, then to integrate separate waypoints that the bots can use in certain situations, e.g. when they go into vents or fall, etc. so that they can get out again without any major problems. The waypoints could, for example, be dropped and displayed directly on the map via a menu or console, as in the old NS 1 bot times (Wichbot, RCBot). In doing so, you have to take the bot's perception of the old navmesh into account, which could possibly lead to misleading results if they check both at the same time. Another idea would be if they fall or walk into pits or vents, they are teleported to the nearest free space on the mesh or straight back to a base before you could kill them with a code after 4 seconds if, for example, they cannot move or move further than a radius of 10.
I haven't noticed the circular search and crashes yet, maybe I play the same maps too often... In any case, it works relatively well for me with your construction logic. I have had crashes, but only shortly after loading the map for the first time, and the second time it worked without any problems. And if circular doesn't work then square or cluster etc... You've already managed that well, I only noticed the construction bug with NS2_Descent.
I wish you the best of luck in fixing the complications and maybe we'll have one or two more ideas for such tough nuts to crack.