Jump to content

Known Scripting Engine Issues


Grimes

Recommended Posts

Partly reproduced on the tester version. Clients were producing the event but the player name was blank. I've reported it.

 

Interesting, I am not getting the event at all from clients.

 

 

I also noticed that if for instance a Mig-29 is hit by an Aim-7 (all clients), and the mig pilot stays in control of the aircraft, isExist() would return false. I think it should only return that if the unit is either exploded or crashed ... or both. Would make more sense scripting wise.


Edited by 0xDEADBEEF
shortened
Link to comment
Share on other sites

  • 1 month later...

With the 2.0.4 patch and Nevada extension I am pleased to let you guys know that two Nevada specific scripting bugs have been fixed. Don't know why they weren't in the changelog.

 

-AI will now find the nearest road when given on road waypoints. Previously you needed to place an on road waypoint precisely on a road for the AI to follow it.

-world.searchObjects now returns world objects. You can stop counting the number of solar panels by hand now.

 

 

There are 51702 solar panels

 

 

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

  • 4 weeks later...
  • 3 weeks later...

Any estimation on when the 32145 - LUA PREDICATE bug will be solved? Lost quite some time today before finding this...

System specs: Win7 x64 | CPU: i7-4770K | RAM: 16 GB | GPU: GTX 980 Ti 6 GB | Thrustmaster HOTAS | MFG rudder pedals | SATA3 SSD | TrackIR

Link to comment
Share on other sites

Crossposting by design.

This seems different/new...https://forums.eagle.ru/showthread.php?p=3007246#post3007246

Getting huey or Mi8 with this code causes a CTD

local groups = coalition.getGroups(coalition.side.BLUE) for i = 1, #groups do     local units = groups[i]:getUnits() --   <- Will crash if the group has a MI-8 end


Edited by Pikey
formatting

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

The Tor isn't an SA-10, it is an SA-15 :)

 

Just tested it out in 1.5.5. It appears to only return the target from the tracking radar and when the target is actually locked onto and the sam is about to shoot it. In the case of the SA-15 (Tor) the tracking radar and search radar unit are one and the same. The Tor unit itself will turn its tracking radar toward the target and track it, but the target object is still nil. Once it gets in range for a hardlock/shooting, the target is correctly returned. For the SA-10 (S-300) only the tracking radar object returned a target value, and under the same conditions above. I added two targets for it to shoot at, the first target engaged was returned until it was destroyed, then it switched to the second.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Any estimation on when the 32145 - LUA PREDICATE bug will be solved? Lost quite some time today before finding this...

+1 :helpsmilie::doh:

i7-7700K@4.8GHz, 16Gb-3200, GTX-1080Ti-Strix-11Gb, Maximus IX Hero, Oculus Rift, Thrustmaster Warthog+F/A-18C, Logitech G940 Pedals.

Link to comment
Share on other sites

Hello again...

 

so here is my headache. I want to make a script, where... If a unit called "Misty1" which is a sabre aircraft, is advised when it is being tracked by a radar.... So it is a homemade RWR.

 

The problem is as mentioned to you, with a Tor it works perfect, I hear the alarm and I can read the message, but when I use a SAM battery SA3, SA10, etc... I cant make it work.

 

sabres = {'Misty1','Misty2','Misty3','Misty4'}

function checkEWR(samunit)

local UnitObject = Unit.getByName(samunit)
	if UnitObject ~= nil then
	local status, target = UnitObject:getRadar()    -- main function.

		if status == true then 						-- to see if the Radar is working
			if target ~= nil then                   -- to see if it is engaging a target, this seems to be the problem. It works with Tor but not with other battery SAMs with SR, TR and LN units in it.
				local targetname = target:getName()	
					
					for k, v in pairs(sabres) do		-- to see if a  unit from the list "sabre" is detected
					local sabrename = sabres[k]
						if targetname == sabrename then
						local targetID = target:getGroup():getID()
						trigger.action.outSoundForGroup(targetID, "alert.wav")	
						trigger.action.outTextForGroup(targetID, "ALERT SAM!",20)		
						end
					end	
				
			end
			end
	end
timer.scheduleFunction(checkEWR, samunit, timer.getTime() + 8)
end

Link to comment
Share on other sites

Which object is the samunit when using a battery? It has to be the tracking radar in order for you to see a result.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Because the radar value on the tracking radar is returning false even when it is returning a target object. That right there is a bug.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

  • 1 month later...

getPlayerName()

 

Just want to let all know that it seems in a multi-player environment, the Unit:getPlayerName() bug seems to be solved ...

 

This bug caused the Unit:getPlayerName() method to return a nil or an empty string on a Unit containing a logged in player as a client.

 

Now it seems this method is returning correctly a player name.

 

So all good.

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 1 month later...

world.searchObjects()

 

I've searched the forum for this kind of bug. Since in this thread "world.searchObjects()" is called "fixed" at some point i'll post the error i found here ...

 

world.searchObjects() is always returning a nil object as first entry. (So always one Object will be missing ... only exception is if none objects were found ... )

I found this error first some patches ago in the 2.x version. Now it'S in 1.5.x too.

 

I attach a little script to show this behaviour. It works with any kind of "Object.Category".

Well ... in case of "UNIT" you have to place some units in the mission first .. ^^

 

In my script Beslan is missing.

 

Regards,

WW

 

Edit : Well ... that one was from the beginning an error on my side ... wow ... i still have the tendency to start counting at 0! :D


Edited by Wunderwolf
My fault!
Link to comment
Share on other sites

Just want to let all know that it seems in a multi-player environment, the Unit:getPlayerName() bug seems to be solved ...

 

This bug caused the Unit:getPlayerName() method to return a nil or an empty string on a Unit containing a logged in player as a client.

 

Now it seems this method is returning correctly a player name.

 

So all good.

 

 

This problem appeared again ... After this last release...

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 1 month later...
With the 2.0.4 patch and Nevada extension I am pleased to let you guys know that two Nevada specific scripting bugs have been fixed. Don't know why they weren't in the changelog.

 

-AI will now find the nearest road when given on road waypoints. Previously you needed to place an on road waypoint precisely on a road for the AI to follow it.

-world.searchObjects now returns world objects. You can stop counting the number of solar panels by hand now.

 

 

There are 51702 solar panels

 

 

Since this was posted here (in 1.5 sub-thread) i report the re-introduction of this bug here ...

 

'world.searchObjects' doesnt work for Object.Category.SCENERY.

This bug got back into 2.0.5 but i wanted to wait for the 2.1 release.

Unfortunately it's still there. I've added a little script for coordinates in normandy. (The result with correct nevada coordinates is in nevada the same.)

No SCENERY-Objects get returned at all.

In 1.5.x caucasus this still works correctly. (Of course the coordinates has to be correct for the box/sphere ... )

 

Regards,

der Wolf


Edited by Wunderwolf
The one-entry-is-nil error was nonsense!
Link to comment
Share on other sites

  • 7 months later...

where to find tutorials on creating missions by scripting

BlackeyCole 20years usaf

XP-11. Dcs 2.5OB

Acer predator laptop/ i7 7720, 2.4ghz, 32 gb ddr4 ram, 500gb ssd,1tb hdd,nvidia 1080 8gb vram

 

 

New FlightSim Blog at https://blackeysblog.wordpress.com. Go visit it and leave me feedback and or comments so I can make it better. A new post every Friday.

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...