Jump to content

2.5.6 Mission Editor and Scripting changes not in changelog


Grimes

Recommended Posts

It appears these items haven't been added to the changelog, so I might as well make a post.

 

 

Additions:

Cows. Found in static objects>Animals.

Submarines can now submerge! There is now a depth parameter for ship groups. For the scripting engine waypoints this value corresponds with altitude.

Trigger/Script to set internal cargo on a select unit. Tested and works in MP on clients. You can now virtually carry objects and have their mass impact the aircraft. It also works on airplanes and it at least goes up to 1 million KG!

 

 

Scripting Engine Events:

 

Kill: Detailed kill information on the death of a unit.

Unit_lost: Yeah I have no idea actually. It occurs at the same time as dead and kill, and contains exactly the same data as dead but with a different id. Maybe they played a bunch of Command and Conquer and named an event after a common phrase from the game?

Landing_after_ejection: Returns the static object of ejected pilots and the aircraft they ejected from so you can know where they land!

 

 

And a change to the mission task that is a workaround fix to a longstanding bug. Basically you know how AI wouldn't do the correct waypoint type or RTB to the correct base that you assigned when you assign a new mission task after the AI spawn? Yeah apparently the game needs to know that you are assigning it to an aircraft group, they can't automate the workaround so we have to add a parameter to the tasking.

 

