Added: Pull request for "fsensor" and "contrtrol" dedicated control theory OOP

[dvdvideo1234]

Added: "fsensor" as a general environment sensor for obtaining process data
Added: "contrtrol" for creating a OOP process variable controller that can me tuned using various methods

Based on: #59

[dvdvideo1234]

@thegrb93 FYI

Tell me if you need some adjustments. The addon is updated to the latest version from my personal machine. It includes the all recent modifications. You can test it if you like 👍

[thegrb93]

Firstly get rid of all the concatenation in the e2 description file unless there's a really good reason for it. Should be a simple replace-all.

Once I can actually read the functions' descriptions then I can review them.

[dvdvideo1234]

The idea is if something is gonna get changed in the future, it will be an update of only one value.
You can read them here: https://github.com/dvdvideo1234/ControlSystemsE2/wiki

This wiki is automatically generated from the description ;). Every OOP class has a dedicated table. The links are not stored in the description. Only the overhead text.

FSensor: https://github.com/dvdvideo1234/ControlSystemsE2/wiki/FSensor
StControl: https://github.com/dvdvideo1234/ControlSystemsE2/wiki/StControl

[dvdvideo1234]

Exported and replaced to ease you out fsensor_descr.txt and stcontrol_descr.txt. Using this method I can dynamically generate the documentation by adding overhead to the file and compiling it 💃 The line local DSC = E2Helper.Descriptions is a micro-optimization

[thegrb93]

I'd say if you really needed to change anything, a find-replace-all would be just as easy. I'll look at your wiki page for now. My main concern is code bloat i.e. adding functions nobody will ever use and just get in the way, or functions that are just as easy to make inside e2 itself. I'll look tonight.

[Divran]

@thegrb93 keep in mind that this is wire extras, where we don't need to care as much about bloat and such. Still care a little, just not as much as the normal wire repo

[dvdvideo1234]

Done. Just tell me how you like 'em ok ;)

[thegrb93]

That looks better, flash sensor needs a new name though. I had no idea what it was until I read the wiki page. It's Trace structure basically, right? Just call it a Trace structure.

[thegrb93]

Don't do manual collectgarbage()'s

[dvdvideo1234]

Gotta leave them to the game collector then. Is it ok for ftrace, ftracer or sttrace ( Personally I like ftracer, ftrace more. Wanted to be kinda like wire rangers, but with different name. That's why I chose sensor as it is generally not measuring just distance but all sorts of things. Most of the Gmod community is English speaking instead of датчик in Russian/Bulgarian ) ?

I want my repo and the wire code to be the same as the OOP related files are concerned. The description I can generate any time in any format, so it's not big of an issue ;)

[dvdvideo1234]

Removing the collectgarbage calls can be done only by removing the flag from remValue so I will do just that. Thanks !

Edit:
come to think of it if that is the case, then I don't need such check because it will never be used.
if(bCall) then collectgarbage() end

[dvdvideo1234]

That looks better, flash sensor needs a new name though. I had no idea what it was until I read the wiki page. It's Trace structure basically, right? Just call it a Trace structure.

Basically, an OOP wich traces and retrieves trace result. Later you can read every aspect of this trace result. Kinda like ranger data, but not need to calculate positions directions, filters and all that stuff in every E2 tick to create a RD class. My tracer is initialized only once and uses this stuff internally ;)

[thegrb93]

Get rid of outError and outPrint or make them singleplayer only.

[dvdvideo1234]

@thegrb93

What I should replace them with ? print() / error() ?

[thegrb93]

Either nothing or the core print function.

[dvdvideo1234]

How can I output an error then ?

[Divran]

All E2 functions fail silently and/or return a zero equivalent value whenever there's an error. If you call the lua error function you shut down the entire chip, which is something that E2 tries to avoid.
Other E2 functions that can error, and where the error message is important (such as json decode or whatever) always have a "get error" function that you can check after.
There's very very few things in E2 that break this rule, and arguably some of them could also be changed to follow it.

The print function seems fine, but pointless. You're using the standard lua print function, and since E2 runs serverside, the user of the E2 will never see those prints. So for example the dumpConsole function literally does nothing.

[dvdvideo1234]

Can I Leave the print statement then, to be intended for singleplayer?
Could you please tell me what I need to call to print in the console?
Or I just return 0 or nil when something fails and that's it?

[thegrb93]

Look in the debug.lua for how e2 printing works https://github.com/wiremod/wire/blob/master/lua/entities/gmod_wire_expression2/core/debug.lua

[bigdogmat]

Or I just return 0 or nil when something fails and that's it?

Depends on the type, it's whatever you think a good default is for the value. e.g. number = 0, string = "", entity = NULL

Don't return something that isn't of the type

Also I've noticed you make fsensor nil when it's invalid, I'd recommend against that.

[dvdvideo1234]

Thank you @thegrb93 @bigdogmat. I have to test how the different prints behave in my home machine because I want to be able to tell the user that something happened.

[dvdvideo1234]

Ok. I was able to replace every occurrence of fsensor with ftracer because seems more correct that way. The OOP is basically an object that does internal tracing and gathers environment data. I've updated the wiki too. It must correspond to the code.

[dvdvideo1234]

Which of these will be better to replace the printing functions:

1. Wire's Addnotify - The addon will show messages in the notification area, but the chip will not halt
2. Player char print - Output errors in the chat area, which may be skipped by the user if the server relies on chat communication.
3. Player print message - This seems to be a great alternative to (2.) but with more output options.

So far I'd like to use option (1.), but if the chip execution does not stop will be more likely has to be (3.), because the screen will be flooded with hint messages otherwise. What do you guys think ?

[thegrb93]

Chatprint probably.

[dvdvideo1234]

@thegrb93
Hello, the lasted version has been merged. I removed outPrint and outError as you sugested from both classes and replaced them with logStatus which just prints the error messages to various outputs ( def. CHAT ) without halting the E2.

-- sMsg > Message to be printed
-- oSelf > Self reference of the E2
-- nPos > Where to print the message ( HUD_% ). Defaults to chat
local function logStatus(sMsg, oSelf, nPos, ...)
  if(varEnStatus:GetBool()) then
    local nPos = tonumber(nPos) or gtPrintName[gsDefPrint]
    local oPly, oEnt = oSelf.player, oSelf.entity
    local sNam, sEID = oPly:Nick() , tostring(oEnt:EntIndex())
    local sTxt = "E2{"..sEID.."}{"..sNam.."}:ftracer:"..tostring(sMsg)
    oPly:PrintMessage(nPos, sTxt:sub(1, 200))
  end; return ...
end

[thegrb93]

Ok. I'll look again

[dvdvideo1234]

I also updated the line endings to CR-LF ( Windows ) to match the other files

[dvdvideo1234]

Updated the wiki accordingly: https://github.com/dvdvideo1234/ControlSystemsE2/wiki/FTrace

[dvdvideo1234]

@thegrb93 I will be able to tes it today and will show you the example code. Thanks !

[thegrb93]

Ok

[dvdvideo1234]

@thegrb93 Tested and updated with 2 bug fixes. You can find the sample code here:
https://github.com/dvdvideo1234/ControlSystemsE2/tree/master/data/Expression2

[dvdvideo1234]

Hello, @thegrb93, the source is ready to be merged on my side ;)