Mateos

You can remove these in OnMapLoad and manually recreate them in-game through the console, using /bot goal_setproperty for all custom required properties

If you don't script any restriction, it's the same for all bots

First problem: https://mygamingtalk.com/wiki/Paththrough_UseSwitch Other problem: You'll probably have 2 CAPPOINT goals, just have 1 enabled for Axis and 1 for Allies

Yes, that's the best solution, so it's bound to the goal and not the bot using it, far better ^^ Thank you again!

Thank you very much! ^^ It seems the forum's account can't be used to login to the Wiki, and creating new accounts seems disabled; is it possible to either get an account or that you add that documentation to the mortar page? ^^" Edit: Just realized this will suspend ALL mortar shooting, just not one btw ^^" This perhaps should be something like this.Bot.DontShootMortar?

Waypoint Commands - MyGamingTalk

Nice! Do you think this is something that could be added in OB, so it's available to all? I don't think other weapon goals (especially large radius, explosive-kind weapons) would benefit from that (a simple make unavailable is fine, for e. g. airstrike/arty), so that they would do something else Only the mortar has that deployment requirement, with large radius/damage

Good morning, I have scripted a system which automatically tracks a vehicle movement to adjust mortar targeting all along When the vehicle is at a destructible like a barrier, and that destructible gets planted, I'd like the mortar bot to stop shooting, but keep its goal (so stay crouched and deployed), until everything is either defused or destroyed I've looked at the dontshoot command to see if I could use that; I see there's a Shooting Disabled flag Is is a right way to go? If so, how can I set/unset that flag through script? Thank you in advance Regards Mateos

From what I see from the GitHub repository, these goals are limited to Soldiers, and have a changed priority, which may change how goals are done by bots omni-bot/0.83/Installer/Files/rtcw/nav/final_deathwish.gm at stable · jswigart/omni-bot (github.com) Even the flag is limited to Soldiers, weird... Comment-out the limits and check ingame if other goals have higher priority Else handle that with roles

Hello, It just came to my attention Legacy mod now has some news weapons, and it's not yet handled in et_weapontables.gm ^^" From the changelog: Added new MP34 weapon for axis covert ops instead of Sten Added allied bazooka weapon Added the KA-BAR weapon for allies Added the Browning MG weapon for allied soldiers (KA-BAR is a knife) Is this already handled by the WEAPON constants, and simply adding lines in the script will do, or does it take some mapping elsewhere? Thank you in advance Regards, Mateos

Due to attachment file size limit and post edit delay limit, an other post with original shader and r_wolffog 0/1