Mission = { 
 id = 'Mission', 
 params = { 
   airborne = boolean,
   route = { 
     points = {
       --- etc

 

There are other scripting engine additions that are more or less dormant or incomplete for now. I'll add some to the wiki, but not all based on the current functionality in game.

 

 

EDIT:

 

Misc Other changes:

Creating a group now defaults the active button to "edit" instead of "add" for the waypoints. This will likely throw off your muscle memory of placing object.

There are changes to the text display box. It appears to no longer be constrained by an arbitrary height limit. Also if multiple messages are visible that cuts off the text it may scroll the text up to view it all.

 

EDIT 2

 

Day/night and moon cycles adjusted to be more accurate.

Default mission date changed from June 1st to June 21. Night should be full moon on this date.

 

EDIT 3. Because I keep remembering stuff edition.

 

With the starting waypoint of "take-off from ramp" and "take-off from ramp hot" the choice of parking location is now disabled and UI element is removed when starting on ships. You can only select starting location with take-off from runway on ships. This is sorta how it worked before anyway because ramp spawns are automatically done on ships.


Edited by Grimes

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

Were there changes to any advanced waypoint actions in 2.5.6?

 

I ran a mission that had an armored group with an advanced waypoint do a Perform Task: Hold, and now it moves ahead right away (Enable Task is checked), whereas before this update, the column stayed put (type: custom). The Condition is: Probability: 100%, and the Stop Condition is: Is User Flag: 3 is checked.

 

Is there anything different we need to do to hold/prevent movement now?

Link to comment
Share on other sites

Thanks for the info.

 
 

Alienware New Aurora R15 | Windows® 11 Home Premium | 64bit, 13thGen Intel(R) Core(TM) i9 13900KF(24-Core, 68MB|  NVIDIA(R) GeForce RTX(TM) 4090, 24GB GDDR6X | 1 X 2TB SSD, 1X 1TB SSD | 64GB, 2x32GB, DDR5, 4800MHz | 1350W PSU, Alienware Cryo-tech (TM) Edition CPU Liquid Cooling  power supply | G2 Rverb VR

Link to comment
Share on other sites

world.getAirbases()

 

Hi,

 

with 2.5.6, scripting function world.getAirbases now returns a list :

for _id, _current in pairs(world.getAirbases()) do
-- _current is an Airbase but id management for airbases is changed in 2.5.6 (see below)

end

 

 

Ok I understood....

First modification : See my post below, _id on evrery maps except Caucacus where 11 must be added to have airdromeId

Second modification : now ship's airbase id is string not number like in previous version, and now uses helipadId not airdromeId when plane orhelo starts on it. But for a ship, the unit ID is number but the same value the the value in the string ID for airbase ID -> so for Stennis by example, it's airbase Id is string (ex '70') and it's unit id is number (70)... not simple

Third modification : helipadId is always number, not string like in previous version


Edited by sunski34
Link to comment
Share on other sites

that is a mess. previous ID could relate to warehouses.lua id file. Now it don't Since warehouses.lua hasn't "airbase name" parameter, now I'm blind trying to see which variable I can use to match stores in warehouses.lua with the placeId that you can get with S_EVENT_TAKEOFF or S_EVENT_ENGINE_SHUTDOWN.

 

and it's not a simple math thing..

i.e.

in warehouses.lua Beslan is n° 32. In unitID is 42. in airbaseID is 5000042.

But in warehouses lua, airports starts from 12

 

 

 

If someone has suggestion...


Edited by chromium

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

Ok after severals tries,

 

for _id, _current in pairs(world.getAirbases()) do
-- _current is an Airbase but id management for airbases is changed in 2.5.6 (see below)

end

 

_id is used for airdromeId in all maps except caucasus when plane start from map airbase.

In caucasus, you have to add 11 to that _id to have the airdromeId

 

So I suspect a bug on Caucasus map.

Link to comment
Share on other sites

Thanks. trying to fix the four new Events in MOOSE. As the days go by we can leverage some of these changes, the static one is helpful, preparation for paratroopers and so many things.

 

The Tasking change.... I dunno how many years we have worked around RTB by respawning aircraft that its likely in so much code already I dont know if we can leverage it much :/

 

There's a lot of possible rewriting available.

 

For the Airbase ID thing, I didnt really understand what you said @sunski34

___________________________________________________________________________

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

Link to comment
Share on other sites

@Pikey,

 

When an aircraft starts from a map's airbase, its WP 1 has airdromeId entry set to an airbase ID.

 

With the V2.5.5 , airbase:getID() returns the same value then airdromeId. That is not the case with 2.5.6.

 

Now airdromeId corresponds to the index of the table returned by world.getAirbases() for all maps except caucasus where you must add 11 (why, bug suspected) . Try you will see.

 

No change for Helipad

 

But for units (Ships) type this is different :

airbase:getID() (Airbase class) for ships returns its ID in a string var.

unit:getID() (Unit class) for ships still returns its ID but in a number var.

 

And now when starting from a ship, ex a F18, its WP 1 don't have its airdromeId entry set but its helipadId entry.

 

Hope it's more clear.


Edited by sunski34
Link to comment
Share on other sites

@Pikey,

 

When an aircraft starts from a map's airbase, its WP 1 has airdromeId entry set to an airbase ID.

 

With the V2.5.5 , airbase:getID() returns the same value then airdromeId. That is not the case with 2.5.6.

 

Now airdromeId corresponds to the index of the table returned by world.getAirbases() for all maps except caucasus where you must add 11 (why, bug suspected) . Try you will see.

 

No change for Helipad

 

But for units (Ships) type this is different :

airbase:getID() (Airbase class) for ships returns its ID in a string var.

unit:getID() (Unit class) for ships still returns its ID but in a number var.

 

And now when starting from a ship, ex a F18, its WP 1 don't have its airdromeId entry set but its helipadId entry.

 

Hope it's more clear.

Thanks for the clear explanation SUnski! It is very much appreciated. I/we need to go through moose code and consider the imapct asessment now. Goign to be painful I think.

___________________________________________________________________________

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

Link to comment
Share on other sites

Were there changes to any advanced waypoint actions in 2.5.6?

 

I ran a mission that had an armored group with an advanced waypoint do a Perform Task: Hold, and now it moves ahead right away (Enable Task is checked), whereas before this update, the column stayed put (type: custom). The Condition is: Probability: 100%, and the Stop Condition is: Is User Flag: 3 is checked.

 

Is there anything different we need to do to hold/prevent movement now?

 

this feature is not busted in the new update. Hold at WP doesn't work. I bugged it. Ruined most of my missions

Paco

Link to comment
Share on other sites

Sorry, typo......this feature is indeed broken in the new update. No hold function for WP's.

 

Thanks Paco, at least it confirms what I have observed. Not sure if anyone has added it to the bug list. Edit - I saw your post Paco in the DCSW 2.5 bugs and problems page and posted there to back you up; thanks for posting it.

 

Oh, and thanks Grimes for the added info you shared in the original post.


Edited by 609_Relentov
Link to comment
Share on other sites

The Event.id's have all changed for events and MOOSE's EventMeta turned to nil in 2.5.6. Which killed umm... most of moose stone dead.

 

 

Trying to recorrect. Why were the id's all shuffled, it's madness, it killed most of the moose servers?! :)

___________________________________________________________________________

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

Link to comment
Share on other sites

The Event.id's have all changed for events and MOOSE's EventMeta turned to nil in 2.5.6. Which killed umm... most of moose stone dead.

 

 

Trying to recorrect. Why were the id's all shuffled, it's madness, it killed most of the moose servers?! :)

 

there it is, the ****ening, been a minute since the SE was toyed with this hard

Link to comment
Share on other sites

Hi Pikey,

 

 

The Event.id's have all changed for events

 

What do you mean ? only event.id values have changed or there are more changes and in that case, what kind of changes ?

 

Hope it's not too important. I use the enumerator event's id.

 

Thanks in advance.

Link to comment
Share on other sites

i.e. use

if event.id == world.event.S_EVENT_ENGINE_SHUTDOWN then

instead of

if event.id == 18 then

that is safer...

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

@Pikey,

 

When an aircraft starts from a map's airbase, its WP 1 has airdromeId entry set to an airbase ID.

 

With the V2.5.5 , airbase:getID() returns the same value then airdromeId. That is not the case with 2.5.6.

 

Now airdromeId corresponds to the index of the table returned by world.getAirbases() for all maps except caucasus where you must add 11 (why, bug suspected) . Try you will see.

 

No change for Helipad

 

But for units (Ships) type this is different :

airbase:getID() (Airbase class) for ships returns its ID in a string var.

unit:getID() (Unit class) for ships still returns its ID but in a number var.

 

And now when starting from a ship, ex a F18, its WP 1 don't have its airdromeId entry set but its helipadId entry.

 

Hope it's more clear.

 

confirmed for airbases on caucasus, I had to do this trick (I hope temporary):

 

function EMBD.getAptInfo()
local apt_Table = world.getAirbases()
for Aid, Adata in pairs(apt_Table) do
	local aptInfo = Adata:getDesc()
	local aptName = Adata:getName()
	local aptID	  = Adata:getID()
	local indexId = Aid
	if env.mission.theatre == "Caucasus" then
		indexId = indexId +11			
		if debugProcessDetail == true then
			env.info(("EMBD.getAptInfo added 11 to airport index due to Caucasus scenery, from: " .. tostring(Aid) .. " to: " .. tostring(indexId)))
		end				
	end	
	tblAirbases[#tblAirbases+1] = {id = aptID, index = indexId, name = aptName, desc = aptInfo}
end
end

ChromiumDis.png

Author of DSMC, mod to enable scenario persistency and save updated miz file

Stable version & site: https://dsmcfordcs.wordpress.com/

Openbeta: https://github.com/Chromium18/DSMC

 

The thing is, helicopters are different from planes. An airplane by it's nature wants to fly, and if not interfered with too strongly by unusual events or by a deliberately incompetent pilot, it will fly. A helicopter does not want to fly. It is maintained in the air by a variety of forces in opposition to each other, and if there is any disturbance in this delicate balance the helicopter stops flying; immediately and disastrously.

Link to comment
Share on other sites

  • Recently Browsing   0 members

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