It probably uses "item_get_type". The types are listed in "header_items.py" and you can get item nos from "ID_items.py".Bridge_Troll said:
WSE - Lua edition [Beta], a new way of scripting
- Thread starter AgentSmith
- Start date
Users who are viewing this thread
No item shares the same id with another.Bridge_Troll said:
The engine automatically decides which armor slot should be used.
Ye, but it didn't show any ids for these items. Was tinkering around a bit and found them. Was junst printing the parts of the player slots that had no item at spawn and got the ids for them, it's 1 to 4 for PW._Sebastian_ said:
No time to waste, next question 
game.addPrsnt seems to be not defined anywhere. I don't know what to do there. I included all the common headers, but no where I am able to find the function addPrsnt.
game.addPrsnt seems to be not defined anywhere. I don't know what to do there. I included all the common headers, but no where I am able to find the function addPrsnt.
Silly question, but you're running this on client yes?Bridge_Troll said:No time to waste, next question
game.addPrsnt seems to be not defined anywhere. I don't know what to do there. I included all the common headers, but no where I am able to find the function addPrsnt.
Ah, no, it was server side.
Bridge_Troll said:
To be fair, it's not in the docu.
Hey, me again.
Got a small problem with the on_agent_killed_or_wounded trigger. Seems as if it always returns -1 for the Agent and the KillerAgent.
I add the trigger by doing this:
AgentID and KillerAgentID are always -1 for some reason, not sure why tho.
Got a small problem with the on_agent_killed_or_wounded trigger. Seems as if it always returns -1 for the Agent and the KillerAgent.
I add the trigger by doing this:
Code:
function onDeath()
--trigger param 1: dead agent id
--trigger param 2: killer agent id
--trigger param 3: 0 = killed, 1 = wounded
--trigger result: 1 = force kill, 2 = force wounded
local AgentID = getTriggerParam(1);
local KillerAgentID = getTriggerParam(2);
local action = getTriggerParam(3);
print("@Trigger: agentid "..AgentID);
print("@Trigger: agentid "..KillerAgentID);
return true;
end
game.addTrigger("mst_conquest", game.const.ti_on_agent_killed_or_wounded, 0, 0, onDeath);Bridge_Troll said:
Hi,
I don't know either, code seems fine. Check if "game.const.ti_on_agent_killed_or_wounded" has the correct value, check if "getTriggerParam" does its thing...
If nothing works, upload your code (native compatible) and I'll have a look.
Btw, you don't need "@" in your strings. Such barbarism is only for MS.
This is literally everything in my main.lua right now:
The console displays -1 -1 0
The trigger id is -26.0 which according to header_triggers.py is fine.
Would be nice if you could test it with the native module, might be that it is because of Persistent World, as you might remember had some trouble adding WSE in the beginning. There might still be errors somewhere in my header files.
Also just to clarify what I try to archive, I try to remove armor from players that have spawned after being killed. So I would actually need to know which player died previously to being spawned again on the server.
Code:
function onDeath()
--trigger param 1: dead agent id
--trigger param 2: killer agent id
--trigger param 3: 0 = killed, 1 = wounded
--trigger result: 1 = force kill, 2 = force wounded
local AgentID = game.store_trigger_param(0,1);
local KillerAgentID = game.store_trigger_param(0,2);
local action = game.store_trigger_param(0,3);
print("Trigger param1: "..AgentID);
print("Trigger param2: "..KillerAgentID);
print("Trigger param3: "..action);
--If player was killed, add him to the kill list
if ( action == 0 ) then
--print(AgentID.." died by "..KillerAgentID )
--RespawnCtr:addKilledPlayer(AgentID);
end
return true;
end
game.addTrigger("mst_conquest", game.const.ti_on_agent_killed_or_wounded, 0, 0, onDeath);The trigger id is -26.0 which according to header_triggers.py is fine.
Would be nice if you could test it with the native module, might be that it is because of Persistent World, as you might remember had some trouble adding WSE in the beginning. There might still be errors somewhere in my header files.
Also just to clarify what I try to archive, I try to remove armor from players that have spawned after being killed. So I would actually need to know which player died previously to being spawned again on the server.
I had that thought for a moment, yes, however at the moment the trigger actual fires, these variables have to be set, since it can only be fired if there already is a spawned agent that gets hit, at least that seems logical too me. I am currently checking other triggers, but they seem to work fine.Muzzle C said:
I tested it and it works just fine. Maybe there's something wrong with your operations header?
Damn, alright there is one thing I remembered while talking to a friend of mine just now who just installed it as well.AgentSmith said:
Code:
Change the following (line 432):
=============================================
if (opcode in [try_begin,
try_for_range,
try_for_range_backwards,
try_for_parties,
try_for_agents]):
=============================================
to
=============================================
if (opcode in [try_begin,
try_for_range,
try_for_range_backwards,
try_for_parties,
try_for_agents,
try_for_prop_instances,
try_for_players,
try_for_dict_keys,
]):
=============================================In the PW module there is no line 432. So I left this out. This might cause some internal error which reaches to this trigger since some loops are not defined/handled incorrectly? Not sure where to add it tho, I'll have to go through the whole module.
Edit:
the save_statement_block function is no present in PW, just checked it with the Native MS
I don't get why you don't just use the normal native + wse operations header. Seems like that would avoid a lot of trouble
I am about to give up. All operations work fine and all triggers are working just right, except the ti_on_agent_killed_or_wounded. Even stranger is, that it seems to still correctly recognize whether you've died or not. But the AgentID's are lost somewhere.AgentSmith said:I don't get why you don't just use the normal native + wse operations header. Seems like that would avoid a lot of trouble
Well, back to normal MS then. Just added the lua_call in the mission_templates and let it call a function on the trigger, which works fine now. Bit of a workaround, but ye.
Was about to ask if it works in MS. Weird...Bridge_Troll said:
I don't know either. I added this to the trigger in the module systemAgentSmith said:
Code:
(lua_push_int,":dead_agent_id"),
(lua_push_int,":killer_agent_id"),
(lua_push_int,":killed_or_wounded"),
(lua_call,"@onDeath",3),
Hi, hope this is not aggravated necromancy. Amazing tool, i'm learning LUA on the fly so there might be a few stupid questions.
Q1: How do I reload the LUA scripts at runtime?
Q2: How does WSE handle the LUA files? Does it just load everything there is into the '/lua' folder?
Q3: I get alot of warnings reading from the headers files added to the 'msfiles' directory. Mainly from header_triggers and header_mission_templates, is this normal? (I'm using legacy WSE, not WSE2)
Bonus: This one is just me trying to a get a second opinion and advice since it seems like there's experienced LUA coders around, I coded a Behaviour Tree like structure for the AI using the module system (with sequence and selectors). I'd like to reimplement this using LUA (and hopefully distribute it to the community), in the module system version I used troop instances' slots as placeholder objects for storing different states & sequences of actions (common modsys trickery), to reimplement this in LUA, I think the easiest way would be to assign those 'troop' states script to LUA scripts and keeping the basic FNS machine in modulesys(for now), to do that I'd need to assign each of them to a LUA file or functions, the problem is it seems like you call LUA scripts from a string while troop slots are really just reference to integers. So either I set my troop name strings to the corresponding LUA file directly (kinda oblique) or there's perhaps a way to convert a string reference to LUA scripts to an integer value that WSE can read, or anyone that cares to grasp my issue has another idea (I'll post the code if anyone's curious)
At any rate, i'm (lately) feeling good about the simple fact I can do a 3 operands math operation on a single line with only one variable assignement.
Q1: How do I reload the LUA scripts at runtime?
Q2: How does WSE handle the LUA files? Does it just load everything there is into the '/lua' folder?
Q3: I get alot of warnings reading from the headers files added to the 'msfiles' directory. Mainly from header_triggers and header_mission_templates, is this normal? (I'm using legacy WSE, not WSE2)
Bonus: This one is just me trying to a get a second opinion and advice since it seems like there's experienced LUA coders around, I coded a Behaviour Tree like structure for the AI using the module system (with sequence and selectors). I'd like to reimplement this using LUA (and hopefully distribute it to the community), in the module system version I used troop instances' slots as placeholder objects for storing different states & sequences of actions (common modsys trickery), to reimplement this in LUA, I think the easiest way would be to assign those 'troop' states script to LUA scripts and keeping the basic FNS machine in modulesys(for now), to do that I'd need to assign each of them to a LUA file or functions, the problem is it seems like you call LUA scripts from a string while troop slots are really just reference to integers. So either I set my troop name strings to the corresponding LUA file directly (kinda oblique) or there's perhaps a way to convert a string reference to LUA scripts to an integer value that WSE can read, or anyone that cares to grasp my issue has another idea (I'll post the code if anyone's curious)
At any rate, i'm (lately) feeling good about the simple fact I can do a 3 operands math operation on a single line with only one variable assignement.