For future reference; Suspected that, couldn't get it working yesterday, found why and got it working now, just like custom .script In the case of that map, faulty shader is textures/marko/fog_crypt in marko_fog.shader The file has to be extracted in a script sub-folder in OB mod folder (not etmain! was why I couldn't get it working) and modified, and the game run with sv_pure 0, in order to load the file outside a PK3 (or have a z_xxx.pk3 containing the file in etmain I guess) Commented out fog-related and texture-related instructions about fog in sub-sections Like this: textures/marko/fog_crypt { qer_editorimage textures/marko/fog_grey1.tga surfaceparm trans surfaceparm nonsolid // surfaceparm fog // Commented out surfaceparm nolightmap q3map_globaltexture q3map_surfacelight 1 // fogparms ( .15 .15 .17 ) 768 // Already commented out // fogparms ( .2 .2 .2 ) 384 // Commented out // fogparms ( .5 .5 .5 ) 128 // Already commented out { //map textures/marko/kc_fogcloud3.tga // Commented out blendfunc gl_dst_color gl_zero tcmod scale -.05 -.05 tcmod scroll .01 -.01 rgbgen identity } { //map textures/marko/kc_fogcloud3.tga // Commented out blendfunc gl_dst_color gl_zero tcmod scale .05 .05 tcmod scroll .01 -.01 rgbgen identity } } Works now!

Hello, I'm starting to make waypoints for the following map, which has fog on most of the ground: Wolffiles.de - your filebase Very quickly, the waypoints fade, so I turned off fog, which helped on all surfaces affected by it, excepted the waypoint nodes themselves ^^' What can I do to have them rendered like normal in that kind of map setting? Thank you in advance Regards, Mateos

Good morning, Is the GameId number, used to query entities, the one only given by /entitylist, or can it be from an other source/reference, like ent->s.number? I ask this question because Legacy loops through the entities in a different order, which would then break some scripts ^^" ent->s.number is the same between 2.60b and Legacy, if that's reachable to use Thanks in advance Regards, Mateos

Oh, a timing issue Alright, thank you for the explanation ^^

Good evening, Just witnessed something quite weird with a switch in V1 Rocket, only with silEnT, only with a least a bot in-game... There's a trigger called rocdoor_Moving, fired when you press a switch to open/close the room where you grab the rocket fuel, in the last map area This trigger is fired during map start, only under silEnT, only when a bot is in-game (tested with the Axis team) If yourself you jointed Axis, but no bot, no trigger; all this doesn't happen with OB mod I've noticed that on an online server, and was able to reproduce that locally; narrowed it down easily, because there's a single location where the Axis have that availability managed, and adding a MapDebugPrint revealed it (printed before OnMapLoad one btw) What kind of madness is this? After that MLB Egypt weird thingy some months ago Map download: Wolffiles.de - your filebase

Thank you very much! Ah yes, with the worldspace the entity orientation is taken into account, so it remains on the Y axis, noice

Good afternoon, I've wrote a little system to adjust MOBILEMORTAR target/orientation to track a MOVER, based on mapgoal_mobilemortar.gm SetProperty callback handling target case (basically replaced player position by MOVER origin), in a thread looping until the given MOBILEMORTAR goal gets unavailable, initially sleep 3 seconds because you'll still hit the vehicle that moved during this interval It works well until the bot runs out of charge, after which it seems to adjust after having shot, but not right before shooting the next one, thus shooting behind the MOVER I think so because lowering the sleep to 0.1 doesn't help (or is it due to some goal refresh timer?) Example of function called in a thread: // TODO Own table + check if target obj has moved, borrow usual EntityDefenceManagement stuff TestThread = function() { tstAxisMortar = GetGoal( "MOBILEMORTAR_AxisAlphaTest" ); tank = GetGoal( "MOVER_tank" ); while ( tstAxisMortar.IsAvailable( TEAM.AXIS ) ) { tbl = CalcTrajectory( tstAxisMortar.GetPosition() + Vector3( 0,0,32 ), tank.GetPosition(), 2350, 1 ); if ( !tbl ) { Util.MapDebugPrint( "^8Mortar trajectory not found for target " + tank.GetName() + " " + ToString( tank.GetPosition() ), true ); } else { dir = tbl[ tableCount( tbl ) - 1 ]; playerFace = Vec3FromSpherical( dir.GetYaw(), dir.GetPitch() - DegToRad( 60 ) ); tstAxisMortar.MortarAim[ 0 ] = playerFace; //Util.MapDebugPrint( tstAxisMortar.GetName() + " aim set to " + ToString( playerFace ), true ); tstAxisMortar.AdjustOrientation(); } sleep( .1 ); } Util.MapDebugPrint( "Exiting Mortar aim management thread", true ); } Tried that on the following map: Wolffiles.de - your filebase Attached the WIP waypoints to try that out directly Do you think I'm doing this right/this is a right thing to do? --- I'm planning on trying to determine the MOVER direction to move an ARTILLERY_S goal to stay in front of it, so there's a single goal that gets adjusted on its own all along There's just an origin for the MOVER and splines aren't readable, what do you think? --- Thanks in advance Regards, Mateos Christmas Hills Beta - Mortar tracking system test.zip

Thank you very much, going to handle it like this

Good evening, I've just refreshed old waypoints I was asked for years ago for Missing in Action v1: Wolffiles.de - your filebase The main objective is to pick up 3 MIAs being held in bamboo cages It requires precise positioning and aiming (stance, as crouch, helps a lot, but isn't required) When Allied bots have Axis enemies in sight, they'll do combat movement (but seem to keep the highly prioritized aiming, thus not engaging shooting, so that's fine to my mind), breaking that precision scripted in related path through navigation tables Is it possible to disable CM like for ATTACK/CAMP/DEFEND spots through script? Can it be re-enabled automatically upon exiting, or will it require an instruction in OnExit table? Thanks in advance Regards, Mateos

With that very map flow it will work yes, no need to look further then Ah like region triggers, oki Thank you!

Good evening, I just saw Neutral Barricades on Marrakech Streets 2 By Night Final, where the BUILD offset could be different for both teams, to have the Engis safe behind the crates Download in case: Wolffiles.de - your filebase Currently, the position (no offset [yet]) is exposed for both teams - Edit: or is it Use Point the correct feature I'm talking about? I don't think that can be handled with the current scripting possibilities? Would that be worth implementing? Regards, Mateos --- Extra question You can do mapGoal.AddUsePoint through script, but can this be done in-game through a console command?

Oh right it's upon saving that they're converted to 0.9 format, the version serializers are all there to read and load Someone from ETS clan at the least So no need for a tool or script, perfect, thank you! Edit: I was unsure because, in the past, I did recompile and replace a single library, and then it went broke, because I was missing the newly added 0.9 serializer in an other lib I guess...

Good afternoon, Is there a script or tool available to automatically convert 0.8x WAY files to 0.9 file format? Some people made navigational waypoints outside SVN for maps not having any over there, and now they're stuck ^^" Btw will try to get these files to incomplete_navs to avoid this in the future, if it is OK

Good afternoon, I've noticed that ETUtil.SetExcludeIndexes isn't taken into account by bots for ESCORT goals until they die (even when going for an other goal like REVIVE then going back to ESCORT will not update) You can quickly see it on Ruins of Acquiesce latest waypoints from the SVN repo, there's a MapDebugPrint for related RegionTriggers, and it's working fine for the BUILD one Can someone confirm first? If reproduced, can the behaviour be aligned with the BUILD one? Thank you in advance Regards, Mateos